Observations from an old timer playing with 64 bit numbers...

Randall Stewart rrs at lakerest.net
Thu Jun 24 12:43:47 UTC 2010


Lugi:

One other comment I want to make about your numbers... well maybe  
three ;-)

On Jun 23, 2010, at 10:12 AM, Luigi Rizzo wrote:

> On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote:
> ...
>>>> strong objection!
>>>> We should instead use names with exact sizes (16,32,64).
>>
>> So please tell me why you object so strongly? We have the 16/32/64  
>> bit
>> names which
>> are nice but are not expected so folks seem to not use them. I have
>
> people's ignorance is not an excuse for not doing things right.
> We'd still be using BYTE, WORD and DWORD otherwise.
>
> I think there is no doubt that we should use the 16/32/64 bit names
> if we could start from scratch, and the only reason for not doing
> so is avoiding gratuitous changes to existing/stable code.
>
> The case of *to*ll does not apply, in that there is no actual legacy
> to adapt to. And btw there is tons of places which use the 16/32/64  
> bit
> names in the filesystem, usb and generic device drivers. In fact,
> many more than ntohl/htonl
>
> 	> grep -r be32 ~/FreeBSD/head/sys/ | grep -v .svn | wc
> 	    1438    6397  145174
> 	> grep -r le32 ~/FreeBSD/head/sys/ | grep -v .svn | wc
> 	    2203   10269  210989
> 	> grep -r ntohl ~/FreeBSD/head/sys/ | grep -v .svn | wc
> 	     854    4009   84855
> 	> grep -r htonl ~/FreeBSD/head/sys/ | grep -v .svn | wc
> 	     738    3604   72970

1) The grep for le32 is really not something you would do. You never
    convert network byte order to le32 for sending things on the wire  
since
    network byte order is be. I would imagine the 2203 occurrences are  
where
    you are dealing with buses (pci comes to mind) that want le.

2) When you grep be32 you are getting both conversions so you are  
comparing
    1438 against 1592 (854+738). So it seems to me be32 is not used  
yet as
    much for network conversions.. and even more so one might want to  
delve
    in kernel wise to where the be32 is being used.. I would bet it is  
also
    in the same vein.. i.e. machines doing things with the bus... and
    very little network transmission code.. and that leads me to my  
final comment, which
    I think proves my point.

3) A much fairer comparison is looking in the head NOT including sys.  
I did a simple
    script along these lines by doing:
    cd ~head
    ls | grep -n sys > list
    grep -r be32 `cat list` | grep -v .svn | wc -l
         215
    grep -r ntohl `cat list` | grep -v .svn | wc -l
         888
    grep -r htonl `cat list` | grep -v .svn | wc -l
         913

    So adding that up its 1801 uses of the h/n macros and 215 of the  
be. Thats almost 10 to 1.


Now I am not disagreeing with you that the be32 is clearer.. but my  
point is still valid... networking
application developers do think in terms of the ntohl/htonl macros.  
Until we get more information
out to them (assuming that the bexx and friends are available on linux  
and windows) you will not
see an uptake in the use of them unless we educate folks. In this case  
ignorance is a good
excuse until all networking manuals have be* and friends... looking in  
Fenner's update to
UNP (3rd edition) I find only the ntohl/htonl macros mentioned ;-(

A good start for documentation would be the man page for ntohl  
pointing directly at the be64 macros man
page for 64 bit conversions.. I would suggest more than a reference  
and an explicit statement.
Do that and people will not flounder around and roll their own..  well  
then again maybe they
still will .. since folks are so conditioned for ntohx()..

Hmm maybe I will take Julian's suggestion and make it easier for SCTP  
folks ;-)

R



>
> cheers
> luigi
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>

------------------------------
Randall Stewart
803-317-4952 (cell)



More information about the freebsd-net mailing list