On Mon, Jan 09, 2006 at 10:51:08PM +0100, Andreas Jellinghaus wrote: > Am Montag, 9. Januar 2006 14:15 schrieb Aurelien Jarno: > > Well you're right, it's not the kernel, but rather one of the kernel > > tools (udev) that uses the new functionalities of the recent kernels, > > and that is now using /dev/bus/usb as default instead of /proc/bus/usb. > > Therefore libusb has to use it if it exists. > > my udev 079 doesn't create that tree. (ok, ububtu dapper, not debian). Maybe there is a bug on your system, please report it to udev.
> but "has to use it"? I think that is wrong. noone forces you. > sure, using the different directories would allow people to use > acl, which is not possible on usbfs. Has to use it, because /proc/bus/usb is not usable anymore if the permissions are wrong. I already received dozen of mails when udev stopped to changes the permissions of /proc/bus/usb in favor of /dev/bus/usb. Note that you can use ACL on /dev/bus/usb, not on /proc/bus/usb. > so, I think there are these options: > a) create a flag so you can ask which system is to be used. > i.e. api modification. apps not using that special flag or > function will use /proc/bus/usb/ and thus be compatible. You can set up the environment variable USB_DEVFS_PATH if you wan to change. > b) use either socket, but keep dirname and filename in the > usbfs format, i.e. %03d. that would keep those fields > in the same format that has been there all the time, and > create compatibility, even if the new directories are used. As said in my previous mail, %03d is now used with newer versions of udev. > c) increase the major library number, create a new api where > the fields can have different names and/or different content. > but make that incompatible change visible by bumping the > libraries major version number, as applications like openct > will break. It's not my fault if openct uses some fields incorrectly. Note also that the problem has been fixed. > <whishlist> > and of course while you are at it anyway, create a function > so I can get a device string for a usb device, and can get > an usb device for a device string, and implement it in a way, > so whatever the linux kernel, udev, hotplug or hald or freebsd > usbd or devd passes to some application will be understood. > on linux it should be an open() able device path, as that is > what kernel / hotplug / ... passes as DEVICE argument in > events. on freebsd it might be the path to the ugen0.0 device > or similar, (i.e. device to the control device, as they have one > device per endpoint for some strange reason), and on > mac os X it might be some string in whatever format you > choose, as there are no devices for usb as far as I know and > thus you don't be compatible with anything. or has apple > some hotplug system, too? > </whishlist> That would be a good idea, but I don't want to diverge from other distributions with an incompatible library. Please note that upstream is currently writting libusb version 1.0.0, which will be ABI and API incompatible, but will have a lot of new features. Maybe you can ask upstream about that. > well, that would help a lot, and would be a good reason to > encourage users to switch to a new library vesion. and with > the changed library major number, we could easily detect > if the old lib is presend, and use the current code, or if the > new lib is present and use new, different code. > > but changeing the library in a way it breaks applications > without any chance to detect that at compile time, that is > wrong. please don't do that. > > The obsoleting has started. Please look at udev (which now replaces and > > removes the hotplug package), it only handle the permissions of > > /dev/bus/usb and not the one of /proc/bus/usb anymore. > > since when did /proc/bus/usb did have permissions? For a long time they were handled via hotplug. > anyway, I don't need them as openct runs as root. > (at least for a long time, only root could do those ioctl()s > we used, so there was no point in using a different user. > and we have a nice security system by splitting in a > server/client part anyway, and could even enhance that > with chroot() or whatever, if people want that). It's not because your application don't need to handle permissions that you should ignore them. Most of the applications that use libusb are using the permissions. > > I see, I didn't know that openct needs such things. However the problem > > is that openct assumes that dirname and filename correspond to the > > string to put after "/proc/bus/usb/" to get the usb device, which is > > false. They correspond to the real directory and to the real filename used. > > well, the documentation doesn't exactly tell anything about that detail, > and it has been that way for ever. so if you change it know, you are > breaking a de facto standard, even if the documenation was unclear > about it so far. if you do so, please upgrade the library major revision, > so people will at least see your new version is no longer compatible > with the old one. different values in the same field is a no no in > compatiblity. Look at the code, you will see that they correspond to that. Note also that nothing has changed in libusb about the way dirname and filename are handled. They still correspond to the name on the filesystem. The contents of these variable may be controversial in the initial design of libusb, but it has not been changed. > > Please note however that udev (>= 0.0.76-3) now behaves like the old > > /proc/bus/usb and use 3 digits to represent the dirname and the > > filename. So openct should work correctly now, maybe you should just add > > a conflict with udev (<< 0.0.76-3). > > I still don't understand how whatever udev does has an effect on libusb. > as far as I can see the code looked at /proc/bus/usb first, so how > do you get those "wrong" values into the dirname and filename fields > anyway? maybe I misread the code, but I couldn't see how that happends > at all. as longs as /proc/bus/usb exists like it currently does, there should > be no issue, right? libusb uses /dev/bus/usb as first, and /proc/bus/usb as fallback. This is necessary because contrary to you, the vast majority of users do care about permissions of their usb devices. Therefore dirname and filename are using the name in /dev/bus/usb, which are now the same as /proc/bus/usb, so that openct is now *working correctly*. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
