From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] cleanup udevstart
Date: Tue, 02 Mar 2004 23:32:02 +0000 [thread overview]
Message-ID: <20040302233202.GD11218@kroah.com> (raw)
In-Reply-To: <20040302215536.GA12039@vrfy.org>
On Wed, Mar 03, 2004 at 12:23:56AM +0100, Olaf Hering wrote:
> On Tue, Mar 02, Greg KH wrote:
>
> > On Wed, Mar 03, 2004 at 12:09:51AM +0100, Olaf Hering wrote:
> > > On Tue, Mar 02, Kay Sievers wrote:
> > >
> > > > +#define SYSBLOCK "/sys/block"
> > > > +#define SYSCLASS "/sys/class"
> > > > +#define UDEV_BIN "/sbin/udev"
> > >
> > > > pid = fork();
> > >
> > > > - retval = execl("/sbin/udev", "/sbin/udev", path, NULL);
> > >
> > > I have not looked closer at it, wouldnt it be better to feed the udevdb
> > > directly, instead of spawning countless udev processes? Some sort of
> > > udev binary which takes optional directories as agument to limit it to
> > > these sysfs dirs.
> >
> > Nah, it's simpler this way. We spawn and then wait, so there isn't a
> > zillion udev processes all running at once :)
>
> thats the point, wait for what?
> I hope the whole point is to create all nodes in a jiffy, in the long run?
At startup we have to wait as usually the next thing the initscripts do
is use those device nodes. So we have to wait until they are all
created.
And it's fast today. Have you timed udevstart (or even the start_udev
bash script)? Here's my box as I do a kernel build in the background at
the same time:
# /usr/bin/time /sbin/udevstart
Command exited with non-zero status 22
0.19user 0.67system 0:01.04elapsed 83%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2major+6065minor)pagefaults 0swaps
1 second to populate a full /dev while the system is under a very heavy
load is pretty good I think :)
thanks,
greg k-h
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&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
next prev parent reply other threads:[~2004-03-02 23:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-02 21:55 [PATCH] cleanup udevstart Kay Sievers
2004-03-02 22:16 ` Greg KH
2004-03-02 23:09 ` Olaf Hering
2004-03-02 23:20 ` Greg KH
2004-03-02 23:23 ` Olaf Hering
2004-03-02 23:32 ` Greg KH [this message]
2004-03-15 21:22 ` Olaf Hering
2004-03-16 1:28 ` Kay Sievers
2004-03-16 2:49 ` Kay Sievers
2004-03-16 17:01 ` Patrick Mansfield
2004-03-16 21:57 ` Kay Sievers
2004-03-16 22:24 ` Patrick Mansfield
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=20040302233202.GD11218@kroah.com \
--to=greg@kroah.com \
--cc=linux-hotplug@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;
as well as URLs for NNTP newsgroup(s).