From owner-freebsd-hackers Mon Aug 23 23:31:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by hub.freebsd.org (Postfix) with ESMTP id CDCC915901; Mon, 23 Aug 1999 23:29:03 -0700 (PDT) (envelope-from ross@gilliam.users.flyingcroc.net) Received: (from ross@localhost) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) id XAA04695; Mon, 23 Aug 1999 23:28:18 -0700 (PDT) Date: Wed, 18 Aug 1999 11:49:25 -0700 (PDT) Message-Id: <199908240628.XAA04695@gilliam.users.flyingcroc.net> From: Terry Lambert Subject: Re: BSD XFS Port & BSD VFS Rewrite To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: tlambert@primenet.com, michaelh@cet.co.jp, wrstuden@nas.nasa.gov, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG, fs@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> > > I'm not familiar with the VFS_default stuff. All the vop_default_desc > >> > > routines in NetBSD point to error routines. > >> > > >> > In FreeBSD, they now point to default routines that are *not* error > >> > routines. This is the problem. I admit the change was very well > >> > intentioned, since it made the code a hell of a lot more readable, > >> > but choosing between readable and additional function, I take function > >> > over form (I think the way I would have "fixed" the readability is by > >> > making the operations that result in the descriptor set for a mounted > >> > FS instance be both discrete, and named for their specific function). > >> > >> As I recall most of FBSD's default routines are also error routines, if > >> the exceptions were a problem it would would be trivial to fix. > > > >You would have to de-collapse several VOP lists that have been > >pre-collapsed. > > You are talking gibberish here. Please show code where this is > a problem. When you write a proxy stacking layer, such as John Heidemann's network proxy stacking layer (an NFS alternative), VOP's which would normally be handled by vfs_default have to be handled on the other end of the proxy, instead, in the same way that they would be handled by the vfs_default stuff. Some VOP's, like advisory locking, need both local assertion and remote proxy of the VOP to avoid introducing race windows. The result of this is that, if you rely on the vfs_default stuff, then you can't proxy those VOP's into a different address space, either on another machine, or to a user space VFS stacking layer developement environment. This is the same problem that embedding VM references directly into any FS causes, and that vm_object_t aliases would exacerbate. John has, in the past, sent me a number of stacking layers done by various people, with the requirement that I not redistribute them, as they are not what he would consider to be properly representative of finished work. Since John himself did the network proxy, you could perhaps get him to send you a copy, so you could have direct access to code where this was a problem. Make sure that the system you are talking to over the proxy is not assumed to be a FreeBSD system (e.g. don't assume that the vfs_default stuff exists on the other end of the proxy, or that it would be functional). 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-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message