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

[Randall Stewart]

On Jun 24, 2010, at 6:10 AM, Luigi Rizzo wrote:

> On Thu, Jun 24, 2010 at 05:43:36AM -0700, Randall Stewart wrote:
>> Lugi:
>>
>> One other comment I want to make about your numbers... well maybe
>> three ;-)
> ...
>
> Randall,
> my numbers may well be affected by large errors, but the point was
> just to show that the *16/32/64 functions are already widely used
> across the board.
> Since we all agree that these names are more clear than the old
> naming conventions, it's time for old timers and net-centric
> people (i am 47 and doing this stuff for over 20 years so i do  
> qualify)
> to adapt to what everyone else is doing, rather than perpetrating
> some confusing naming conventions.
>
> Fine, let's not change the existing ntohl() for no reason
> (though, at some point in time there was a sweep of changes
> from the macro NTOHL() to the function form), but at least
> let's not introduce new functions with a poorly chosen name.

Well, I don't know about poorly chosen names. Like you I have been in
this business a long time now (over 30 years) ... and you know.. names
are the only thing I have found that gets wild debate... ask a technical
important point on an IETF mailing list when you are the lead document  
editor/author
and you get dead silence.. ask what you should name this field... and  
you will get
1,000 email reply's with heated debate ;-)

And the "preferred" name changes over time. Thats fine when the  
documentation
keeps up of course... but in this case it just has not. I am of course  
assuming
that the be64to* functions exist in linux at least and hopefully  
windoz... otherwise
you have another problem... i.e. portability..

But like I said the preferred name will change.. as one private  
contact wrote me:

"
I too have used {hton,hton}{s,l} for many years but I hadn't
heard of htobe64 until now.  I bet 10 years from now someone
will think *that* is too cryptic a name and will insist on
using host_to_big_endian_64bit.
"

And I think thats a valid point.. what we "think" is a good name now
will be thought of in the future as not so good. ntohs/ntohl made sense
when they were introduced and due to propagation and years of use..  
they exist
most all places... and folks guess from that where to go for 64 bit..  
hey if
I do %lld in printf .. it must be ntohll() ...

R



>
> Then sure, documentation is not up to date because no one has time
> to fix it, old books and old code still show mostly old APIs, and
> so on...
>
> cheers
> luigi
>
>>> 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)
> _______________________________________________
> 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)