Re: New hotplug interface is not working right for me

Re: New hotplug interface is not working right for me

[Eric S. Raymond]

Greg KH <greg@kroah.com>:
> On Fri, Mar 11, 2005 at 12:20:54AM -0500, Eric S. Raymond wrote:
> > Greg KH <greg@kroah.com>:
> > > > The problem appears to be that whatever thread of control is creating 
> > > > the /dev/ttyUSB* node is running asynchronously with the hotplug
> > > > script and does not reliably (or even usually) create it before the
> > > > gpsd instance gets spawned and goes looking for the node.
> > > 
> > > Then use the /etc/dev.d/ interface instead.  That requires udev and a
> > > 2.6 kernel, but is the only way you can know exactly when the /dev entry
> > > is created.
> > 
> > Where is this documented?
> 
> In the udev documentation and a simple google search brings it up.
>
> > Even if the /etc/dev.d/ interface works, that doesn't really make it
> > acceptable that the /etc/hotplug.d/ interface is broken.  There is some
> > locking that ought to be happening and isn't.
> 
> The interface is not broken, you are trying to trigger off of two
> different hotplug events (one when the device appears, and a different
> one when the device node is to be created.)

If it's not broken, then it's not documented either.

Or, at least, I don't see any documentation that tells me about a
second hotplug event when /dev/ttyUSB0 is created.  Now, if I could
write a script that would fire on only only /dev/ttyUSB* creation events and
allow me to filter on the vendor/product ID, that would be fine -- those
are what I'm really interested in.

> Also, please don't restrict this to private email, all further responses
> should be on the linux-hotplug-devel mailing list.

Done.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Greg KH]

On Fri, Mar 11, 2005 at 01:04:05AM -0500, Eric S. Raymond wrote:
> Greg KH <greg@kroah.com>:
> > On Fri, Mar 11, 2005 at 12:20:54AM -0500, Eric S. Raymond wrote:
> > > Greg KH <greg@kroah.com>:
> > > > > The problem appears to be that whatever thread of control is creating 
> > > > > the /dev/ttyUSB* node is running asynchronously with the hotplug
> > > > > script and does not reliably (or even usually) create it before the
> > > > > gpsd instance gets spawned and goes looking for the node.
> > > > 
> > > > Then use the /etc/dev.d/ interface instead.  That requires udev and a
> > > > 2.6 kernel, but is the only way you can know exactly when the /dev entry
> > > > is created.
> > > 
> > > Where is this documented?
> > 
> > In the udev documentation and a simple google search brings it up.
> >
> > > Even if the /etc/dev.d/ interface works, that doesn't really make it
> > > acceptable that the /etc/hotplug.d/ interface is broken.  There is some
> > > locking that ought to be happening and isn't.
> > 
> > The interface is not broken, you are trying to trigger off of two
> > different hotplug events (one when the device appears, and a different
> > one when the device node is to be created.)
> 
> If it's not broken, then it's not documented either.

You are watching for the wrong hotplug event, how can we document that?
:)

> Or, at least, I don't see any documentation that tells me about a
> second hotplug event when /dev/ttyUSB0 is created.  Now, if I could
> write a script that would fire on only only /dev/ttyUSB* creation events and
> allow me to filter on the vendor/product ID, that would be fine -- those
> are what I'm really interested in.

You can, just put your script into /etc/hotplug.d/tty and watch for the
device name to be ttyUSB*.  Then walk the sysfs chain back up the
directory to see the vendor and product id of the device attached to
that ttyUSB device.

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Kay Sievers]

