From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9A92749F for ; Sun, 25 Jun 2017 21:38:29 +0000 (UTC) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9F24171 for ; Sun, 25 Jun 2017 21:38:28 +0000 (UTC) Received: by mail-ot0-f176.google.com with SMTP id u13so57678919otd.2 for ; Sun, 25 Jun 2017 14:38:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Matthew Wilcox Date: Sun, 25 Jun 2017 17:38:27 -0400 Message-ID: To: Hannes Reinecke Content-Type: multipart/alternative; boundary="001a113ec948ac37360552cfa754" Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] (PCI) driver rebinding List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --001a113ec948ac37360552cfa754 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Is udev the solution here? Have ->probe do common initialisation and return success. Then udev says something to the driver to make it choose one or the other modes. On 25 Jun 2017 11:40 am, "Hannes Reinecke" wrote: > Hi all, > > here's a thing which came up recently on the SCSI ml: > > 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. > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke Teamlead Storage & Networking > hare@suse.com +49 911 74053 688 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg > GF: F. Imend=C3=B6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG N=C3=BCrnberg) > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > --001a113ec948ac37360552cfa754 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is udev the solution here?

Have ->probe do common initialisation and return success.= Then udev says something to the driver to make it choose one or the other = modes.

On 25 Jun 2017 11:40 am, "Hannes Reinecke" <hare@suse.com> wrote:
Hi all,

here's a thing which came up recently on the SCSI ml:

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&= #39;
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.

Cheers,

Hannes
--
Dr. Hannes Reinecke=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Teamlead Storage & Networking
hare@suse.com=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg
GF: F. Imend=C3=B6rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG N=C3=BCrnberg)
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discus= s@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--001a113ec948ac37360552cfa754--