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

* Re: udev and depinit
  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
  2 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2006-05-05 21:01 UTC (permalink / raw)
  To: linux-hotplug

On Fri, May 05, 2006 at 07:36:16PM +0100, Luke Kenneth Casson Leighton wrote:
> 
> if there was a "pull" capability whereby a udev-command could
> be run "respond to all the networking hotplug events and tell
> me when you've done that including running all the net.agent
> scripts, please" then that would be ABSOLUTELY ideal.

You can do that today, look at how udevtrigger works.  Just do that for
network devices and you are done.

In short, what you are wanting to do doesn't have much at all to do with
udev, but with how your distro handles the startup logic.  All udev does
is act apon the events it gets.  If you don't trigger events, it doesn't
act on them.

So just trigger the events that you care about and you will be fine.

good luck,

greg k-h


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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

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

* Re: udev and depinit
  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
  2 siblings, 0 replies; 4+ messages in thread
From: Luke Kenneth Casson Leighton @ 2006-05-06  1:59 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: 2545 bytes --]

greg, thank you v. much for responding.
On 5/5/06, Greg KH <greg@kroah.com> wrote:> On Fri, May 05, 2006 at 07:36:16PM +0100, Luke Kenneth Casson Leighton wrote:> >> > if there was a "pull" capability whereby a udev-command could> > be run "respond to all the networking hotplug events and tell> > me when you've done that including running all the net.agent> > scripts, please" then that would be ABSOLUTELY ideal.>> You can do that today, look at how udevtrigger works.  Just do that for> network devices and you are done.
 ooooo :)
 so udev _does_ work the sensible way.
> In short, what you are wanting to do doesn't have much at all to do with> udev, but with how your distro handles the startup logic.
 [ trying to help put it into a debian package - having lots of fun... ]
>  All udev does> is act apon the events it gets.  If you don't trigger events, it doesn't> act on them.
hmmmmm ...
> So just trigger the events that you care about and you will be fine.
 okayyy... ah _ha_ so that's what the debian /sbin/udevsynthesize scriptis all about - the one that walks looking for /sys/...../uevent things andechoing "add" into them.
... and... oh, yes, it looks like udevtrigger does exactly the same thing,but just in c-code instead of as a shell script.
hmmm...
okay - here's the bit i don't quite get: what tells me that a particulardevice (e.g. /sys/block/hda) will get all its dependent modules loadedor doesn't it matter?
here's the thing: it would appear to me that /sys/block/hda is the idehard drive - but if i _just_ trigger the /sys/block/hda/uevent, and the/sys/block/hda/hda1+2 etc ones, will i get access to my hard drive?do i need to also echo "add" into /sys/bus/ide/uevent?
and equally for networking: do i need to do the same thing for e.g.the pci bus on which the network interface is?
for the usb devices, will i need to do the same for /sys/bus/usb_host/...before the individual usb devices will work?
if it matters, how would i identify the dependency chain?
i don't want to have to run absolutely everything (and one of the reasonswhy i think debian is so slow is because they have nearly 500 tty deviceswhich is insane).
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

* Re: udev and depinit
  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
  2 siblings, 0 replies; 4+ messages in thread
From: Luke Kenneth Casson Leighton @ 2006-05-06 10:26 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: 1274 bytes --]

k greg - a quick one: is there any documentation describing theprocedure for actual hotplugging?  i note that this is done in thedebian scripts: is that it?
set_hotplug_handler() {  case "$(uname -r)" in    2.6.1[0-4]|2.6.1[0-4][!0-9]*) HANDLER='/sbin/udevsend' ;;  esac  echo $HANDLER > /proc/sys/kernel/hotplug}
hum - man page for udevsend says that "normally udevd listensdirectly to kernel uevents".
so... how does this all hang together, when, oh, say, a usb printeris plugged in?
the non-ideal scenario is .... ah, damnit - i just found/etc/udev/alsa-utils.rules,which say RUN=/lib/alsa-utils/udev, which says exec/etc/init.d/alsa-utils start.
yep, that's the non-ideal scenario - finding all these little tricksand replacingthem with "exec depctl -s alsa-utils."
i think i answered my own question but confirmation that this is the "way to go"would be greatly 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).