On Thu, 2005-03-10 at 22:45 -0800, Greg KH wrote:
> On Fri, Mar 11, 2005 at 01:04:05AM -0500, Eric S. Raymond wrote:
> > Greg KH <greg@kroah.com>:
> > > On Fri, Mar 11, 2005 at 12:20:54AM -0500, Eric S. Raymond wrote:
> > > > Greg KH <greg@kroah.com>:
> > > > > > The problem appears to be that whatever thread of control is creating 
> > > > > > the /dev/ttyUSB* node is running asynchronously with the hotplug
> > > > > > script and does not reliably (or even usually) create it before the
> > > > > > gpsd instance gets spawned and goes looking for the node.
> > > > > 
> > > > > Then use the /etc/dev.d/ interface instead.  That requires udev and a
> > > > > 2.6 kernel, but is the only way you can know exactly when the /dev entry
> > > > > is created.
> > > > 
> > > > Where is this documented?
> > > 
> > > In the udev documentation and a simple google search brings it up.
> > >
> > > > Even if the /etc/dev.d/ interface works, that doesn't really make it
> > > > acceptable that the /etc/hotplug.d/ interface is broken.  There is some
> > > > locking that ought to be happening and isn't.
> > > 
> > > The interface is not broken, you are trying to trigger off of two
> > > different hotplug events (one when the device appears, and a different
> > > one when the device node is to be created.)
> > 
> > If it's not broken, then it's not documented either.
> 
> You are watching for the wrong hotplug event, how can we document that?
> :)

If the hotplug helper in /proc/sys/kernel/hotplug is set
to /sbin/udevsend, what all major distributions seems to do today, than
there is nearly no difference between /etc/hotplug.d/ and /etc/dev.d/.
Both directories are handled after the node creation with the same
kernel hotplug event and have the name of the created/removed node in
the environment.

> > Or, at least, I don't see any documentation that tells me about a
> > second hotplug event when /dev/ttyUSB0 is created.

It is the _same_ hotplug event but an additional path of execution that
only happens if udev created/removed a device node or a renamed a
network interface. That was needed before we took over the hotplug event
management with udev, cause applications wanted to know the name of the
added device node. It is documented in the udev man page.

> Now, if I could
> > write a script that would fire on only only /dev/ttyUSB* creation events and
> > allow me to filter on the vendor/product ID, that would be fine -- those
> > are what I'm really interested in.

Yeah, I'm all for doing this with udev rules. It is already working on
my box. We just need to agree if and how we should do that. The plan is
to add hotplug scripts with udev rules and execute scripts based on the
same rule logic we use to name the device node.

Your hook into hotplug with a udev rule would look like this:
  ACTION="add", SYSFS{vendor}="GPS", SYSFS{product}="0815", NAME="gps", HOTPLUG="/usr/bin/gps-something"

> You can, just put your script into /etc/hotplug.d/tty and watch for the
> device name to be ttyUSB*.  Then walk the sysfs chain back up the
> directory to see the vendor and product id of the device attached to
> that ttyUSB device.

That should work, but that script will add a noticeable overhead, cause
it is executed for all hundreds of ttys on every bootup and for every vc
open and close. Something similar adds a ~8 seconds delay on bootup for
one of my slower boxes.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Eric S. Raymond]

Kay Sievers <kay.sievers@vrfy.org>:
> Yeah, I'm all for doing this with udev rules. It is already working on
> my box. We just need to agree if and how we should do that. The plan is
> to add hotplug scripts with udev rules and execute scripts based on the
> same rule logic we use to name the device node.
> 
> Your hook into hotplug with a udev rule would look like this:
>   ACTION="add", SYSFS{vendor}="GPS", SYSFS{product}="0815", NAME="gps", HOTPLUG="/usr/bin/gps-something"

Hmm, this looks interesting.  I'm looking at the udev man page, and it looks
as though rules like this might work:

# The Prolific Technology 2303 (commonly in tandem with SiRF chips)
BUS="usb" ACTION="add" SYSFS{vendor}="067b" SYSFS{product}="2303" \
		NAME="gps%e" \
		HOTPLUG="/usr/bin/gps-probe"
# FTDI 8U232AM
BUS="usb" ACTION="add" SYSFS{vendor}="0403" SYSFS{product}="6001" \
		NAME="gps%e" \
		HOTPLUG="/usr/bin/gps-probe"
# Cypress M8/CY7C64013 (DeLorme uses these)
BUS="usb" ACTION="add" SYSFS{vendor}="1163" SYSFS{product}="0100" \
		NAME="gps%e" \
		HOTPLUG="/usr/bin/gps-probe"

1. Am I correct that when triggered, these would create a device called
   /dev/gpsN for some enumerated N?

2. What is the lifetime of that device?  Under what circumstances is it
   removed?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Kay Sievers]

