Date: Sat, 25 Aug 2001 18:57:12 +0300 From: Peter Pentchev <roam@ringlet.net> To: Edwin de Jong <mauddib@gmx.net> Cc: arch@FreeBSD.org Subject: Re: slight change to kldload(8)/kldunload(8) Message-ID: <20010825185712.H559@ringworld.oblivion.bg> In-Reply-To: <20010825175113.A63868@gmx.net>; from mauddib@gmx.net on Sat, Aug 25, 2001 at 05:51:14PM %2B0200 References: <20010824141407.A3733@gmx.net> <20010824192943.B532@ringworld.oblivion.bg> <20010824200527.A41553@gmx.net> <20010825145021.G487@ringworld.oblivion.bg> <20010825175113.A63868@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hrm.. It looks like you sent this to -arch after I replied to your personal message to me.. Okay, here's my reply for the benefit of -arch.. On Sat, Aug 25, 2001 at 05:51:14PM +0200, Edwin de Jong wrote: > On Sat, Aug 25, 2001 at 02:50:21PM +0300, Peter Pentchev wrote: > > On Fri, Aug 24, 2001 at 08:05:27PM +0200, Edwin de Jong wrote: > > > On Fri, Aug 24, 2001 at 07:29:43PM +0300, Peter Pentchev wrote: > > > > On Fri, Aug 24, 2001 at 02:14:08PM +0200, Edwin de Jong wrote: > > > > > > > > The attached diffs are slight changes to kldload and kldload to support > > > > > multiple arguments (so it is possible now to say kldload module1.ko > > > > > module2.ko). > > > > > > > IMHO, additional cmdline arguments to kldload/kldunload(8) ought > > > > to be reserved for specifying options (hints, or whatever one would > > > > choose to call them). That *could* be done with getopt-style options > > > > or something, but IMHO, hints specified on the command line would be > > > > more useful and more intuitive than additional modules to load.. > > > > > > Well, the idea was that since most other tools like ps, ls, rm, cp and > > > others also take more than one input argument. Since in this case there > > > are no hints to modules, this seems to be most clean option. > > > > > > Since shell glob substitution increases the number of arguments > > > depending on the number of matches, this also allows you to use the > > > shell more effectively. > > > > Yes, the ability to add more than one module might be useful, > > I'm not saying it might not. > > > > All I'm saying is, the ability to specify options while loading > > a module might be a bit more useful (think sound card IRQ's), > > and adding the options after the module name is the way that it is > > usually done in other OS's. > > > > And BTW, I do think that this discussion should be on a public > > mailing list, to see how other people feel on this - quite important > > IMHO - subject. > > At this moment, the function kldload only takes one arg, which is the > filename of the module. Indeed, I agree with you that it might be > best to add additional arguments to specify how and where the module > should be loaded, but this would require a change to the module system > also. Well, modules in -current already honor hints. All that is needed is a userland utility to read/set hints - I have it on my RSN TODO list to see what I can do about the kldconfig(8) that I hacked up recently, but I suppose kldload(8) would be another nice place to specify hints for the module you're loading right now. > I'm willing to look at that, and see how this could best be tackled. > For now I think it might be best to keep the multiple arguments for a > while. Actually, it is kind of hard for me to think of a (commonly occurring) situation when you'd want to load more than one module of a time :) So basically, the question would be whether we want to *introduce* this functionality :) > I don't want to say that modinstall (or whatever it is called in Linux) > is one of the best solutions, however, the automatic loading of module > dependencies could work out very well. Module dependencies already work quite fine - or are supposed to. If they don't, then tackling *that* would be a much more important project :) > Another interesting thing is for example with the screensaver modules. > One generally only wants to load one module at a time (only the last one > is effective). Actually the other modules should be unloaded > automagically. This is interesting - having modules "provide" some "functionality", and either not allowing another module with the same functionality, or automatically unloading the old one.. What if there is a third module depending on the old one? Points to ponder.. Points to be raised in a separate mail to -arch and/or -hackers.. G'luck, Peter -- What would this sentence be like if it weren't self-referential? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010825185712.H559>