From owner-freebsd-current Sun Mar 8 20:16:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA18220 for freebsd-current-outgoing; Sun, 8 Mar 1998 20:16:23 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA18114 for ; Sun, 8 Mar 1998 20:15:54 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id UAA25399; Sun, 8 Mar 1998 20:56:28 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id UAA14668; Sun, 8 Mar 1998 20:56:26 -0700 Date: Sun, 8 Mar 1998 20:56:26 -0700 Message-Id: <199803090356.UAA14668@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), dima@tejblum.dnttm.rssi.ru, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system In-Reply-To: <199803090344.UAA17601@usr08.primenet.com> References: <199803090300.UAA13920@mt.sri.com> <199803090344.UAA17601@usr08.primenet.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Terry wants FS implementors (therefore all FS's) to explicitly write > > > > code for vnode_pagers, rather than having the (potentially buggy) code > > > > used by FS writers. > > > > > > Terry wants local media FS implementors (therefore all non-stackable > > > FS's) to explicitly write code for vnode_pagers as payment for their > > > direct consumption of OS-specific kernel internals. > > > > Same thing, different way of putting it. > > ??? > > Can't you diff "all FS's" and "all non-stackable FS's"? What's the difference? Aren't all FS's stackable? > > Screw the design when it comes to having buggy/non-working FS's. That's > > one of the rules of getting your code committed. If your solution isn't > > complete, then it shouldn't be committed. > > That's BS. I've tried that road before, and the code has been > consistently refused commit. > > I've bowed to (IMO, unreasonable) pressure to get there incrementally, and > now you are bitching that the code's not getting there all at once. Make your increments complete. Incomplete increments don't do anyone any good. > > So, if you didn't provide > > patches to *all* existing code then you should be taken out and beat > > about the head and shoulders with a large noodle. > > I will be *happy* to wield the noodle over the death of LFS, X.25, > and the ISO networking code. Where do I sign up for a noodle? Touche. OK, how about your patches should be for all currently working/used code. > > If you want all the FS's to *require* the code, then write code for all > > of the existing FS in FreeBSD. > > I want them to *eventually* require the code. This is very different > from your characterization of my statements. Right now they *require* the code. If they don't have it, they whine and sometimes misbehave. > > Finally, I disagree with the claim that *all* FS must implement *every* > > vops operation. If so, then the 'stackable' design is broken, since in > > any good design you should have the ability to use a default for common > > operations. > > All FS's do *NOT* have to implement every VOP. All FS's do not even have > to implement VOP_{GET|PUT}PAGES, if they don't want to. If they don't have to, then why do they whine if they don't have it? > > > Terry claims that use of the default vops vector breaks automatic > > > bypass in vfs_init. > > > > Pray tell which existing FS break if you add the code to the default vops? > > None. Which existing FS's break if you add stub functions? None. Which > existing FS's break if you make a modification to make the warning not > fatal, the patch for which was included in my last post? None. So what's the point in the warning then? > > > Dima wants it to work the way it used to, and doesn't see any reason > > > to change the existing code path in a way which is visible to Dima. > > > > Dima (and I) are fans of POLA. > > So am I. We are just astonished by different things. I'm astonished > that after 2 full years of effort, FS stacking still doesn't work. What effort? Yours? I dont see anyone working on the FS stacking effort. > And the only "punishment" is a perfectly valid warning. Maybe it should > be changed to say "..stale FS code: you will not be able to stack FS's > on this FS!". It's violates POLA. A normal user of FreeBSD doesn't have any stacking FS, and he's seeing irrelevant/whiney messages that imply something bad about his system, when in fact there are no problems with his system. (There are potential problems, but if he's writing stackable FS's, then he should be smart enough to figure this out, shouldn't he?) > > > Terry claims to have read the comment in /sys/vm/vnode_pager.c: > > > > > > /* > > > * TODO: > > > * Implement VOP_GETPAGES/PUTPAGES interface for filesystems. Will > > > * greatly re-simplify the vnode_pager. > > > */ > > > > I don't see anywhere it states that a 'default' VOP_GETPAGES can't be > > added in here, vs. a VOP_GETPAGES in every [ local media ] FS. > > It doesn't say I can't include a uuencoded copy of the human genome > database in the damn thing, either, but it would be just as stupid to > do that. In your mind yes. To my mind, no. > > That's a total non-sequiter. LFS and NFS have brokeness way beyond the > > VOP_GETPAGES stuff. Getting them working require that as well as much > > other stuff. The reason they don't work is that their bits have rotted > > due to inattention. > > Software. Does. Not. Mutate. Bits. Rot. Due. To. Changes. Around. Them. > You as much as agree with me when you suggest "So, if you didn't provide > patches to *all* existing code then you should be taken out and beat > about the head and shoulders with a large noodle." They were broken when we got them. Their brokeness continued and was at times made worse due to changes made around them. If they had been used by someone, then they would have been maintained. > > (BTW, can you describe succintly what a 'local media' FS is in your > > terms, so that I'm not making any wrong assumptions?) > > A file system is stackable if it both provides and consumes the VFS > interface. NULLFS is an example of a stackable FS. > > A file system is not stackable if it provides the VFS interface, but > consumes another interface (such as the local OS's VM system). FFS is > an example of a non-stackable FS which consumes another interface. > > A file system is not stackable if it does not provide the VFS interface, > even if it consumes the VFS interface. The NFS server is an example of > a non-stackable VFS consumer. The FreeBSD system call interface is another > example of a non-stackable VFS consumer. Thank you. Nate ps. Even though I am often-times the devil's advocate here, I do appreciate you taking the time to answer my questions. I'm attempting to learn wherever I can, and since FS-101 died I'm learning wherever I can. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message