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@xxxxxxxxx Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
