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

[Luigi Rizzo]

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.

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)