mà den 18.04.2005 Klokka 15:07 (-0700) skreiv Bryan Henderson:
> >We're already up to version 6 of the binary interfaces for v2/v3, and if
> >you count NFSv4 too, then that makes 7.
>
> I don't know the NFS mount option format, but I'm having a hard time
> imagining how a string-based format can take less code to parse and be
> more forward compatible than a binary one. People don't even use the term
> "parse" for binary structures, because parsing typically means turning
> strings into binary structures.
The string based parser (based, BTW, on the generic string parser in
lib/parser.c) for NFS mount options is already in the kernel, thanks to
NFSroot, and already needs to be maintained. As is the NFSv2/v3 "mount"
RPC code, and everything else that the kernel needs to take over that
duty.
The only extra information we need from userland is the DNS lookup of
the server hostname(NFSv2/v3/v4) and the client IP address (NFSv4 only).
> Having 6 separate formats isn't the only way to have an evolving
> binary
> interface. People do make extensible binary formats.
I never said they were 6 _separate_ formats. The NFSv2/v3 stuff is one
constantly "extending" binary format. See include/linux/nfs_mount.h.
Note how 4 of those fields are currently entirely obsolete (fd,
old_root, namlen, bsize) and how one more cannot be extended to cope
with IPv6 and other new transports (addr), and how one more (root)
cannot be used for NFSv4 mounts, which had to add in at least 2 more
fields that are unused by NFSv2/v3...
Sure, we could indeed have developed more sensible binary formats if our
1992 crystal ball had told us all about NFSv3 (RFC dates from 1995) and
NFSv4 (RFC dates from 2003). Not to forget lockd, statd, nfsacl, IPv6,
etc...
> I personally almost never worry about the number of bytes of code, but
> I
> worry a lot about its simplicity. User space code is less costly to
> develop and less risky to make a mistake in. I would add,
>
> 3) Keeping the kernel parsing code simple.
No.
3) Keeping the kernel parsing code _maintainable_
...and keeping around parsers for all these different formats and fields
and now extra 32-bit counterparts isn't my idea of code simplicity, code
compactness, or code maintainability.
Cheers,
Trond
--
Trond Myklebust <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
