From owner-freebsd-arch@FreeBSD.ORG Sun Sep 11 10:12:34 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A12B6106566C for ; Sun, 11 Sep 2011 10:12:34 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id EEF618FC08 for ; Sun, 11 Sep 2011 10:12:33 +0000 (UTC) Received: by eye4 with SMTP id 4so1944663eye.31 for ; Sun, 11 Sep 2011 03:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=X0kZLWPEAhcNi9fsOQmajWsY61uoM1+VC2gyA3RgQrA=; b=UbGOFwmxCUBEs8yyBm4ojYY6a1v6qiU2O0Skp5fCIaY7EUh4H0RZhsliHvrDYVPeJp 5zf2V27bRL7TrZaWZkxrNBPVth9L+sdR9AOVZfsA6+aLSVoAyzXw4CjrEa6OK1VPzBGK AvPKZ7EBeAsd3s2Cq6p1hwCaViE/GWA26IVGc= Received: by 10.213.28.10 with SMTP id k10mr351989ebc.32.1315734171551; Sun, 11 Sep 2011 02:42:51 -0700 (PDT) Received: from [192.168.1.12] (5ED0E470.cm-7-1d.dynamic.ziggo.nl [94.208.228.112]) by mx.google.com with ESMTPS id d59sm15511761eea.3.2011.09.11.02.42.50 (version=SSLv3 cipher=OTHER); Sun, 11 Sep 2011 02:42:51 -0700 (PDT) Message-ID: <4E6C829A.2080007@gmail.com> Date: Sun, 11 Sep 2011 11:42:50 +0200 From: johan Hendriks User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 4.x era X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 10:12:34 -0000 Hello all First of all this is not a rant, just a write down of my feel about FreeBSD. Secondly i want to thank all of the people involved in FreeBSD for this fantastic OS that i use on a daily basis for most tasks like Mail filtering, proxy/web services and file sharing. Here i go. In the time of FreeBSD 4.x, i would without hesitating recommend FreeBSD for almost everything on the server side. You know you could take FreeBSD 4.x and start throwing rocks at it no matter how big the rocks where, and the FreeBSD people would probably stand in front of the crowd with the biggest rocks. But with the latest like 6, 7 and the 8 releases i have my doubts! I would still be throwing rocks, but i will not stand in front, and would be more picky about the rocks i pick to throw. I have no data to prove this, it is just a feeling. FreeBSD does not have the same robuust feel like it had in the 4.x days. Is this because FreeBSD does not get ironed out anymore like the 4.x release? We stop at x.3 or x.4 as where the 4.x release did go to .11 , and it proved to be a succes. Also is FreeBSD not to conservative in its settings? For example if there is a performance battle between linux, opensolaris or whatever and FreeBSD and FreeBSD lacks in performance, there is always the statement that you need to tune FreeBSD! Why? Could we not set defaults to more standard values that modern hardware uses. This has been asked several times before if i memeber correctly, and the answer is mostly that there are still some users that have old hardware. Well is it not time to let them tune the system down. Maybe an installer option, like GENERIC kernel and T_GENERIC kernel for Tuned Kernel, with has some settings that is always a good thing to have on your modern hardware. And with it comes a more suitable /etc/sysctl.conf file or default sysctl values that fits latest hardware better. This way if you have old hardware, you can select your good old known FreeBSD. If you are on modern hardware you can select the tuned version. Samba performance is in my opinion not good at FreeBSD. Windows and Linux get higher performance without any tuning. But i do not want to start using a mix of operating systems. Linux for Samba, FreeBSD fo web/mail filtering and Windows for exchange and so on. I know you can not suspect to be a high performance webserver and a samba server with the same tunings, but there must be a way to find a good balance. So if you install FreeBSD, Linux and Windows there are some differences, but not that huge as there are now. In my opinion we now starting to enter the storage era. FreeBSD with ZFS could play a major role in this. But here i get a little reluctent to use FreeBSD. If i read the maillings lists and some performance and trouble issues people have with ZFS, i starting to get doubts. I also know that succes stories are not on these lists, and only the bad things are. I work for a small company with three people. We do not have budgets to buy SAN and or NAS machines and do endless testing. Vmware is getting bigger and bigger, even for the smaller company's we work for. So again FreeBSD and ZFS could really be a good solution for a SAN/NAS. But we can not have kernel panics on the SAN/NAS! But here again reluctend to do so. Maybe it is because the problems on the mailling list, or the whole feel of it, i do not know. Now we need to make a choice. HP SANS or FreeBSD with ZFS for the SAN. Again not a rant, just my writing down the feeling i have with FreeBSD right now. And again thanks to all for making FreeBSD to what it is today. A wonderful clean sytem that still does the job for me. regards Johan Hendriks From owner-freebsd-arch@FreeBSD.ORG Sun Sep 11 16:12:29 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE0F5106564A for ; Sun, 11 Sep 2011 16:12:28 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 7B54D8FC15 for ; Sun, 11 Sep 2011 16:12:28 +0000 (UTC) Received: (qmail 23152 invoked by uid 110); 11 Sep 2011 15:45:46 -0000 Received: from unknown (HELO desktop1) (simon@optinet.com@69.112.29.172) by cobra.acceleratedweb.net with SMTP; 11 Sep 2011 15:45:46 -0000 From: "Simon" To: "freebsd-arch@freebsd.org" , "johan Hendriks" Date: Sun, 11 Sep 2011 11:45:51 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: <4E6C829A.2080007@gmail.com> MIME-Version: 1.0 Message-Id: <20110911161228.EE0F5106564A@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: 4.x era X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 16:12:29 -0000 Every stable system starts with a rock-solid hardware. Without proper hardware, it won't matter what OS you install on it. I had a slew of issues with 4.x on flaky hardware. I have had pretty loaded servers running 7-8x for years at a time without reboot. I did run into few bugs with 4,6,7 releases, had to submit a bug and to get it fixed. I also ran into a problem upgrading from 7 to 8 on one of my machines with MBR out of whack somehow. I don't believe that got fixed. So I will have to do a clean reinstall of 8 to upgrade. I must say, FreeBSD is VERY sensitive about flaky hardware. It is a lot less forgiving, thus the more panics. It is both good and bad. On one hand you will know that your hardware is bad and or failing, on the other you will get panics and downtime. I agree with you on performance tuning. It could come with pretuned settings out of the box. The fact that you have to tune it is in its roots. I believe it's very hard to have a one fit-all settings. It is fairly simple to tune it. This isn't a point-click OS, after all. I also agree that the need for storage is expanding very rapidly. All the media and cloud computing pushing storage to its limits. I am also in need of a stable yet affordable NAS solution. I tried UFS2 with NFS several years ago without great luck, so I gave up. I'll look into ZFS soon. I've had entire RAID5 fail on more than one occasion, so I know something like ZFS is important to have. My 2 cents. -Simon On Sun, 11 Sep 2011 11:42:50 +0200, johan Hendriks wrote: >Hello all >First of all this is not a rant, just a write down of my feel about FreeBSD. >Secondly i want to thank all of the people involved in FreeBSD for this >fantastic OS that i use on a daily basis for most tasks like Mail >filtering, proxy/web services and file sharing. >Here i go. >In the time of FreeBSD 4.x, i would without hesitating recommend FreeBSD >for almost everything on the server side. >You know you could take FreeBSD 4.x and start throwing rocks at it no >matter how big the rocks where, and the FreeBSD people would probably >stand in front of the crowd with the biggest rocks. >But with the latest like 6, 7 and the 8 releases i have my doubts! I >would still be throwing rocks, but i will not stand in front, and would >be more picky about the rocks i pick to throw. >I have no data to prove this, it is just a feeling. >FreeBSD does not have the same robuust feel like it had in the 4.x days. >Is this because FreeBSD does not get ironed out anymore like the 4.x >release? >We stop at x.3 or x.4 as where the 4.x release did go to .11 , and it >proved to be a succes. >Also is FreeBSD not to conservative in its settings? >For example if there is a performance battle between linux, opensolaris >or whatever and FreeBSD and FreeBSD lacks in performance, there is >always the statement that you need to tune FreeBSD! >Why? >Could we not set defaults to more standard values that modern hardware >uses. >This has been asked several times before if i memeber correctly, and the >answer is mostly that there are still some users that have old hardware. >Well is it not time to let them tune the system down. >Maybe an installer option, like GENERIC kernel and T_GENERIC kernel for >Tuned Kernel, with has some settings that is always a good thing to have >on your modern hardware. >And with it comes a more suitable /etc/sysctl.conf file or default >sysctl values that fits latest hardware better. >This way if you have old hardware, you can select your good old known >FreeBSD. >If you are on modern hardware you can select the tuned version. >Samba performance is in my opinion not good at FreeBSD. >Windows and Linux get higher performance without any tuning. >But i do not want to start using a mix of operating systems. >Linux for Samba, FreeBSD fo web/mail filtering and Windows for exchange >and so on. >I know you can not suspect to be a high performance webserver and a >samba server with the same tunings, but there must be a way to find a >good balance. >So if you install FreeBSD, Linux and Windows there are some differences, >but not that huge as there are now. >In my opinion we now starting to enter the storage era. >FreeBSD with ZFS could play a major role in this. >But here i get a little reluctent to use FreeBSD. >If i read the maillings lists and some performance and trouble issues >people have with ZFS, i starting to get doubts. >I also know that succes stories are not on these lists, and only the bad >things are. >I work for a small company with three people. >We do not have budgets to buy SAN and or NAS machines and do endless >testing. >Vmware is getting bigger and bigger, even for the smaller company's we >work for. >So again FreeBSD and ZFS could really be a good solution for a SAN/NAS. >But we can not have kernel panics on the SAN/NAS! >But here again reluctend to do so. >Maybe it is because the problems on the mailling list, or the whole feel >of it, i do not know. >Now we need to make a choice. >HP SANS or FreeBSD with ZFS for the SAN. >Again not a rant, just my writing down the feeling i have with FreeBSD >right now. >And again thanks to all for making FreeBSD to what it is today. >A wonderful clean sytem that still does the job for me. >regards >Johan Hendriks >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Sep 11 16:56:54 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97223106566B for ; Sun, 11 Sep 2011 16:56:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 53AFF8FC13 for ; Sun, 11 Sep 2011 16:56:54 +0000 (UTC) Received: by vxi39 with SMTP id 39so3220665vxi.13 for ; Sun, 11 Sep 2011 09:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AteM7UgPh2dwYS5QFIjPjfnoXVd+QKmSPTO8Dq4pELk=; b=eRbw7B4Qp3FEwF/0CAp8/f19tqSYRmBkajeC1cZMCZm1PCMaUb9wLoL+8QG8EHkvRS +3DeUAsEWD1wT6nNgH4LDS38N13hQ4Zfb5xE8u0vK8juWKWk1GJKX/PHPrVaEHihyI1D O2G2EF5cpkWjddgvGIl3ps54FKXRDqlTrCNok= MIME-Version: 1.0 Received: by 10.52.26.197 with SMTP id n5mr1744250vdg.462.1315760213549; Sun, 11 Sep 2011 09:56:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.161.138 with HTTP; Sun, 11 Sep 2011 09:56:53 -0700 (PDT) In-Reply-To: <20110911161228.EE0F5106564A@hub.freebsd.org> References: <4E6C829A.2080007@gmail.com> <20110911161228.EE0F5106564A@hub.freebsd.org> Date: Mon, 12 Sep 2011 00:56:53 +0800 X-Google-Sender-Auth: RhifcaiabGGsFFPhk2FwFstDBio Message-ID: From: Adrian Chadd To: Simon Content-Type: text/plain; charset=ISO-8859-1 Cc: johan Hendriks , "freebsd-arch@freebsd.org" Subject: Re: 4.x era X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 16:56:54 -0000 I've heard this many times, and here's my (paraphrased) stock response: People remember FreeBSD 4.x fondly. They likely don't remember 3.x fondly. They remember 2.x fondly - because it was rock stable for a lot of users. Then 3.x came along, with (new!) softupdates, and VM changes, and some other stuff I was too young to understand. It was stable for me, but unstable for a lot of much more serious and larger users. 4.x was when that matured. People see 8.x as stable. Not in all situations, but in a lot of them. 9.x may not be as stable for some, but there's a lot of good stuff going into it. If the developers play their cards right, 9.x will be the cycle where those bugs are shaken out and later 9.x releases will be rock solid. The only way that (and hopefully, 10.0) is going to be rock stable and be remembered like 4.x was remembered is if users actively use it, report bugs and work with developers to fix it. Rather than, you know, staying on FreeBSD-4.x :-) Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Sep 12 07:26:57 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3C091065675 for ; Mon, 12 Sep 2011 07:26:57 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 69B4C8FC14 for ; Mon, 12 Sep 2011 07:26:56 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1R30v4-000C6d-QV; Mon, 12 Sep 2011 11:27:06 +0400 Date: Mon, 12 Sep 2011 11:27:06 +0400 From: Slawa Olhovchenkov To: Adrian Chadd Message-ID: <20110912072706.GA13360@zxy.spb.ru> References: <4E6C829A.2080007@gmail.com> <20110911161228.EE0F5106564A@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: johan Hendriks , "freebsd-arch@freebsd.org" , Simon Subject: Re: 4.x era X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 07:26:57 -0000 On Mon, Sep 12, 2011 at 12:56:53AM +0800, Adrian Chadd wrote: > I've heard this many times, and here's my (paraphrased) stock response: > > People remember FreeBSD 4.x fondly. They likely don't remember 3.x > fondly. They remember 2.x fondly - because it was rock stable for a > lot of users. Then 3.x came along, with (new!) softupdates, and VM Forget about hard rock stable 1.1.5.1! From owner-freebsd-arch@FreeBSD.ORG Mon Sep 12 11:08:21 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A3A5106564A; Mon, 12 Sep 2011 11:08:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 33A0C8FC21; Mon, 12 Sep 2011 11:08:21 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C63A746B17; Mon, 12 Sep 2011 07:08:20 -0400 (EDT) Date: Mon, 12 Sep 2011 12:08:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD FS , freebsd-current@freebsd.org, Konstantin Belousov , freebsd-arch@freebsd.org Subject: Call to arms: MPSAFE file systems (was: Re: Removal of Giant from the VFS layer for 10.0) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 11:08:21 -0000 On Sat, 27 Aug 2011, Attilio Rao wrote: > With the aid of kib and rwatson I made a roughly outlined plan about what is > left to do in order to have all the filesystems locked (or eventually > dropped) before 10.0) and is summarized here: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS Here's a more succinct summary of the key points from the wiki: FreeBSD has supported Giant lock-free file systems for years, and almost all file systems have been shipping "MPSAFE" for several years. However, VFS retains compatibility support for non-MPSAFE file systems. We want to remove that compatibility support, as it adds non-trivial complexity to an already quite complex VFS, simplifying the code and making it easier to maintain and enhance. This means either fixing or removing any file systems that can't operate without compatibility support. Attilio has posted a schedule for the removal of compatibility crutches, which in turn means removing any un-updated file systems. We are looking for volunteers to perform those updates. Here's the schedule: 27 August 2011 Attilio posts plan on arch@ 1 October 2011 Add VFS_GIANT_COMPATIBILITY option (enabled) 1 March 2012 Disable VFS_GIANT_COMPATIBILITY option by default 1 September 2012 Disconnect non-MPSAFE file systems from build 1 March 2013 Garbage collect any un-updated file systems Most of our critical file systems are already done: UFS, ZFS, the NFS client and server (both old and new), unionfs, pseudofs, tmpfs, nullfs, devfs, cd9660, ext2fs, fdescfs, msdosfs, udf, and procfs. However, some remain, and they require owners: File system Owner State coda rwatson Non-MPSAFE hpfs ??? Non-MPSAFE ntfs attilio Non-MPSAFE nwfs ??? Non-MPSAFE portalfs ??? Non-MPSAFE smbfs ??? Non-MPSAFE reiserfs ??? Non-MPSAFE xfs ??? Non-MPSAFE Any file system that remains on this list will be removed by 10.0 -- so, if you care about one of the above file systems, please help us get them updated. You can find more information here, including on the methodology for making a file system MPSAFE, with worked examples: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS Robert From owner-freebsd-arch@FreeBSD.ORG Mon Sep 12 11:16:00 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97361106564A; Mon, 12 Sep 2011 11:16:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 577878FC16; Mon, 12 Sep 2011 11:16:00 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E92CD46B2D; Mon, 12 Sep 2011 07:15:59 -0400 (EDT) Date: Mon, 12 Sep 2011 12:15:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Adrian Chadd In-Reply-To: Message-ID: References: <4E6C829A.2080007@gmail.com> <20110911161228.EE0F5106564A@hub.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: johan Hendriks , "freebsd-arch@freebsd.org" , Simon Subject: Re: 4.x era X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 11:16:00 -0000 On Mon, 12 Sep 2011, Adrian Chadd wrote: > I've heard this many times, and here's my (paraphrased) stock response: > > People remember FreeBSD 4.x fondly. They likely don't remember 3.x fondly. > They remember 2.x fondly - because it was rock stable for a lot of users. > Then 3.x came along, with (new!) softupdates, and VM changes, and some other > stuff I was too young to understand. It was stable for me, but unstable for > a lot of much more serious and larger users. 4.x was when that matured. > > People see 8.x as stable. Not in all situations, but in a lot of them. 9.x > may not be as stable for some, but there's a lot of good stuff going into > it. If the developers play their cards right, 9.x will be the cycle where > those bugs are shaken out and later 9.x releases will be rock solid. The > only way that (and hopefully, 10.0) is going to be rock stable and be > remembered like 4.x was remembered is if users actively use it, report bugs > and work with developers to fix it. > > Rather than, you know, staying on FreeBSD-4.x :-) The other rather interesting thing I've observed is that people often remember the same releases quite differently, depending on their environment and workload. I know of several companies that have quite happily deployed early 5.x pre-releases in products that have now been in the field for years -- whereas I tend to remember the early releases as a bit shaky (especially as background file system checking shook out its bugs). The best general strategy is what many companies do: begin early deployment of .0 releases so that you can gain experience, and in particular, help identify critical bugs. Do widespread deployment with .1 and .2 releases, and as you begin to reach .3 and .4, think really hard about how to upgrade! For appliance vendors, it's particularly important to be tracking in-development FreeBSD while building a product, since you want to maximise overlap between FreeBSD's support lifetime for a release and your own. This is particularly critical so that you can avoid backporting drivers yourself when the FreeBSD Project (effectively) de-supports an old development line, but you still have to provide in-the-field hardware upgrades that necessarily involve newer parts that aren't supported by the old release. At least in my own deployments, multi-year uptimes of all our major releases are common. I have one box doing quite active service based on a FreeBSD 7.1 prerelease that has just shy of 900 days uptime. This isn't to say that there aren't problems, but rather to point out that a lot of our intuitions depend on our own quite specific perspectives. A lot depends on the hardware you select -- some of it down to good choices of vendors and avoiding discount parts, but some of it is pure luck -- did you get a generation of disks that was particularly poor, or end up with a BIOS revision that seriously harmed stability. You can often significantly improve OS stability by disabling lots of random BIOS features, regardless of the OS, reducing use of features like SMM that are beyond the OS's control. Robert From owner-freebsd-arch@FreeBSD.ORG Mon Sep 12 12:47:37 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0848A106566C; Mon, 12 Sep 2011 12:47:37 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3BE8FC28; Mon, 12 Sep 2011 12:47:35 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTm3/Zuunad2q5uT1HgN3LaAcd6vN+5BJ@postini.com; Mon, 12 Sep 2011 05:47:36 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 12 Sep 2011 05:46:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 12 Sep 2011 08:46:16 -0400 From: Andrew Duane To: John Baldwin , "freebsd-arch@freebsd.org" Date: Mon, 12 Sep 2011 08:46:15 -0400 Thread-Topic: Soliciting opinions on an extension of the bootinfo structure Thread-Index: Acxu7If3eeG5YhC2RxiKwSeS4k5V0ACXT73Q Message-ID: References: <4E6940D3.4070801@freebsd.org> <201109090832.20770.jhb@freebsd.org> In-Reply-To: <201109090832.20770.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-hackers@freebsd.org" , Peter Grehan Subject: RE: Soliciting opinions on an extension of the bootinfo structure X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 12:47:37 -0000 Since this has turned out to be a more contentious idea than I thought, and= the upcoming FDT work will probably remove the need for it at all, I'm wit= hdrawing the idea. Although our current code uses such a platform extension= structure, we can make do with either metadata or environment variables fo= r the time being. =A0................................... Andrew Duane Juniper Networks o=A0=A0=A0+1 978 589 0551 m=A0 +1 603-770-7088 aduane@juniper.net =A0 -----Original Message----- From: John Baldwin [mailto:jhb@freebsd.org]=20 Sent: Friday, September 09, 2011 8:32 AM To: freebsd-arch@freebsd.org Cc: Peter Wemm; Peter Grehan; freebsd-hackers@freebsd.org; Andrew Duane Subject: Re: Soliciting opinions on an extension of the bootinfo structure On Thursday, September 08, 2011 6:48:19 pm Peter Wemm wrote: > On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan wrote: > >> I'm proposing an extension framework for the bootinfo structure used > >> to pass information from the bootstrap/loader to the kernel. Although > >> I'm only proposing this for the MIPS bootinfo, it's completely > >> applicable to any of them. > >> > >> What I propose is adding an optional platform extension structure: > >> bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT > > > > Any reason not to put the vendor bits into another piece of loader=20 metadata > > ? That seems the extensible way to add additional info from the loader, > > rather than extending bootinfo (as was the case pre-loader days). > > > > later, >=20 > It sounds like they're not using loader, which is probably a > reasonable thing for their environment. That doesn't stop you from adding metadata to the kernel. It is just an ar= ray=20 of variable length blobs appended after 'end'. Any boot loader can support adding metadata. --=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 03:16:33 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02BC0106564A for ; Wed, 14 Sep 2011 03:16:33 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9A10A8FC08 for ; Wed, 14 Sep 2011 03:16:32 +0000 (UTC) Received: from sa-nc-common4-116.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p8E2apXM082568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 Sep 2011 19:37:00 -0700 (PDT) (envelope-from marcel@xcllnt.net) From: Marcel Moolenaar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 13 Sep 2011 19:36:49 -0700 Message-Id: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> To: FreeBSD Arch Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 03:16:33 -0000 All, Is there a reason not to add ntohq and htonq to the short and long versions we (and everyone else) already has? Juniper has 64-bit entities that go over the wire in network byte order and, while these macros are absolutely arcane, I see no reason not to complete them with 64-bit variants. I did some googling and htonq and ntohq seem to be de facto names used, but oddly enough no OS has them defined. It's surreal. Are there better alternatives we should migrate to? -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 11:48:43 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7726C106566B for ; Wed, 14 Sep 2011 11:48:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 509688FC18 for ; Wed, 14 Sep 2011 11:48:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0691A46B0A; Wed, 14 Sep 2011 07:48:43 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7F07B8A037; Wed, 14 Sep 2011 07:48:42 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 14 Sep 2011 07:47:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> In-Reply-To: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109140747.21979.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 14 Sep 2011 07:48:42 -0400 (EDT) Cc: Marcel Moolenaar Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 11:48:43 -0000 On Tuesday, September 13, 2011 10:36:49 pm Marcel Moolenaar wrote: > All, > > Is there a reason not to add ntohq and htonq to the short > and long versions we (and everyone else) already has? > > Juniper has 64-bit entities that go over the wire in > network byte order and, while these macros are absolutely > arcane, I see no reason not to complete them with 64-bit > variants. > > I did some googling and htonq and ntohq seem to be de > facto names used, but oddly enough no OS has them defined. > It's surreal. Are there better alternatives we should > migrate to? I don't have a better idea. I do wish the names encoded the size instead like we do for the [lb]etoh*() and hto[lb]e*() macros (that is ntoh64(), etc.). However, given that ntohl() and ntohs() are standardized we've probably lost the opportunity to fix that misfeature of ntoh*() and hton*() and a 'q' suffix is consistent (though hackish). I guess the one other possiblity is to add *16 and *32 aliases for 's' and 'l' and then add *64 for the new one if we think that using the names is better for the future (e.g. ntoh128() when it comes (or will that be ntoho() (octword?))). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 12:51:32 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A00421065673 for ; Wed, 14 Sep 2011 12:51:32 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 64E908FC14 for ; Wed, 14 Sep 2011 12:51:31 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 82F285DC8; Wed, 14 Sep 2011 12:51:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p8EBPn8H002334; Wed, 14 Sep 2011 11:25:49 GMT (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 13 Sep 2011 19:36:49 MST." <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Wed, 14 Sep 2011 11:25:49 +0000 Message-ID: <2333.1315999549@critter.freebsd.dk> Cc: FreeBSD Arch Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 12:51:32 -0000 In message <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net>, Marcel Moolenaar writes: >Is there a reason not to add ntohq and htonq to the short >and long versions we (and everyone else) already has? > >I did some googling and htonq and ntohq seem to be de >facto names used, but oddly enough no OS has them defined. >It's surreal. Are there better alternatives we should >migrate to? I prefer the explicit encode/decode functions in because they don't need to be arch specific and they don't make assumptions about alignment. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 14:39:02 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 248E6106566C for ; Wed, 14 Sep 2011 14:39:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D8CC68FC0C for ; Wed, 14 Sep 2011 14:39:01 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p8EEZ4rv054458; Wed, 14 Sep 2011 08:35:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> Date: Wed, 14 Sep 2011 09:34:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1084) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [127.0.0.1]); Wed, 14 Sep 2011 08:35:09 -0600 (MDT) Cc: FreeBSD Arch Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 14:39:02 -0000 Linux has hton64, but last time I checked it was kernel only. NetBSD = has talked about different flavors of hton64 or htonq, but it appears = none made it into the tree. htonll is in both AIX and Solaris (well, OpenSolaris 2009.06). It isn't standardized, so the standards wonks will say "be sure not to = pollute namespace with these if you implement them." If I was doing it, I'd be tempted to implement all three with two being = simple aliases to the third canonical implementation, but I think that = might get me shot when I posted the patch. Nobody wants 1/3 of a baby. Warner On Sep 13, 2011, at 9:36 PM, Marcel Moolenaar wrote: > All, >=20 > Is there a reason not to add ntohq and htonq to the short > and long versions we (and everyone else) already has? >=20 > Juniper has 64-bit entities that go over the wire in > network byte order and, while these macros are absolutely > arcane, I see no reason not to complete them with 64-bit > variants. >=20 > I did some googling and htonq and ntohq seem to be de > facto names used, but oddly enough no OS has them defined. > It's surreal. Are there better alternatives we should > migrate to? >=20 > --=20 > Marcel Moolenaar > marcel@xcllnt.net >=20 >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 14:48:45 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9D99106566B; Wed, 14 Sep 2011 14:48:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 980F38FC0C; Wed, 14 Sep 2011 14:48:45 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p8EEdZcr054475; Wed, 14 Sep 2011 08:39:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201109140747.21979.jhb@freebsd.org> Date: Wed, 14 Sep 2011 09:39:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [127.0.0.1]); Wed, 14 Sep 2011 08:39:37 -0600 (MDT) Cc: Marcel Moolenaar , freebsd-arch@FreeBSD.org Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 14:48:45 -0000 On Sep 14, 2011, at 6:47 AM, John Baldwin wrote: > On Tuesday, September 13, 2011 10:36:49 pm Marcel Moolenaar wrote: >> All, >>=20 >> Is there a reason not to add ntohq and htonq to the short >> and long versions we (and everyone else) already has? >>=20 >> Juniper has 64-bit entities that go over the wire in >> network byte order and, while these macros are absolutely >> arcane, I see no reason not to complete them with 64-bit >> variants. >>=20 >> I did some googling and htonq and ntohq seem to be de >> facto names used, but oddly enough no OS has them defined. >> It's surreal. Are there better alternatives we should >> migrate to? >=20 > I don't have a better idea. I do wish the names encoded the size = instead like=20 > we do for the [lb]etoh*() and hto[lb]e*() macros (that is ntoh64(), = etc.). =20 > However, given that ntohl() and ntohs() are standardized we've = probably lost=20 > the opportunity to fix that misfeature of ntoh*() and hton*() and a = 'q' suffix=20 > is consistent (though hackish). >=20 > I guess the one other possiblity is to add *16 and *32 aliases for 's' = and 'l'=20 > and then add *64 for the new one if we think that using the names is = better=20 > for the future (e.g. ntoh128() when it comes (or will that be ntoho()=20= > (octword?))). >=20 Looks like the hotel ate my reply... hton64/ntoh64 is what Linux has in the kernel. htonll and ntohll is = what Solaris and AIX have. So (1) I'd shy away from htonq since that's not as well established as = the other two in the OS (although googling suggests that many programs = use it). (2) I'd provide both htonll and hton64 with a note saying that = hton128 is the wave of the future. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 16:30:19 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51CFF1065672 for ; Wed, 14 Sep 2011 16:30:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 289648FC15 for ; Wed, 14 Sep 2011 16:30:19 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D1C7D46B09; Wed, 14 Sep 2011 12:30:18 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 675E88A02E; Wed, 14 Sep 2011 12:30:18 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Wed, 14 Sep 2011 12:30:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109141230.17846.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 14 Sep 2011 12:30:18 -0400 (EDT) Cc: Marcel Moolenaar , freebsd-arch@freebsd.org Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 16:30:19 -0000 On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote: > > On Sep 14, 2011, at 6:47 AM, John Baldwin wrote: > > > On Tuesday, September 13, 2011 10:36:49 pm Marcel Moolenaar wrote: > >> All, > >> > >> Is there a reason not to add ntohq and htonq to the short > >> and long versions we (and everyone else) already has? > >> > >> Juniper has 64-bit entities that go over the wire in > >> network byte order and, while these macros are absolutely > >> arcane, I see no reason not to complete them with 64-bit > >> variants. > >> > >> I did some googling and htonq and ntohq seem to be de > >> facto names used, but oddly enough no OS has them defined. > >> It's surreal. Are there better alternatives we should > >> migrate to? > > > > I don't have a better idea. I do wish the names encoded the size instead like > > we do for the [lb]etoh*() and hto[lb]e*() macros (that is ntoh64(), etc.). > > However, given that ntohl() and ntohs() are standardized we've probably lost > > the opportunity to fix that misfeature of ntoh*() and hton*() and a 'q' suffix > > is consistent (though hackish). > > > > I guess the one other possiblity is to add *16 and *32 aliases for 's' and 'l' > > and then add *64 for the new one if we think that using the names is better > > for the future (e.g. ntoh128() when it comes (or will that be ntoho() > > (octword?))). > > > > Looks like the hotel ate my reply... > > hton64/ntoh64 is what Linux has in the kernel. htonll and ntohll is what Solaris and AIX have. > > So (1) I'd shy away from htonq since that's not as well established as the other two in the OS (although googling suggests that many programs use it). (2) I'd provide both htonll and hton64 with a note saying that hton128 is the wave of the future. > > Warner > > -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 16:31:32 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28516106566C for ; Wed, 14 Sep 2011 16:31:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F33608FC1B for ; Wed, 14 Sep 2011 16:31:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A8E2246B09; Wed, 14 Sep 2011 12:31:31 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4DC148A02E; Wed, 14 Sep 2011 12:31:31 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Wed, 14 Sep 2011 12:30:51 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109141230.51827.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 14 Sep 2011 12:31:31 -0400 (EDT) Cc: Marcel Moolenaar , freebsd-arch@freebsd.org Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 16:31:32 -0000 On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote: > > On Sep 14, 2011, at 6:47 AM, John Baldwin wrote: > > > On Tuesday, September 13, 2011 10:36:49 pm Marcel Moolenaar wrote: > >> All, > >> > >> Is there a reason not to add ntohq and htonq to the short > >> and long versions we (and everyone else) already has? > >> > >> Juniper has 64-bit entities that go over the wire in > >> network byte order and, while these macros are absolutely > >> arcane, I see no reason not to complete them with 64-bit > >> variants. > >> > >> I did some googling and htonq and ntohq seem to be de > >> facto names used, but oddly enough no OS has them defined. > >> It's surreal. Are there better alternatives we should > >> migrate to? > > > > I don't have a better idea. I do wish the names encoded the size instead like > > we do for the [lb]etoh*() and hto[lb]e*() macros (that is ntoh64(), etc.). > > However, given that ntohl() and ntohs() are standardized we've probably lost > > the opportunity to fix that misfeature of ntoh*() and hton*() and a 'q' suffix > > is consistent (though hackish). > > > > I guess the one other possiblity is to add *16 and *32 aliases for 's' and 'l' > > and then add *64 for the new one if we think that using the names is better > > for the future (e.g. ntoh128() when it comes (or will that be ntoho() > > (octword?))). > > > > Looks like the hotel ate my reply... > > hton64/ntoh64 is what Linux has in the kernel. htonll and ntohll is what Solaris and AIX have. > > So (1) I'd shy away from htonq since that's not as well established as the other two in the OS (although googling suggests that many programs use it). (2) I'd provide both htonll and hton64 with a note saying that hton128 is the wave of the future. Actually, come to think of it, we use *ll rather than *q variants here at work as well. I'd vote for (2). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 16:46:34 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF686106564A for ; Wed, 14 Sep 2011 16:46:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 851C08FC12 for ; Wed, 14 Sep 2011 16:46:34 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p8EGkFmU032091 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 09:46:23 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E70DA7A.7020307@freebsd.org> Date: Wed, 14 Sep 2011 09:46:50 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: John Baldwin References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> <201109141230.51827.jhb@freebsd.org> In-Reply-To: <201109141230.51827.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, Marcel Moolenaar Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 16:46:35 -0000 On 9/14/11 9:30 AM, John Baldwin wrote: > On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote: >> On Sep 14, 2011, at 6:47 AM, John Baldwin wrote: >> >>> On Tuesday, September 13, 2011 10:36:49 pm Marcel Moolenaar wrote: >>>> All, >>>> >>>> Is there a reason not to add ntohq and htonq to the short >>>> and long versions we (and everyone else) already has? >>>> >>>> Juniper has 64-bit entities that go over the wire in >>>> network byte order and, while these macros are absolutely >>>> arcane, I see no reason not to complete them with 64-bit >>>> variants. >>>> >>>> I did some googling and htonq and ntohq seem to be de >>>> facto names used, but oddly enough no OS has them defined. >>>> It's surreal. Are there better alternatives we should >>>> migrate to? >>> I don't have a better idea. I do wish the names encoded the size instead like >>> we do for the [lb]etoh*() and hto[lb]e*() macros (that is ntoh64(), etc.). >>> However, given that ntohl() and ntohs() are standardized we've probably lost >>> the opportunity to fix that misfeature of ntoh*() and hton*() and a 'q' suffix >>> is consistent (though hackish). >>> >>> I guess the one other possiblity is to add *16 and *32 aliases for 's' and 'l' >>> and then add *64 for the new one if we think that using the names is better >>> for the future (e.g. ntoh128() when it comes (or will that be ntoho() >>> (octword?))). >>> >> Looks like the hotel ate my reply... >> >> hton64/ntoh64 is what Linux has in the kernel. htonll and ntohll is what Solaris and AIX have. >> >> So (1) I'd shy away from htonq since that's not as well established as the other two in the OS (although googling suggests that many programs use > it). (2) I'd provide both htonll and hton64 with a note saying that hton128 is the wave of the future. > > Actually, come to think of it, we use *ll rather than *q variants here at work > as well. I'd vote for (2). > it won't cost us to provide ntoh16, ntoh32, ntoh64 even if we do also have ntohs, ntohl, ntohll AND ntohq. just make it clear in the definitions which one we want people to use in new code. ntohs, and ntohl have alway annoyed me just like 'short' and 'long' and 'long long' these days I always try use "int32_t" stuff if it's going to be exported anywhere.. and I think the same should be true of the ntohXX stuff. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 16:53:09 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 434FA106564A for ; Wed, 14 Sep 2011 16:53:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 15AAB8FC14 for ; Wed, 14 Sep 2011 16:53:08 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p8EGqtLq032105 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 09:53:01 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E70DC0A.1010407@freebsd.org> Date: Wed, 14 Sep 2011 09:53:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Warner Losh References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Arch , Marcel Moolenaar Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 16:53:09 -0000 On 9/14/11 7:34 AM, Warner Losh wrote: > Linux has hton64, but last time I checked it was kernel only. NetBSD has talked about different flavors of hton64 or htonq, but it appears none made it into the tree. > > htonll is in both AIX and Solaris (well, OpenSolaris 2009.06). > > It isn't standardized, so the standards wonks will say "be sure not to pollute namespace with these if you implement them." > > If I was doing it, I'd be tempted to implement all three with two being simple aliases to the third canonical implementation, but I think that might get me shot when I posted the patch. Nobody wants 1/3 of a baby. what he said.. and I'd go further by making the numeric ones the base definitions. there are also the types in BYTEORDER(9) which use the numeric style if you want a precedence. > Warner > > > On Sep 13, 2011, at 9:36 PM, Marcel Moolenaar wrote: >> All, >> >> Is there a reason not to add ntohq and htonq to the short >> and long versions we (and everyone else) already has? >> >> Juniper has 64-bit entities that go over the wire in >> network byte order and, while these macros are absolutely >> arcane, I see no reason not to complete them with 64-bit >> variants. >> >> I did some googling and htonq and ntohq seem to be de >> facto names used, but oddly enough no OS has them defined. >> It's surreal. Are there better alternatives we should >> migrate to? >> >> -- >> Marcel Moolenaar >> marcel@xcllnt.net >> >> >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 17:12:34 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B8E1106564A; Wed, 14 Sep 2011 17:12:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5478FC08; Wed, 14 Sep 2011 17:12:34 +0000 (UTC) Received: from [10.0.0.163] ([12.186.246.114]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p8EH4Lw8056212 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 14 Sep 2011 11:04:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4E70DA7A.7020307@freebsd.org> Date: Wed, 14 Sep 2011 12:04:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <94A8CF2C-432D-43D6-8FB6-ADDAA013CA9D@bsdimp.com> References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> <201109141230.51827.jhb@freebsd.org> <4E70DA7A.7020307@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 14 Sep 2011 11:04:25 -0600 (MDT) Cc: freebsd-arch@freebsd.org, Marcel Moolenaar Subject: Re: ntohq/htonq? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 17:12:34 -0000 On Sep 14, 2011, at 11:46 AM, Julian Elischer wrote: > On 9/14/11 9:30 AM, John Baldwin wrote: >> On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote: >>> On Sep 14, 2011, at 6:47 AM, John Baldwin wrote: >>>=20 >>>> On Tuesday, September 13, 2011 10:36:49 pm Marcel Moolenaar wrote: >>>>> All, >>>>>=20 >>>>> Is there a reason not to add ntohq and htonq to the short >>>>> and long versions we (and everyone else) already has? >>>>>=20 >>>>> Juniper has 64-bit entities that go over the wire in >>>>> network byte order and, while these macros are absolutely >>>>> arcane, I see no reason not to complete them with 64-bit >>>>> variants. >>>>>=20 >>>>> I did some googling and htonq and ntohq seem to be de >>>>> facto names used, but oddly enough no OS has them defined. >>>>> It's surreal. Are there better alternatives we should >>>>> migrate to? >>>> I don't have a better idea. I do wish the names encoded the size = instead like >>>> we do for the [lb]etoh*() and hto[lb]e*() macros (that is ntoh64(), = etc.). >>>> However, given that ntohl() and ntohs() are standardized we've = probably lost >>>> the opportunity to fix that misfeature of ntoh*() and hton*() and a = 'q' suffix >>>> is consistent (though hackish). >>>>=20 >>>> I guess the one other possiblity is to add *16 and *32 aliases for = 's' and 'l' >>>> and then add *64 for the new one if we think that using the names = is better >>>> for the future (e.g. ntoh128() when it comes (or will that be = ntoho() >>>> (octword?))). >>>>=20 >>> Looks like the hotel ate my reply... >>>=20 >>> hton64/ntoh64 is what Linux has in the kernel. htonll and ntohll is = what Solaris and AIX have. >>>=20 >>> So (1) I'd shy away from htonq since that's not as well established = as the other two in the OS (although googling suggests that many = programs use >> it). (2) I'd provide both htonll and hton64 with a note saying that = hton128 is the wave of the future. >>=20 >> Actually, come to think of it, we use *ll rather than *q variants = here at work >> as well. I'd vote for (2). >>=20 > it won't cost us to provide ntoh16, ntoh32, ntoh64 even if we do also = have ntohs, ntohl, ntohll AND ntohq. > just make it clear in the definitions which one we want people to use = in new code. >=20 > ntohs, and ntohl have alway annoyed me just like 'short' and 'long' = and 'long long' > these days I always try use "int32_t" stuff if it's going to be = exported anywhere.. and I think the same > should be true of the ntohXX stuff. I rather like this idea, but they definitely are non-standard. htons = grew up in an era that pre-dated intXX_t by a decade and there's been no = updated, standardized versions since. I'd make a subtle change to the = XX versions: have them operate/return on the uintXX_t variants. But I = think that's also a separate discussion. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 17:15:01 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C673106564A; Wed, 14 Sep 2011 17:15:01 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id E83A08FC15; Wed, 14 Sep 2011 17:15:00 +0000 (UTC) Received: from sa-nc-common4-116.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p8EHEkdF086007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Sep 2011 10:14:53 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: <201109141230.51827.jhb@freebsd.org> Date: Wed, 14 Sep 2011 10:14:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> <201109141230.51827.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-arch@freebsd.org Subject: Re: ntohll/htonll? [was: Re: ntohq/htonq?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 17:15:01 -0000 [changing subject to tie *ll to *q for search purposes] On Sep 14, 2011, at 9:30 AM, John Baldwin wrote: > On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote: >>=20 >> hton64/ntoh64 is what Linux has in the kernel. htonll and ntohll is = what Solaris and AIX have. >>=20 >> So (1) I'd shy away from htonq since that's not as well established = as the other two in the OS >> (although googling suggests that many programs use it). (2) I'd = provide both htonll and hton64 >> with a note saying that hton128 is the wave of the future. >=20 > Actually, come to think of it, we use *ll rather than *q variants here = at work > as well. I'd vote for (2). The only problem I'm facing is that htonq/ntohq are well-established and heavily used within Junos. They are even exposed in the SDK. So, while I don't mind taking a slightly different route, I do need to deal with compatibility. But if I need to do that, then there's also no real reason anymore to add a 64-bit variant to FreeBSD. I need to see what is possible... Anyway: I sense a preference for a numerical suffix over any single or multi-letter suffix. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Wed Sep 14 18:19:14 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D14F7106564A; Wed, 14 Sep 2011 18:19:14 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 73D868FC15; Wed, 14 Sep 2011 18:19:14 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p8EID6J3056974; Wed, 14 Sep 2011 12:13:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 14 Sep 2011 13:12:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <306FD881-6140-4DE2-AFF1-95C8079E4187@xcllnt.net> <201109140747.21979.jhb@freebsd.org> <201109141230.51827.jhb@freebsd.org> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1084) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [127.0.0.1]); Wed, 14 Sep 2011 12:13:19 -0600 (MDT) Cc: freebsd-arch@freebsd.org Subject: Re: ntohll/htonll? [was: Re: ntohq/htonq?] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 18:19:14 -0000 On Sep 14, 2011, at 12:14 PM, Marcel Moolenaar wrote: > [changing subject to tie *ll to *q for search purposes] >=20 > On Sep 14, 2011, at 9:30 AM, John Baldwin wrote: >=20 >> On Wednesday, September 14, 2011 10:39:31 am Warner Losh wrote: >>>=20 >>> hton64/ntoh64 is what Linux has in the kernel. htonll and ntohll is = what Solaris and AIX have. >>>=20 >>> So (1) I'd shy away from htonq since that's not as well established = as the other two in the OS >>> (although googling suggests that many programs use it). (2) I'd = provide both htonll and hton64 >>> with a note saying that hton128 is the wave of the future. >>=20 >> Actually, come to think of it, we use *ll rather than *q variants = here at work >> as well. I'd vote for (2). >=20 > The only problem I'm facing is that htonq/ntohq are well-established > and heavily used within Junos. They are even exposed in the SDK. So, > while I don't mind taking a slightly different route, I do need to > deal with compatibility. But if I need to do that, then there's also > no real reason anymore to add a 64-bit variant to FreeBSD. I need to > see what is possible... >=20 > Anyway: I sense a preference for a numerical suffix over any single > or multi-letter suffix. There's no reason not to support all 3. They'd all be in the BSD name = space anyway... My hesitance to do that is based on my intuition, but = there's no actual resistance so far in this thread... Sometimes doing = the little things like this can help a huge amount. The one down side would be for those applications that have defined = these routines themselves might need minor tweaking for FreeBSD. I = suspect that this question could be answered by a simple ports run. I = think that body of software would be a good estimator for all = third-party software... Warner=