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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org
"
------------------------------
Randall Stewart
803-317-4952 (cell)
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
------------------------------
Randall Stewart
803-317-4952 (cell)
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
