From: Alex Galakhov <agalakhov@ifmlrs.uran.ru>
To: linux-kernel@vger.kernel.org
Subject: hotplug/udev and SysV init
Date: Wed, 28 Jul 2004 23:23:25 +0600 [thread overview]
Message-ID: <ce8nel$aji$1@sea.gmane.org> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello All,
While experimenting with the kernel I found that there may be races
between /sbin/hotplug and initscripts (I can provide a lot of examples) if
handling cold-plugging. It happens if the initscripts assume the presence
of some device (it is very very hard to avoid such assumptions in a
production system, you know). The other problem is that we need initscript
to run "lost" hotplugs.
There was a patch somewhere (don't remember the topic, sorry) to
have /sbin/hotplug handle all the devices immediately after the kernel
starts (to avoid loss of hotplug events). Its problem was that it fires up
a lot of asynchronous /sbin/hotplugs while the kernel detects your network
cards, disks, mousepads, light bulbs and other hardware. Or, a standard
solution was, to have /etc/init.d/hotplug (and maybe udev) that does all
the job (which has problems as well).
IMHO, the problem is that if /sbin/hotplug is not "ready" (for any reason,
but we assume it may be not ready before something special happens in
system initialization, i.e., some fs is mounted), the hotplug event is
lost. From the other side, assuming that /sbin/hotplug is always "ready"
doesn't seem to be a good idea. It is known that forking a lot of hotplugs
is not good. Serializing helps but is unacceptable in kernel (but
acceptable in initscripts).
Thus, a possible solution is to have the kernel to remember all the hotplug
events that happen at the system boot (before the hotplug subsystem becomes
"ready") and replay the events journal in initscripts. After the journal is
replayed, hotplug continues in usual way. Assume that:
1. If /proc/sys/kernel/hotplug is not set (empty string), the kernel records
the journal of hotplug events. After an
'echo "/sbin/hotplug" > /proc/sys/kernel/hotplug' (or any other modifying
of /proc/... file) the recording is stopped. (To disable hotplug, use
'/bin/false' or '/bin/true' instead of '/sbin/hotplug').
2. The journal may be read (and deleted) through /proc or /sys.
3. The initscript reads the journal, calls /sbin/hotplug multiple times
(probably serial, no forking), waits for forked hotplugs (if any), flushes
the events journal and then does an echo to /proc/sys/kernel/hotplug.
4. At this point, it is guaranteed that all the coldplug events are
processed and all coldplug devices are initialized. Everything else is
"true" hotplug.
IMHO, this approach solves many problems and should not produce any problems
by itself. What do you think about it?
Regards,
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBB+EUaA+H7vY+1kURAtweAJ9E/A5i/16xK39nEGfe9PZdGnXLPgCgjV1p
gOdorOVEXr6BeEJ60b7ieS0=
=MKdb
-----END PGP SIGNATURE-----
reply other threads:[~2004-07-28 18:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='ce8nel$aji$1@sea.gmane.org' \
--to=agalakhov@ifmlrs.uran.ru \
--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.