On Mon, Dec 10, 2001, David Brownell <[EMAIL PROTECTED]> wrote: > > I also never advocated removing topology information. We already have it > > via an ioctl call. I just don't want topology exposed in the directory > > structure for usbdevfs. > > > > In that case, we're forcing the information on everyone if they care or > > not, and most programs don't care. > > Hmm ... today we force "addressing information" on everyone regardless > of whether they care, and unlike topology info it's quite useless.
Not really. We use addressing information to provide unique filenames. I don't parse the filename, nor should anyone else. It could be completely random for all I care, as long as it's unique. > For backwards compatibility, I think "usbdevfs" should likely not change > very much. I can imagine replacing "bus number" with a stable ID (like > PCI slot/function), and "bus address" with a different one (encoding > topology without new directory names). Adding more directory structure > would seem trouble-prone to me. I'm against a new directory structure. We could encode the topology in the filename, but I don't see why we should go through that trouble. > But I could imagine something else working a lot better than "usbdevfs". > It's just "preliminary" after all, and now folk have had a chance to learn > a lot more about how to expose USB to user mode drivers. There's > no reason not to leverage that knowledge to create a better model. I agree that we can make it better, but I don't think exposing the topology in the directory or filename is better. I just think we're focusing on the wrong thing here. JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
