Hotplug events vs proc - timing

Hotplug events vs proc - timing

[Ivan Gyurdiev]

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?

Thanks,

I.G.





-------------------------------------------------------
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

Re: Hotplug events vs proc - timing

[Greg KH]

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.

thanks,

greg k-h


-------------------------------------------------------
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

Re: Hotplug events vs proc - timing

[Bill Nottingham]

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.

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?

Bill


-------------------------------------------------------
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

Re: Hotplug events vs proc - timing

[Greg KH]

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.
> 
> 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.

thanks,

greg k-h


-------------------------------------------------------
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

Re: Hotplug events vs proc - timing

[Marcelo Ricardo Leitner]

On Wed Jun 02, 2004 at 13:36:09 -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.
> 
> 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?
---end quoted text---

What about having something like:

while [ ! -f /proc/cmdline ]; do
        sleep 1;
done

at /etc/hotplug/usb.agent?
But be careful, if your proc doesn't show it, this process would stay alive
forever. Putting a timeout no X retries on it doesn't seem to be a bad idea.
Also, note that /proc can be mounted, but not /proc/bus/usb.

Or ignore the signal and coldplug it. :)

Best regards,
-- 
Marcelo Ricardo Leitner <mrl@conectiva.com.br>


-------------------------------------------------------
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

Re: Hotplug events vs proc - timing

[Greg KH]

On Wed, Jun 02, 2004 at 02:57:31PM -0300, Marcelo Ricardo Leitner wrote:
> 
> Or ignore the signal and coldplug it. :)

Or use /etc/dev.d/ :)

thanks,

greg k-h


-------------------------------------------------------
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

Re: Hotplug events vs proc - timing

[Ivan Gyurdiev]

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

Re: Hotplug events vs proc - timing

[Harald Hoyer]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

Greg KH wrote:
> On Wed, Jun 02, 2004 at 01:36:09PM -0400, Bill Nottingham wrote:
>>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.
> 
> thanks,
> 
> greg k-h

but remember Bill, udev has to be activate for that :)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: Hotplug events vs proc - timing

[Greg KH]

On Wed, Jun 02, 2004 at 05:19:19PM -0600, Ivan Gyurdiev wrote:
> >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.

I use udev on FC2 just fine.  See the README notes on how to do this in
the udev tarball.  FC2 also ships a udev rpm, which you can use not to
manage your /dev, but to handle the /etc/dev.d notification only if you
wish.

Good luck,

greg k-h


-------------------------------------------------------
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