[...]
> > 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
ifconfig(8) uses kldfirstmod(2), kldnext(2) etc. to check if the
required interface module in the memory or not. all mount_???(8)
utilities use getvfsbyname(3), vfsisloadable(3) and vfsload(3)
interface, which makes kernel code useless (kernel will never execute this
code).
> 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
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
