From owner-freebsd-current Mon Mar 9 00:44:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18092 for freebsd-current-outgoing; Mon, 9 Mar 1998 00:44:38 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA18050 for ; Mon, 9 Mar 1998 00:44:25 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id IAA21631; Mon, 9 Mar 1998 08:01:06 GMT Date: Mon, 9 Mar 1998 17:01:06 +0900 (JST) From: Michael Hancock To: Nate Williams cc: Terry Lambert , dima@tejblum.dnttm.rssi.ru, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system In-Reply-To: <199803090727.AAA16521@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 9 Mar 1998, Nate Williams wrote: > > > 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. You probably need to explain things seven different ways before things get clearer, before things click, before things feel right, ... to a wider audience because different people have different ways of perceiving the world. 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. Regards, Mike Hancock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message