> > On Sun 2000-06-04 (23:06), Coleman Kane wrote:
> > > Look through /modules...
> >
> > I'm still having problems working out what this will do. Can you
> > explain the differences between the current way of doing things, and
> > what your stuff will conceptually do?
> >
>
> i will try :-) please do not beat me :-)
>
> 1) right now we have several places in kernel/user space where we
> load KLD. if we need add dynamic module loading in some new
> place we will have to duplicate all code
This isn't necessarily bad, as it is this code which determines the
criteria for loading a module. I'm not entirely keen on having this
thrown away; especially since all you'd be doing would be replacing it
with code which would invoke the kernel daemon.
> 2) kernel/user space does not unload modules, unless you
> unload it manually
This is, IMO, a good idea. I certainly don't want some smartass daemon
unloading a module just because it thinks it should. 8)
> 3) we can not configure which module should be loaded.
> it is hardcoded
Since the code knows what it wants, this isn't necessarily a bad thing
either. In most cases, part of the module name is actually parametric,
eg. in the ifconfig(8) case, so this isn't as much of a problem as it
sounds.
Basically, I think that the current practice of demand-loading modules
from inside the kernel is the way to go. There are a couple of cases
where pushing them in from the outside (ifconfig, usb, pccard) works, but
in each case these already have tools suited to the job.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
