I'm not absolutely sure about the status of the PCI support, but it
should be close to working. Anyway, the driverfs infrastructure itself
is in place in 2.5, so even if the PCI part wasn't there, still we can
convert USB and Input to it.
> > > but for the time being, it'd be very useful.
> >
> > +int usb_make_path(struct usb_device *dev, char *buf, size_t size)
>
> I don't think that patch is necessary. It's simpler to just
>
> strncpy (buf, dev->devpath, min_t(size_t, size, sizeof dev->devpath));
>
> Use like you'd use pci_dev->slot_name ... no mallocation necessary.
> It's just the path from root hub down to device, /2/1/7 and so on: the
> physical path, which stays the same so long as you don't recable your
> tree of USB devices and hubs.
>
> I'd expect the typical "driverfs" path for a USB device to be the
> path for the root hub (normally a PCI slot like 00:0f.3) followed by
> what "devpath" now shows.
Ahh, I see. This "devpath" entry wasn't available at the time I wrote
the 'usb_make_path' function. This is of course much better. What's not
very convenient for me right now is that it uses slashes instead of
dots, which the input subsystem uses for delimiting busses from each
other, like:
isa0060/serio0/input0 - AT keyboard
pci0:7.3/usb1:2.2/input0 - USB keboard
Using slashes in place of the dots would make it quite a mess. The
slashes are probably there because of usbdevfs, right?
Note that the PCI "slot_name" doesn't use slashes ...
-- Vojtech Pavlik SuSE Labs - 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/