(Address presentation aside)
Presenting the flag bits in symbolic form is much more
portable (which reminds me of all the pain we have when
we add new mount options and everybody must upgrade the
mount program..) With some kernel (and utility) support
the option flags could be fed to the kernel as strings,
and let the kernel to interpret the string into a set of
bits. With such behaviour the pains we have had with the
mount would not be needed... How the 'exportfs' does it ?
(hmm... 'amusing')
But what is the purpose of the interface ? Is it intended
to be *only* human readable, or *only* program parsable ?
Or perhaps *mainly* program parsable ?
(This is the reason why I don't like about the suggestions
of messing with the ways how current /proc/net/ things present
addresses.. Those are *mainly* program parsable.)
> Guess which one I prefer.
> Linus
If the interface is only for humans, I agree with Linus.
If it isn't, be carefull what you do. You may have to
live with it for a long time...
Oh yes, one thing which protocol designers always try to
add into a protocol is a version label up front:
#version: 1
That way your client programs are easier to write to
accomodate format revisions.
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/