Messages in this thread | | | Date | Sun, 12 Dec 1999 21:28:57 +0000 | From | Steve Dodd <> | Subject | Re: 2.3.31: parport_lowlevel |
| |
On Sun, Dec 12, 1999 at 08:50:33PM +0000, Philip Blundell wrote: > Steve Dodd wrote:
> >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/
| |