From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric S. Raymond" Date: Fri, 11 Mar 2005 17:03:32 +0000 Subject: Re: New hotplug interface is not working right for me Message-Id: <20050311170332.GA21004@thyrsus.com> List-Id: References: <20050311060405.GA16141@thyrsus.com> In-Reply-To: <20050311060405.GA16141@thyrsus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Kay Sievers : > 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. -- Eric S. Raymond ------------------------------------------------------- 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_id396&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