On Fri, 2005-03-11 at 08:38 -0500, Eric S. Raymond wrote:
> Kay Sievers <kay.sievers@vrfy.org>:
> > Yeah, I'm all for doing this with udev rules. It is already working on
> > my box. We just need to agree if and how we should do that. The plan is
> > to add hotplug scripts with udev rules and execute scripts based on the
> > same rule logic we use to name the device node.
> > 
> > Your hook into hotplug with a udev rule would look like this:
> >   ACTION="add", SYSFS{vendor}="GPS", SYSFS{product}="0815", NAME="gps", HOTPLUG="/usr/bin/gps-something"
> 
> Hmm, this looks interesting.  I'm looking at the udev man page, and it looks
> as though rules like this might work:

No, not today, not with the current version. We are just thought about
adding rule based program execution, cause it is similar to all the
match logic to name a device and it would be more elegant than the
current directory searching.

> # The Prolific Technology 2303 (commonly in tandem with SiRF chips)
> BUS="usb" ACTION="add" SYSFS{vendor}="067b" SYSFS{product}="2303" \
> 		NAME="gps%e" \
> 		HOTPLUG="/usr/bin/gps-probe"
> # FTDI 8U232AM
> BUS="usb" ACTION="add" SYSFS{vendor}="0403" SYSFS{product}="6001" \
> 		NAME="gps%e" \
> 		HOTPLUG="/usr/bin/gps-probe"
> # Cypress M8/CY7C64013 (DeLorme uses these)
> BUS="usb" ACTION="add" SYSFS{vendor}="1163" SYSFS{product}="0100" \
> 		NAME="gps%e" \
> 		HOTPLUG="/usr/bin/gps-probe"
> 
> 1. Am I correct that when triggered, these would create a device called
>    /dev/gpsN for some enumerated N?

