Date: Mon, 02 Jun 2003 09:28:05 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Hiten Pandya <hmp@FreeBSD.ORG> Cc: des@FreeBSD.ORG Subject: Re: VFS: C99 sparse format for struct vfsops Message-ID: <3EDB7B15.8B23E5C7@mindspring.com> References: <20030602014757.GA99626@perrin.int.nxad.com> <3EDB6A6F.827B7C22@mindspring.com> <20030602160411.GA24490@perrin.int.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EDB7B15.8B23E5C7>