Subject: Re: [RFC][PATCH] add driver matching priorities
From: Adam Belay <abelay@novell.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Greg KH <greg@kroah.com>, rml@novell.com, linux-kernel@vger.kernel.org
In-Reply-To: <20050210184508.B5800@flint.arm.linux.org.uk>
References: <1106951404.29709.20.camel@localhost.localdomain>
	 <20050210084113.GZ32727@kroah.com>
	 <1108055918.3423.23.camel@localhost.localdomain>
	 <20050210184508.B5800@flint.arm.linux.org.uk>
Content-Type: text/plain
Date: Thu, 10 Feb 2005 16:37:03 -0500
Message-Id: <1108071423.3423.46.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1275
Lines: 32

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.

Thanks,
Adam


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/