lkml.org 
[lkml]   [2007]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [linux-usb-devel] why was MODALIAS removed from usb kernel events? [u]
    Date
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-08-21 14:23    [W:0.025 / U:88.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site