From: Hannes Reinecke <hare@suse.com>
To: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: [Ksummit-discuss] [TECH TOPIC] (PCI) driver rebinding
Date: Sun, 25 Jun 2017 17:39:34 +0200 [thread overview]
Message-ID: <c0ebdd10-5c7c-dfb1-9bc8-c6c632ac1396@suse.com> (raw)
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ürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
next reply other threads:[~2017-06-25 15:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-25 15:39 Hannes Reinecke [this message]
2017-06-25 21:38 ` [Ksummit-discuss] [TECH TOPIC] (PCI) driver rebinding Matthew Wilcox
2017-06-26 5:54 ` Hannes Reinecke
2017-06-26 4:59 ` Greg KH
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=c0ebdd10-5c7c-dfb1-9bc8-c6c632ac1396@suse.com \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).