Ah that makes more sense now, thanks.
But the problem is that the USB hid driver does NOT have a relationship
with a pci driver. The USB drivers don't care about what kind of host
controller driver they talk to, _and_ that relationship isn't present.
There are quite a few USB host drivers that do not sit on the PCI bus,
but talk directly over a "system" bus to the controller (embedded
devices mostly.)
But a PCI bus could also be present, with a USB controller, and the hid
driver would be able to handle devices on it too. So how would you show
this "dual" relationship then?
In short, I don't see the value in showing relationships between
different driver types. But I see the value in relationships between
devices, as is shown in the root/ tree.
> As you can now see in my new diagrams the problem I am trying to
> solve is not how devices are represented but rather how drivers are
> represented. Sorry I wasn't clear. I have completely removed bus and
> replaced it with a driver interface. This is better because a bus does
> not deserve special implementations as it is a driver too. My more
> scaleable interface can handle both buses and drivers.
A bus is different than a driver, as drivers bind to the bus type. In a
way, you can say a bus is nothing more than a "class", and class support
_is_ coming soon. I think class support is what you are really looking
for, as it will be able to show you the relationship between devices
much better.
> >> `This patch also provides user level driver management support
> >>through the advanced features of the new interface. It creates a file
> >>entry named "driver" for each device.
> >>To attach a driver simply echo the name of the driver you want to
> >>attach. For example:
> >>#cd ./root/pci0/00:00.0
> >>#echo "agpgart" > driver
> >>
> >
> >Hm, how does this bind the driver to the device? What if the driver
> >doesn't want to bind to this device? And how does userspace know what
> >pci device to bind to what driver? Does it use the information in the
> >modules.*map file? If so, that comes directly from the drivers
> >themselves, which are the ones knowing what devices they _should_ be
> >bound to, so why not let the driver themselves do the work (well
> >actually the very small function at
> >drivers/pci/pci-driver.c:pci_match_device() does the work).
> >
> This feature is well designed, if a driver doesn't want to bind to the
> device the request will fail. Check the code yourself. This is simply
> a userspace override for the Driver Model. This is useful because it
> provides the user with more control over driver management. If two
> drivers can support the same device and the driver model selects one the
> user doesn't want to use the user can change it. This could even happen
> now with ALSA and Open Sound. Since it calls both probe and match it is
> also a great debugging tool. I'm currently working on a user level
> utility that will take full advantage of this and other driver
> management features.
Again, I don't see the advantage here. Since you say the kernel driver
knows best, and that the kernel driver gets a say in if it really binds
to the device or not, why not just let the kernel driver do all the work
then? I don't see how an extra step from the user will help any.
'insmod' works quite well for picking which driver you want loaded for
the devices (ALSA vs. OSS.) Yes, it doesn't handle mixing lots of the
same device with different drivers, but I don't think that is a very
common thing (otherwise people would have complained about it by now.)
> >>To remove a driver simply echo remove to the driver file while a driver
> >>is loaded. For example:
> >>#echo "remove" > driver
> >>
> >
> >Again, why? And does this force the ->remove() function to be called?
> >
> Yes this does call ->remove() among other things. In fact it calls
> do_driver_detach.
> Why is above.
Again, 'rmmod' does the same thing :)
thanks,
greg k-h
-
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/