From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from casper.infradead.org ([85.118.1.10]:39924 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753030Ab0BTKfL (ORCPT ); Sat, 20 Feb 2010 05:35:11 -0500 Subject: Re: Firmware versioning best practices II From: David Woodhouse To: "Luis R. Rodriguez" Cc: linux-kernel@vger.kernel.org, linux-wireless , Marcel Holtmann , Vipin Mehta In-Reply-To: <43e72e891002191823h3245bc0cn7a8745ae77409aa8@mail.gmail.com> References: <43e72e891002191823h3245bc0cn7a8745ae77409aa8@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 20 Feb 2010 10:35:06 +0000 Message-ID: <1266662106.1820.4034.camel@macbook.infradead.org> Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: 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@intel.com Intel Corporation