Re: [linux-usb-devel] why was MODALIAS removed from usb kernel events? [u]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] [PNP] modalias sysfs export
    ... multiline sysfs modalias files are not going to happen. ... the PNP layer to export modalias, so that's what I'm trying to do. ... kernel to lookup a matching kernel module name. ... The problem is to represent multiple id's in a single string or find ...
    (Linux-Kernel)
  • Alpha tftp bootloader kernel stack not valid halt
    ... I have an AlphaPC 164LX that I've decided to try Plan 9 on, ... Bootp works great, the loader loads, the loader loads its configuration ... perfectly, but as soon as it gets the first block of the kernel, the ... Intel 8255x isn't known to work with Plan 9 on Alpha, ...
    (comp.os.plan9)
  • Re: Warning: MFC of security event audit support RELENG_6 in the next 2-3 weeks
    ... I plan to MFC support for CAPP security eventing auditing from 7-CURRENT to 6-STABLE. ... The audit implementation will be considered an experimental feature in 6.2-RELEASE, but in practice runs quite well, so is ready for more wide-spread deployment. ... In principle, all the potentially tricky kernel ABI dependencies, etc, were dealt with before 6.0-RELEASE, such as changes in the size of the kernel system call data structures. ...
    (freebsd-stable)
  • Re: Warning: MFC of security event audit support RELENG_6 in the next 2-3 weeks
    ... I plan to MFC support for CAPP security eventing auditing from 7-CURRENT to 6-STABLE. ... The audit implementation will be considered an experimental feature in 6.2-RELEASE, but in practice runs quite well, so is ready for more wide-spread deployment. ... In principle, all the potentially tricky kernel ABI dependencies, etc, were dealt with before 6.0-RELEASE, such as changes in the size of the kernel system call data structures. ...
    (FreeBSD-Security)
  • Re: [9fans] security
    ... those thoughts sounds too paranoid, but i can't see why that's bad. ... Change the path default value to looks like a painless change ... You can't segment the Plan 9 kernel. ...
    (comp.os.plan9)