From: Rob Love <rml@ximian.com>
To: "J.A. Magallon" <jamagallon@able.es>
Cc: Greg KH <greg@kroah.com>,
linux-hotplug-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] udev 011 release
Date: Sat, 27 Dec 2003 21:19:14 -0500 [thread overview]
Message-ID: <1072577823.4042.3.camel@fur> (raw)
In-Reply-To: <20031228020449.GA26527@werewolf.able.es>
On Sat, 2003-12-27 at 21:04, J.A. Magallon wrote:
> This means that it will try to run, for example, gpm before the device for
> the mouse is created (as I said, if you booted with an empty /dev you want
> to populate with device nodes).
Yah, I guess it ought to go lower, so long as sysfs is sufficiently
mounted before it runs.
The reason I put it at 20 was that it really does not matter. udev is
not a functional replacement for a static /dev while we do not have
initramfs. Once we have udev working during early boot, we won't need
the initscripts.
> And a couple questions.
> a) Should not ordering be reversed here:
>
> start)
> if [ ! -d $udev_dir ]; then
> mkdir $udev_dir
> fi
> if [ ! -d $sysfs_dir ]; then
> exit 1
> fi
> If we have not /sys, there's no sense on creating /udev, so I would check first
> for /sys.
Makes sense.
> b) What is the sense of removing devices when udev is stopped ? As I understand
> it, udev is not 'running', it is just a command to create device nodes, called
> by hotplug.
Because if you have your udev on a persistent storage media (e.g., ext3,
like most of us) then it is nice to clear it out across reboots.
Rob Love
next prev parent reply other threads:[~2003-12-28 2:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-25 0:56 [ANNOUNCE] udev 011 release Greg KH
2003-12-28 2:04 ` J.A. Magallon
2003-12-28 2:19 ` Rob Love [this message]
2003-12-29 22:48 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2003-12-25 0:56 Greg KH
2003-12-28 2:04 ` J.A. Magallon
2003-12-28 2:19 ` Rob Love
2003-12-28 2:19 ` Rob Love
2003-12-28 2:19 ` Rob Love
2003-12-29 22:48 ` Greg KH
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=1072577823.4042.3.camel@fur \
--to=rml@ximian.com \
--cc=greg@kroah.com \
--cc=jamagallon@able.es \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.