Firmware versioning best practices II
in [Kernel]
|
From: David Woodhouse on 20 Feb 2010 06:40 On Sat, 2010-02-20 at 12:10 +0100, Johannes Berg wrote: > 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. I suppose we could, but this seems like overkill to me. -- 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: Marcel Holtmann on 21 Feb 2010 05:20 Hi David, > > > > 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. > > I suppose we could, but this seems like overkill to me. I have to agree. This looks like total overkill to me. Just use the $APIVER in the firmware filename. And if someone wants to keep track of more details then they can manually symlink them. Unless we have full control over the source code of every firmware used in the kernel, why bother. It is up to the companies providing them anyway to make sure everything works as expected and the community can't fix it. Regards Marcel -- 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: Luis R. Rodriguez on 22 Feb 2010 14:20 On Sun, Feb 21, 2010 at 2:13 AM, Marcel Holtmann <marcel(a)holtmann.org> wrote: > Hi David, > >> > > > 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. >> >> I suppose we could, but this seems like overkill to me. > > I have to agree. This looks like total overkill to me. > > Just use the $APIVER in the firmware filename. OK -- so what goes into linux-firmware is just the latest foo-$(API) > And if someone wants to > keep track of more details then they can manually symlink them. Well do we want the older foo-$(API)-$(VAR) files in linux-firmware too for those companies/developers wishing to do this? What about deprecating APIs of the firmware based on kernel releases. I see it reasonable to deprecate a firmware API completely for a future kernel release provided you maintain all features and functionality in par. Does that sound reasonable? > Unless we have full control over the source code of every firmware used > in the kernel, why bother. It is up to the companies providing them > anyway to make sure everything works as expected and the community can't > fix it. Well that's exactly it -- we do have access to the code for ar9170 for example, so these details will become more relevant in the future. 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: Marcel Holtmann on 22 Feb 2010 14:30 Hi Luis, > >> > > > 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. > >> > >> I suppose we could, but this seems like overkill to me. > > > > I have to agree. This looks like total overkill to me. > > > > Just use the $APIVER in the firmware filename. > > OK -- so what goes into linux-firmware is just the latest > > foo-$(API) > > > And if someone wants to > > keep track of more details then they can manually symlink them. > > Well do we want the older foo-$(API)-$(VAR) files in linux-firmware > too for those companies/developers wishing to do this? personally I would say no, but for some projects it might make sense. I would just leave this up to the project/driver itself. > What about deprecating APIs of the firmware based on kernel releases. > I see it reasonable to deprecate a firmware API completely for a > future kernel release provided you maintain all features and > functionality in par. Does that sound reasonable? Realistically you have to deprecate firmware versions at some point anyway. So yes, that makes sense. However I would leave this again up to the driver itself and how far the maintainers wanna go in supported older API versions. > > Unless we have full control over the source code of every firmware used > > in the kernel, why bother. It is up to the companies providing them > > anyway to make sure everything works as expected and the community can't > > fix it. > > Well that's exactly it -- we do have access to the code for ar9170 for > example, so these details will become more relevant in the future. That is one of the few exception. However even for ar9170 there has to be release engineering team that creates the binary and uploads it into linux-firmware.git since I don't see the majority of people compiling it from source. And at that point the release engineering needs to test the API compatibility. Regards Marcel -- 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: Luis R. Rodriguez on 22 Feb 2010 16:10 On Mon, Feb 22, 2010 at 11:27 AM, Marcel Holtmann <marcel(a)holtmann.org> wrote: > Hi Luis, > >> >> > > > 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. >> >> >> >> I suppose we could, but this seems like overkill to me. >> > >> > I have to agree. This looks like total overkill to me. >> > >> > Just use the $APIVER in the firmware filename. >> >> OK -- so what goes into linux-firmware is just the latest >> >> foo-$(API) >> >> > And if someone wants to >> > keep track of more details then they can manually symlink them. >> >> Well do we want the older foo-$(API)-$(VAR) files in linux-firmware >> too for those companies/developers wishing to do this? > > personally I would say no, but for some projects it might make sense. I > would just leave this up to the project/driver itself. OK >> What about deprecating APIs of the firmware based on kernel releases. >> I see it reasonable to deprecate a firmware API completely for a >> future kernel release provided you maintain all features and >> functionality in par. Does that sound reasonable? > > Realistically you have to deprecate firmware versions at some point > anyway. So yes, that makes sense. OK > However I would leave this again up to > the driver itself and how far the maintainers wanna go in supported > older API versions. I was looking for general rules and guidelines to document. That includes things to do and things to not do. It sounds we are flexible with what people can do with their firmware and their driver firmware API. The things to not do are not so clear though still. I am wondering specifically about deprecation of older firmware APIs, or are we flexible enough to allow any firmware API rewrite so long as its properly supported? >> > Unless we have full control over the source code of every firmware used >> > in the kernel, why bother. It is up to the companies providing them >> > anyway to make sure everything works as expected and the community can't >> > fix it. >> >> Well that's exactly it -- we do have access to the code for ar9170 for >> example, so these details will become more relevant in the future. > > That is one of the few exception. However even for ar9170 there has to > be release engineering team that creates the binary and uploads it into > linux-firmware.git Release engineering team? Hah. > since I don't see the majority of people compiling it > from source. I am curious how distributions will want to handle this. Distributions with sane people might just ship a gcc built open firmware binary but utopian distributions like Debian might require to build the whole thing for redistribution. I don't know. > And at that point the release engineering needs to test the > API compatibility. Release engineering.. heh... 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/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: [GIT]: Networking Next: git ignore *.builtin generated file |