On Wed, Dec 3, 2014 at 3:29 PM, Wookey wookey@wookware.org wrote:
All that said, I'm sure that study of Debian and options for having standardised ways of improving boottime would be worthwhile. I bet there are things we could do to at least make this easier and possibly make things go faster _without_ undue loss of generality, especially as there has been a pile of change recently in the boot process (don't mention the war! :-)
... whatever you do, don't mention ze war :)
yes. wookey, there is *definitely* something that can be done, unfortunately i lost the work back in 2006 (and would have to recreate it). basically udev right now creates hundreds of nodes and has to "settle".
this "settling" *can* be sub-divided into at least two groups. you can look in the udev event trigger location (somewhere in /sys) and instead of "is empty subdirectory" use "grep sd* net* tty?" and other tricks.
in this way it's possible to have (at the very least) mounting and networking come up a good few seconds *before* everything else. you *do not* need to delay networking or early mount just because 768 pseudo-ttys have to be created.
and it _does_ take a long time because of udev spawning bash/dash scripts, which then spawn more bash scripts... back in 2004 i think i saw a stack of bash scripts *THIRTY DEEP* on a old Pentium 90 system - it was something like *2 MINUTES* for udev to stop f******g about.
whilst there have been many improvements in hardware context-switching for x86 systems, other processor architectures *do not* have such good context-switching (extreme case: ARM9 as you well know) so on such systems the effects of the assumptions "everything works fine on x86" are much more marked.
l.