Re: [RFC][PATCH] add driver matching priorities

[Adam Belay]

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
this?

Finally, should every in-kernel driver be registered before devices are
detected?

Thanks,
Adam


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