From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5d375e920708101216y225ca5e5oa06270d90e6d4271@mail.gmail.com> Date: Fri, 10 Aug 2007 21:16:30 +0200 From: Uriel To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] 9P vs. FUSE In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070810114225.GF18939@nibiru.local> <2d66a95ea087868174cfdc519a48a2d7@9netics.com> <20070810123336.GG18939@nibiru.local> Topicbox-Message-UUID: a513a508-ead2-11e9-9d60-3106f5b1d025 > However, it was decided at the last IWP9 that we had probably taken > the wrong approach with 9p2000.u and it would probably have been > better to extend 9p with new operations that had different > syntax/semantics from standard 9p as these would be easier to filter > out. I'm currently playing with a new design in my copious spare > time. > > It was further suggested by some that a better approach on Linux/UNIX > would have been to take what we know from 9p and design a protocol > specific to the VFS (similar to FUSE but capable of transparent > network, etc.) > > Some of the recent v9fs effort has been looking at 9p for > paravirtualized file system access between hosts using shared memory > transports. Much initial work has been done using 9p and 9p2000.u, > but requests for more comprehensive solutions have been requested by > customers/interested-parties with full support for Linux capabilities. > As such, there may be a foray into providing something along the > lines of a new set of extensions supporting all Linux VFS operations > (perhaps I'll call it 9p2000.l) Strange, this is not what I remember from IWP9 at all. What I remember is that pretty much all requirements people had could be accommodated *without* changing the existing 9p2000 protocol by using conventions on special attach names to provide access to extra required functionality or other such tricks (the exception was the idea of how to group messages, which unfortunately nemo seems to have discarded but I still think is so far the only real improvement 9p might need, and it could be largely backwards compatible) Of course, my memory could be wrong, but it would be really sad to see yet another 9p variant pop up after the .u debacle when I think the consensus was clear that 9p could handle just fine pretty much everything everyone wanted (again with the exception of the message grouping for high latency links). In any case, it would be nice if people considering changes to the protocol could be a bit more open about it so we could have some discussion about how much sense it makes, and we could avoid a repeat of the waste of time and effort with .u. Best wishes uriel