On Tue, Nov 11, 2008 at 8:11 PM, sqweek <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen <[EMAIL PROTECTED]>
> wrote:
>> I have two measurements of success:
>> a) what keeps me working on Plan 9 related technologies in a paid position
>> b) what switches people from using NFS, GPFS, or other horribly
>> complicated solutions to something closer to Plan 9
>
> Fair enough. Does .L still qualify as "closer to Plan 9", or is it
> NFS by any other name?
It'll likely be more tightly bound to Linux than NFS (in much the same
way that 9P is tightly bound to Plan 9). Some of the new features of
NFSv4 actually bring it closer to 9P in ways, but .L isn't an attempt
to mimic NFSv4, its merely an attempt at defining a protocol to remote
Linux VFS operations. Since the core of the protocol is base don 9P
(use of fids, walks, tags, etc.) many of the basic principals are
closer to 9P versus NFS -- its just there is a larger potential
operation space with parameters and argument syntax that matches the
underlying Linux interfaces (so no mapping/unmapping gorp is
necessary).
> I'd hazard a guess that 9p's auth mechanism is more flexible, for starters.
While this may be true, its not clear how Auth will actually play out
in a Linux context. However, one thing I am trying to do is keep
everything within the protocol instead of defining separate protocols
and ports for auth, locking, id mapping, etc. Although IIRC, NFSv4
actually makes some progress on fixing that as well.
-eric
