From owner-freebsd-hackers Mon Jun 5 10: 9:41 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by hub.freebsd.org (Postfix) with ESMTP id 713E537B894 for ; Mon, 5 Jun 2000 10:09:37 -0700 (PDT) (envelope-from myevmenkin@att.com) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id NAA20502 for ; Mon, 5 Jun 2000 13:09:36 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA03799; Mon, 5 Jun 2000 13:08:34 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 13:09:36 -0400 Message-ID: From: "Yevmenkin, Maksim N, CSCIO" To: hackers@FreeBSD.ORG Subject: RE: kerneld for FreeBSD Date: Mon, 5 Jun 2000 13:09:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [...] > > 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