From owner-freebsd-current Fri Mar 6 17:55:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA01167 for freebsd-current-outgoing; Fri, 6 Mar 1998 17:55:13 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA01161; Fri, 6 Mar 1998 17:55:04 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id SAA00386; Fri, 6 Mar 1998 18:55:04 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd000364; Fri Mar 6 18:55:00 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA27728; Fri, 6 Mar 1998 18:54:55 -0700 (MST) From: Terry Lambert Message-Id: <199803070154.SAA27728@usr09.primenet.com> Subject: Re: vnode_pager: *** WARNING *** stale FS code in system To: dima@tejblum.dnttm.rssi.ru (Dmitrij Tejblum) Date: Sat, 7 Mar 1998 01:54:55 +0000 (GMT) Cc: dmaddox@scsn.net, dyson@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199803060930.MAA01918@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Mar 6, 98 12:30:29 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 > > > Whomever has been doing the vnode_pager changes should likely > > > fix the msdosfs also. I am now working on fixing NFS, and am > > > totally swamped. > > > > If I recall correctly, the fix in question was submitted by Terry, and > > committed by Michael Smith, so I expect one of them may want to take a > > look at it... > > Not quite so. The breakage was introduced by Terry in this commit. Now he > made a patch to fix the remaining filesystems, but the patch was not > committed. The patches being discussed are at: http://www.freebsd.org/~terry/D.GP.REST > These changes completely break my "aesthetic principles", and > I started to argue. Then the weekend was finished, I lost the free > time.... So --- sorry, I feel I lose due to timeout... On other hand, > there is a new weekend soon... :) Anyway, arguing with Terry is not a big > fun... I'm willing to discuss (not argue) the design. The reason I went the way I did was that putting the vnode_pager.c code in the defaultops vector does nothing toward making the code in vnode_pager.c _go away_, which is the eventual goal. FS's which can act as backing store need to have FS specific backing store management, for a large variety of reasons (I can enumerate these reasons again, if you need me to). A secondary reason is that it means I have to make special code in stacking FS's in order to be able to access the bypass (which I think should be placed in the defaultops vector instead). I think this is bad because I think that FS stacking layers are going to vastly outnumber local media FS's in the near future, providing we can get the code to make them work committed for people to use as a foundation for their own hacking. I personally have three that I'd like to see done, and other people have approached me about cryptography, compression, NFS anonymous mount/WebNFS exposure via "//nfs/...", the same thing for FTP, ACL's, and other stuff so wierd even I think it's strange to want. A tertiary reason is that if the code is in the defaultops vector, I can't know when it becomes safe to remove from vnode_pager.c and the defaultops vector. There's no way to measure usage of the defaultops code (that's kind of the point, really). I don't think you've "lost by timeout", but by the same token, you've failed to make a compelling case why putting it in the defaultops is not ill-advised. Like I said, I'm open to discussion on all of this; lately, I've found a granularity where I've been on a roll, and nothing would squelch that faster than a set of badly thought out patches. It's in my best interests to listen to what you have to say. 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