status of /etc/hotplug/usb/

status of /etc/hotplug/usb/

[Andreas Jellinghaus]

Hi,

I read that debian killed that directory and thus
openct was no longer working(1).

So I wonder what the position of the hotplug and udev
people here is on /etc/hotplug/usb/, what the replacement
is (I guess udev rules files), and if there is some
paper with reasoning and suggestions for the transition.
any link would be fine.

Regards, Andreas
(1) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug38699
p.s. if anyone has a link for the "NEWS.Debian" file mentioned
in the bugmail, that would be nice.



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

Re: status of /etc/hotplug/usb/

[Kay Sievers]

On Fri, Dec 02, 2005 at 07:08:15PM +0100, Andreas Jellinghaus wrote:
> Hi,
> 
> I read that debian killed that directory and thus
> openct was no longer working(1).
> 
> So I wonder what the position of the hotplug and udev
> people here is on /etc/hotplug/usb/

Everything that is called "hotplug" should go, yes. :)

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

> and if there is some > paper with reasoning and suggestions
> for the transition. any link would be fine.

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.

That way all applications interested in a certain class of hardware
just get the proper information and can adopt to the changing setup.

Kay


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

Re: status of /etc/hotplug/usb/

[Andreas Jellinghaus]

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?

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

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

Will join the hal mailing list and readup on the recent documentation.

thanks!

Andreas



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

Re: status of /etc/hotplug/usb/

[Kay Sievers]

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