From owner-cvs-all Sat Oct 10 12:07:02 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16836 for cvs-all-outgoing; Sat, 10 Oct 1998 12:07:02 -0700 (PDT) (envelope-from owner-cvs-all) Received: from sicily.odyssey.cs.cmu.edu (SICILY.ODYSSEY.CS.CMU.EDU [128.2.185.138]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA16792; Sat, 10 Oct 1998 12:06:45 -0700 (PDT) (envelope-from rvb+@sicily.odyssey.cs.cmu.edu) To: Peter Wemm Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys kernel.h References: <199810092303.QAA06098@freefall.freebsd.org> From: "Robert V. Baron" Date: 10 Oct 1998 15:06:31 -0400 In-Reply-To: Peter Wemm's message of Fri, 9 Oct 1998 16:03:27 -0700 (PDT) Message-ID: Lines: 13 X-Mailer: Gnus v5.4.46/Emacs 19.34 Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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.