Yes, this would be correct, if we decide to support the HOTPLUG key. For
now you need to put a script in /etc/dev.d/* that needs to check if a
DEVNAME=gps* is in the environment.

And the enumeration %e is an ugly thing in a world where devices can
come and go at any time. The result is unpredictable if you don't
connect and probe in the same order every time and under all situations
like suspend/resume, reboot, later plug-in.
If possible, these simple kind of enumerations should be avoided and the
names should depend on a unique attribute like a device serial number or
similar. Or the physical location can possibly be included in the device
node name if there is no better attribute.

> 2. What is the lifetime of that device?  Under what circumstances is it
>    removed?

The device will stay there as long as the kernel represents the device.
If the kernel discovers a USB-disconnect the node will be removed and a
newly connected device will get the lowest free %e number in the node
name.

Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Hannes Reinecke]

Kay Sievers wrote:
> On Thu, 2005-03-10 at 22:45 -0800, Greg KH wrote:
>>On Fri, Mar 11, 2005 at 01:04:05AM -0500, Eric S. Raymond wrote:
>>>Greg KH <greg@kroah.com>:
>>>>On Fri, Mar 11, 2005 at 12:20:54AM -0500, Eric S. Raymond wrote:
>>>>>Greg KH <greg@kroah.com>:
>>>>>>>The problem appears to be that whatever thread of control is creating 
>>>>>>>the /dev/ttyUSB* node is running asynchronously with the hotplug
>>>>>>>script and does not reliably (or even usually) create it before the
>>>>>>>gpsd instance gets spawned and goes looking for the node.
>>>>>>Then use the /etc/dev.d/ interface instead.  That requires udev and a
>>>>>>2.6 kernel, but is the only way you can know exactly when the /dev entry
>>>>>>is created.
>>>>>Where is this documented?
>>>>In the udev documentation and a simple google search brings it up.
>>>>
>>>>>Even if the /etc/dev.d/ interface works, that doesn't really make it
>>>>>acceptable that the /etc/hotplug.d/ interface is broken.  There is some
>>>>>locking that ought to be happening and isn't.
>>>>The interface is not broken, you are trying to trigger off of two
>>>>different hotplug events (one when the device appears, and a different
>>>>one when the device node is to be created.)
>>>If it's not broken, then it's not documented either.
>>You are watching for the wrong hotplug event, how can we document that?
>>:)
> 
> If the hotplug helper in /proc/sys/kernel/hotplug is set
> to /sbin/udevsend, what all major distributions seems to do today, than
> there is nearly no difference between /etc/hotplug.d/ and /etc/dev.d/.
True. Especially since hotplug.d is _always_ called after dev.d.
Having them in seperate directories just adds to the maintenance overhead.
> Yeah, I'm all for doing this with udev rules. It is already working on
> my box. We just need to agree if and how we should do that. The plan is
> to add hotplug scripts with udev rules and execute scripts based on the
> same rule logic we use to name the device node.
> 
> Your hook into hotplug with a udev rule would look like this:
>   ACTION="add", SYSFS{vendor}="GPS", SYSFS{product}="0815", NAME="gps", HOTPLUG="/usr/bin/gps-something"
> 
And that would be really nice.
Then we would have a truly fine-grained selection for which devices we
actually need to call scripts.
Booting with full event replay is slow enough as it is, any speed-up is
greatly welcome.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÃk
_______________________________________________
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: New hotplug interface is not working right for me

[Eric S. Raymond]

Kay Sievers <kay.sievers@vrfy.org>:
> No, not today, not with the current version. We are just thought about
> adding rule based program execution, cause it is similar to all the
> match logic to name a device and it would be more elegant than the
> current directory searching.

Agreed.  Mark me in favor of the feature, though not strongly attached to
it if anyone comes up with a better architectural approach.
 
> > # The Prolific Technology 2303 (commonly in tandem with SiRF chips)
> > BUS="usb" ACTION="add" SYSFS{vendor}="067b" SYSFS{product}="2303" \
> > 		NAME="gps%e" \
> > 		HOTPLUG="/usr/bin/gps-probe"
> > # FTDI 8U232AM
> > BUS="usb" ACTION="add" SYSFS{vendor}="0403" SYSFS{product}="6001" \
> > 		NAME="gps%e" \
> > 		HOTPLUG="/usr/bin/gps-probe"
> > # Cypress M8/CY7C64013 (DeLorme uses these)
> > BUS="usb" ACTION="add" SYSFS{vendor}="1163" SYSFS{product}="0100" \
> > 		NAME="gps%e" \
> > 		HOTPLUG="/usr/bin/gps-probe"
> > 
> > 1. Am I correct that when triggered, these would create a device called
> >    /dev/gpsN for some enumerated N?
> 
> Yes, this would be correct, if we decide to support the HOTPLUG key. For
> now you need to put a script in /etc/dev.d/* that needs to check if a
> DEVNAME=gps* is in the environment.

I think I see what you're getting at here, but would you either be explicit
about the activation rule for /etc/dev.d/ scripts or point me at documentation
of same?

> And the enumeration %e is an ugly thing in a world where devices can
> come and go at any time. The result is unpredictable if you don't
> connect and probe in the same order every time and under all situations
> like suspend/resume, reboot, later plug-in.
> If possible, these simple kind of enumerations should be avoided and the
> names should depend on a unique attribute like a device serial number or
> similar. Or the physical location can possibly be included in the device
> node name if there is no better attribute.

Gotcha.   For my application, 

(a) Name uniqueness is valuable but name persistence is not necessary or even
particularly useful -- so %e would be functionally OK.  

(b) I fundamentally don't care what the uniquifier is.

> > 2. What is the lifetime of that device?  Under what circumstances is it
> >    removed?
> 
> The device will stay there as long as the kernel represents the device.
> If the kernel discovers a USB-disconnect the node will be removed and a
> newly connected device will get the lowest free %e number in the node
> name.

OK, that's exactly the answer I expected, even to the rule for %e allocation.  
Good to have it confirmed.

One more question: what happens if I leave out the ACTION clause?  Ideally,
I'd like the device node to still be created on add and deleted on remove,
but with the script waking up on both actions.

The udev documentation looks pretty good, but it could stand to be a touch more
explicit in spots.  If I generate patches to fix this, where should I send 
them?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Kay Sievers]

On Fri, 2005-03-11 at 10:40 -0500, Eric S. Raymond wrote:
> Kay Sievers <kay.sievers@vrfy.org>:
> > No, not today, not with the current version. We are just thought about
> > adding rule based program execution, cause it is similar to all the
> > match logic to name a device and it would be more elegant than the
> > current directory searching.
> 
> Agreed.  Mark me in favor of the feature, though not strongly attached to
> it if anyone comes up with a better architectural approach.
>  
> > > # The Prolific Technology 2303 (commonly in tandem with SiRF chips)
> > > BUS="usb" ACTION="add" SYSFS{vendor}="067b" SYSFS{product}="2303" \
> > > 		NAME="gps%e" \
> > > 		HOTPLUG="/usr/bin/gps-probe"
> > > # FTDI 8U232AM
> > > BUS="usb" ACTION="add" SYSFS{vendor}="0403" SYSFS{product}="6001" \
> > > 		NAME="gps%e" \
> > > 		HOTPLUG="/usr/bin/gps-probe"
> > > # Cypress M8/CY7C64013 (DeLorme uses these)
> > > BUS="usb" ACTION="add" SYSFS{vendor}="1163" SYSFS{product}="0100" \
> > > 		NAME="gps%e" \
> > > 		HOTPLUG="/usr/bin/gps-probe"
> > > 
> > > 1. Am I correct that when triggered, these would create a device called
> > >    /dev/gpsN for some enumerated N?
> > 
> > Yes, this would be correct, if we decide to support the HOTPLUG key. For
> > now you need to put a script in /etc/dev.d/* that needs to check if a
> > DEVNAME=gps* is in the environment.
> 
> I think I see what you're getting at here, but would you either be explicit
> about the activation rule for /etc/dev.d/ scripts or point me at documentation
> of same?

After node creation/removal udev executes the following scripts:
  /etc/dev.d/$DEVNAME/*.dev
  /etc/dev.d/$SUBSYSTEM/*.dev
  /etc/dev.d/default/*.dev

You may place your executable script or a symlink to it as:
  /etc/dev.d/tty/gps.dev

and check for ACTION and DEVNAME values to sort out wrong devices and
match your action.

> > And the enumeration %e is an ugly thing in a world where devices can
> > come and go at any time. The result is unpredictable if you don't
> > connect and probe in the same order every time and under all situations
> > like suspend/resume, reboot, later plug-in.
> > If possible, these simple kind of enumerations should be avoided and the
> > names should depend on a unique attribute like a device serial number or
> > similar. Or the physical location can possibly be included in the device
> > node name if there is no better attribute.
> 
> Gotcha.   For my application, 
> 
> (a) Name uniqueness is valuable but name persistence is not necessary or even
> particularly useful -- so %e would be functionally OK.  
> 
> (b) I fundamentally don't care what the uniquifier is.
>
> > > 2. What is the lifetime of that device?  Under what circumstances is it
> > >    removed?
> > 
> > The device will stay there as long as the kernel represents the device.
> > If the kernel discovers a USB-disconnect the node will be removed and a
> > newly connected device will get the lowest free %e number in the node
> > name.
> 
> OK, that's exactly the answer I expected, even to the rule for %e allocation.  
> Good to have it confirmed.
> 
> One more question: what happens if I leave out the ACTION clause?  Ideally,
> I'd like the device node to still be created on add and deleted on remove,
> but with the script waking up on both actions.

That's the default. The scripts are invoked on "add" and "remove". The
DEVNAME value for the "remove" event comes from the udev database, not
from a rule. The ACTION key will only be needed if we do hotplug script
execution by rule.

> The udev documentation looks pretty good, but it could stand to be a touch more
> explicit in spots.  If I generate patches to fix this, where should I send 
> them?

That would be nice. To that list is fine, here happens all the udev
discussion.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Eric S. Raymond]

Kay Sievers <kay.sievers@vrfy.org>:
> After node creation/removal udev executes the following scripts:
>   /etc/dev.d/$DEVNAME/*.dev
>   /etc/dev.d/$SUBSYSTEM/*.dev
>   /etc/dev.d/default/*.dev
> 
> You may place your executable script or a symlink to it as:
>   /etc/dev.d/tty/gps.dev
> 
> and check for ACTION and DEVNAME values to sort out wrong devices and
> match your action.

Will gps.dev will be executed on every tty activation, or just
when a gps%e node gets created?   

If, as I suspect, the answer is "every tty activation", then the
boot-time lag due to virtual consoles that someone pointed out is a
real performance issue -- slowing down boot is very anti-social behavior
which I don't want to contribute to.  There is a udev design issue here
which could be addressed in several ways:

1. Split up the tty subsystem. Perhaps there should be a defined 
subsystem for serial-over-USB devices?  Perhaps virtual ttys should
go into a pty subsystem, with only real serial ports in tty?  

Or maybe the right subsystem map would look like this:

    tty -- all tty devices
    pty -- virtual consoles and software ttys
    usbtty -- hotplug serial-over-USB devices
    rstty  -- real hardware serial ports

2. Allow device or subsystem wildcarding in directory names 
for finer control of when the scripts activate.

> > One more question: what happens if I leave out the ACTION clause?  Ideally,
> > I'd like the device node to still be created on add and deleted on remove,
> > but with the script waking up on both actions.
> 
> That's the default. The scripts are invoked on "add" and "remove". The
> DEVNAME value for the "remove" event comes from the udev database, not
> from a rule. The ACTION key will only be needed if we do hotplug script
> execution by rule.

Again, the answer I expected.  Good.  The udev architecture is looking 
impressively well-done to me so far.
 
> > The udev documentation looks pretty good, but it could stand to be a
> > touch more explicit in spots.  If I generate patches to fix this, where
> > should I send them?
> 
> That would be nice. To that list is fine, here happens all the udev
> discussion.

Will do.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Kay Sievers]

On Fri, 2005-03-11 at 12:03 -0500, Eric S. Raymond wrote:
> Kay Sievers <kay.sievers@vrfy.org>:
> > After node creation/removal udev executes the following scripts:
> >   /etc/dev.d/$DEVNAME/*.dev
> >   /etc/dev.d/$SUBSYSTEM/*.dev
> >   /etc/dev.d/default/*.dev
> > 
> > You may place your executable script or a symlink to it as:
> >   /etc/dev.d/tty/gps.dev
> > 
> > and check for ACTION and DEVNAME values to sort out wrong devices and
> > match your action.
> 
> Will gps.dev will be executed on every tty activation, or just
> when a gps%e node gets created?   

Yes, that is right.

> If, as I suspect, the answer is "every tty activation", then the
> boot-time lag due to virtual consoles that someone pointed out is a
> real performance issue -- slowing down boot is very anti-social behavior
> which I don't want to contribute to.  There is a udev design issue here
> which could be addressed in several ways:
> 
> 1. Split up the tty subsystem. Perhaps there should be a defined 
> subsystem for serial-over-USB devices?  Perhaps virtual ttys should
> go into a pty subsystem, with only real serial ports in tty?  
>
> Or maybe the right subsystem map would look like this:
> 
>     tty -- all tty devices
>     pty -- virtual consoles and software ttys
>     usbtty -- hotplug serial-over-USB devices
>     rstty  -- real hardware serial ports

This would be a very big change to the kernel just for the sake of a new
name. I don't expect something like that to happen. :)

> 2. Allow device or subsystem wildcarding in directory names 
> for finer control of when the scripts activate.

Hmm, I'm not sure. I don't like these directories anymore. All the
scripts need to check if they are invoked for the right ACTION and the
right device, you don't have stuff like sysfs attributes to match
against...

Here is my number: :)
3. Add a rule file in /etc/udev/rules.d/ and match with that rule
against any value that this device event exposes. A successful rule adds
the program to a list of programs to be executed after the node is
handled.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Christian Zoz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1684 bytes --]

On Fri, Mar 11, Kay Sievers wrote:
> On Fri, 2005-03-11 at 08:38 -0500, Eric S. Raymond wrote:
> > Kay Sievers <kay.sievers@vrfy.org>:
> > > Yeah, I'm all for doing this with udev rules. It is already working on
> > > my box. We just need to agree if and how we should do that. The plan is
> > > to add hotplug scripts with udev rules and execute scripts based on the
> > > same rule logic we use to name the device node.
> > > 
> > > Your hook into hotplug with a udev rule would look like this:
> > >   ACTION="add", SYSFS{vendor}="GPS", SYSFS{product}="0815", NAME="gps", HOTPLUG="/usr/bin/gps-something"
> > 
> > Hmm, this looks interesting.  I'm looking at the udev man page, and it looks
> > as though rules like this might work:
> 
> No, not today, not with the current version. We are just thought about
> adding rule based program execution, cause it is similar to all the
> match logic to name a device and it would be more elegant than the
> current directory searching.

Kay, your ideas are very good. Go on and make this happen. I like
this way much more then the current multiplexer.

-- 

ciao, christian

睡眠不足はいい仕事の敵だ。


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&opÌk
_______________________________________________
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: New hotplug interface is not working right for me

[Eric S. Raymond]

Kay Sievers <kay.sievers@vrfy.org>:
> > Will gps.dev will be executed on every tty activation, or just
> > when a gps%e node gets created?   
> 
> Yes, that is right.

Your answer is ambiguous.  Which arm of the disjunct are you referring to?

(Alas, I fear I know the answer.)

> 3. Add a rule file in /etc/udev/rules.d/ and match with that rule
> against any value that this device event exposes. A successful rule adds
> the program to a list of programs to be executed after the node is
> handled.

That would work for me.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Kay Sievers]

On Fri, 2005-03-11 at 14:07 -0500, Eric S. Raymond wrote:
> Kay Sievers <kay.sievers@vrfy.org>:
> > > Will gps.dev will be executed on every tty activation, or just
> > > when a gps%e node gets created?   
> > 
> > Yes, that is right.
> 
> Your answer is ambiguous.  Which arm of the disjunct are you referring to?

The first one. It will get executed for every tty.

Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Eric S. Raymond]

Kay Sievers <kay.sievers@vrfy.org>:
> On Fri, 2005-03-11 at 14:07 -0500, Eric S. Raymond wrote:
> > Kay Sievers <kay.sievers@vrfy.org>:
> > > > Will gps.dev will be executed on every tty activation, or just
> > > > when a gps%e node gets created?   
> > > 
> > > Yes, that is right.
> > 
> > Your answer is ambiguous.  Which arm of the disjunct are you referring to?
> 
> The first one. It will get executed for every tty.

That's what I thought you were going to tell me.  Oh, well.

OK.  My descision is that I'm going to stick with old-style hotplug
until udev is a bit more mature.  I have a hotplug agent that works,
and I doubt distro makers will break it in the forseeable future, because
tremendously popular USB cameras rely on the same mechanism.

But I like the udev approach better, and when It grows the right kind
of event filtering that I needn't worry about causing nasty amounts of
boot lag, I'll move to it.

I support the proposed HOTPLUG key and Kay's proposal for an
additional rules file.  But I'm not attached to either.

Thanks for the help and explanations.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Darren Salt]

I demand that Kay Sievers may or may not have written...

[snip]
> If the hotplug helper in /proc/sys/kernel/hotplug is set to /sbin/udevsend,
> what all major distributions seems to do today,

FWIW, it's currently /sbin/hotplug here (sarge).

[snip]

-- 
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   <URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html>

Envy is a pain of mind that successful men cause their neighbors.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Marco d'Itri]

On Mar 14, Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:

> > If the hotplug helper in /proc/sys/kernel/hotplug is set to /sbin/udevsend,
> > what all major distributions seems to do today,
> FWIW, it's currently /sbin/hotplug here (sarge).
Not for long, at least if the debian kernel team will ship a fixed
2.6.8 (or if you install your own >= 2.6.10 kernel).

-- 
ciao,
Marco


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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: New hotplug interface is not working right for me

[Kay Sievers]

On Mon, 2005-03-14 at 17:06 +0000, Darren Salt wrote:
> I demand that Kay Sievers may or may not have written...
> 
> [snip]
> > If the hotplug helper in /proc/sys/kernel/hotplug is set to /sbin/udevsend,
> > what all major distributions seems to do today,
> 
> FWIW, it's currently /sbin/hotplug here (sarge).

If you use a recent udev version, udevsend/udevd can manage the whole
hotplug handling by taking over the kernel spawned event process.

udev will first wait for sysfs to populate, create the node and then
execute the hotplug scripts. This way your scripts will not need to wait
for sysfs to show up and the name of the device node in in the
environment as DEVNAME.

The kernel events have a sequence number and udevd will reorder the
events. That way the scripts in /etc/hotplug.d/ will be executed in the
right order. It also cares about the serialization of events they belong
to the same device sequence. Your hotplug hooks can be sure that the
event for /dev/hda has completely finished before the event
for /dev/hda1 is executed.

This solves the problem to implement the complex logic for every hotplug
consumer again and again. As an example, the latest HAL version depends
on that and cannot work without udev's managed hotplug events.

Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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