From owner-freebsd-hackers Mon Jun 5 8:41:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 6A6FF37B92D for ; Mon, 5 Jun 2000 08:41:32 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id IAA17524; Mon, 5 Jun 2000 08:44:29 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006051544.IAA17524@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Yevmenkin, Maksim N, CSCIO" Cc: hackers@FreeBSD.ORG Subject: Re: kerneld for FreeBSD In-reply-to: Your message of "Mon, 05 Jun 2000 09:40:30 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jun 2000 08:44:29 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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, \\ 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