Re: New hotplug interface is not working right for me

["Eric S. Raymond" <esr@thyrsus.com>]

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