Matthias Drochner <M.Drochner@fz-juelich.de> writes:

> nathanw@wasabisystems.com said:
>> It seems like what you want for direct-config buses is:
>>  - the bus to track what subdevices have what drivers attached, and
>>    which subdevices have nothing attached. 
>
> A pointer to "what driver" is useful only if there is a mechanism
> which tells the bus framework that the device in a particular slot
> is gone. Plain PCI doesn't have this, that's why I suggested just
> a bitmap.
> There are (at least) 2 "hot-plug-PCI" standards; maybe we'll support
> some once a working piece of hardware hits a NetBSD user... So it
> might make sense to keep a pointer from the beginning.

The force-detach we discuss below makes this useful, even in the
absence of support for actual hot-plug hardware.

>> - a call into the bus to re-run the probe/attach for unattached
>>   devices (or a particular device identifier?)
>
> For unattached devices. The device identifiers are checked in the
> driver's xxxmatch() function - there is no need to duplicate this.
> It should also obey the autoconf "locators", so that can load a
> driver module which attaches to a specific slot only. This should
> happen more or less automatically is the existing framework is used.

OK, locator was what I had in mind when I wrote that, not
vendor/product ID, so I think we agree.

>> - a call to cause a driver at a particular device to be detached (for
>>   unloading and trying again).
>
> Here we have 2 possibilities: Tell the device to detach; it would
> have to call back to the bus to free its slot related ressources.
> Or tell the bus to do it and call the driver's detach function
> implicitely.
> The former seems to be more general to me -- Telling "detach foo0"
> is possible without knowing bus internals, opposed to "detach the thing
> in slot x function y".

Well, there's the question of how to access this interface. At least
for PCI, we currently have a PCI device node where we could issue this
command; if it's per-device, we either have a hodgepodge of having to
open /dev/foo for whatever foo0 and issuing a driver-specific "detach"
ioctl (and then there are issues with pass through for things that
attach subdrivers, and devices without device nodes, and so on), or we
need a generic "/dev/dev" or something where we can issue "detach
foo0" commands (that might also be a fine place to listen for
device-attach notifications, to tie this in to other wish list items).

It seems to me that both "detach foo0" and "detach whatever is at pci0
dev 7 function 3" could be useful commands to support. I agree that
the former is more obviously useful, though.

    - Nathan