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