From owner-freebsd-hackers Mon Jun 5 6:40:55 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by hub.freebsd.org (Postfix) with ESMTP id 1F5F237B70E for ; Mon, 5 Jun 2000 06:40:44 -0700 (PDT) (envelope-from myevmenkin@att.com) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA03888 for ; Mon, 5 Jun 2000 09:40:41 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA20857; Mon, 5 Jun 2000 09:39:40 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 09:40:41 -0400 Message-ID: From: "Yevmenkin, Maksim N, CSCIO" To: hackers@FreeBSD.ORG Subject: RE: kerneld for FreeBSD Date: Mon, 5 Jun 2000 09:40:30 -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 > 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 2) kernel/user space does not unload modules, unless you unload it manually 3) we can not configure which module should be loaded. it is hardcoded so, when i started to code ``kerneld'', i was thinking about 1) one simple interface to load all modules from kernel 2) ability to determine which module can be unloaded and unload it 3) flexible configuration file and, yes, Linux guys have abandoned ``kerneld'', but .... they do not need it :-) look for KERND define in new Linux kernel. the way they load kernel module is 1) create new kernel thread 2) run /sbin/depmod (or something like this) in the thread 3) wait for thread finished and check for result it does not look like kernel code, indeed :) looks like daemon code :) thanks, emax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message