Re: status of /etc/hotplug/usb/

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, Dec 02, 2005 at 08:42:05PM +0100, Andreas Jellinghaus wrote:
> Kay Sievers wrote:
> > Everything that is called "hotplug" should go, yes. :)
> 
> ok, thanks. does that include the linux kernel hotplug
> mechanism? AFAIK there is the old /proc/sys/kernel/hotplug
> based exec mechanism and a new netlink interface. will either
> or both die?

The forking of a event helper should be disabled. Udevd will listen to
kernel uevents only.

> >> what the replacement is (I guess udev rules files),
> > 
> > For a lot of simple things udev rules are a good replacement, right.
> > For everthing advanced, more complicated, or touching Desktop
> > applications, HAL is the way to go. SUSE uses HAL(simple hook-in)
> > for openct.
> 
> from openct point of view, it will deliver the same result?
> i.e. hardware is attached, and openct-control attach ... is
> started, if it is a hardware we support (I can add a fitting
> file for hal).
> 
> does hal, udev or anything else provide coldplugging to me?

HAl does. Udev may not, if the utilities are not on the root filesystem.
You can work around this, but HAL solves all these problems without any
hacks.

> what openct currently does is this: the init script is
> started and openct-control prepares everything (a status
> file), starts fixed configured readers, and does a usb
> scan for hotplugable readers it supports. it would be nicer
> to send a feedback to some system "I'm ready know, if you
> have any hardware for the list I gave you, please send
> events". 

You can match against all properties in HAL and let HAL call anything
you like.

> > There is no paper, it just died silently. :)
> > 
> > The rules can do everything that the map files did in the past. But as
> > said, HAL is the proper place to do this. It can just do what
> > /etc/hotplug/usb did, but ideally, any advanced hardware setup
> > would expose its state trough HAL to the whole system with appropriate
> > signals and properties on the corresponding HAL device object.
> 
> ok, I was about to add a udev rules file for debian. will talk
> to them about using hal as alternative.
> 
> > That way all applications interested in a certain class of hardware
> > just get the proper information and can adopt to the changing setup.
> 
> I understood hal always as some kind of message bus? I hope I don't
> need to run a daemon or anything to receive signals? Since I can
> express what I'm interested in in modules map compatible format
> (and I guess many other apps can do so too), it would be nice
> if some central authority could do all that matching. otherwise
> we would write the same code in each usb hotplug'able application,
> I guess.

You can just hook into the HAL device handling process. That's much
more flexible and provides the proper desktop integration to announce
such a device.

Ka


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&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