On Sat, 9 Nov 2013 12:29:49 +0000 (UTC) Duncan <1i5t5.dun...@cox.net> wrote:
> > Libusb, meanwhile, has been updated to work with the /dev/bus/usb/ tree, > so AFAIK that's what you need to create... somehow. > Thanks for this synopsis. I've been slowly piecing together essentially the same picture from many different sources but was still unsure about how libusb fits into the scheme. Creating, somehow, the /dev/bus/usb devices is also the conclusion I thought would be necessary, but I don't believe that it is possible without udev. Yet it seems that it *should* be possible. Everything, at least according to my limited understanding, within the /dev tree is just an interface to the kernel using major and minor numbers. The necessary modules, namely ehci-pci and uhci-pci, are already integrated into the kernel. Scanners used to work in the same way that USB printers or USB mass storage devices *still* work. That is, an appropriate module is either built or separately loaded into the kernel which will allow the use of certain interfaces in the /dev tree (e.g. /dev/usb/lp0). My USB modem also functions in the same way using a module, cdc-acm, and /dev/usb/ttyACM0. These /dev interfaces could be created independently of udev. Why not with /dev/bus/usb? In fact, everything classed as USB on my system, i.e. keyboard, mouse, printer, mass storage, modem, external hard drives, can be straightforwardly controlled using this module/dev method -- with the sole exception of USB scanners. Why this crazy distinction? Of course I could always jump on the udev bandwagon, like most everyone else, but I still very much enjoy the ability to control, in a simple manner, the operation of my own system. I don't like the idea of another system daemon doing things without my knowledge or approval. Frank Peters
