I attempted to document hotplug and firmware loading, and will make another attempt, but it's an uphill battle. The documentation I have _works_, but the relevant kernel maintainers dispute it and plan to break it in future releases. The version I posted is at http://kernel.org/doc/pending/ http://kernel.org/doc/pending/hotplug.txt I've got another version pending but it's still in pieces. I've made several attempts over the past few days to document why this is hard, but each time it turned into a rant. My current problems are: 1) The developers give conflicting information. At OLS Kay Sievers told me to use path names containing the "device" symlink, and after I got back from OLS Greg KH posted the largely useless "sysfs-rules.txt" which says that using any path that follows the "device" symlink is forbidden. (I never did get clarification on this point. Kay Sievers has been bouncing my email as spam for over two months now, and in response to the long paragraph by paragraph examination I wrote concerning _why_ sysfs-rules.txt is more or less useless (http://lkml.org/lkml/2007/7/20/487 ), Greg KH latched onto something halfway through as an excuse to announce he would no longer respond to any messages in the thread either. (These developers have not exactly welcomed third party attempts to document their API with open arms.) 2) The developers don't thoroughly answer questions. I asked how to distinguish char devices from block devices almost 20 times before I got an answer. And before announcing he was bit-bucketing the thread about my first attempt at documenting this topic, Greg KH told me that I don't need sysfs to dynamically populate /dev. At the same time he questioned the need for such documentation, since udev does it and is the One True Implementation: http://lkml.org/lkml/2007/7/20/495 What Greg didn't say was _how_ to handle coldplug (enumerating existing devices available before /init gets fired off) without sysfs. Greg won't reply on this topic anymore, and I still can't email Kay directly, so I'm left to guess. There _might_ be a way to do it through netlink, but the versions of udev and hald's coldplug.c I looked at used sysfs, and Google isn't finding anything either. (Also, requiring netlink inconveniences the embedded Linux guys who may not want the network stack in an embedded device, although that additional requirement is a fairly minor concern.) 3) Although you can find out most of this information experimentally, if you do so the udev developers then change it and break your application/documentation. They claim that use of undocumented portions of sysfs is user error and not guaranteed to work in future versions, yet their supposed "documentation" consists primarily of "don't do this, don't do this, don't do this" instead of stating what _is_ allowed. The fundamental problem seems to be that the sysfs developers do not want to be constrained by an API, and respond to attempts to document one as a threat or invasion of their turf. They consider sysfs to work by the rules inside the kernel ("stable API nonsense") rather than as an export to userspace that userspace programs are expected to use. They question why anyone would want to document it, provide contradictory information when asked about it, don't answer direct questions repeatedly posed to them, and blame the questioner for not already knowing. They point to the udev implementation as the one true way to do this sort of thing (or in some cases hald), but reserve the right to force upgrades to udev as newer kernels drop support for older versions. (There is already a minimum required version of udev, 081 from January 2006. Newer kernels are not expected to work with older versions of udev, because they changed the sysfs exports udev used. They make no promises not to do it again.) I have personal experience of how this is inconvenient to third party developers. Back in 2005 I wrote a tool called "mdev" for busybox that populates /dev from sysfs and handles hotplug requests afterwards in 7k. Changes to sysfs broke it when upgrading to kernels 2.6.12, 2.6.14, and 2.6.20, and additional changes are pending to break it again. I detailed the history and current state of the problem here: (warning, big rant) http://lkml.org/lkml/2007/7/23/470 Making udev work is so complicated that distribution maintainers can't seem to reliably do it. Even Fedora's developers apparently can't figure out how to make the thing work right, and were recently admonished by the udev developers to just use the ruleset that comes bundled with udev without trying to modify things they don't understand: http://lkml.org/lkml/2007/7/20/524 I note also that the Ubuntu 7.04 (the current release version) preinstalled by Dell on my new laptop is applying a UUID to every _partition_ on my SATA hard drive (not just to the drive itself), and is mounting each partition by uuid in /etc/fstab, in an attempt to persistently name them between reboots. Except that if you persistently identify the _drive_, the partitions fall out from that, and the point of udev is to do this so you can avoid that kind of "hunt through every disk attached to the system to find labels". Apparently Ubuntu can't reliably get udev to persistently name devices either. (I noticed this because it spins up my external USB hard drive when trying to find the root partition during boot, and tracked it back to fstab.) That said, I'm working on another revision of the darn document. I don't give up easily, but this one is really not fun. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
