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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
