> Mike Smith writes: > > > Take the following scenario: > > > > > > compiled in: module A > > > > > > kldstat -v shows module 'A' > > > > > > kldload A > > > damned thing succeeds. > > > > That's correct. There's a fundamental problem here in that there's a > > confusion between file names and module names. This is a basic flaw in > > the way that KLD was implemented (no offense to Doug; it was initially > > meant to be a better LKM, not necessarily a whole new ball of wax). > > > > I've taken about four different runs at a "right" way of doing this > > subsequently. I think that, with some help and advice from Doug and > > Peter, I'm on the right track now, but there's no hope of it being > > ready for 3.1. > > This may be oversimplifying, but why wouldn't this work: just do > everything at the module level: > > - All dependencies are inter-*module* dependencies. > - Only one *module* with the same name can be loaded at one time. > - KLD files (eg, foo.ko) are simply containers for one or more modules.
This is basically what I've been working on. > We'd take the conservative stance on loading: if you tried to > kldload foo.ko, it would fail unless *all* the modules in it were > successfully able to link & load. > > It seems if you just make consistent what the atomic unit of linking > is (is it a file?? it is a module??) then all will be well. We just > have to make sure we have unique names for all modules as we do now > for files. There's a problem here in that the atomic linkage unit (file) is not the same as the atomic identity unit (module). This means that you need to associate information with modules, and then teach everything that's going to try to load files how to read this infomation and apply it to the currently-loaded arrangement. It's all doable; it's just moderately complex and I've not had the time to attack it properly. If this is something of interest/relevance to you and you'd like to take it on, please let me know and I'll dump everything I've been doing and thinking on you and we can talk about it at length. > Now, there remains the problem of how do you find the file foo.ko > containing module "bar", eg, if you want to auto-load dependencies? > For starters, we could just assert that only module "foo" can be > found this way. I was planning on using that as a base rule; Doug (IIRC) suggested an optimisation whereby we'd keep a database of module:file mappings lying around. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
