From: "Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: hotplug and "rw" on kernel command line
Date: Mon, 31 May 2004 19:28:37 +0000 [thread overview]
Message-ID: <40BB8765.3070004@backtobasicsmgmt.com> (raw)
In-Reply-To: <40B9E956.2000608@ums.usu.ru>
Alexander E. Patrakov wrote:
> /proc/bus/usb. Both bootscripts are attached. You see that none of them
> does things that can lead to a hotplug event, so the source of that
> bogus event is a mystery for me.
Speaking as the original bug reporter, I'll jump in here: I am not
suggesting that the unexpected hotplug event is bogus at all. Hotplug
events are not only caused by the actions taken by the bootscripts, they
can be caused by almost anything at all.
Consider the possibility that the user has a USB storage device that
takes some time to respond to USB enumeration... the kernel could easily
have finished its own initialization mounted the root filesystem
read-write before this device is finally found and accepted by the USB
storage driver. At the instant the driver binds to the device, one or
more hotplug events will be generated. If the system's boot scripts have
not yet had a chance to finish their work, the hotplug event will occur
at an inopportune time and things can get weird.
The only solution I can see for this (well, proper solution that works
in all cases I can think of) is to _not_ have the kernel default to
calling /sbin/hotplug, but rather have the system bootscripts have to
forcibly set /proc/sys/kernel/hotplug to that value. Alternatively, the
/sbin/hotplug script from the hotplug package could be renamed after
installation and then appropriate script could set
/proc/sys/kernel/hotplug to /sbin/hotplug.real.
Either of these changes will get around this problem, because the boot
scripts can handle the appropriate cold-plugging when ready, and they
can very closely control when userspace will actually start to receive
hotplug events.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_idÅ66&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-05-31 19:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-30 14:01 hotplug and "rw" on kernel command line Alexander E. Patrakov
2004-05-31 19:28 ` Kevin P. Fleming [this message]
2004-06-01 8:59 ` Alex Galakhov
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=40BB8765.3070004@backtobasicsmgmt.com \
--to=kpfleming@backtobasicsmgmt.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).