Messages in this thread | | | Subject | Re: [RFC] /proc/fs/nfsd/exports | Date | Fri, 30 Oct 1998 01:56:46 +0200 (EET) | From | Matti Aarnio <> |
| |
Riley Williams commented on /proc/fs/nfsd/exports: .... > Personally, I'd go for the second - there's enough arguments already > about the existing /proc files that show IP addresses as numbers, and > whether they should be displayed in big-endian format (as your example > above does) or little-endian format (as /proc/net/route does).
The problem there is that IPv4 addresses, and masks are 32 bits long network-byte-order values, and our tradition has been printing them out thru %08X as if they are mere integers. (And letting user-space applications to 1: scan in the hex value, 2: turn it from network-byte-order value to presentation value of dotted- decimal form.)
Those values are NOT integers originally, they are octet arrays.
IPv6 does things cleanly -- it has to, as there are no primitives to "help" for hex/whatnot presentation of 128 bit values. (Adding the primitives into kernel's "printf" format stuff get barfed by gcc -- apparently there is no gcc extension to tell it of new primitives, even though glibc has mechanics to add new formats, and one could expect gcc to have ways too...)
Of course, if the interfaces would do ntohl() before printout, the applications would need to do htonl() for the scanned value before presenting it out... (This has propably been the reason why the kernel does these endianity games at the printouts.)
Considering /proc/fs/nfsd/exports:
At interfaces where the call of ntohl() at the values is felt to be exessively heavy (as to compared against sprintf, or what ??), they values are in whatever mixed-endian the system feels like to do -- little-endian at intel architecture. If you want them humanly semi-readable, do ntohl() at the values first, else just print them as integers. BUT! Be prepared to accomodate IPv6 addresses there too! That is, all the sudden you could get 128 bits long hex-encoded octet arrays there, and you would (need to) know it only by noteing the length of the hex encoded array before non-hex character.
I mean, by preparing for a clean integration to IPv6 addresses amongst the exports reports, you already should use form: sprintf(buf, " .. %08X ..", ntohl(zzz->ipv4_addr))
Then latter when we get to integrate the beast with IPv6, we might not need to create a new file to report about IPv6 exports. And if we are really lucky, the user-space applications already are aware of the possible alternate encodings...
For that matter, I would suggest the addresses to begin with an octet (in hex) telling the protocol family just in case we get to play with some other esoteric network protocols, like ATM NSAPs some day, and the applications would be ready for it -- or could tell that they don't know about it, and just show the raw hex stuff..
/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/
| |