>My concern is that we are slowly but surely building up a bigger
>in-kernel library for parsing the binary structure than it would take to
>parse the naked mount option string.
>
>...
>If people really do need a fully documented NFS mount interface, then
>the only one that makes sense is a string interface. Looking back at the
>manpages, the string mount options are the only thing that have remained
>constant over the last 10 years.
>
>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.
Having 6 separate formats isn't the only way to have an evolving binary
interface. People do make extensible binary formats.
>There are only 2 reasons for doing
>that parsing in userland:
>
> 1) DNS lookups
> 2) Keeping the kernel parsing code small
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.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
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
