Daniel Kahn Gillmor wrote:
hrm. /dev/bus/usb appears to be created/managed by udev entirely, but
/proc/bus/usb is exported (as an empty directory) by the kernel, and
then usbfs is mounted on top of that.
mounting usbfs should no longer be necessary. since debian added udev
with /dev/bus/usb they should have checked and modified all usb
applications to use that instead of /proc/bus/usb.
[0 [EMAIL PROTECTED] ~]# rmdir /proc/bus/usb
rmdir: /proc/bus/usb: Operation not permitted
thats ok, you can't remove it.
udev will start two processes, one tries the /dev/bus/usb device,
one tries the /proc/bus/usb device, and the one who can claim the
interface wins.
i can see why that would be a problem. i'm just not sure what to do
about it. Maybe this bug should be reassigned to udev or initscripts?
check if the policy has something about usb devices. if not it could
be best to start discussing that - like agreeing on a migration path
away from /proc/bus/usb (which is called obsolete by greg kh IIRC),
and maybe also touching the topic of the duplicate events and how
to suppress them - that can be done either central in udev or
individually in each package.
with /proc/bus/usb unmounted, i'm still getting two ifdhandlers, but
with slightly different messages than before:
Dec 13 16:37:56 squeak ifdhandler[14736]: Unable to open USB device
/proc/bus/usb/002/032: No such file or directory
Dec 13 16:37:56 squeak ifdhandler[14736]: usb:/proc/bus/usb/002/032:
initialization failed (driver egate)
Dec 13 16:37:56 squeak ifdhandler[14736]: unable to open reader egate usb
/proc/bus/usb/002/032
this is ok. since /proc/bus/usb does not exist, the kernel or udev
shouldn't throw an event for it. whether this is a bug or not should
be discussed with kernel and udev teams.
was there still a reader running after this? I'm asking because I'm
quite confused. if there was one running then this:
Dec 13 16:37:56 squeak ifdhandler[14728]: Unable to open USB device
/dev/usbdev2.32_ep00: No such device or address
Dec 13 16:37:56 squeak ifdhandler[14728]: usb:/dev/usbdev2.32_ep00:
initialization failed (driver egate)
Dec 13 16:37:56 squeak ifdhandler[14728]: unable to open reader egate usb
/dev/usbdev2.32_ep00
indicates a third event and a third ifdhandler was launched.
end point devices? when did they get added? are we breaking
compatibility once more? I was nice all year, why is santa claus
bringing compatibility issues / api change / new problems for
xmas?
I haven't fiddled with /lib/udev/openct_usb yet.
might be necessary. if you want to hack it, that would be
the fastest way to get towards a solution.
but the clean way is to get some statement from udev and kernel
folks and agree on a policy, and get everyone agree on a best
practice. udev adding changes without telling everyone involved
is not really a nice way. (and it would have be easy for anyone to
have a look which packages contain udev rules files and let
those maintainers know.)
hrm. i still don't know why udev should be spawning two ifdhandler
processes if /proc/bus/usb is unmounted.
in my opinion a udev or kernel bug. but the openct_usb script could
do a test -e $DEVICE before running openct-control. still I think that
is a work around and it is better to fix udev or kernel, but others
might disagree.
If that's not OK, maybe this
should be reassigned to udev. But if that is deemed acceptable, maybe
the bug should be with the initscripts package, for including an
/etc/init.d/mountkernfs.sh which mounts /proc/bus/usb even on systems
which have /dev/bus/usb already?
udev added /dev/bus/usb at least half a year ago. I wonder why noone
triggered a policy process and came up with a migration plan. IMO
/proc/bus/usb is obsolete, and distributions should simply drop it
(and fix all packages to use /dev/bus/usb instead). but I guess noone
stepped forward to coordinate the process, and thus nothing happened?
no idea, after all I don't know what the udev and kernel folks are up
to. best is to have a chat with them about what their plans are and how
they see it.
would be sad if they put the burdon of handling everything
on the applications. you could add checks to openct_usb to
ignore events if the file does not exist, and to filter out
those end point events. but still if the default etch installation
has both /dev/bus/usb and /proc/bus/usb you will get two events
and two ifdhandler and which one succeeds will be random.
except if you filter one out hard again (e.g. ignore all /proc
events). but that is somehow a hack I think, not a clean solution.
if test -n "$DEVICE"
then
if ! test -e "$DEVICE
then
exit 0
fi
if echo $DEVICE |grep -q _ep
then
exit 0
fi
if echo $DEVICE |grep -q /proc
then
exit 0
fi
fi
if test -n "$DEVNAME"
then
if ! test -e "$DEVNAME"
then
exit 0
fi
if echo $DEVNAME |grep -q _ep
then
exit 0
fi
if echo $DEVNAME |grep -q /proc
then
exit 0
fi
fi
might do the trick. this can be optimized - /proc/bus/usb shows up in
$DEVICE and /dev/bus/usb in $DEVNAME - or the other way round. no idea,
you would need to check with trial and error or some additional
echo foo >> /root/mydebuglog
commands for debugging. no idea where those _ep devices show up,
since I never saw them before.
I hope this helps. Good luck!
Regards, Andreas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
