Date: Mon, 5 Jun 2000 13:09:29 -0400 From: "Yevmenkin, Maksim N, CSCIO" <myevmenkin@att.com> To: hackers@FreeBSD.ORG Subject: RE: kerneld for FreeBSD Message-ID: <E598F159668DD311B9C700902799EAF4473416@njb140po01.ems.att.com>
next in thread | raw e-mail | index | archive | help
[...] > > 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, \\ > msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E598F159668DD311B9C700902799EAF4473416>