Date: Sat, 10 Oct 1998 22:09:20 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: "Robert V. Baron" <rvb@cs.cmu.edu> Cc: Peter Wemm <peter@freebsd.org>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sys kernel.h Message-ID: <Pine.BSF.4.01.9810102206420.416-100000@herring.nlsystems.com> In-Reply-To: <yzsr9wg9qyw.fsf@sicily.odyssey.cs.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 Oct 1998, 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. This is directly addressed by the KLD system. The terminology is that a 'file' (ELF or a.out) is loaded by the kernel linker. The file contains a number of 'modules', each of which is initialised and has an event handler (similar to lkmdispatch). The kernel in many ways is a file which contains all the statically linked modules. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9810102206420.416-100000>