From owner-freebsd-current@FreeBSD.ORG Mon Jun 2 19:13:29 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 516E537B401; Mon, 2 Jun 2003 19:13:29 -0700 (PDT) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id C88CD43F3F; Mon, 2 Jun 2003 19:13:28 -0700 (PDT) (envelope-from hmp@nxad.com) Received: by perrin.int.nxad.com (Postfix, from userid 1072) id 42F2D2105A; Mon, 2 Jun 2003 19:13:28 -0700 (PDT) Date: Mon, 2 Jun 2003 19:13:28 -0700 From: Hiten Pandya To: Terry Lambert Message-ID: <20030603021328.GB46362@perrin.int.nxad.com> References: <20030602014757.GA99626@perrin.int.nxad.com> <3EDB6A6F.827B7C22@mindspring.com> <20030602160411.GA24490@perrin.int.nxad.com> <3EDB7B15.8B23E5C7@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EDB7B15.8B23E5C7@mindspring.com> X-Operating-System: FreeBSD FreeBSD 4.7-STABLE User-Agent: Mutt/1.5.4i cc: current@FreeBSD.ORG cc: des@FreeBSD.ORG Subject: Re: VFS: C99 sparse format for struct vfsops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 02:13:29 -0000 On Mon, Jun 02, 2003 at 09:28:05AM -0700, Terry Lambert wrote: > This is a different thing entirely... you are not adding > elements in the cdevsw case. Er, huh? Did you read Poul's HEADSUP mail for cdevsw sparse init? > The VFSOP case is less of a problem than the VOP case, but it's > still a problem. Poul broke the VOP case a long time ago, when > he added the default stuff, since there is no way to add a new > default to an already existing array, and the entries with a > default can't be proxied (e.g. over the network or to user space > via a descriptor, per John Heidemann's original design for VFS > stacking in UCLS's FICUS). OK, we are moving away from UCLS' FICUS. Could you kindly provide me with some examples, and practicle use of this ``adding'' a new default in an already existing array? > By making this change, you are basically changing it from a > data structure to something that has to be coded, and there's > no way to add code for a new entry that needs to be defaulted > to a non-NULL value -- which they all have to be. Huh? Come again please? Could you ellaborate on this point as it is sending me in circles. I don't see how it is not possible to do that, please provide a practical case, so I can understand. > As I said above: Poul broke this for VOPs. It doesn't make > sense to say "It's broken for VOPs now, so it's OK to break it > for VFSOPs, too". ... > It's "not been a problem", as you say, so far, because the VFS > stacking in FreeBSD has been broken for a long time. Breaking > it more just moves us farther away from ever fixing the code, > which I think is a bad thing. That is such of a broad statement..= > If, at some point, we get rid of the "default" crap, then it > would be possible to add VOPs to a running kernel by just > reallocating the VOP array for each mounted FS to add the entry > to the end of the array. And here is the question again, why would you want to add VOPs to a running kernel? Please provide some examples, or practical cases. > Your change makes this impossible for VFSOPS. Awaiting your reply... Cheers. -- Hiten (hmp@FreeBSD.ORG)