From: Ivan Gyurdiev <ivg2@cornell.edu>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hotplug events vs proc - timing
Date: Wed, 02 Jun 2004 23:19:19 +0000 [thread overview]
Message-ID: <40BE6077.8090401@cornell.edu> (raw)
In-Reply-To: <40BCD9C6.1040909@cornell.edu>
Greg KH wrote:
> On Wed, Jun 02, 2004 at 01:36:09PM -0400, Bill Nottingham wrote:
>
>>Greg KH (greg@kroah.com) said:
>>
>>>On Tue, Jun 01, 2004 at 01:32:22PM -0600, Ivan Gyurdiev wrote:
>>>
>>>>Fedora's updfstab tool (part of kudzu) is trigged by hotplug to
>>>>add/remove things from fstab, such as my Fujifilm Digital Camera
>>>>(usb-storage, scsi emulation). However... it reads /proc/scsi/scsi, and
>>>>doesn't work as it should because it's triggered before /proc/scsi/scsi
>>>>is updated most of the time. Where is the bug, and how should this race
>>>>be corrected?
>>>
>>>The race should be fixed by having the hotplug script wait around for
>>>the proc file to show up.
The proc file is already there. It says "Attached Devices:" and that's
it. The question here is when the /proc/scsi/scsi file is updated to say
that I have a digital camera attached. It seems any sort of delay fixes
it - if I run kudzu from the startup script it works, if I modprobe
usb-storage out so it has to load it it works (delay while loading?).
If I sleep 1 it works too..
otherwise the old file is read, and no scsi devices are found.
How do we know when the /proc/scsi/scsi file is updated?
>>Hm, as I was thinking, the hotplug event is triggered by the USB
>>insertion; what's really needed for updfstab is that it gets
>>run triggered on the *scsi* device creation. Or is this the proc
>>file you're referring too?
>
>
> Yes, good point, you should update the fstab after the device node is
> created. You can learn of that by putting your script in the
> /etc/dev.d/ directory tree.
FC2 does not use udev. I'd like to use udev, but I understand there are
early userspace issues to resolve. Last time I tried it did not work
well for me, since init wouldn't start.
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
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-06-02 23:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-01 19:32 Hotplug events vs proc - timing Ivan Gyurdiev
2004-06-02 17:20 ` Greg KH
2004-06-02 17:36 ` Bill Nottingham
2004-06-02 17:41 ` Greg KH
2004-06-02 17:57 ` Marcelo Ricardo Leitner
2004-06-02 18:05 ` Greg KH
2004-06-02 23:19 ` Ivan Gyurdiev [this message]
2004-06-03 8:30 ` Harald Hoyer
2004-06-03 16:54 ` 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=40BE6077.8090401@cornell.edu \
--to=ivg2@cornell.edu \
--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).