From owner-freebsd-arch Wed Mar 6 9:49:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 6F85F37B419; Wed, 6 Mar 2002 09:49:42 -0800 (PST) Received: from pool0158.cvx21-bradley.dialup.earthlink.net ([209.179.192.158] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16ifXj-0004hK-00; Wed, 06 Mar 2002 09:49:36 -0800 Message-ID: <3C86569D.5ECC414E@mindspring.com> Date: Wed, 06 Mar 2002 09:49:17 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: obrien@FreeBSD.ORG, Eivind Eklund , arch@FreeBSD.ORG Subject: Re: do we need full kernel sources to compile loadable modules ? References: <20020305134932.A79697@iguana.icir.org> <20020305230738.C13979@phoenix.dmnshq.net> <20020305145406.A37648@dragon.nuxi.com> <3C85680B.776B76CD@mindspring.com> <20020306003700.A83775@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > I agree on the comments on the generated files, > I was just asking if we could, as part of the install > of include files, include some rule in the makefile so > that it would generate a copy of vnode_if.h > somewhere in the include tree. The vnode_if.h file is pretty heinous. The problem it's trying to solve is actually the wrong problem to try to solve. The vnode_if.h and vnode_if.c descriptor list is limiting by definition. The original design intent was to permit the addition of descriptor types dynamically. To get to this point, it's pretty imperitive that the descriptor lists be uniquified and sorted. The only way that works to uniquify between two sets of added descriptors vs, the default set is to do it by string name, which is about the only way you can assume a collision space that is non-intersecting. If you consider the case where there is a new VOP, let's call it VOP_TRANSACT, that is supported by two new stacking layers that have to comunicate between an intermediate stacking layer, e.g. a stack of NEW1, nullfs, NEW2, ffs, then the only way to support it is to reinstance the VOP vectors of the existing systems when the new VOPs are added, so that you don't run off the end of the array of vectors in the assembly list when you are calling from NEW1 to NEW2 through the nullfs vector, and so that you get the unsupported VOP when you call from the NEW2 to the ffs layer (a ringing condemnation of the "defaultvops" vector idea, if ever there was one). THe other thing you notice, when you do this, is that in the uniquification process, you end up with a sorted VOP list, and can call directly through the vector, bypassing the reverse lookup-by-descriptor. This takes out two indirections per call through a layer boundary. 8-). Exposing vnode_if.h is a bad idea... because perpetuating a vnode_if.* in the first place is a bad idea. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message