Firmware versioning best practices II
in [Kernel]
|
From: Luis R. Rodriguez on 19 Feb 2010 21:30 Last year, with the help of the community we at Atheros opened up the first (to my knowledge) firmware for a device driver used on the Linux kernel. The community has been advancing the firmware and making changes and even an alternative driver with more features is being baked. We hadn't dealt with open firmware before and this itself raises a few management questions about the firmware APIs, code revision and general best practices which are likely not documented anywhere. We reviewed this on linux-wireless last year [1] and Pavel Roskin made a good suggestion for model to follow. I still have a few more questions though and wanted a wider review on this. I've documented a summary of what we have discussed and suggested so far here: http://wireless.kernel.org/en/developers/Documentation/firmware-versioning We should still address how drivers should deprecate firmware. Can we deprecate old firmware APIs from drivers on each kernel release? Any other comments or feedback? [1] http://wireless.kernel.org/en/developers/Documentation/firmware-versioning Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Woodhouse on 20 Feb 2010 05:40 On Fri, 2010-02-19 at 18:23 -0800, Luis R. Rodriguez wrote: > Last year, with the help of the community we at Atheros opened up the > first (to my knowledge) firmware for a device driver used on the Linux > kernel. The community has been advancing the firmware and making > changes and even an alternative driver with more features is being > baked. We hadn't dealt with open firmware before and this itself > raises a few management questions about the firmware APIs, code > revision and general best practices which are likely not documented > anywhere. We reviewed this on linux-wireless last year [1] and Pavel > Roskin made a good suggestion for model to follow. I still have a few > more questions though and wanted a wider review on this. > > I've documented a summary of what we have discussed and suggested so far here: > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning > > We should still address how drivers should deprecate firmware. Can we > deprecate old firmware APIs from drivers on each kernel release? Any > other comments or feedback? > > [1] http://wireless.kernel.org/en/developers/Documentation/firmware-versioning > > Luis So far it looks like you've just rewritten a subset of the rules for handling shared library sonames. I wouldn't suggest that including the API version as a _separate_ field from the code version is best practice. Why not just bump the major # of the code version when you change the API, just as we do with shared libraries? That doesn't prevent some people from using foo-$APIVER-$CODEVER if they really have to, of course -- if they have firmware which can be conditionally compiled for both old and new APIs, for example. But I don't think it should be recommended. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Woodhouse on 20 Feb 2010 06:10 On Sat, 2010-02-20 at 12:00 +0100, Johannes Berg wrote: > That doesn't make much sense anyway. If the firmware filename is > foo-$APIVER-$CODEVER every code change would need a corresponding driver > change. If it is just foo-$APIVER then the $CODEVER can be embedded in > the firmware file and printed so you know which code you're using, but > if it doesn't influence the API I don't see why it should be part of the > filename? The idea is that just like with shared libraries, you have a symlink from the 'soname' foo-3.fw to the actual file foo-3-1.4.1.fw. For shared libraries, it's easy to create those symlinks automatically using ldconfig. For firmware that doesn't really work though -- since the soname isn't encoded in the file like it is in ELF libraries. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Berg on 20 Feb 2010 06:10 On Sat, 2010-02-20 at 10:35 +0000, David Woodhouse wrote: > That doesn't prevent some people from using foo-$APIVER-$CODEVER if > they really have to, of course -- if they have firmware which can be > conditionally compiled for both old and new APIs, for example. But I > don't think it should be recommended. That doesn't make much sense anyway. If the firmware filename is foo-$APIVER-$CODEVER every code change would need a corresponding driver change. If it is just foo-$APIVER then the $CODEVER can be embedded in the firmware file and printed so you know which code you're using, but if it doesn't influence the API I don't see why it should be part of the filename? johannes
From: Johannes Berg on 20 Feb 2010 06:20
On Sat, 2010-02-20 at 11:09 +0000, David Woodhouse wrote: > On Sat, 2010-02-20 at 12:00 +0100, Johannes Berg wrote: > > That doesn't make much sense anyway. If the firmware filename is > > foo-$APIVER-$CODEVER every code change would need a corresponding > driver > > change. If it is just foo-$APIVER then the $CODEVER can be embedded > in > > the firmware file and printed so you know which code you're using, > but > > if it doesn't influence the API I don't see why it should be part of > the > > filename? > > The idea is that just like with shared libraries, you have a symlink > from the 'soname' foo-3.fw to the actual file foo-3-1.4.1.fw. Ah ok. I indeed do that manually with iwlwifi firmware :) > For shared libraries, it's easy to create those symlinks automatically > using ldconfig. For firmware that doesn't really work though -- since > the soname isn't encoded in the file like it is in ELF libraries. Right. Though I guess we could come up with a unified firmware wrapper format that the firmware loader can unwrap. johannes |