Re: [RFC][PATCH] add driver matching priorities
From: Adam Belay
Date: Mon Feb 28 2005 - 19:09:00 EST
On Fri, 2005-02-25 at 15:41 -0800, Greg KH wrote:
> On Thu, Feb 10, 2005 at 04:37:03PM -0500, Adam Belay wrote:
> > On Thu, 2005-02-10 at 18:45 +0000, Russell King wrote:
> > > On Thu, Feb 10, 2005 at 12:18:37PM -0500, Adam Belay wrote:
> > > > > I think the issue that Al raises about drivers grabbing devices, and
> > > > > then trying to unbind them might be a real problem.
> > > >
> > > > I agree. Do you think registering every in-kernel driver before probing
> > > > hardware would solve this problem?
> > >
> > > In which case, consider whether we should be tainting the kernel if
> > > someone loads a device driver, it binds to a device, and then they
> > > unload that driver.
> > >
> > > It's precisely the same situation, and precisely the same mechanics
> > > as what I've suggested should be going on here. If one scenario is
> > > inherently buggy, so is the other.
> > >
> > I think it would depend on whether the user makes the device busy before
> > the driver is unloaded. Different device classes may have different
> > requirements for when and how a device can be removed. Are there other
> > issues as well? Maybe there are ways to improve driver start and stop
> > mechanics.
> We never fail a device unbind from a driver, so this isn't as big a deal
> as I originally thought. Yes, userspace can get messy, but as userspace
> was the one that loaded the new driver to bind, it's acceptable.
> So, care to resubmit your patch?
Would you like me to include the portion that adds "*match" to "struct
device_driver"? After some more thought, I began considering having
driver priority be a static quality of a device driver. The question is
whether we want a device driver to be able to return a variable priority
based on bind device. Also, "*match" could be used to split some
detection and validation out of "*probe". What are your reactions to
Finally, should every in-kernel driver be registered before devices are
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/