Date: Fri, 17 Jul 1998 21:31:56 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: michaelh@cet.co.jp (Michael Hancock) Cc: Matthew.Alton@anheuser-busch.com, FreeBSD-fs@FreeBSD.ORG Subject: Re: LFS Hacking Message-ID: <199807172131.OAA11571@usr09.primenet.com> In-Reply-To: <Pine.SV4.3.95.980718005634.10475C-100000@parkplace.cet.co.jp> from "Michael Hancock" at Jul 18, 98 01:06:02 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Vahalla's > > _UNIX Internals_ has shed considerable light on the subject. > > Yeah, excellent book. One thing that was wrong in the book was that it > said in BSD 4.4 you were able to take advantage of state and process paths > in chunks of components up to mount points in stateful systems. But it > actually works as it does in SYSV processing component at a time as if all > file systems were stateless. > > If we did take advantage of such state then stacking would probably even > more complicated to get right. The point was that the underlying VOP_LOOKUP could take one or more of the remainder of the path components in the cn_pnbuf to return a vnode. This allows things like network transport of relatively rooted paths from a network mount point. The code *still* permits this, but no one takes advantage of it in FreeBSD (in the Ficus project, this is used to do remote stack proxy to VFS layers on other machines). This is, in fact, why it is *wrong* to expect the underlying code to free your path buffers for you, or for VOP_ABORTOP to do it for you. The underlying layer may not be in the same address space, or even on the same machine. This means only the caller can free the memory with a 100% guarantee that the allocation and return occurs in the same address space. Proxy interfaces need to copy components across address spaces on the way in, and proxy modifications back on the way out. This is, in fact, the basis of my arguments for opaque, pre-parsed lists of path components in the calling 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807172131.OAA11571>