Date: Sun, 11 Oct 1998 07:58:37 +0800 From: Peter Wemm <peter@netplex.com.au> To: "Robert V. Baron" <rvb@cs.cmu.edu> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys kernel.h Message-ID: <199810102358.HAA17811@spinner.netplex.com.au> In-Reply-To: Your message of "10 Oct 1998 15:06:31 -0400." <yzsr9wg9qyw.fsf@sicily.odyssey.cs.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
"Robert V. Baron" wrote: > Happy to see that LKD's are being worked on. There is a structural > problem in lkm design. Maybe we can do it right on lkd's. The > problem is that there is a concept of a module. Then there is the > idea that there are services made available. So it is easy to imagine > that a block of code -- a module, would make serveral services > available say vfs, dev, maybe even inodes. So I would argue that the > private data of a module, should be a linked list if it has to be > explicit at all. Then when you call lkmdispatch(), you pass the > module pointer and the service you wish to initialize. You do this as > many times as necessary to setup the module. (You do not pass the > service as the private data of the module). To make things a bit more > concrete, look at coda/coda_fbsd.c and see what had to happen to tuck > Coda in as an lkm. As far as I understand things, The Grand Plan is that all major kernel components will be grouped as "modules" of some sort or other. This just means that source components will have their own module glue code and will be registered during startup via SYSINIT, a lot like the present routines for registering devsw[] devices etc. The beauty of this arrangement is that you can take a group of kernel .o files and link them as a kld object (.ko - basically "cc -shared -o foo.ko file1.o file2.o file3.o") and the exact same binaries and code will work Just Fine either linked into the static kernel or as preloadable objects from /boot/loader or even after the event via kldload(8). Obviously there will be some gotchas if you try and load somthing post-boot that really needs to be run early and as part of (say) the ISA device probe sequence, but making this kind of thing work isn't out of the question. In answer to your comments.. You'd just create a control structure and do a DEVICE_MODULE() declaration to have your device registered, something like a VFS_MODULE() declaration for the VFS and so on. The rest of the kernel code will probably be something like this one day too. The Alpha port is already based on this design and some ISA drivers have already been converted. Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810102358.HAA17811>