From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sun, 03 Jul 2005 14:01:23 +0000 Subject: Re: udev-059 and default.hotplug script Message-Id: <20050703140123.GC29752@vrfy.org> List-Id: References: <20050702012817.46255.qmail@web30214.mail.mud.yahoo.com> In-Reply-To: <20050702012817.46255.qmail@web30214.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Sun, Jul 03, 2005 at 02:15:47PM +0200, Marco d'Itri wrote: > On Jul 03, Kay Sievers wrote: > > > There is no general rule. It depends on your setup and how you organize > > things on bootup. SUSE does kernel event-replay from initramfs. udevstart > > and coldplug are not used anymore. > > > > udevstart did dev.d/ also with the old udev versions, so only the > > hotplug.d/ replacement RUN rules you may disable with matching > > $UDEVD_EVENT. > > > > But it may also be possible to modify udevstart to replace coldplug. > > Don't know, you may have a better view, if this is possible? > This same tought occurred to me before, coldplugging could come for > free since udevstart already walks sysfs and generates events for the > PCI and USB devices, but I am not sure about all the possible > consequences. But we need to walk through /sys/devices to catch devices there for modules-load, ..., right? That is not handled by udevstart currently. > My first tought about this is that it's too early to mandate using > initramfs, so udevstart should continue to be fully supported until > other reasons will make using initramfs mandatory for everybody. Yes, righ. It is not mandatory to use replay. But it works very nicely and I expect we all will go that route sooner or later. Time will tell... :) > My second tought is that I do not understand exactly which events are > generated and when in these cases, both when drivers are modular and > statically built in the kernel: > - initramfs with events replaying All events are catched and can be replayed. No logic needed, it's all possible with the normal udev rules without any coldplug-scan or whatever. > - udevstart Handles only devices with a node. > - coldplugging Scans for devices to load modules too. Maybe we can combine udevstart and coldplugging, but someone that will actually use it will need to help here. I'm expected to concentrate on the event-replay stuff. > so I would welcome some documentation about this. > (The "when" part is very important, because it's crucial to know at > which point of the boot process the RUN scripts will be started.) We have an initramfs that stores every event with udeveventrecorder in the filesystem and when the real root is mounted udevd is started with the exec_queue blocked. After feeding the events to udevd, the queue handling is switched on and udevd starts with the very fist events the kernel has emitted and seamlessly receives and handles all new events that arrive in the meantime in the queue. > Did you look yet at my hotplug-light scripts? > http://www.bofh.it/~md/debian/ Only a short look and it looks great compared to the current ones. But SUSE does not use the hotplug package, it has it's own version which is highly integrated into the configuration system. We are going to revamp major parts and replace a huge part of it. > > The next major udev version will depend on kernel 2.6.12 and will support > > fast node creation in the udev daemon itself. _Simple_ rules will be able to > > handled by the daemon itself. That will hopefully make event-replay fast > > and easy and be a better approach than udevstart and coldplug. > Why? How was udev determined to be slower? On event replay you fire ~800 processes in a few seconds, while most of these events are simple devices without any further processing. Tests showed and my coworkers needed to convince me that doing this in-process is much faster and you save some seconds bootup-time. (using udevstart does not have this problem, cause it already does everything with only one process) > I am a bit concerned about increasing complexity and code size. It's not getting bigger, it will be lot smaller I expect, cause I will remove a lot of old code and half of wait_for_sysfs, cause this is solved with kernel changes. It will also be able to work without sysfs for simple rules, which will make some people very happy. > (And I am very concerned about the dependency on a kernel newer than the > 2.6.8 shipped in Debian 3.1, which I fear will make upgrades painful.) Debian will need to have shorter release cycles than 3 years. :) The next version will definitely not work with kernels earlier than 2.6.12 and a next HAL version will require that udev version to be functional. The recent HAL already depends on 2.6.11 anyway. But I see no problem for Debian to stick with that version, or make some tricky boot script to decide what udev version to run. Also I don't see a problem to have official maintence releases on top of the version before the cut if that is useful. We have no other option to make progress with our integration work and need to get rid of the old stuff during the next months to reach that goal. We will see big changes in the dynamic hardware handling and all that stuff will only be possible with recent kernels, udev and HAL versions. The commercial distributions have definitely no ressources to support so many options and will just require specific kernel versions to work with the rest of the system. They just make sure that the systems will run with recent custom kernels, therefore udevstart will also be supported as long as it is needed. But support for older kernels will need to be dropped to keep the packages maintainable if the difference is that big like the netlink-uevent, the modalias-support, no need to wait_for_sysfs for most of the events and the $MAJOR/$MINOR in the event env. Thanks, Kay ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel