It's using /var as a message-passing interface, yet in 99% of the cases where it will be signaled (everything except a USB device plugged in post-boot), that won't be writable.
Ahh, I've only tested this when hotplugging devices that require firmware, so it's probably you are correct. What should I be doing in this case? I need something very early in the boot sequence.
So, I'm assuming the idea here is: - udev rule drops a notifier on the filesystem somewhere - PK started from the user's session picks it up and tries to install packages Historically, for any sort of thing this early, we use a directory or file under /dev. This isn't clean, or FHS compliant, or anything like that... but it's the only thing that's guaranteed to be writable. Some ideas: - shared memory? (You may need to keep a daemon around for this) - /dev/.udev/failed (Not sure this has all the information needed)
(In reply to comment #2) > - udev rule drops a notifier on the filesystem somewhere > - PK started from the user's session picks it up and tries to install packages Exactly. > Some ideas: > - shared memory? (You may need to keep a daemon around for this) Nahh, that seems icky, well, ickier than what we've got already. > - /dev/.udev/failed (Not sure this has all the information needed) Can't I just create /dev/.udev/firmware-failed and then use that? I'm going to be shot by the FHS police at some stage anyway. Richard.
(In reply to comment #3) > > - /dev/.udev/failed (Not sure this has all the information needed) > > Can't I just create /dev/.udev/firmware-failed and then use that? I'm going to > be shot by the FHS police at some stage anyway. Sure, I just don't know if the already existing (from udev) /dev/.udev/failed stuff contains everything you need or not.
> (In reply to comment #3) > > > - /dev/.udev/failed (Not sure this has all the information needed) > > > > Can't I just create /dev/.udev/firmware-failed and then use that? I'm going to > > be shot by the FHS police at some stage anyway. Sure, but name it after your rules file, or include at least packagekit, so people see where it comes from. Otherwise somebody will complain that udev does no longer create "something", if you have a better idea some day. :) Just in case you create a lot of files here, don't know why, but it's good to remember, that every file that has more than 0 bytes content, takes 4k of ram until it is deleted. > Sure, I just don't know if the already existing (from udev) /dev/.udev/failed > stuff contains everything you need or not. If it works as expected, the failed marker will be removed when the (temporarily created) firmware loading "/sys device" will go away. These markers are only for devices which are still present.
Created attachment 322292 [details] test patch What about something like this?
Hmm, you don't know which device it is. That might not be useful? Firmware can be in more than one location, we must check the same stuff defined in the loader script. Maybe we just let the firmware script create symlinks like: /dev/.udev/firmware-missing/iwlwifi-3945-1.ucode -> \ /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/0000:03:00.0 That way, you check all locations the loader searches. Have all missing filenames, can retrieve the last device that tried to load the firmware. Don't waste space for multiple devices reqesting the same file, don't waste tmps memory pages by creating files. But the more interesting things are, how will you handle devices which try to load several firmware files in a row, and they find the right one with the second call? Some devices just check if they should update their internal firmware with something newer. Most CPU's check for new microcode, but almost nobody has or needs that. Some devices use the firmware interface to request optional mapping files, which is nothing you need to get the device working. All that will create failing requests, but have a fully working device.
(In reply to comment #7) > All that will create failing requests, but have a fully working device. Oh wait, does PackageKit only get active when it finds a matching firmware file in a known package? That would solve that problem, right?
(In reply to comment #8) > Oh wait, does PackageKit only get active when it finds a matching firmware file > in a known package? That would solve that problem, right? Yes, it's only tries to install the firmware if it's found in a package in a currently enabled repo. (In reply to comment #7) > you don't know which device it is. That might not be useful? I'm not sure it is -- I mean before a device has firmware it's not "interesting", so we can't tell the user that it's a Phillips webcam, as it's just a generic bit of hardware looking for a file, that becomes interesting when it's got it's firmware. The only thing that's useful to PackageKit is the filename, which I'm guessing modifying udev to supply that might be the best plan.
Created attachment 322301 [details] firmware.sh: record requested but missing firmware files (In reply to comment #9) > (In reply to comment #8) > > Oh wait, does PackageKit only get active when it finds a matching firmware file > > in a known package? That would solve that problem, right? > > Yes, it's only tries to install the firmware if it's found in a package in a > currently enabled repo. > > (In reply to comment #7) > > you don't know which device it is. That might not be useful? > > I'm not sure it is -- I mean before a device has firmware it's not > "interesting", so we can't tell the user that it's a Phillips webcam, as it's > just a generic bit of hardware looking for a file, that becomes interesting > when it's got it's firmware. That's true for stuff like generic EZusb, which disappears after upload, and shows up as a different device. But many of thes devices have unique ids also for the non-firmware-loaded device, and can be identified. Even for generic ones, it might be good to know that we look for an USB device which wanted a file. > The only thing that's useful to PackageKit is the filename, which I'm guessing > modifying udev to supply that might be the best plan. Care to try this patch to /lib/udev/firmware.sh? As usual for all udev path names, you need to unescape the hex code '\x2f' in the name, to restore '/', if the requested firmware string contains a subdirectory.
Kay, that's works great. This would allow the session to find the list without any grotty temporary files or catch all firmware rules. Could you add that to udev please, and then I can obsolete PackageKit-udev. Also, as a random aside, the files in /dev/.udev/firmware-missing are escaped (\x2f) and point to /devices rather than /sys/devices -- intentional? Thanks!
(In reply to comment #11) > Kay, that's works great. This would allow the session to find the list without > any grotty temporary files or catch all firmware rules. Could you add that to > udev please, and then I can obsolete PackageKit-udev. Done. > Also, as a random aside, the files in /dev/.udev/firmware-missing are escaped > (\x2f) Yeah, we need to tanslate the possible path name, to store it in a single file name. > and point to /devices rather than /sys/devices -- intentional? Yes, it's just the value of DEVPATH, all paths in /dev/.udev/ are relative. It is needed, because broken software that scans /dev for device nodes to find things like labels and uuid's runs into nearly endless loops following the links to /sys, and getting lost in the web of links in /sys, after doing millions and millions of stat()'s there. :) Also some /dev/.udev/ symlink targets are just misused to store other data, and not to point directly to files. Tmpfs allocates 4 kB for every file, even when it contains only a few bytes. On systems with a large number of devices this can grow to many MB, therefore we use (fake) symlinks.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
gnome-packagekit now uses the new UDEV feature of /dev/.udev/missing-firmware and therefore PackageKit-udev-helper has been removed and the firmware requests issued at boot are picked up on first login. Thanks to all involved.