From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 13 Nov 2008 21:52:42 -0800 From: Roman Shaposhnik In-reply-to: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <3ADF7D1A-295E-42EA-BFFB-C7739BBC3FF7@sun.com> MIME-version: 1.0 Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <5d375e920811121100o15702c64ufb6e367220606058@mail.gmail.com> <4506d967646c9cd2dd052fb9f5356c7f@plan9.bell-labs.com> Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 4160441a-ead4-11e9-9d60-3106f5b1d025 On Nov 13, 2008, at 8:37 AM, Dan Cross wrote: > On Wed, Nov 12, 2008 at 2:13 PM, wrote: >> stat(5) specifies exclusive-access files, which we do use for >> locking. >> In what sense is that not `doing locking'? It's not POSIX byte-range >> read- or write-locking per fcntl, but it's not clear to me how often >> that's actually useful. In quite a few situations, having a single >> process directly access a resource and forcing all other accesses >> through that process suffices. > > For special purposes, the canonical solution is probably just to have > a ctl file that accepts commands to manipulate locks. It's a bit of a > protocol dance in the sense of the calling program having some smarts > about what order it does things in, but wouldn't require changes to 9P > proper. > > I recall when we were talking about adding a Tflush message around the > time of 9P2000 and Rob or Russ or someone saying, "that's really the > job of a fileserver." I didn't fully appreciate what they meant at > that time, thinking solely in terms of disk-based "file servers" > (instead of the more abstract notion of a fileserver as a collection > of related resources with well-defined operations on them) like kenfs, > but it dawned on me (much) later that they were just referring to some > sort of ctl file and a command along the lines of "sync ". > Locking is a natural abstraction of that kind of thing; it could > easily be abstracted into a library function that does the right > thing, much as dial() does. But along the very same line of thought -- wouldn't it also then be much more reasonable to stick with an "alternative aname" approach when adopting 9P for symlinks, FIFOs and the rest of the POSIX paraphernalia? You pay with a slightly more complicated server, but you reap a huge benefit in a form of: term% srvssh unix unix-fs term% mount /srv/unix-fs /n/unix-fs term% mount /srv/unix-fs /n/unix-fs-symlinks posix-symlinks # Look ma, I'm creating a symbolic link from a Plan9 terminal # I'll name it after you and it'll point to the root term% echo / > /n/unix-fs-symlinks/home/glenda/mama # And I can even do readlink() term% cat /n/unix-fs-symlinks/home/glenda/mama / # Best of all -- it all works as expected term% cd /n/unix-fs/home/glenda/mama term% ls bin cdrom etc initrd initrd.img.old lib32 lost+found mnt proc sbin sys usr vmlinuz boot dev home initrd.img lib lib64 media opt root srv tmp var vmlinuz.old Thanks, Roman.