Re: [Ksummit-discuss] [TECH TOPIC] (PCI) driver rebinding

[Bart Van Assche <Bart.VanAssche@wdc.com>]

On Sun, 2017-06-25 at 17:39 +0200, Hannes Reinecke wrote:
> How should we handle devices with _several_ possible drivers?
> 
> Case in point are some HBAs, for which the plan is to have distinct
> drivers for either target or initiator mode.
> 
> There are several options how this could be handled:
> - Have a default driver, and manually rebind the 'real' driver once the
> configuration could be read and acted upon.
> That would have the drawback that we do an initialisation in the 'wrong'
> mode, and later have to switch configuration. Which at best will 'just'
> induce some pointless initialisation, at worst confuse attached devices
> to no end. Not to mention introducing lots of interesting races with
> udev and systemd
> - Inhibit default binding, and load the correct drivers after the
> configuration has been read.
> Would be a deviation from the original scenario (where the driver are
> bound/loaded as soon as the device becomes available). Has the drawback
> that one would need to inhibit automatic bindings on the _bus_ level (ie
> PCI), which will be even more interesting.
> - Add some bus-specific (or even general?) device configuration syntax,
> which would allow to pass in the required configuration from the
> command-line (or reasonably early, anyway). For which we need a syntax
> first, anyway. And need to figure out if we can have an abstract syntax
> or would need to have a bus- (or even driver-) specific configuration.
> 
> So no easy way out here, and it might be worth having input from other
> parties. And some might have similar problems (just thinking of
> usb-modeswitch ...), so there might be some synergies to be had.

(resending from an e-mail address that is subscribed to ksummit-discuss)

Hello Hannes,

Thanks for having brought up this topic. I think this is an important
topic and something we need to solve. I am interested to join the
discussion about this topic.

My preference is to solve this by following the same approach as for the
iSCSI, SRP and several other protocols: design the protocol and HBA such
that initiator and target mode can coexist on the same HBA port, make one
driver responsible for controlling the HBA, a second driver responsible
for providing initiator functionality and make a third driver responsible
for providing target functionality. Whether initiator and/or target mode
are activated depends on which drivers are loaded and also on which
drivers the user chooses to activate.  With this approach no PCI rebinding
is necessary.

Bart.