From: "Luke Kenneth Casson Leighton" <lkcl@lkcl.net>
To: linux-kernel@vger.kernel.org, kernel-discuss@handhelds.org
Cc: lkcl@lkcl.net
Subject: parallel boot device initialisation (kernel-space not userspace)
Date: Fri, 8 Dec 2006 16:34:02 +0000 (UTC) [thread overview]
Message-ID: <4758137481lkcl@lkcl.net> (raw)
hello darlings,
well i actually followed the FAQ http://www.tux.org/lkml/#s3-17
on this one, and got to try 'do a search' bit, and when searches
for 'parallel boot initialisation' came up with discussions about
parallel ports, and articles on ibm developerworks about sysvinit,
i made the decision to post this anyway.
I Have A Great Idea(tm) and would like to describe it concisely
to see if anyone likes it and hopefully hasn't thought of it before
so i'm not consuming people's time.
The idea is: parallel device initialisation of built-in modules, to
reduce kernel boot time.
parallel initialisation is taken care of in user-space by modifying
udev coldplug scripts to watch subsets of the /sys/class/*/event
files disappearing, and by using things like depinit, startpar for
suse, gentoo's parallel startup system (inspired by depinit)
.. but is there _anything_ like this actually in the linux kernel
itself?
i don't believe so, and the reasoning i base that on is that when
i boot my devices (be it a pc or be it an HTC smartphone device
i'm helping to reverse-engineer) the kernel startup log is always
the same, and that multiple messages coming from the same device
(printks) are always grouped together.
i realise that that's slightly faulty reasoning: it could
be that device initialisation is so regular like clockwork that
the output is always the same...
anyway.
now i have to try some things, as an experiment. and i would
like to start with asic3 platform_device, because it contains
dynamically-created lists of child devices and so is a model
example of the kind of dependency-hierarchy that's needed.
so, i seek people's advice on this rather naive approach: simply
set up a workqueue and call schedule_work() on each of the asic3
child platform_devices.
does that sound reasonable, or is it just too simplistic?
l.
p.s. see last few lines of asic3_probe, here, where
platform_add_devices() is called:
http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/soc/asic3_base.c?rev=1.28&content-type=text/x-cvsweb-markup
p.p.s. whilst my 1.2ghz fujitsu laptop (debian/unstable) with depinit
takes only 20 seconds to get from 1st process being run (/sbin/depinit)
to xorg running, it takes ANOTHER 20 seconds to get from kernel boot
up to 1st process (/sbin/depinit) ! that's with a standard debian
kernel - hence my interest in cutting that time to ... well...
under 5 seconds would be nice.
next reply other threads:[~2006-12-08 16:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-08 16:34 Luke Kenneth Casson Leighton [this message]
2006-12-08 16:38 ` parallel boot device initialisation (kernel-space not userspace) Jiri Kosina
2006-12-08 17:42 ` Luke Kenneth Casson Leighton
2006-12-08 22:44 ` Stefan Richter
2006-12-10 21:35 ` [Kernel-discuss] " Ian Molton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4758137481lkcl@lkcl.net \
--to=lkcl@lkcl.net \
--cc=kernel-discuss@handhelds.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox