linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* udev and depinit
@ 2006-05-05 18:36 Luke Kenneth Casson Leighton
  2006-05-05 21:01 ` Greg KH
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Luke Kenneth Casson Leighton @ 2006-05-05 18:36 UTC (permalink / raw)
  To: linux-hotplug

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 4596 bytes --]

dear hotplug developers,

a friend of mine (richard lightman), the author of depinit,whom some of you may have met at last year's ukuug, will bedoing a presentation on depinit at this year's ukuug in brighton.
http://www.nezumi.plus.com/depinit/ (documentation slightlyout-of-date because work is underway again on it, in preparationfor the talk e.g. yes it's possible to run spawnshell -l andget a standard login prompt as might be expected).
depinit makes a linux server system boot up in about 5 to 8seconds, and a standard debian/unstable desktop system running one.g. a 1.2ghz laptop in about 25.
one of the major things slowing it down is udev, and the reason isbecause of the population of the device nodes and all the damnscripts that udevd is (unnecessarily) running.
this may take a little explanation, but for now i will simply mentionthat by putting in a command into /lib/udev/net.agent, it's possibleto "notice" that individual network interfaces have been set up, andto, for example, start all daemon services - and the firewall - whichdepend on that network interface.
so in the network interface script, you would simply do depctl-s firewall daemons and that would start the daemons and the firewall.
this is where, unfortunately, in my view, it goes slightly wrong.
depinit's dependency management is all "push" - depinit takes theinitiative in starting services and all dependent services.
unfortunately for udev, udev is _also_ "push" - it expects to "start"things.
this is, in my opinion, the wrong way.
if there was a "pull" capability whereby a udev-command couldbe run "respond to all the networking hotplug events and tellme when you've done that including running all the net.agentscripts, please" then that would be ABSOLUTELY ideal.
why?  how would this work?  why would it be of benefit?
well, then it would be possible to write a depinit "service" called"udev-network".  this service udev-network would call this (proposed)udev-command to get udev to populate all of the required networking.
no other hotplug events would be responded to.  no other udev scriptswould be run (unless there was another udev-command run e.g. forprinting)
so if you didn't _need_ the usb bus, at all, for networking, then theusb udev scripts would not be run.  months later down the line (assumingthat the machine stays up that long), when someone decided that theyneeded a usb printer, they'd create a depinit service calledudev-usb-printer which "activated" the usb subsystem and also"activated" the udev agent responsible for /dev/usb/lp*...
... i presume that the usb hotplug events waiting in the kernel queuewould still be there, months later?

equally, it would be possible to create a depinit dependency scriptfor /dev/hd* and /dev/sd* which tied in with partitions being mountedfrom /etc/fstab (yes, the default depinit scripts that have beendeveloped list each entry e.g. var, usr as individual dependencies,so that you can start services that need /proc and /var/log butdon't need /home without worrying about oh e.g. whether /home isnfs-mounted)
in this way, it would be possible for a service which required e.g./var to go, down the dependency chain: first have udev started,then have the udev-ide-drive dependency started (which populated/dev/hda*), then have the var dependency started (which mounts/var on /dev/hda5) _then_ have the service started (which writesto /var/log).
and in the mean-time, networking hasn't even been started (becausethis particular daemon doesn't need it), 90% of the other entriesin /dev haven't been populated (because this particular daemondoesn't need them) and the boot time is cut by another 2 seconds.
okay.  so, here's a possible mad-cap implementation: instead of havingudev as the hotplug command, have a command udev-depinit whichRECORDS the hotplug event, and then the udev command, when runFROM depinit (by depinit) will look to see if that event has occurred,and if not it will WAIT until it does - but if it HAS occurred, then theudev scripts are run; if it's _already_ been run then it exits immediatelyof course.
would this be practical?
thoughtful questions, useful comments, valuable advice andinsightful guidance much appreciated.
l.ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÔ²)àN‰œjÖî¶wžvÚ\x1d¢j+{ó^yÛh²êi¢»py»\x1e®øœzÏìyË«ŠÜÿ\x19ël¶çßv‰Þªèœ’\°ŠØi­ïâž× ­«^vל†z%¢\f­¢f¤{*.®:^[y«"z°èÂyhiÒ\x011g›J˜^­à)¦Xœjب'«½êïÿ_ôÿVÚ±çhœZr\x17†zº'Šj!¶Úÿÿû\x1e—ö¬þëÿ}©dj\x0fçzßìz_Ü™žOä‰ÛNô÷öâßN{ýÖ­ëÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿòâžìÿ†‹i–èÿuëÞ–f¢–)à–+-†ÛiÿÿåŠ{±þ\x1a-¦[ þÊ.­ÇŸ¢¸\x1eþw­.)îÇøh¶™nƒ÷^½éÿ–+-³û(º·\x1e~Šà{ùÞ¶^[m¦ÏÿþX¬¶Ïì¢êÜyú+ïçzßåŠËlþX¬¶)ߣùbžìÿ†‹i–èÿuëÞ

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-05-06 10:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-05 18:36 udev and depinit Luke Kenneth Casson Leighton
2006-05-05 21:01 ` Greg KH
2006-05-06  1:59 ` Luke Kenneth Casson Leighton
2006-05-06 10:26 ` Luke Kenneth Casson Leighton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).