From owner-freebsd-current Sun Mar 8 19:01:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA03982 for freebsd-current-outgoing; Sun, 8 Mar 1998 19:01:13 -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 TAA03954 for ; Sun, 8 Mar 1998 19:01:02 -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 UAA24932; Sun, 8 Mar 1998 20:00:53 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id UAA13920; Sun, 8 Mar 1998 20:00:47 -0700 Date: Sun, 8 Mar 1998 20:00:47 -0700 Message-Id: <199803090300.UAA13920@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: <199803090245.TAA15424@usr08.primenet.com> References: <199803080002.RAA05223@mt.sri.com> <199803090245.TAA15424@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. > > Dima wants people to not have write potentially trivial code into their > > FS, but give them a default that will work in most cases. > > By use of the default vops vector, which violates the design principles > of the stacking FS code according to both "The Design and Implementation > of the 4.4BSD Operating System" and "Stackable Layers: An architecture > for File System Development", both of which FreeBSD purports to pay > lip-service to. 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. 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. If you want all the FS's to *require* the code, then write code for all of the existing FS in FreeBSD. 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. > > Terry claims that if they rely on the trivial code, it could cause bugs. > > 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? > > Dima claims that for most existing FS's, the trivial stuff is good > > enough for their purposes, and that any FS developer that isn't writing > > a trivial FS already is smart enough to write a non-default vnode_pager > > implementation. > > 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. Terry wants to punish people for not doing things his way. I think reading 20 page emails is punishment enought w/out have the FS's break (or whine alot) is overkill. > > Terry claims that this vnode_pager stuff should go away, and it'll be > > easier to remove it by making sure that all FS's have this code, but > > then he loses me from that point on. > > 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. > > Anyone silly enough to write > > [ local media ] > > > FS's should know what they're doing, and forcing them to write more > > boilerplate code that could be done by default is simply silliness. > > The point is, of course, that the code *can't* be done by default, and we > have as evidence the death of LFS and the non-function of NFS. 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. > > If you're smart enough to write FS, you should also be smart enough to > > figure out when the defaults won't cut it. > > > > This is the intent of stacking FS's as I understand. The VFS stuff is > > intended to make FS design more OOP, so that you can pick what things > > you need to implement, and not have to implement others, just like > > object inheritence. > > For stackable FS's (which means *NOT* local media FS's) the underlying > FS below the stack will implement the VOP_{GET|PUT}PAGES by means of > the bypass. So, stacking only applies to non 'local media' FS? Seems like a bad design if it can't take care of both cases. (BTW, can you describe succintly what a 'local media' FS is in your terms, so that I'm not making any wrong assumptions?) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message