> >I've always viewed the post-install thing as a bit of a hack -- I admit I
> >don't have any concrete reasons for thinking this, though. Is there no way
> >of making things work under the existing scheme? Or perhaps adding features
> >to the dependency analysis done by depmod and friends?
>
> Not really. It's an equivalent problem to automatically loading the driver
> for your particular SCSI card -- the kernel doesn't know what sort of parallel
> ports you have, and neither do depmod or modprobe. The old scheme was even
> more of a hack, in my opinion.
I did say I couldn't /justify/ feeling that it was a hack :-) Actually, the
SCSI adapter situation is/was worse: what on earth happens when you have more
than one adapter? I don't even know if the SCSI layer can cope with that.
For the parport thing, my initial idea was that char-dev-xxx should be
aliased to the appropriate arch-specific parport module; this presumably
depends on symbols from the high-level parport code, so they would both
be loaded in the right order and the device registration should br complete
when request-module returns.
However, I've not looked at how (for example) the lp code interacts with the
parport, this maybe a problem. If it *knows* which port it wants, it should
be able to request the appropriate char-dev-xxx (or perhaps an alias) to
get the right stuff loaded.
This of course breaks when something accesses a device and you can't tell
from the device number which parport driver / scsi adapter / other interface
provides it. Then you'd have to scan them all, which requires loading them
all. Basically insmod/depmod/modprobe would need to be told "load all
modules of this class", where class could be "low level parport drivers".
Expanding the alias directive to map to a collection of modules would handle
this.
Hmm, actually I've just thought of some other problems. I'm going to regret
getting involved in this, I can tell. Maybe I'll shut up..
> We could add some magic to modutils to let you say "pretend that module X
> depends on module Y". This would possibly be a tiny bit neater than using
> post-install but I don't think it really buys anything.
I just don't like the idea of modprobe fork()ing and exec()ing modprobe..
I have this fuzzy idea that it might be useful in future for the dependency
tree to be "complete", but as I can't think of any concrete examples, that's
rather a big hand-wave.
-- If it walks out of your refrigerator, let it go.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/