From owner-freebsd-current Sun Mar 8 18:46:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29648 for freebsd-current-outgoing; Sun, 8 Mar 1998 18:46:09 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA29632 for ; Sun, 8 Mar 1998 18:46:04 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA21271; Sun, 8 Mar 1998 19:46:04 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd021258; Sun Mar 8 19:46:01 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA15424; Sun, 8 Mar 1998 19:45:58 -0700 (MST) From: Terry Lambert Message-Id: <199803090245.TAA15424@usr08.primenet.com> Subject: Re: vnode_pager: *** WARNING *** stale FS code in system To: nate@mt.sri.com (Nate Williams) Date: Mon, 9 Mar 1998 02:45:58 +0000 (GMT) Cc: dima@tejblum.dnttm.rssi.ru, tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: <199803080002.RAA05223@mt.sri.com> from "Nate Williams" at Mar 7, 98 05:02:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Tell me what I'm missing, if anything? > 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. FFS consumes 151 kernel functions; about 120 more than it should. > 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. > 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. > 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. > 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. */ > 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. In addition, we have the implied comments about VOP_GETPAGES being necessary through its existance in various working FS implementations. > 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. Because of this, yoy are mixing the idea of writing a non-stackable local media FS (it can only be stacked *on top of* because it does not properly implement a bottom end that is identical to its top end; it's bottom end is the kernel interfaces to subsystems like VM) and a stackable FS (for which your second paragraph is true). People, *PLEASE* read Heidemann's paper before making comments on FS architecture! It is *the* architectural refrence for the BSD 4.4 stacking vnode interface! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message