From owner-freebsd-net@FreeBSD.ORG Thu Jun 24 16:25:17 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01930106566C for ; Thu, 24 Jun 2010 16:25:17 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 948DC8FC14 for ; Thu, 24 Jun 2010 16:25:16 +0000 (UTC) Received: from mobile-166-129-250-066.mycingular.net (mobile-166-129-250-066.mycingular.net [166.129.250.66] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o5OGP44a062681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Jun 2010 12:25:09 -0400 (EDT) (envelope-from rrs@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1277396715; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=MWvF7QZbRj8Mv83HbHTZUZ6l/YfQUr3dDrHYZguM0EKjO3wuPreAF/W wRZ8gW+U1tuc4qK+yLIz0TKkXU1o29A== Message-Id: <3CF072B5-2DE3-45F4-B2B3-6C7DA89F09EE@lakerest.net> From: Randall Stewart To: Luigi Rizzo In-Reply-To: <20100624131004.GA39128@onelab2.iet.unipi.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 09:24:59 -0700 References: <20100622221228.GA93249@onelab2.iet.unipi.it> <20100623232402.X45536@delplex.bde.org> <9C936FEB-4858-4D8D-89CC-182EA3A80365@lakerest.net> <20100623171222.GA7981@onelab2.iet.unipi.it> <3A61E8D1-94A2-43D4-BD08-E4701A7A429D@lakerest.net> <20100624131004.GA39128@onelab2.iet.unipi.it> X-Mailer: Apple Mail (2.936) Cc: net@freebsd.org Subject: Re: Observations from an old timer playing with 64 bit numbers... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 16:25:17 -0000 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-unsubscribe@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-unsubscribe@freebsd.org" > ------------------------------ Randall Stewart 803-317-4952 (cell)