From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: g@parcelfarce.linux.theplanet.co.uk,
Adam Belay <abelay@novell.com>,
greg@kroah.com, rml@novell.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] add driver matching priorities
Date: Fri, 28 Jan 2005 21:45:13 -0500 [thread overview]
Message-ID: <200501282145.13837.dtor_core@ameritech.net> (raw)
In-Reply-To: <20050129001105.GQ8859@parcelfarce.linux.theplanet.co.uk>
On Friday 28 January 2005 19:11, Al Viro wrote:
> On Fri, Jan 28, 2005 at 06:23:26PM -0500, Dmitry Torokhov wrote:
> > On Friday 28 JanuarDy 2005 17:30, Adam Belay wrote:
> > > Of course this patch is not going to be effective alone. We also need
> > > to change the init order. If a driver is registered early but isn't the
> > > best available, it will be bound to the device prematurely. This would
> > > be a problem for carbus (yenta) bridges.
> > >
> > > I think we may have to load all in kernel drivers first, and then begin
> > > matching them to hardware. Do you agree? If so, I'd be happy to make a
> > > patch for that too.
> > >
> >
> > I disagree. The driver core should automatically unbind generic driver
> > from a device when native driver gets loaded. I think the only change is
> > that we can no longer skip devices that are bound to a driver and match
> > them all over again when a new driver is loaded.
>
> And what happens if we've already got the object busy?
>
Mark it as dead and release structures when holder lets it go. With hotplug
pretty much everywhere more and more systems can handle it. Plus one could
argue that if an object needs a special driver to function properly it will
unlikely be busy before native driver is loaded.
Also, one still can do what Adam offers by pre-loading native drivers in
cases whent is required but still support more flexible default scheme.
--
Dmitry
next prev parent reply other threads:[~2005-01-29 2:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-28 22:30 [RFC][PATCH] add driver matching priorities Adam Belay
2005-01-28 23:23 ` Dmitry Torokhov
2005-01-28 23:33 ` Adam Belay
2005-01-28 23:51 ` Dmitry Torokhov
2005-01-29 0:05 ` Adam Belay
2005-01-29 0:11 ` Al Viro
2005-01-29 2:45 ` Dmitry Torokhov [this message]
2005-02-10 8:41 ` Greg KH
2005-02-10 17:18 ` Adam Belay
2005-02-10 18:08 ` Dmitry Torokhov
2005-02-10 18:12 ` Greg KH
2005-02-10 21:26 ` Adam Belay
2005-02-10 18:33 ` Greg KH
2005-02-10 18:46 ` Dmitry Torokhov
2005-02-10 21:32 ` Adam Belay
2005-02-10 18:45 ` Russell King
2005-02-10 21:37 ` Adam Belay
2005-02-25 23:41 ` Greg KH
2005-03-01 0:05 ` Adam Belay
2005-03-01 7:58 ` Greg KH
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=200501282145.13837.dtor_core@ameritech.net \
--to=dtor_core@ameritech.net \
--cc=abelay@novell.com \
--cc=g@parcelfarce.linux.theplanet.co.uk \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@novell.com \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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