From owner-freebsd-current Mon Mar 9 00:45:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18652 for freebsd-current-outgoing; Mon, 9 Mar 1998 00:45:58 -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 AAA18603 for ; Mon, 9 Mar 1998 00:45:51 -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 BAA27145; Mon, 9 Mar 1998 01:05:58 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id BAA16882; Mon, 9 Mar 1998 01:05:56 -0700 Date: Mon, 9 Mar 1998 01:05:56 -0700 Message-Id: <199803090805.BAA16882@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Hancock Cc: Nate Williams , Terry Lambert , dima@tejblum.dnttm.rssi.ru, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system In-Reply-To: References: <199803090727.AAA16521@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > In short, you are attempting to make local media FS's the 'base class' > > > > for all FS (using C++ vernacular). As Base Classes, they must > > > > implement/define *everything* for all classes, and that all other > > > > 'stackable' FS's can inherit from the base class. > > > > > > Yes. This is different from interfaces. which are allowed to be "pure > > > virtual" base classes. I wasn't sure about using OO terminology. 8-(. > > > > Bingo. I didn't want to say that for fear of complicating the simple > > definition. As I understand it, the whole VFS framework is an attempt > > to OOPify (is that a word) the FS interface. > > I think this is good enough to go forward, but you need to understand that > with the Heidemann FS stacking framework you can extend the set of VOP's > in interesting ways. For example, suppose you wanted to implement > VOP_NEWFEATURE. You could do the following: > > Layer1 - Supports it and maps results from one below. > Layer2 - Doesn't support so does a bypass. > Layer3 - Supports it and maps results from one below. > Layer4 - Doesn't support so does a bypass. > Layer5 - Terminal layer, some support some don't. > > I'm not sure traditional OOP can do this and this makes finding good > analogies difficult. Traditional OOP does this right, since you inherit from the class below you, and not from the base class. If you want to inherit from the base class, you inherit from it and not a subclass. > VOP_PUT|GET are pretty important to support given the symbiotic > relationship of the FS and the VM system. So it should definitely be > supported to full capability of the given local media FS. There are > some VOP's that are fundamental to the system and some that aren't. I understand that now. (I can't do anything about it at this point in time, but understanding is a step in the right direction. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message