lkml.org 
[lkml]   [1998]   [Oct]   [29]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] /proc/fs/nfsd/exports
    DateFri, 30 Oct 1998 01:56:46 +0200 (EET)
    FromMatti 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/
    
    
    \
     
     \ /
      Last update: 2005-03-22 13:45    [from the cache]
    ©2003-2008