Re: [3C509] Fix sysfs leak.

[Dave Jones <davej@redhat.com>]

On Tue, Mar 16, 2004 at 04:05:38PM +0100, Marc Zyngier wrote:
 > >>>>> "Dave" == Dave Jones <davej@redhat.com> writes:
 > 
 > Dave,
 > 
 > Dave> The damned bus doesn't even exist. If this is a case that couldn't be
 > Dave> detected, I'd not be complaining, but this is just nonsense having
 > Dave> a driver claim that its found an EISA device, when there aren't even
 > Dave> any EISA slots on the board.
 > 
 > The driver doesn't claim to have found any device. It just registered
 > to the EISA framework, which you compiled in for a reason.

which is valid for a single kernel image that supports boxes both with
and without eisa (ie, vendor kernels).

 > Unload the driver and the directory will go.

no it doesn't, which is the whole purpose of the patch I sent.
try it..

modprobe 3c509
lsmod | grep 3c509     # module didnt stay around
find /sys | grep 3c509 # oh look, it left crap in sysfs


 > Dave> This happens long after bus initialisation should have already figured
 > Dave> out that the bus doesn't exist. Even if it was left this late, the
 > Dave> eisa registration code should be doing a 'oh, I've not even checked
 > Dave> if I have a bus yet, I'll do it now' before it starts doing completely
 > Dave> bogus things like checking for devices.
 > 
 > Sure. When EISA bus is hanging off the PCI bus, which haven't been
 > probed yet ?

We have multiple levels of initcalls for a reason. Whilst they suck in a lot
of ways, they can be used to enforce dependancies like this.

 > When the driver registers, the EISA framework may not
 > have a f*cking clue about where the EISA bus sits, or if it even
 > exists.

Why is this even an issue so late on? Bus probing should have been done as
part of bootup. By the time I get to modprobing device drivers, it should have
been determined already.

Your argument seems to be "probing is hard, so we don't do it", which is
just *wrong*.

		Dave