http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9f8b17e643fe6aa505629658445849397bda4e4f
removes MODALIAS from one of the events, this breaks user space applications
like openct - everything that depends on getting an event that has both the
DEVICE= path to the usb device and any information on the interface, so it
can check if the device is something it supports (in case of openct:
smart card reader, i.e. bInterfaceClass 0b).
The text does not mention MODALIAS nor the reason for it's removal.
sorry for being late, this problem shows up with 2.6.21 -> 2.6.22 changes.
Andreas
On Fri, 17 Aug 2007, Andreas Jellinghaus [c] wrote:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9f8b17e643fe6aa505629658445849397bda4e4f
>
> removes MODALIAS from one of the events, this breaks user space applications
> like openct - everything that depends on getting an event that has both the
> DEVICE= path to the usb device and any information on the interface, so it
> can check if the device is something it supports (in case of openct:
> smart card reader, i.e. bInterfaceClass 0b).
There is no MODALIAS for these events because there are no drivers for
the devices they report. Perhaps you should be looking at
usb_if_uevent() in drivers/usb/core/message.c instead. Is the problem
that this routine doesn't set DEVICE, BUSNUM, or DEVNUM?
Alan Stern
Am Freitag, 17. August 2007 schrieb Alan Stern:
> On Fri, 17 Aug 2007, Andreas Jellinghaus [c] wrote:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit
> >diff;h=9f8b17e643fe6aa505629658445849397bda4e4f
> >
> > removes MODALIAS from one of the events, this breaks user space
> > applications like openct - everything that depends on getting an event
> > that has both the DEVICE= path to the usb device and any information on
> > the interface, so it can check if the device is something it supports (in
> > case of openct: smart card reader, i.e. bInterfaceClass 0b).
>
> There is no MODALIAS for these events because there are no drivers for
> the devices they report. Perhaps you should be looking at
> usb_if_uevent() in drivers/usb/core/message.c instead. Is the problem
> that this routine doesn't set DEVICE, BUSNUM, or DEVNUM?
I need some kernel event that has both DEVICE and MODALIAS set.
up to including kernel 2.6.21 this seems to come from
drivers/usb/core/driver.c if I read the code correctly, and then
it was removed.
udevmonitor --kernel --environment shows one event with both on 2.6.21 plain,
but not on 2.6.22 plain.
Regards, Andreas
On Fri, 17 Aug 2007, Andreas Jellinghaus [c] wrote:
> I need some kernel event that has both DEVICE and MODALIAS set.
> up to including kernel 2.6.21 this seems to come from
> drivers/usb/core/driver.c if I read the code correctly, and then
> it was removed.
>
> udevmonitor --kernel --environment shows one event with both on 2.6.21 plain,
> but not on 2.6.22 plain.
Does this patch improve matters?
Alan Stern
Index: 2.6.22/drivers/usb/core/message.c
===================================================================
--- 2.6.22.orig/drivers/usb/core/message.c
+++ 2.6.22/drivers/usb/core/message.c
@@ -1344,6 +1344,30 @@ static int usb_if_uevent(struct device *
usb_dev = interface_to_usbdev(intf);
alt = intf->cur_altsetting;
+#ifdef CONFIG_USB_DEVICEFS
+ /* If this is available, userspace programs can directly read
+ * all the device descriptors we don't tell them about. Or
+ * act as usermode drivers.
+ */
+ if (add_uevent_var(envp, num_envp, &i,
+ buffer, buffer_size, &length,
+ "DEVICE=/proc/bus/usb/%03d/%03d",
+ usb_dev->bus->busnum, usb_dev->devnum))
+ return -ENOMEM;
+#endif
+
+ if (add_uevent_var(envp, num_envp, &i,
+ buffer, buffer_size, &length,
+ "BUSNUM=%03d",
+ usb_dev->bus->busnum))
+ return -ENOMEM;
+
+ if (add_uevent_var(envp, num_envp, &i,
+ buffer, buffer_size, &length,
+ "DEVNUM=%03d",
+ usb_dev->devnum))
+ return -ENOMEM;
+
if (add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"INTERFACE=%d/%d/%d",
Am Freitag, 17. August 2007 schrieben Sie:
> On Fri, 17 Aug 2007, Andreas Jellinghaus [c] wrote:
> > I need some kernel event that has both DEVICE and MODALIAS set.
> > up to including kernel 2.6.21 this seems to come from
> > drivers/usb/core/driver.c if I read the code correctly, and then
> > it was removed.
> >
> > udevmonitor --kernel --environment shows one event with both on 2.6.21
> > plain, but not on 2.6.22 plain.
>
> Does this patch improve matters?
yes, thanks, it does. can you add PRODUCT as well?
remembered too late that my scripts at least use it too.
but that one is no big issue, MODALIAS has the same information
so I could use that information. but other people might use it.
Regards, Andreas
On Sat, 18 Aug 2007, Andreas Jellinghaus [c] wrote:
> Am Freitag, 17. August 2007 schrieben Sie:
> > On Fri, 17 Aug 2007, Andreas Jellinghaus [c] wrote:
> > > I need some kernel event that has both DEVICE and MODALIAS set.
> > > up to including kernel 2.6.21 this seems to come from
> > > drivers/usb/core/driver.c if I read the code correctly, and then
> > > it was removed.
> > >
> > > udevmonitor --kernel --environment shows one event with both on 2.6.21
> > > plain, but not on 2.6.22 plain.
> >
> > Does this patch improve matters?
>
> yes, thanks, it does. can you add PRODUCT as well?
> remembered too late that my scripts at least use it too.
> but that one is no big issue, MODALIAS has the same information
> so I could use that information. but other people might use it.
I could, but I don't know whether any of this would be accepted for
2.6.22.stable. It might not be too late to get into 2.6.23...
Alan Stern
Am Montag, 20. August 2007 schrieb Alan Stern:
> I could, but I don't know whether any of this would be accepted for
> 2.6.22.stable. It might not be too late to get into 2.6.23...
even without it is a first step. I hope it gets accepted into both,
as 2.6.22 broke kernel<->user space interfaces and those should
never change (or only after a long time with announcement, time
for switching to a new one etc).
Thanks for your work!
Regards, Andreas
On Fri, Aug 17, 2007 at 04:22:04PM +0200, Andreas Jellinghaus [c] wrote:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9f8b17e643fe6aa505629658445849397bda4e4f
>
> removes MODALIAS from one of the events,
Which event?
If you enable CONFIG_USB_DEVICE_CLASS, does everything work the same
again?
> this breaks user space applications like openct - everything that
> depends on getting an event that has both the DEVICE= path to the usb
> device and any information on the interface, so it can check if the
> device is something it supports (in case of openct: smart card reader,
> i.e. bInterfaceClass 0b).
What specific udev rule are you matching against here that is now
broken?
> The text does not mention MODALIAS nor the reason for it's removal.
The reason is we don't need the usb_device class anymore, but we still
provide for the compatibility if you have an old distro with old udev
rules that is expecting it (only rule we ran into was the one for the
usbfs /dev nodes, but there might be more.)
confused,
greg k-h
Am Dienstag, 21. August 2007 schrieb Greg KH:
> On Fri, Aug 17, 2007 at 04:22:04PM +0200, Andreas Jellinghaus [c] wrote:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit
> >diff;h=9f8b17e643fe6aa505629658445849397bda4e4f
> >
> > removes MODALIAS from one of the events,
>
> Which event?
here is the event with kernel 2.6.21:
UEVENT[1187683991.583384]
add /devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1.7/2-1.7:1.0 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1.7/2-1.7:1.0
SUBSYSTEM=usb
SEQNUM=3070
PHYSDEVBUS=usb
DEVICE=/proc/bus/usb/002/006
PRODUCT=8e6/3438/100
TYPE=0/0/0
INTERFACE=11/0/0
MODALIAS=usb:v08E6p3438d0100dc00dsc00dp00ic0Bisc00ip00
note: it has both - MODALIAS and DEVICE.
here is the event with kernel 2.6.22 (with CONFIG_USB_DEVICE_CLASS):
UEVENT[1187684539.588975]
add /devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1.7/2-1.7:1.0 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1.7/2-1.7:1.0
SUBSYSTEM=usb
SEQNUM=3029
DEVTYPE=usb_interface
PHYSDEVBUS=usb
INTERFACE=11/0/0
MODALIAS=usb:v08E6p3438d0100dc00dsc00dp00ic0Bisc00ip00
you see, it is missing DEVICE and PRODUCT and TYPE
and here is the event with kernel 2.6.22 with alans patch and
CONFIG_USB_DEVICE_CLASS:
UEVENT[1187684125.860105]
add /devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1.7/2-1.7:1.0 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1.7/2-1.7:1.0
SUBSYSTEM=usb
SEQNUM=3029
DEVTYPE=usb_interface
PHYSDEVBUS=usb
DEVICE=/proc/bus/usb/002/006
BUSNUM=002
DEVNUM=006
INTERFACE=11/0/0
MODALIAS=usb:v08E6p3438d0100dc00dsc00dp00ic0Bisc00ip00
it still misses PRODUCT and TYPE, for real compatibility those should be added
too. (I can work around that, as the PRODUCT information is part of MODALIAS
and I don't use TYPE.)
> If you enable CONFIG_USB_DEVICE_CLASS, does everything work the same
> again?
both with CONFIG_USB_DEVICE_CLASS. would it change anything here?
> What specific udev rule are you matching against here that is now
> broken?
still trying to get it to work, so far I try:
SUBSYSTEM!="usb", GOTO="openct_usb_rules_end"
ACTION!="add", GOTO="openct_usb_rules_end"
ENV{MODALIAS}=="usb:v0973p0001*", RUN+="/lib/udev/openct_usb"
ENV{MODALIAS}=="usb:*ic0Bisc00*", RUN+="/lib/udev/openct_usb"
LABEL="openct_usb_rules_end"
this should work?
> > The text does not mention MODALIAS nor the reason for it's removal.
>
> The reason is we don't need the usb_device class anymore, but we still
> provide for the compatibility if you have an old distro with old udev
> rules that is expecting it (only rule we ran into was the one for the
> usbfs /dev nodes, but there might be more.)
I'm no udev expert, but old kernels provide an event with all three
informations I care about: MODALIAS, DEVICE and PRODUCT. this is changed,
and I don't understand what it has to do with usb_device class.
but I can say that without any event that has all three (or at least the first
two - I can create PRODUCT from MODALIAS i think), I would need to redesign
how openct finds out if new devices are plugged in. long term I might need
to do so anyway, but right now people complain "it doesn't work" to me, and
the culprit seems to be the kernel to me - 2.6.21 works, 2.6.22 does not.
Now I'm working on getting openct udev rules and handling script fixed so
they work at least with alans patch and work around missing PRODUCT.
Regards, Andreas
On Tue, 2007-08-21 at 00:36 -0700, Greg KH wrote:
> On Fri, Aug 17, 2007 at 04:22:04PM +0200, Andreas Jellinghaus [c] wrote:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9f8b17e643fe6aa505629658445849397bda4e4f
> >
> > removes MODALIAS from one of the events,
>
> Which event?
>
> If you enable CONFIG_USB_DEVICE_CLASS, does everything work the same
> again?
>
> > this breaks user space applications like openct - everything that
> > depends on getting an event that has both the DEVICE= path to the usb
> > device and any information on the interface, so it can check if the
> > device is something it supports (in case of openct: smart card reader,
> > i.e. bInterfaceClass 0b).
>
> What specific udev rule are you matching against here that is now
> broken?
>
> > The text does not mention MODALIAS nor the reason for it's removal.
>
> The reason is we don't need the usb_device class anymore, but we still
> provide for the compatibility if you have an old distro with old udev
> rules that is expecting it (only rule we ran into was the one for the
> usbfs /dev nodes, but there might be more.)
>
> confused,
Hmm, I'm a bit confused too. :)
The subject says MODALIAS was removed, but I don't think that it ever
was there for a usb-device event. And sure, it's still there for a
usb-interface event.
Andreas, do I read this right, you miss:
DEVICE, PRODUCT, TYPE
in the usb-interface event, and they only exist in the usb-device event?
And MODALIAS is not what you miss, and the subject of the mail is
misleading?
Note:
DEVICE only exists when USB_DEVICE_CLASS=y, because it unfortunately is
prefixed with the /proc mount path, which doesn't exist when the /proc
device node support is not compiled in, so nothing should depend on the
existence of DEVICE. Most of the recent distros don't mount or configure
usbfs anymore, but use /dev/bus/usb/ device nodes, which can handle
access control lists for local users.
Is this patch fixing your problem?
From: Kay Sievers <[email protected]>
Subject: usb: add PRODUCT, TYPE to usb-interface events
Signed-off-by: Kay Sievers <[email protected]>
---
message.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index b6bd05e..3b57d53 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1358,6 +1358,30 @@ static int usb_if_uevent(struct device *dev, char **envp, int num_envp,
usb_dev = interface_to_usbdev(intf);
alt = intf->cur_altsetting;
+#ifdef CONFIG_USB_DEVICEFS
+ if (add_uevent_var(envp, num_envp, &i,
+ buffer, buffer_size, &length,
+ "DEVICE=/proc/bus/usb/%03d/%03d",
+ usb_dev->bus->busnum, usb_dev->devnum))
+ return -ENOMEM;
+#endif
+
+ if (add_uevent_var(envp, num_envp, &i,
+ buffer, buffer_size, &length,
+ "PRODUCT=%x/%x/%x",
+ le16_to_cpu(usb_dev->descriptor.idVendor),
+ le16_to_cpu(usb_dev->descriptor.idProduct),
+ le16_to_cpu(usb_dev->descriptor.bcdDevice)))
+ return -ENOMEM;
+
+ if (add_uevent_var(envp, num_envp, &i,
+ buffer, buffer_size, &length,
+ "TYPE=%d/%d/%d",
+ usb_dev->descriptor.bDeviceClass,
+ usb_dev->descriptor.bDeviceSubClass,
+ usb_dev->descriptor.bDeviceProtocol))
+ return -ENOMEM;
+
if (add_uevent_var(envp, num_envp, &i,
buffer, buffer_size, &length,
"INTERFACE=%d/%d/%d",
Am Dienstag, 21. August 2007 schrieb Kay Sievers:
> The subject says MODALIAS was removed, but I don't think that it ever
> was there for a usb-device event. And sure, it's still there for a
> usb-interface event.
>
> Andreas, do I read this right, you miss:
> DEVICE, PRODUCT, TYPE
> in the usb-interface event, and they only exist in the usb-device event?
>
> And MODALIAS is not what you miss, and the subject of the mail is
> misleading?
I'm coming from a different side, as I know not much about the kernel
internals. but if I run "udevmonitor --kernel --environment" and then
plug in some usb device (e.g. my smart card reader):
- on 2.6.21 there are two events with DEVICE and the second has DEVICE
and MODALIAS set. thats what I need.
- on 2.6.22 there are two events: one has DEVICE and one has MODALIAS,
but neither has both. this breaks openct.
PRODUCT and TYPE are also missing from the event that has MODALIAS in 2.6.22.
> Note:
> DEVICE only exists when USB_DEVICE_CLASS=y,
yes, I tested with 2.6.22 with that turned on. if setting this to no breaks
openct, then we should not easily deprecate it. instead we first need a
migration plan, than we need enough time to get a new version of openct to
every user that works with the new and the old kernel, and only after that is
done we can deprecate it, suggest to turn it of, and even later remove it.
please keep such a timing, many other parts of the kernel follow these rules
too. Documentation/feature-removal-schedule.txt should be updated to contain
exact information how long we can count on USB_DEVICE_CLASS=y etc.
> because it unfortunately is
> prefixed with the /proc mount path, which doesn't exist when the /proc
> device node support is not compiled in
I'm fine with that. people have used that one for years, and they still should
have it. if you suggest people should use /dev/bus/usb instead, we need the
same plan: migration plan first, enough time to adjust the software and get
it to the users, then deprecation plan and later a removeal. maybe add an
entry to feature-removal-schedule.txt too? even if only to let everyone
incl. distribution makers know, that /dev/bus/usb is not an instant
replacement for /proc/bus/usb, even if it seems so for some software.
> so nothing should depend on the existence of DEVICE.
well, first I need the migration plan: so far I could depend on it,
please give me the new thing that I can depend on. it needs to work
with old kernels too (something like a 6month to 2year window of kernel,
we shouldn't force people to upgrade and downgrade kernel and other
apps unless it is absolutely necessary).
all discussions I remember ended nowhere: there is no alternative
for the combination of DEVICE and MODALIAS. I tried /dev/bus/usb
and sysfs, but it didn't work out because of timing and race conditions
and other problems you summed up as "there is no sane way" ...
but maybe I got this wrong, so I'm asking once more: DEVICE plus MODALIAS
is working fine for me, but I'm happy to migrate. what is the plan,
what shall I do instead? and what is the minimum kernel and udev etc.
required for this alternative to work? and how long can I count on the
old style still to work?
> Most of the recent distros don't mount or configure
> usbfs anymore, but use /dev/bus/usb/ device nodes, which can handle
> access control lists for local users.
that would be a huge problem, as I know no alternative to DEVICE with
/proc/bus/usb. the kernel tells me about new /proc/bus/usb devices,
but who tells me about any /dev/bus/usb device? as far as I know: no one.
please correct me if I'm wrong, I would be real happy to migrate to a working
new solution, if it fixes the problem and gives me time for new adventures.
> Is this patch fixing your problem?
will give it a try and respond later. thanks!
Regards, Andreas
thanks, the patch works great!
would be nice if it could be send to the stable team as well
(I think a number of distributions want to use 2.6.22 as base
for there next release, and I would be happy if users had the patch
in it).
sorry for creating confusion: initially I thought MODALIAS had been removed,
as I looked at the event with DEVICE and in 2.6.21 it has MODALIAS= and in
2.6.22 it doesn't. that was wrong, I should have looked at the MODALIAS event
to find out that DEVICE, TYPE and PRODUCT where missing. sorry again.
> Andreas, do I read this right, you miss:
> DEVICE, PRODUCT, TYPE
> in the usb-interface event, and they only exist in the usb-device event?
yes, in 2.6.21 two events have DEVICE (one of them has also MODALIAS), in
2.6.22 one event has DEVICE and PRODUCT and TYPE, the other one MODALIAS,
no event has both. your patch fixes this, thanks!
> +#ifdef CONFIG_USB_DEVICEFS
does this depend on USB_CLASS_DEVICE? i.e. will it break if USB_CLASS_DEVICE
is turned off? a migration plan / what shall I do so my code still works
when that is done, would be very nice. and enough time so I can get new
versions out to the users. so far the kernel was faster and I got bug reports
about openct not working with 2.6.22 :(
Regards, Andreas
On Tue, 2007-08-21 at 14:21 +0200, Andreas Jellinghaus [c] wrote:
> Am Dienstag, 21. August 2007 schrieb Kay Sievers:
> > The subject says MODALIAS was removed, but I don't think that it ever
> > was there for a usb-device event. And sure, it's still there for a
> > usb-interface event.
> >
> > Andreas, do I read this right, you miss:
> > DEVICE, PRODUCT, TYPE
> > in the usb-interface event, and they only exist in the usb-device event?
> >
> > And MODALIAS is not what you miss, and the subject of the mail is
> > misleading?
>
> I'm coming from a different side, as I know not much about the kernel
> internals. but if I run "udevmonitor --kernel --environment" and then
> plug in some usb device (e.g. my smart card reader):
> - on 2.6.21 there are two events with DEVICE and the second has DEVICE
> and MODALIAS set. thats what I need.
> - on 2.6.22 there are two events: one has DEVICE and one has MODALIAS,
> but neither has both. this breaks openct.
Ok, the patch fixes this.
> PRODUCT and TYPE are also missing from the event that has MODALIAS in 2.6.22.
>
> > Note:
> > DEVICE only exists when USB_DEVICE_CLASS=y,
Oops, I meant USB_DEVICEFS.
> yes, I tested with 2.6.22 with that turned on. if setting this to no breaks
> openct, then we should not easily deprecate it. instead we first need a
> migration plan, than we need enough time to get a new version of openct to
> every user that works with the new and the old kernel, and only after that is
> done we can deprecate it, suggest to turn it of, and even later remove it.
> please keep such a timing, many other parts of the kernel follow these rules
> too. Documentation/feature-removal-schedule.txt should be updated to contain
> exact information how long we can count on USB_DEVICE_CLASS=y etc.
You don't use USB_DEVICE_CLASS devices at all, I guess. Sorry, for the
confusion about the option name.
> > because it unfortunately is
> > prefixed with the /proc mount path, which doesn't exist when the /proc
> > device node support is not compiled in
>
> I'm fine with that. people have used that one for years, and they still should
> have it. if you suggest people should use /dev/bus/usb instead, we need the
> same plan: migration plan first, enough time to adjust the software and get
> it to the users, then deprecation plan and later a removeal. maybe add an
> entry to feature-removal-schedule.txt too? even if only to let everyone
> incl. distribution makers know, that /dev/bus/usb is not an instant
> replacement for /proc/bus/usb, even if it seems so for some software.
Oh, it's not our call what distros do. There is nothing deprecated and
distros don't need to change anything, if they don't want. It's just
that distros who need to support fast-user-switching and support for
ownership of device nodes for multiple people at the same time, depend
on ACL support and switched to udev managed device nodes for usb
devices.
There is no plan, or removal schedule on the kernel side, it's all up to
the distros to fit their needs.
As an example, openSUSE disabled usbfs and switched entirely
to /dev/bus/usb/ nodes, openct is integrated into HAL instead of udev.
But that does not mean anything for other distros, or the kernel itself.
> > so nothing should depend on the existence of DEVICE.
> well, first I need the migration plan: so far I could depend on it,
> please give me the new thing that I can depend on. it needs to work
> with old kernels too (something like a 6month to 2year window of kernel,
> we shouldn't force people to upgrade and downgrade kernel and other
> apps unless it is absolutely necessary).
Again, its up to the distro, nothing in the kernel has changed. It's
just that some distros stopped to provide an option the kernel provides,
which doesn't mean that the kernel will remove that feature anytime
soon.
> all discussions I remember ended nowhere: there is no alternative
> for the combination of DEVICE and MODALIAS. I tried /dev/bus/usb
> and sysfs, but it didn't work out because of timing and race conditions
> and other problems you summed up as "there is no sane way" ...
Yes, that was true, there was no sane way, now there is. With the device
nodes exported directly from the usb-device instead of an additional
artificial class device with the timing problems.
> but maybe I got this wrong, so I'm asking once more: DEVICE plus MODALIAS
> is working fine for me, but I'm happy to migrate. what is the plan,
> what shall I do instead? and what is the minimum kernel and udev etc.
> required for this alternative to work? and how long can I count on the
> old style still to work?
It all depends on the distro, DEVICE will not go away from the kernel,
but from some distros.
> > Most of the recent distros don't mount or configure
> > usbfs anymore, but use /dev/bus/usb/ device nodes, which can handle
> > access control lists for local users.
>
> that would be a huge problem, as I know no alternative to DEVICE with
> /proc/bus/usb.
The udev event contains DEVNAME, which points you to the device node
in /dev. With the recent kernel, it's just the parent device of the
interface-device you match on.
Your script could ask from the interface event, which is a child of the
usb-device, the parent device has the node you want to access. Something
like the following should work to get the name of the device node:
/dev/$(udevinfo --query=name --path=$(dirname /sys/$DEVPATH))
> the kernel tells me about new /proc/bus/usb devices,
> but who tells me about any /dev/bus/usb device?
> as far as I know: no one.
> please correct me if I'm wrong,
Udev, with DEVNAME is doing this, like for all other devices with device
nodes too. But it just does this for the device that created the device
node. You hook into the interface which is a child of the device,
therefore you need to ask with udevinfo.
> I would be real happy to migrate to a working
> new solution, if it fixes the problem and gives me time for new adventures.
Good luck with the new adventures! :)
If you have further questions about integration into udev, you may start
a new thread at the hotplug list, that is where all the distro
maintainers coordinate their work for things like this.
Thanks,
Kay