From owner-freebsd-current@FreeBSD.ORG Mon Jun 2 09:30:18 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 870BA37B407; Mon, 2 Jun 2003 09:30:18 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id B343A43FD7; Mon, 2 Jun 2003 09:30:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldshk.dialup.mindspring.com ([209.86.242.52] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19MsCL-0002le-00; Mon, 02 Jun 2003 09:30:13 -0700 Message-ID: <3EDB7B15.8B23E5C7@mindspring.com> Date: Mon, 02 Jun 2003 09:28:05 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hiten Pandya References: <20030602014757.GA99626@perrin.int.nxad.com> <3EDB6A6F.827B7C22@mindspring.com> <20030602160411.GA24490@perrin.int.nxad.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e1ff5574377303568a8f76550999b6bd548b785378294e88350badd9bab72f9c350badd9bab72f9c 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: Mon, 02 Jun 2003 16:30:18 -0000 Hiten Pandya wrote: > > Consider this going forward: someone adds a new VFSOP to the > > list of allowable VFSOPs, and the vfs_init() doesn't have any > > specific code for it. > > Considered. Now consider this, would you argue this about the > sparse cdevsw initialisation in make_dev()? I hardly think so. > It does a good job of centralising things, and making it easier > for all of us. This is a different thing entirely... you are not adding elements in the cdevsw case. 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). 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. > > This could happen with a new VFS implementation that gets loaded > > as a module. While the current code can't really handle this > > well, the changes move us further away from ever being able to > > handle something like this. 8-(. > > But, up to now, this has not been a problem, unless you make it > so. I don't think I even needed to add conditional checks for > the mount and nmount ops in vfs_init. These are things which > would be fault of developer if he doesn't update the > `centralised' code, not yours or mine, or FreeBSD's. > > I also don't see the point of having a gazillion default ops > being inited in every fs specific vector when we can just do > this centrally. 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. 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. Your change makes this impossible for VFSOPS. -- Terry