IRC Log of firmware discussion

Just a quick copy-and-paste of an IRC discussion about our current
firmware file locations and names.

General outcome:

Our current firmware locatin is /lib/hotplug/firmware/$FIRMWARE-$VERSION
where $FIRMWARE is the firmware file name being requested, and $VERSION is
the kernel version.

Because of udev, we already have to move to the commonly used location of
/lib/firmware. After discussion, we decided to ultimately move to this
naming scheme:

/lib/firmware/$VERSION/$FIRMWARE

Packages known affected are the kernel(BenC) and
linux-restricted-modules(infinity) and hotplug(Keybuk).


Oh, and read the last ten lines or so. There's atleast a few quotables in
there :0



------ IRC LOG ------
Keybuk howdy
BenC Keybuk: can you tell me what I need to be aware of, or need to help with in order to get udev/hotplug/whatever ready for 2.6.15?
Keybuk the current kernel (2.6.15-3) seems to work with both udevs, which was an unexpected bonus as it makes our lives a little easier
Keybuk breezy's is so old that it actually works with the newer kernel (heh)
Keybuk it didn't have the logic that broke
Keybuk the firmware move is pretty important though
infinity Ahh, so we're in the clear to update linux-meta once lrm is happy, and you can deal with the fallout at your own pace?
infinity Oh, except for the firmware bit.
Keybuk right, the firmware move is interesting
Keybuk I still figure it's the right thing to do, as that's where everyone else will be looking for it now -- and it makes dapper fit in with newer documentation and howto on driver sites
Keybuk I can stick the new path in the old hotplug FIRMWARE_DIRS for that though
Keybuk (if we need a stop-gap)
infinity What's the new path?  /lib/firmware?
Keybuk yup
Keybuk I'm still a bit mystified over the -$(uname -r) bit though
Keybuk neither the new Debian or upstream scripts look for that
infinity Erm, why would one need uname?
Keybuk so I couldn't work out whether that's going to break, or whether the kernel actually appends its own version in the request anyway
Keybuk well
fabbione we do need that
Keybuk the files are currently named:
fabbione because you can have multiple kernels installed
infinity Oh, you mean on the filenames.
Keybuk /lib/hotplug/firmware/ipw1200-1.3.fw-2.6.15-3-686
fabbione that requires different firmwares
Keybuk for example
infinity I thought you meant on the directory.
infinity Which would just be wrong.
Keybuk the current firmware.agent looks for /lib/hotplug/firmware/$FIRMWARE-$VERSION and /lib/hotplug/firmware/$FIRMWARE
Keybuk where $FIRMWARE is the thing in the firmware request from the kernel
Keybuk however
Keybuk neither the new firmware.agent in Debian, or the udev firmware_helper do that
Keybuk they both just load /lib/firwmare/$FIRMWARE
infinity Which clearly means you need to fix that. :)
Keybuk well, do I?
Keybuk why has everyone else stopped doing that?
infinity Because they ship firmware differently, in ways that don't cause file overlaps?
infinity The only reason we do it that way is for packaging reasons.
infinity There's no reaon, once the files are on disk, to have it that way, it just makes package MUCH simpler.
Keybuk Debian ship it the same way we do
infinity s/package/packaging/
Keybuk don't they?
infinity I don't think they ship firmware in their kernel packages at all, but I could be wrong.  I never use Debian kernels.
Keybuk or are they doing the "la la la we don't ship firmware" thing?
Keybuk Kamion: ?
Keybuk you still use Debian :)
infinity I use Debian plenty, but never their kernels.
Kamion Debian aren't shipping firmware AFAIK, no (I could be wrong, I'm not always 100% up to date)
Kamion certainly not in the kernel packages
Keybuk hmm
Keybuk so should we do:
Keybuk /lib/firmware/$FIRMWARE-$VERSION
Keybuk or we could do:
Keybuk /lib/firmware/$VERSION/$FIRMWARE
Keybuk which would kinda match /lib/modules
Kamion the latter would be neater, I guess
infinity No.
Keybuk either way, we should also look for /lib/firmware/$FIRMWARE for user-dropped firmware, as that's the "standard" path now
fabbione the latter will need more work and users to set their minds again
infinity Then hand-installed firmware will need to be versioned, which it never had to be before.
Kamion although makes it hard to arrange a symlink transition in future
infinity Firmware is device dependant, not kernel-dependant.
Kamion infinity: we'd definitely need to still support /lib/firmware/$FIRMWARE
infinity Ahh.
Keybuk fabbione: both are the same amount of work
infinity Well, in that case, I guess it's a pure case of what people think looks better.
fabbione Keybuk: the first one is a known ubuntu standard.. even across users
Keybuk fabbione: /lib/firmware != /lib/hotplug/firmware
Kamion in the future, do we want to make /usr/lib/hotplug/firmware or whatever a symlink to /lib/firmware?
fabbione Keybuk /lib/firmware/$FIRMWARE-$VERSION <-
Kamion that would suggest sticking with the current file naming
Kamion and just changing the directory over
Keybuk Kamion: /usr/ anything is considered wrong by the current kernel people
Kamion Keybuk: sure, but for pure backward-compat
Keybuk have we ever put anything in /usr/lib/hotplug/firmware?
Kamion e.g. if there's old documentation lying around that says "put your firmware in /usr/lib/hotplug/firmware/", a symlink would make that magically work
infinity s,/usr,,
infinity Kamion's brain is tab-completing to a nonexistant path, that's all.
Keybuk infinity: nah, it exists
Kamion ok, forget the /usr if that makes you all happier :)
infinity I agree that a symlink would be nice, which means not changing the layout.
Kamion my point is "paths other than /lib/firmware which we've used and previously documented for firmware"
Keybuk there's both a /usr/lib/hotplug/firmware *and* a /usr/local/lib/hotplug/firmware
infinity Eww.
infinity Nothing's ever told me to put stuff in either, afaik.
Keybuk the trouble with the symlink is that we can't put it there while the user still has old kernels installed
infinity (no HOWTOs, that is)
Kamion infinity: you probably don't read docs put together by the forums guys
Keybuk which means it'd only work for new users, who won't have learned the old path
infinity You can do a forceful symlink transition.
Kamion Keybuk: why not? mv /usr/lib/hotplug/firmware/* /lib/firmware/ && rmdir /usr/lib/hotplug/firmware && ln -s /lib/firmware /usr/lib/hotplug/firmware
Kamion and dpkg should be happy after that
Keybuk Kamion: debian dpkg is happy, I think iwj broke that in our dpkg *sigh*
Keybuk but yeah, that'd kinda work
Keybuk for all three old paths?
Kamion I thought he only broke it for conffiles; doesn't our X, like, *rely* on symlink transitions like that?
Keybuk he broke symlink upgrades too
Kamion hmm, moving stuff in /usr/local forcefully sucks
Keybuk both patches he did were wrong in some way
Keybuk aye
Keybuk though having firmware under /usr is kinda silly ... as we'll be almost certainly loading it in initramfs or very early in the boot sequence
Keybuk the advantage to /lib/firmware/$VERSION of course is that it's much easier to copy into the initramfs
Kamion sure, though it'll be fine in default Ubuntu installations as long as something prods the driver after early userspace
Kamion so for a lot of people, it'll be working and they'll wonder why we broke it :)
Kamion shame there's no /usr/local equivalent that's guaranteed to be on the root filesystem
Keybuk actually, why don't we do this ...
Keybuk look in
Keybuk 1) /lib/firmware/$VERSION
Keybuk 2) /lib/firmware
Keybuk 3) all the old paths
jbailey Keybuk: Copying onto the initramfs isn't a big deal from /usr.  It's needing the network card to mount /usr but not / where it's needed.
jbailey I don't think we've ever made the assertion that you can build the initramfs from anything other than a complete system.
jbailey Although at this point, I think it's generally true.
jbailey Mm, no.  klibc.
Keybuk jbailey: right, I just mean that /$VERSION/* is theoretically easier/cleaner/more-elegant than /*-$VERSION
jbailey 'fair nuff.
Keybuk the /usr thing is just the fact that if you put your network card firmware under /usr on an nfs-mounted partition, you're silly :)
* BenC is reading the scrollback
Keybuk I think I like /lib/firmware/$VERSION as it's symmetrical with /lib/modules
* BenC thinks a seperate firmware package makes more sense
BenC with all the firmware for all kernels we support in the package
infinity That's too much hassle.
BenC not really, it wouldn't even be touched very often
BenC maybe once or twice a release
BenC kernel would depend on linux-image-firmware, and that's it
infinity But what do you do when firmware needs to be updated for a driver?  Bloat the package with two versions of the firmware, so the old driver in the old kernel keeps working?
BenC infinity: all the firmware is 50k or less
infinity Or cripple the old kernel by removing its firmware?
Keybuk infinity: the only time I've ever seen that happen, the driver is sensible enough to change the firmware name
Keybuk e.g. the ipw2100 drivers
infinity Sure, but the firmware package just keeps growing and growing, then.
infinity Keybuk : Yes, the name changes, so we keep adding more and more files.
infinity Keybuk : Or we remove the old one, package is upgraded, old kernels break.
BenC infinity: I don't think it would ever grow that large
Keybuk I don't mind what we do :)  just as long as we do it
BenC really, the firmware is so small, a single one is nothing compared to the size of the kernel .deb itself
infinity BenC : It wouldn't be huge, but it would become a fair number of files, s'all.  And how do we decide when to remove firmware?
infinity Do we remove warty firmware when we stop supporting warty? :)
BenC I think we should keep only what's needed for the current release, and release - 1
infinity (having it tied to the kernel packages makes more sense to me, that's all I'm arguing.  Kernel goes away, so does its firmware)
infinity BenC : I don't want to futz with manually finding old firmware.deb revisions to test old drivers on old kernels.
BenC we don't support old kernels anyway...dapper wont be able to run breezy kernels
BenC supporting the firmware will just be a technical decision
infinity No, we don't support them.  But not supporting them doesn't mean going out of our way to break them harder.
Keybuk we could put old firmware in /lib/staleware
Keybuk <g>
* infinity smirks.
BenC infinity: I don't think we have to try any hardware to break old kernels running on new releases, it already happens
BenC harder
* BenC types and reads at the same time
infinity BenC : They break for things like inotify and other fun stuff, but in general old kernels can do useful things like get a network going.
jbailey infinity: I can fix that if you'd like ;)
infinity (Which is helpful if you want to, say, upgrade/troubleshoot over a network requiring firmware to function)
Keybuk I guess it comes done to jbailey's favourite argument ... how far do we go to support people who aren't running the current ubuntu-meta depends?
infinity <shrug>... I'm not arguing for support, I'm arguing against making a change that gratuitously breaks a working setup for a benefit I don't see.
Keybuk having a firmware package that contains the firmware for all of our supported kernels across all our supported releases seems sane
BenC infinity: then the argument could be made that since we only support rel->rel+1 upgrades, we will always support the old kernel that the user has
Keybuk then again, having the firmware in the kernel also seems sane
infinity Keybuk : And that's really my point.  The current situation already makes sense to me, so why change it?
BenC the version thing is a bit much
infinity It's just to avoid file overlaps.
Keybuk if the user upgrades, and doesn't upgrade the kernel, they're already going to be fucked
BenC and uneeded bloat
infinity And it's hardly the end of the world.
infinity BenC : You were just arguing a page back that the firmware is so tiny it doesn't matter, so bloat can't be an argument. :)
Keybuk right now, if the user runs the breezy kernel they won't be able to run the dapper udev
BenC infinity: I'm allowed to contradict myself :)
Keybuk and they won't be able to step back a kernel either
infinity Keybuk : By "right now", you mean "after you upload some shit", right? :)
Keybuk infinity: well, yes
infinity Keybuk : Cause I'[m happily swapping kernels right now.
BenC I'm not against either decision, just pointing out that a firmware package makes more sense to me
BenC but I'm not the only one affected by the change, so I'm open to doing whatever is decided
Keybuk we have three choices?
infinity <shrug>... I'll probably keep providing versioned firmware in l-r-m, since I feel no urge to provide an external firmware source package.
Keybuk 1) /lib/firmware/$FIRMWARE-$VERSION in each kernel package
infinity So we still need a way to do versioning.
Keybuk 2) /lib/firmware/$VERSION/$FIRMWARE in each kernel package
Keybuk 3) /lib/firmware/$FIRMWARE in a firmware package
Keybuk #3 will be supported anyway, because upstream finally got their acts in gear and documented that as the official, canonical place to put firmware
BenC infinity: good point, I forgot that lrm had firmware
BenC I like #2
BenC keeps the directory cleaner
Keybuk I think #2 is my favourite too
infinity If we're settled on 2, that's where I'll shove LRM's firmware on the next upload.
BenC #2 it is then?
BenC I'll post this IRC log to -devel for good measure
BenC or is it -announce?
infinity Yay for public dissemination of bickering!
BenC -devel-announce I guess
Keybuk -devel-announce
jbailey infinity: There's a surprising abscence of profanity, it's really not that bad. =)
Keybuk fabbione: can you bring ubuntulog in here, it's probably gonna hang around as a channel <g>
infinity jbailey : Fuck you.
Keybuk angie might object
infinity She can join in / push / hold the camera / mix the Jell-O / whatever turns her on.
jbailey infinity: I'd suggest non-dairy whipped cream but the smell takes so long to get out of the skin.

-- 
   Ben Collins <ben.collins at ubuntu.com>
   Developer
   Ubuntu Linux