![]() | |||||||||||||
Messages in this thread |
Linus voiced his opinions: > On Thu, 29 Oct 1998, G. Allen Morris III wrote: > > /proc/fs/nfsd/exports would have: > > /home myhost 15 01000001,-02000001 > > /home 2.0.0.1 10 02000001 > > or > > /home localhost(async,ro,root_squash) # 1.0.0.1,(2.0.0.1) > > /home 2.0.0.1(async) # 2.0.0.1 > > > > I prefer the first, as it is much easier to implement, and easier to parse. > > but the second one is easier to read and would be compatible with exports(5). > > I look at the first, and I don't immediately understand what it means. > I look at the second, and it looks much clearer. (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/ | ||||||||||||
| Last update: 2005-03-22 13:45 [from the cache] ©2003-2008 | |||||||||||||