On Mon, 2014-05-12 at 17:41 +0800, Adam Lee wrote: > > > > > > File: intel/ibt-hw-37.7.bseq > > > > > Version: 1316.02.00 > > > > > File: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq > > > > > -Version: 1344.01.33 > > > > > +Version: auto.WP_1303_02_patch_0.1.54.1 (0x36) > > > > > File: intel/ibt-hw-37.7.10-fw-1.0.2.3.d.bseq > > > > > -Version: 1344.01.33 > > > > > +Version: auto.WP_1303_02_patch_0.1.54.1 (0x36) > > > > [...] > > > > > > > > Why has the version format changed? Are all the different parts actually > > > > significant? > > [...] > > > > That doesn't answer the second question. > > > > I really have a hard time believing that all of 'auto.WP', '1303_02', > > 'patch', '0.1.54.1' and '0x36' are all significant. No-one else seems > > to need more than 4 components in a version number; what's so special > > about this firmware? > > > > And another question: can an outside observer compare version strings > > and get any sense of which is newer? Are the components in the right > > order (most significant first)? > > > > Ben. > > Hi, all > > This firmware also fixes another EHCI HSP/HFP profile not working issue, > could you guys please reach a consensus about the version string and get > it upstreamed? I don't care as much about the version number. Even Ben's question about which is newer isn't that interesting to me. With closed-source firmware you never know that newer is *better*, and you often end up deliberately staying on old versions. I'm more bothered by all the crap in the filename. That ought to be considered equivalent to the soname in a dynamically linked library — it specifies the ABI (and the specific hardware). And it looks like the *filename* has more version-cruft in it than it should have. But that's a separate issue and it isn't being changed in this patch. It should ideally have been caught when the file was originally added. -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
