lkml.org 
[lkml]   [1998]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] /proc/fs/nfsd/exports
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.548 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site