All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Hannes Reinecke <hare@suse.com>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] (PCI) driver rebinding
Date: Mon, 26 Jun 2017 06:59:19 +0200	[thread overview]
Message-ID: <20170626045919.GD17296@kroah.com> (raw)
In-Reply-To: <c0ebdd10-5c7c-dfb1-9bc8-c6c632ac1396@suse.com>

On Sun, Jun 25, 2017 at 05:39:34PM +0200, 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?

Go kick the hardware developers for trying to come up with such complex
beasts :)

> 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.

Yes, do this.

> 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

How will udev and systemd have "races"?  We do this today all the time
in USB with the usb-modeswitch userspace code, as you point out.

> - Inhibit default binding, and load the correct drivers after the
> configuration has been read.

You can do that too vfio does it from what I recall.  It's easy in that
you can just not do a MODULE_DEVICE_TABLE() export and no driver will
automatically be loaded and userspace is required to load what it wants.

> 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.

Hah, good luck with that :)

greg k-h

  parent reply	other threads:[~2017-06-26  4:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-25 15:39 [Ksummit-discuss] [TECH TOPIC] (PCI) driver rebinding Hannes Reinecke
2017-06-25 21:38 ` Matthew Wilcox
2017-06-26  5:54   ` Hannes Reinecke
2017-06-26  4:59 ` Greg KH [this message]
2017-06-26  6:05   ` Hannes Reinecke
2017-06-26  6:57     ` Greg KH
2017-06-26  5:37 ` Leon Romanovsky
2017-06-26  5:44 ` Bart Van Assche
2017-06-26 17:40 ` Lee Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170626045919.GD17296@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=hare@suse.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.