From owner-freebsd-arch@FreeBSD.ORG Sun Nov 14 02:19:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D878D16A4CE; Sun, 14 Nov 2004 02:19:39 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B6D243D4C; Sun, 14 Nov 2004 02:19:39 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) iAE2JdcW003118; Sat, 13 Nov 2004 18:19:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id iAE2Jd8Z003117; Sat, 13 Nov 2004 18:19:39 -0800 (PST) (envelope-from dillon) Date: Sat, 13 Nov 2004 18:19:39 -0800 (PST) From: Matthew Dillon Message-Id: <200411140219.iAE2Jd8Z003117@apollo.backplane.com> To: Peter Wemm References: <20041111030035.GA70923@VARK.MIT.EDU> <200411131600.55982.peter@wemm.org> cc: arch@freebsd.org cc: David Schultz cc: freebsd-arch@freebsd.org Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2004 02:19:40 -0000 :On Wednesday 10 November 2004 07:00 pm, David Schultz wrote: : :> I propose to remove the ability to swap the U area, allocating :> p_stats from malloced memory instead. Medium-term scheduling and :> swapping of kernel stacks would be retained. : :For what its worth, I support this change. With the plimit/pstats fixes :of course. :-) : :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com I've had u-area swapping turned off almost from day-1 in DragonFly with no adverse effects. I'm still using the area for a stack so I haven't completely ripped it out, but as far as the swapping goes I think it's a good idea to rip it out. It does significantly simplify certain aspects of the kernel. -Matt Matthew Dillon From owner-freebsd-arch@FreeBSD.ORG Sun Nov 14 02:19:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D878D16A4CE; Sun, 14 Nov 2004 02:19:39 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B6D243D4C; Sun, 14 Nov 2004 02:19:39 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) iAE2JdcW003118; Sat, 13 Nov 2004 18:19:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id iAE2Jd8Z003117; Sat, 13 Nov 2004 18:19:39 -0800 (PST) (envelope-from dillon) Date: Sat, 13 Nov 2004 18:19:39 -0800 (PST) From: Matthew Dillon Message-Id: <200411140219.iAE2Jd8Z003117@apollo.backplane.com> To: Peter Wemm References: <20041111030035.GA70923@VARK.MIT.EDU> <200411131600.55982.peter@wemm.org> cc: arch@freebsd.org cc: David Schultz cc: freebsd-arch@freebsd.org Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2004 02:19:40 -0000 :On Wednesday 10 November 2004 07:00 pm, David Schultz wrote: : :> I propose to remove the ability to swap the U area, allocating :> p_stats from malloced memory instead. Medium-term scheduling and :> swapping of kernel stacks would be retained. : :For what its worth, I support this change. With the plimit/pstats fixes :of course. :-) : :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com I've had u-area swapping turned off almost from day-1 in DragonFly with no adverse effects. I'm still using the area for a stack so I haven't completely ripped it out, but as far as the swapping goes I think it's a good idea to rip it out. It does significantly simplify certain aspects of the kernel. -Matt Matthew Dillon From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 13:32:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CBF616A4CE for ; Wed, 17 Nov 2004 13:32:13 +0000 (GMT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id B499F43D1D for ; Wed, 17 Nov 2004 13:32:12 +0000 (GMT) (envelope-from marks@ripe.net) Received: by postman.ripe.net (Postfix, from userid 8) id 1079924D8E; Wed, 17 Nov 2004 14:32:12 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0C49324DCA for ; Wed, 17 Nov 2004 14:32:11 +0100 (CET) Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id iAHDWALE023223 for ; Wed, 17 Nov 2004 14:32:10 +0100 Received: (nullmailer pid 55182 invoked by uid 1001); Wed, 17 Nov 2004 13:32:10 -0000 Date: Wed, 17 Nov 2004 14:32:10 +0100 From: Mark Santcroos To: freebsd-arch@freebsd.org Message-ID: <20041117133210.GA17117@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.005899 / -5.9 X-RIPE-Signature: 50dc45c1f8f4d5fe7bedaa4f7d7428a2 Subject: ntp_gettime(2) system call implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 13:32:13 -0000 Background: Since the early days in FreeBSD, ntp_gettime(2) is hacked as a libc wrapper around sysctlbyname(3). I propose to convert it into a system call. The patch[1] adds the ntp_gettime system call, preserving the sysctl behavior for now. However, I want to investigate at some point to get rid of it in -CURRENT, if we can work out libc compat issues. The output of my test program[2] is as follows: # time ./ntp_gettime-test -ctl 10000000 13.804u 66.966s 1:24.21 95.9% 5+168k 0+0io 0pf+0w # time ./ntp_gettime-test -call 10000000 4.917u 19.035s 0:24.66 97.0% 5+168k 0+0io 0pf+0w So the system call is also ~3x as fast as the sysctl version (for various reasons both in userspace and kernelspace). As far as the syscall number is concerned, NetBSD and OpenBSD both use 175, but that is already used in FreeBSD. However, in src/sys/compat/svr4/syscalls.master, 248 is used. So I choose to go for that. I don't feel strongly about that though, so any number would be fine for me. Comments welcome, especially about the compat issues later on. Mark [1] http://www.santcroos.net/mark/freebsd/files/ntp_gettime.diff [2] http://www.santcroos.net/mark/freebsd/files/ntp_gettime-test.c -- RIPE NCC - Delft University of Technology - The FreeBSD Project marks@ripe.net - m.a.santcroos@ewi.tudelft.nl - marks@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 16:50:36 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F255B16A4D1; Wed, 17 Nov 2004 16:50:35 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A3BE43D1F; Wed, 17 Nov 2004 16:50:35 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CUT0q-000Dnd-L5; Wed, 17 Nov 2004 19:50:32 +0300 From: Vladimir Grebenschikov To: Max Laier In-Reply-To: <200411112124.12616.max@love2party.net> References: <200411112124.12616.max@love2party.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Wed, 17 Nov 2004 19:50:32 +0300 Message-Id: <1100710232.47346.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 16:50:36 -0000 =F7 =DE=D4, 11/11/2004 =D7 21:24 +0100, Max Laier =D0=C9=DB=C5=D4:=20 > All, >=20 > I know I have sent this a couple of times before, but never got anywhere.= This=20 > time I am set to commit! >=20 > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived= from=20 > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix= =20 > routes. >=20 > Right now you can't have two legs into the same network. If you want to, = you=20 > must give on of the interfaces a host address only (netmask /32). This wa= y it=20 > is not possible to hand over the route if one of the interfaces is=20 > "removed" (however this is done in the special case). >=20 > The patch allows to add more than on IPv4 address with the same prefix. I= n the=20 > case that there is a route already, we leave it alone and add the new add= ress=20 > without the IFA_ROUTE flag. When we remove an address later on, that has = a=20 > route associated, we try to find an alternative address to use for the ro= ute=20 > and hand it over. >=20 > This is required for CARP, but should be helpful for other situations as = well. >=20 > Any objections? This change actually broke one simple thing: # ifconfig lo0 alias 10.0.16.111/32 # ping 10.0.16.111 PING 10.0.16.111 (10.0.16.111): 56 data bytes ping: sendto: No route to host ^C # You should (anyway should) add routing of interface address itself to loop-back interface, like it usually done in all other cases. Please fix. --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 22:02:56 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1B5C16A4CE; Wed, 17 Nov 2004 22:02:56 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8BC843D46; Wed, 17 Nov 2004 22:02:55 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAHM2mhK047963; Thu, 18 Nov 2004 00:02:48 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 83815-14; Thu, 18 Nov 2004 00:02:47 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAHM2kFo047960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2004 00:02:47 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iAHM2m7B081982; Thu, 18 Nov 2004 00:02:48 +0200 (EET) (envelope-from ru) Date: Thu, 18 Nov 2004 00:02:47 +0200 From: Ruslan Ermilov To: Vladimir Grebenschikov Message-ID: <20041117220247.GA60793@ip.net.ua> References: <200411112124.12616.max@love2party.net> <1100710232.47346.5.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <1100710232.47346.5.camel@localhost> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Max Laier cc: freebsd-arch@FreeBSD.org cc: freebsd-net@FreeBSD.org Subject: Re: in.c autoadding prefix route [PATCH] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 22:02:56 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2004 at 07:50:32PM +0300, Vladimir Grebenschikov wrote: > =F7 =DE=D4, 11/11/2004 =D7 21:24 +0100, Max Laier =D0=C9=DB=C5=D4:=20 > > All, > >=20 > > I know I have sent this a couple of times before, but never got anywher= e. This=20 > > time I am set to commit! > >=20 > > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) deriv= ed from=20 > > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic pref= ix=20 > > routes. > >=20 > > Right now you can't have two legs into the same network. If you want to= , you=20 > > must give on of the interfaces a host address only (netmask /32). This = way it=20 > > is not possible to hand over the route if one of the interfaces is=20 > > "removed" (however this is done in the special case). > >=20 > > The patch allows to add more than on IPv4 address with the same prefix.= In the=20 > > case that there is a route already, we leave it alone and add the new a= ddress=20 > > without the IFA_ROUTE flag. When we remove an address later on, that ha= s a=20 > > route associated, we try to find an alternative address to use for the = route=20 > > and hand it over. > >=20 > > This is required for CARP, but should be helpful for other situations a= s well. > >=20 > > Any objections? >=20 > This change actually broke one simple thing: >=20 > # ifconfig lo0 alias 10.0.16.111/32 > # ping 10.0.16.111 > PING 10.0.16.111 (10.0.16.111): 56 data bytes > ping: sendto: No route to host > ^C > # >=20 > You should (anyway should) add routing of interface address itself to > loop-back interface, like it usually done in all other cases. >=20 > Please fix. >=20 This bug was borrowed from OpenBSD (they still have it). The problem is that in "struct in_ifaddr", initially ia_ifa.ifa_addr points to ia_addr - and - ia_ifa.ifa_dstaddr points to ia_dstaddr and the IFF_LOOPBACK code in in_ifinit() just resets the ia_ifa.ifa_dstaddr pointer to point to ia_ifa.ifa_addr. But new in_addprefix() code ignores this fact, and just uses INET fields directly, i.e., ia_dstaddr (which happens to be 0.0.0.0). Then all the havoc happens (it matches another interface address (ia_addr=3D127.0.0.1, ia_dstaddr=3D0) and refuses to install a host route. The fix is a one line change, and as I later found out, it also corresponds to NetBSD revision 1.83: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=3D1.82&r= 2=3D1.83&cvsroot=3Dnetbsd %%% Index: in.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.78 diff -u -p -r1.78 in.c --- in.c 12 Nov 2004 20:53:51 -0000 1.78 +++ in.c 17 Nov 2004 21:42:44 -0000 @@ -759,7 +759,7 @@ in_ifinit(ifp, ia, sin, scrub) ia->ia_netbroadcast.s_addr =3D htonl(ia->ia_net | ~ ia->ia_netmask); } else if (ifp->if_flags & IFF_LOOPBACK) { - ia->ia_ifa.ifa_dstaddr =3D ia->ia_ifa.ifa_addr; + ia->ia_dstaddr =3D ia->ia_addr; flags |=3D RTF_HOST; } else if (ifp->if_flags & IFF_POINTOPOINT) { if (ia->ia_dstaddr.sin_family !=3D AF_INET) %%% An alternative would be to fix in_addprefix() to pay attention to ia_ifa pointers, but as this bug shows, this is error prone. It's much easier to just initialize the ia_dstaddr as appropriate. =09 Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBm8qHqRfpzJluFF4RAjApAJ9/D86FqpwPvb6oLRmyd41zjyWZQQCeKXuy A6+YwAicxvtMT+7Os1KcZvk= =I3CA -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 22:03:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AB2316A4CE for ; Wed, 17 Nov 2004 22:03:11 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11BAD43D45 for ; Wed, 17 Nov 2004 22:03:09 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id iAHM38t7002055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2004 17:03:08 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id iAHM32Y5001458; Wed, 17 Nov 2004 17:03:02 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16795.51862.698490.378530@grasshopper.cs.duke.edu> Date: Wed, 17 Nov 2004 17:03:02 -0500 (EST) To: Poul-Henning Kamp In-Reply-To: <39210.1099557885@critter.freebsd.dk> References: <39210.1099557885@critter.freebsd.dk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 22:03:11 -0000 Poul-Henning Kamp writes: > > We increasingly need better granularity in our sleep/wakeup calls and > things like device polling and trafic shaping needs higher granularity > in particular. > Have you (or anybody else) looked at what dragonfly has done with tvtohz() and clock aliasing? The results presented at http://www.dragonflybsd.org/docs/nanosleep look very promising. But I've never thought very hard about timers, and I'm not sure I understand what they are doing. Drew From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 23:07:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B48716A4CE; Wed, 17 Nov 2004 23:07:21 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B55743D4C; Wed, 17 Nov 2004 23:07:20 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CUYtT-0004l1-00; Thu, 18 Nov 2004 00:07:19 +0100 Received: from [217.83.7.105] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CUYtS-0000z9-00; Thu, 18 Nov 2004 00:07:19 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Thu, 18 Nov 2004 00:07:30 +0100 User-Agent: KMail/1.7.1 References: <200411112124.12616.max@love2party.net> <1100710232.47346.5.camel@localhost> <20041117220247.GA60793@ip.net.ua> In-Reply-To: <20041117220247.GA60793@ip.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7242309.1ZlrrbEUC1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411180007.39802.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Vladimir Grebenschikov cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route [PATCH] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 23:07:21 -0000 --nextPart7242309.1ZlrrbEUC1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 17 November 2004 23:02, Ruslan Ermilov wrote: > On Wed, Nov 17, 2004 at 07:50:32PM +0300, Vladimir Grebenschikov wrote: > > =D0=92 =D1=87=D1=82, 11/11/2004 =D0=B2 21:24 +0100, Max Laier =D0=BF=D0= =B8=D1=88=D0=B5=D1=82: > > > All, > > > > > > I know I have sent this a couple of times before, but never got > > > anywhere. This time I am set to commit! > > > > > > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) > > > derived from WIDE via OpenBSD in.c, rev 1.21 improves the handling of > > > automatic prefix routes. > > > > > > Right now you can't have two legs into the same network. If you want > > > to, you must give on of the interfaces a host address only (netmask > > > /32). This way it is not possible to hand over the route if one of the > > > interfaces is "removed" (however this is done in the special case). > > > > > > The patch allows to add more than on IPv4 address with the same prefi= x. > > > In the case that there is a route already, we leave it alone and add > > > the new address without the IFA_ROUTE flag. When we remove an address > > > later on, that has a route associated, we try to find an alternative > > > address to use for the route and hand it over. > > > > > > This is required for CARP, but should be helpful for other situations > > > as well. > > > > > > Any objections? > > > > This change actually broke one simple thing: > > > > # ifconfig lo0 alias 10.0.16.111/32 > > # ping 10.0.16.111 > > PING 10.0.16.111 (10.0.16.111): 56 data bytes > > ping: sendto: No route to host > > ^C > > # > > > > You should (anyway should) add routing of interface address itself to > > loop-back interface, like it usually done in all other cases. > > > > Please fix. > > This bug was borrowed from OpenBSD (they still have it). > The problem is that in "struct in_ifaddr", initially > > ia_ifa.ifa_addr points to ia_addr > - and - > ia_ifa.ifa_dstaddr points to ia_dstaddr > > and the IFF_LOOPBACK code in in_ifinit() just resets > the ia_ifa.ifa_dstaddr pointer to point to ia_ifa.ifa_addr. > But new in_addprefix() code ignores this fact, and just > uses INET fields directly, i.e., ia_dstaddr (which happens > to be 0.0.0.0). Then all the havoc happens (it matches > another interface address (ia_addr=3D127.0.0.1, ia_dstaddr=3D0) > and refuses to install a host route. > > The fix is a one line change, and as I later found out, > it also corresponds to NetBSD revision 1.83: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=3D1.82= &r2=3D >1.83&cvsroot=3Dnetbsd > > %%% > Index: in.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sys/netinet/in.c,v > retrieving revision 1.78 > diff -u -p -r1.78 in.c > --- in.c 12 Nov 2004 20:53:51 -0000 1.78 > +++ in.c 17 Nov 2004 21:42:44 -0000 > @@ -759,7 +759,7 @@ in_ifinit(ifp, ia, sin, scrub) > ia->ia_netbroadcast.s_addr =3D > htonl(ia->ia_net | ~ ia->ia_netmask); > } else if (ifp->if_flags & IFF_LOOPBACK) { > - ia->ia_ifa.ifa_dstaddr =3D ia->ia_ifa.ifa_addr; > + ia->ia_dstaddr =3D ia->ia_addr; > flags |=3D RTF_HOST; > } else if (ifp->if_flags & IFF_POINTOPOINT) { > if (ia->ia_dstaddr.sin_family !=3D AF_INET) > %%% > > An alternative would be to fix in_addprefix() to pay > attention to ia_ifa pointers, but as this bug shows, > this is error prone. It's much easier to just > initialize the ia_dstaddr as appropriate. Thanks. Good analysis ... I failed to see it :-\ I agree that setting ia_dstaddr is the less painful option. Again, thanks a lot and sorry for the mess! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart7242309.1ZlrrbEUC1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBm9m7XyyEoT62BG0RAnI0AJ4rLuIe3rkQDhBla5REG+U3X5ZlBgCfVeLd cmuE1BIz9XdLzFOjq6lW8TU= =aShL -----END PGP SIGNATURE----- --nextPart7242309.1ZlrrbEUC1-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 23:22:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4C0F16A4D0 for ; Wed, 17 Nov 2004 23:22:58 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id D5D0343D55 for ; Wed, 17 Nov 2004 23:22:57 +0000 (GMT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Nov 2004 23:22:56 +0000 (GMT) To: arch@freebsd.org Date: Wed, 17 Nov 2004 23:22:56 +0000 From: Ian Dowse Message-ID: <200411172322.aa34520@salmon.maths.tcd.ie> Subject: Simpler SMP-friendly callout/timeout semantics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 23:22:58 -0000 The current callout/timeout API supports Giant-locked and MP-safe usage options, but in both cases it is very difficult to use the API in a way that is free of race conditions and complications. Below is an attempt to extend that API to offer much simpler semantics to many users while not limiting its usefulness or performance. A summary of the difficulties faced when using the current callout API can be found at: http://people.freebsd.org/~iedowse/callout/callout_current.txt This subject has been discussed a few times before (e.g, search for "Timeout and SMP race"). One of the suggestions, made by Archie Cobbs, was to supply a mutex when the callout is created and have the callout code use that to avoid many of the races. This is what I've attempted to do. The patch below adds a new API function: callout_init_mtx(struct callout *c, struct mtx *mtx, int flags); If a non-NULL `mtx' is supplied, then the callout system will acquire that mutex before invoking the callout handler. Normally the handler must return with the mutex still locked, but if the CALLOUT_RETURNUNLOCKED flag is supplied, then the handler should unlock the mutex itself before returning. Since the callout system is acquiring the mutex itself, it can check if the callout has been cancelled while holding the mutex and before invoking the handler or dereferencing the callout function pointer or argument. When combined with a requirement of holding the mutex during calls to callout_stop() and callout_reset(), this entirely eliminates the races, so callout_stop() and callout_reset() reliably do what you'd expect. The semantics of callouts initialised with the new function are: o When calling callout_stop() or callout_reset() on the callout, the specified mutex must be held. o Calls to callout_stop() and callout_reset() guarantee that the handler will not be invoked even if it has already been de-queued by softclock(). There are no races since the mutex is held by the caller of callout_stop() or callout_reset(). When the CALLOUT_RETURNUNLOCKED flag is used, it is however possible that the handler function is still running, but the because the caller holds the mutex, it is known that the handler, if active, has at least got past the mtx_unlock(). These functions do not sleep. o Before destroying the specified mutex, callout_drain() must be called. Since callout_drain() may sleep, the mutex may not be held at this time. If the callout has not been cancelled already, then it might be invoked while callout_drain() executes. To avoid this, call callout_stop() before releasing the mutex and then call callout_drain() afterwards. The call to callout_drain() is necessary to ensure that softclock() no longer references the mutex (e.g. it might still be waiting to acquire it). The patch also changes the semantics of all existing Giant-locked callouts to match the above with a mutex of Giant implicitly specified. This means that Giant-locked users MUST hold Giant while calling callout_stop(), callout_reset(), timeout() and untimeout(), which will require a number of changes in various parts of the kernel. It also means that fully Giant-locked code gets the race-free semantics with no source changes. The new API function handles some cases very well: - Code that uses just one mutex per instance, such as many device drivers. - Giant-locked code because again there is just one mutex involved. However there are more complex uses of the callout API that currently use more than one mutex due to lock ordering requirements. A good example is the TCP code, where the timeout routines can acquire a global TCP mutex before the per-connection mutex, so this new scheme on its own cannot be used directly. Maybe it is possible to rework the TCP code to avoid this, or even extend the callout API further so that an alternative locking routine can be supplied if that helps. Do people think that a change like this is worth attempting? Are there further improvements that could be made or any other suggestions or comments? Ian Additional stuff: Patch to make the "re" driver use the new API (currently it uses timeout/untimeout without locking Giant): http://people.freebsd.org/~iedowse/callout/callout_re.diff Patch that attempts to close a number of timeout races in the ATA code using the new API: http://people.freebsd.org/~iedowse/callout/callout_ata.diff Finally the callout patch itself: Index: sys/kern/kern_timeout.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/kern/kern_timeout.c,v retrieving revision 1.91 diff -u -r1.91 kern_timeout.c --- sys/kern/kern_timeout.c 6 Aug 2004 21:49:00 -0000 1.91 +++ sys/kern/kern_timeout.c 17 Nov 2004 02:31:28 -0000 @@ -53,6 +53,9 @@ static int avg_gcalls; SYSCTL_INT(_debug, OID_AUTO, to_avg_gcalls, CTLFLAG_RD, &avg_gcalls, 0, "Average number of Giant callouts made per softclock call. Units = 1/1000"); +static int avg_mtxcalls; +SYSCTL_INT(_debug, OID_AUTO, to_avg_mtxcalls, CTLFLAG_RD, &avg_mtxcalls, 0, + "Average number of mtx callouts made per softclock call. Units = 1/1000"); static int avg_mpcalls; SYSCTL_INT(_debug, OID_AUTO, to_avg_mpcalls, CTLFLAG_RD, &avg_mpcalls, 0, "Average number of MP callouts made per softclock call. Units = 1/1000"); @@ -80,6 +83,12 @@ * If curr_callout is non-NULL, threads waiting on * callout_wait will be woken up as soon as the * relevant callout completes. + * curr_cancelled - Changing to 1 with both callout_lock and c_mtx held + * guarantees that the current callout will not run. + * The softclock() function sets this to 0 before it + * drops callout_lock to acquire c_mtx, and it calls + * the handler only if curr_cancelled still 0 when + * c_mtx is successfully acquired. * wakeup_ctr - Incremented every time a thread wants to wait * for a callout to complete. Modified only when * curr_callout is non-NULL. @@ -88,6 +97,7 @@ * cutt_callout is non-NULL. */ static struct callout *curr_callout; +static int curr_cancelled; static int wakeup_ctr; static int wakeup_needed; @@ -181,6 +191,7 @@ int steps; /* #steps since we last allowed interrupts */ int depth; int mpcalls; + int mtxcalls; int gcalls; int wakeup_cookie; #ifdef DIAGNOSTIC @@ -195,6 +206,7 @@ #endif /* MAX_SOFTCLOCK_STEPS */ mpcalls = 0; + mtxcalls = 0; gcalls = 0; depth = 0; steps = 0; @@ -225,12 +237,14 @@ } else { void (*c_func)(void *); void *c_arg; + struct mtx *c_mtx; int c_flags; nextsoftcheck = TAILQ_NEXT(c, c_links.tqe); TAILQ_REMOVE(bucket, c, c_links.tqe); c_func = c->c_func; c_arg = c->c_arg; + c_mtx = c->c_mtx; c_flags = c->c_flags; c->c_func = NULL; if (c->c_flags & CALLOUT_LOCAL_ALLOC) { @@ -242,11 +256,32 @@ (c->c_flags & ~CALLOUT_PENDING); } curr_callout = c; + curr_cancelled = 0; mtx_unlock_spin(&callout_lock); - if (!(c_flags & CALLOUT_MPSAFE)) { - mtx_lock(&Giant); - gcalls++; - CTR1(KTR_CALLOUT, "callout %p", c_func); + if (c_mtx != NULL) { + mtx_lock(c_mtx); + /* + * The callout may have been cancelled + * while we switched locks. + */ + if (curr_cancelled) { + mtx_unlock(c_mtx); + mtx_lock_spin(&callout_lock); + goto done_locked; + } + /* The callout cannot be stopped now. */ + curr_cancelled = 1; + + if (c_mtx == &Giant) { + gcalls++; + CTR1(KTR_CALLOUT, "callout %p", + c_func); + } else { + mtxcalls++; + CTR1(KTR_CALLOUT, + "callout mtx %p", + c_func); + } } else { mpcalls++; CTR1(KTR_CALLOUT, "callout mpsafe %p", @@ -275,9 +310,10 @@ lastfunc = c_func; } #endif - if (!(c_flags & CALLOUT_MPSAFE)) - mtx_unlock(&Giant); + if ((c_flags & CALLOUT_RETURNUNLOCKED) == 0) + mtx_unlock(c_mtx); mtx_lock_spin(&callout_lock); +done_locked: curr_callout = NULL; if (wakeup_needed) { /* @@ -300,6 +336,7 @@ } avg_depth += (depth * 1000 - avg_depth) >> 8; avg_mpcalls += (mpcalls * 1000 - avg_mpcalls) >> 8; + avg_mtxcalls += (mtxcalls * 1000 - avg_mtxcalls) >> 8; avg_gcalls += (gcalls * 1000 - avg_gcalls) >> 8; nextsoftcheck = NULL; mtx_unlock_spin(&callout_lock); @@ -395,15 +432,26 @@ void *arg; { + if (c->c_mtx != NULL) + mtx_assert(c->c_mtx, MA_OWNED); + mtx_lock_spin(&callout_lock); - if (c == curr_callout && wakeup_needed) { + if (c == curr_callout) { /* * We're being asked to reschedule a callout which is - * currently in progress, and someone has called - * callout_drain to kill that callout. Don't reschedule. + * currently in progress. If there is a mutex then we + * can cancel the callout if it has not really started. */ - mtx_unlock_spin(&callout_lock); - return; + if (c->c_mtx != NULL && !curr_cancelled) + curr_cancelled = 1; + if (wakeup_needed) { + /* + * Someone has called callout_drain to kill this + * callout. Don't reschedule. + */ + mtx_unlock_spin(&callout_lock); + return; + } } if (c->c_flags & CALLOUT_PENDING) { if (nextsoftcheck == c) { @@ -446,13 +494,20 @@ { int wakeup_cookie; + if (!safe && c->c_mtx != NULL) + mtx_assert(c->c_mtx, MA_OWNED); + mtx_lock_spin(&callout_lock); /* * Don't attempt to delete a callout that's not on the queue. */ if (!(c->c_flags & CALLOUT_PENDING)) { c->c_flags &= ~CALLOUT_ACTIVE; - if (c == curr_callout && safe) { + if (c != curr_callout) { + mtx_unlock_spin(&callout_lock); + return (0); + } + if (safe) { /* We need to wait until the callout is finished. */ wakeup_needed = 1; wakeup_cookie = wakeup_ctr++; @@ -468,6 +523,11 @@ cv_wait(&callout_wait, &callout_wait_lock); mtx_unlock(&callout_wait_lock); + } else if (c->c_mtx != NULL && !curr_cancelled) { + /* We can stop the callout before it runs. */ + curr_cancelled = 1; + mtx_unlock_spin(&callout_lock); + return (1); } else mtx_unlock_spin(&callout_lock); return (0); @@ -493,8 +553,29 @@ int mpsafe; { bzero(c, sizeof *c); - if (mpsafe) - c->c_flags |= CALLOUT_MPSAFE; + if (mpsafe) { + c->c_mtx = NULL; + c->c_flags = CALLOUT_RETURNUNLOCKED; + } else { + c->c_mtx = &Giant; + c->c_flags = 0; + } +} + +void +callout_init_mtx(c, mtx, flags) + struct callout *c; + struct mtx *mtx; + int flags; +{ + bzero(c, sizeof *c); + c->c_mtx = mtx; + KASSERT((flags & ~CALLOUT_RETURNUNLOCKED) == 0, + ("callout_init_mtx: bad flags %d", flags)); + /* CALLOUT_RETURNUNLOCKED makes no sense without a mutex. */ + KASSERT(mtx != NULL || (flags & CALLOUT_RETURNUNLOCKED) == 0, + ("callout_init_mtx: CALLOUT_RETURNUNLOCKED with no mutex")); + c->c_flags = flags & CALLOUT_RETURNUNLOCKED; } #ifdef APM_FIXUP_CALLTODO Index: sys/sys/callout.h =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/sys/callout.h,v retrieving revision 1.27 diff -u -r1.27 callout.h --- sys/sys/callout.h 20 Apr 2004 15:49:31 -0000 1.27 +++ sys/sys/callout.h 17 Nov 2004 01:12:01 -0000 @@ -40,6 +40,8 @@ #include +struct mtx; + SLIST_HEAD(callout_list, callout); TAILQ_HEAD(callout_tailq, callout); @@ -51,6 +53,7 @@ int c_time; /* ticks to the event */ void *c_arg; /* function argument */ void (*c_func)(void *); /* function to call */ + struct mtx *c_mtx; /* mutex to lock */ int c_flags; /* state of this entry */ }; @@ -58,6 +61,7 @@ #define CALLOUT_ACTIVE 0x0002 /* callout is currently active */ #define CALLOUT_PENDING 0x0004 /* callout is waiting for timeout */ #define CALLOUT_MPSAFE 0x0008 /* callout handler is mp safe */ +#define CALLOUT_RETURNUNLOCKED 0x0010 /* handler returns with mtx unlocked */ struct callout_handle { struct callout *callout; @@ -75,6 +79,7 @@ #define callout_deactivate(c) ((c)->c_flags &= ~CALLOUT_ACTIVE) #define callout_drain(c) _callout_stop_safe(c, 1) void callout_init(struct callout *, int); +void callout_init_mtx(struct callout *, struct mtx *, int); #define callout_pending(c) ((c)->c_flags & CALLOUT_PENDING) void callout_reset(struct callout *, int, void (*)(void *), void *); #define callout_stop(c) _callout_stop_safe(c, 0) From owner-freebsd-arch@FreeBSD.ORG Wed Nov 17 23:37:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 326B016A4CE for ; Wed, 17 Nov 2004 23:37:35 +0000 (GMT) Received: from Daffy.timing.com (mail.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD32143D2D for ; Wed, 17 Nov 2004 23:37:34 +0000 (GMT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.12.8p2/8.12.8) with ESMTP id iAHNbYIm058041 for ; Wed, 17 Nov 2004 16:37:34 -0700 (MST) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6p3/8.12.6) with ESMTP id iAHNbYhC031413 for ; Wed, 17 Nov 2004 16:37:34 -0700 (MST) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6p3/8.12.6/Submit) id iAHNbYkQ031410; Wed, 17 Nov 2004 16:37:34 -0700 (MST) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16795.57534.19299.407779@piglet.timing.com> Date: Wed, 17 Nov 2004 16:37:34 -0700 To: freebsd-arch@freebsd.org X-Mailer: VM 7.00 under Emacs 21.2.95.2 X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 19:09:44 2004 clamav-milter version 0.80j on Daffy.timing.com X-Virus-Status: Clean Subject: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 23:37:35 -0000 Hi, It's come to my attention that libregex on FreeBSD is GPL'd - not LGPL'd. I think it rather violates the POLA that anything that uses regex_t and is compiled on FreeBSD ends up being covered by the terms of the GPL. Has there been any thought given to moving to the modified Henry Spencer regex library used in NetBSD & OpenBSD's libc? Regards, Ben From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 00:35:15 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B217016A517 for ; Thu, 18 Nov 2004 00:35:15 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56FF043D45 for ; Thu, 18 Nov 2004 00:34:16 +0000 (GMT) (envelope-from imp@harmony.village.org) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iAI0Uqd7059453; Wed, 17 Nov 2004 17:30:52 -0700 (MST) (envelope-from imp@harmony.village.org) Date: Wed, 17 Nov 2004 17:30:52 -0700 (MST) Message-Id: <20041117.173052.74691441.imp@harmony.village.org> To: ben@timing.com From: Warner Losh In-Reply-To: <16795.57534.19299.407779@piglet.timing.com> References: <16795.57534.19299.407779@piglet.timing.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@FreeBSD.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 00:35:15 -0000 > It's come to my attention that libregex on FreeBSD is GPL'd - not > LGPL'd. I think it rather violates the POLA that anything that uses > regex_t and is compiled on FreeBSD ends up being covered by the terms > of the GPL. > > Has there been any thought given to moving to the modified Henry > Spencer regex library used in NetBSD & OpenBSD's libc? I'm happy and willing to do te leg work to get this work into FreeBSD, so don't let that be an argument against this. I'll work with Ben to move forward with this integration if I don't hear anything to the contrary... Warner From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 08:27:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54CE416A4CE for ; Thu, 18 Nov 2004 08:27:05 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB8D043D54 for ; Thu, 18 Nov 2004 08:27:02 +0000 (GMT) (envelope-from tjr@freebsd.org) Received: from robbins.dropbear.id.au (210.50.219.132) by smtp01.syd.iprimus.net.au (7.0.036) id 4192AAA9003013CB; Thu, 18 Nov 2004 19:27:01 +1100 Received: from 192.168.0.64 (tim.robbins.dropbear.id.au [192.168.0.64]) by robbins.dropbear.id.au (Postfix) with ESMTP id A90064254; Thu, 18 Nov 2004 19:26:47 +1100 (EST) From: Tim Robbins To: Ben Mesander In-Reply-To: <16795.57534.19299.407779@piglet.timing.com> References: <16795.57534.19299.407779@piglet.timing.com> Content-Type: text/plain Date: Thu, 18 Nov 2004 19:26:47 +1100 Message-Id: <1100766407.3475.1.camel@starshine.robbins.dropbear.id.au> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 08:27:05 -0000 On Wed, 2004-11-17 at 16:37 -0700, Ben Mesander wrote: > Hi, > > It's come to my attention that libregex on FreeBSD is GPL'd - not > LGPL'd. I think it rather violates the POLA that anything that uses > regex_t and is compiled on FreeBSD ends up being covered by the terms > of the GPL. > > Has there been any thought given to moving to the modified Henry > Spencer regex library used in NetBSD & OpenBSD's libc? What do you think src/lib/libc/regex is? Tim From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 16:54:07 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D26C16A4CE; Thu, 18 Nov 2004 16:54:07 +0000 (GMT) Received: from Daffy.timing.com (mx1.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA5E843D5C; Thu, 18 Nov 2004 16:54:06 +0000 (GMT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.12.8p2/8.12.8) with ESMTP id iAIGs6Im060167; Thu, 18 Nov 2004 09:54:06 -0700 (MST) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6p3/8.12.6) with ESMTP id iAIGs6hC033027; Thu, 18 Nov 2004 09:54:06 -0700 (MST) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6p3/8.12.6/Submit) id iAIGs5wi033024; Thu, 18 Nov 2004 09:54:05 -0700 (MST) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16796.54189.894371.247346@piglet.timing.com> Date: Thu, 18 Nov 2004 09:54:05 -0700 To: Tim Robbins In-Reply-To: <1100766407.3475.1.camel@starshine.robbins.dropbear.id.au> References: <16795.57534.19299.407779@piglet.timing.com> <1100766407.3475.1.camel@starshine.robbins.dropbear.id.au> X-Mailer: VM 7.00 under Emacs 21.2.95.2 X-Virus-Scanned: ClamAV 0.80/533/Sat Oct 16 19:09:44 2004 clamav-milter version 0.80j on Daffy.timing.com X-Virus-Status: Clean cc: freebsd-arch@freebsd.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 16:54:07 -0000 Tim Robbins writes: > What do you think src/lib/libc/regex is? Now that's a nice question. So why are there two regex libs? Thanks, Ben From owner-freebsd-arch@FreeBSD.ORG Thu Nov 18 17:14:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E1DE16A4CE; Thu, 18 Nov 2004 17:14:17 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9550143D49; Thu, 18 Nov 2004 17:14:16 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id iAIHEDcp043244; Thu, 18 Nov 2004 11:14:13 -0600 (CST) (envelope-from dan) Date: Thu, 18 Nov 2004 11:14:13 -0600 From: Dan Nelson To: Ben Mesander Message-ID: <20041118171412.GC19265@dan.emsphone.com> References: <16795.57534.19299.407779@piglet.timing.com> <1100766407.3475.1.camel@starshine.robbins.dropbear.id.au> <16796.54189.894371.247346@piglet.timing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16796.54189.894371.247346@piglet.timing.com> X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-arch@freebsd.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 17:14:17 -0000 In the last episode (Nov 18), Ben Mesander said: > Tim Robbins writes: > > What do you think src/lib/libc/regex is? > > Now that's a nice question. > > So why are there two regex libs? Because GNU programs expect to use the GNU regex, I suppose. The only apps that pull in libgnuregex are gdb, cvs, diff, and grep. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Fri Nov 19 09:38:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F8DE16A4CE; Fri, 19 Nov 2004 09:38:00 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C50B943D1D; Fri, 19 Nov 2004 09:37:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iAJ9bvaU076634; Fri, 19 Nov 2004 10:37:58 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org, current@freebsd.org From: Poul-Henning Kamp Date: Fri, 19 Nov 2004 10:37:57 +0100 Message-ID: <76633.1100857077@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [REVIEW/TEST] nanodelay() vs DELAY() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 09:38:00 -0000 A number of device drivers need to have predictable small delays and today they largely rely on DELAY() for that. Problem is, DELAY sucks for durations below 10-20 usec. I have written a first cut of a self-calibrating nanodelay() which is better three orders of magnitude further down. The patch can be found at in p4::phk_dev or http://phk.freebsd.dk/patch/nanodelay.patch nanodelay() takes a nanosecond argument and will try to sleep exactly that many nanoseconds but never less than that. With a primed cache, the performance is close to perfect from 200nsec and up, and below that it depends a lot on the speed of the machine. Without a primed cache, an unpredictable jitter will be superimposed on the delay duration. Here is a plot which shows how DELAY() and nanodelay() perform on two of my test-machines: http://phk.freebsd.dk/misc/nanodelay.png I would appreciate if driver writers could play with this and see if makes any difference anywhere. Please notice that this is a timed cpu-spin, it does not allow another thread to use the CPU, so it should only be used for short (< 1/hz) delays. How it works: A default routine spins on the timecounter using nanouptime(). How well this works depends on which timecounter we use, but in general we can trust it to be OK above a few microseconds. An array contains function+arg to use for delays less than 8 usec, for longer delays the timecounter routine is always called. Each bucket in the array spans 8 nanoseconds, so delays of 0-7 nanoseconds use bucket 0, 8-15 nsec use bucket 1 etc. A number of cpu based spin routines are calibrated against the timecounter for various argument values and plugged into the array accordingly. The array takes up 9000 bytes on 32 bit and 17000 on 64 bit. This can be reduced at the cost of reduced precision in nanodelay(), we need to determine the correct tradeoff there. -- 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 Sat Nov 20 01:26:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6498416A4CE for ; Sat, 20 Nov 2004 01:26:28 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3303B43D2D for ; Sat, 20 Nov 2004 01:26:28 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id iAK1QRAG021117; Fri, 19 Nov 2004 17:26:27 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id iAK1QREP021116; Fri, 19 Nov 2004 17:26:27 -0800 (PST) (envelope-from obrien) Date: Fri, 19 Nov 2004 17:26:26 -0800 From: "David O'Brien" To: Ben Mesander Message-ID: <20041120012626.GG20068@dragon.nuxi.com> References: <16795.57534.19299.407779@piglet.timing.com> <1100766407.3475.1.camel@starshine.robbins.dropbear.id.au> <16796.54189.894371.247346@piglet.timing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16796.54189.894371.247346@piglet.timing.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-arch@freebsd.org Subject: Re: libregex library X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2004 01:26:28 -0000 On Thu, Nov 18, 2004 at 09:54:05AM -0700, Ben Mesander wrote: > Tim Robbins writes: > > What do you think src/lib/libc/regex is? > > Now that's a nice question. > So why are there two regex libs? They have differing API's and GNU utilities consume the GNU API not the Henry Spencer standard one. So we have to have both. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Sat Nov 20 23:38:37 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D00516A4CE for ; Sat, 20 Nov 2004 23:38:37 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B332343D2F for ; Sat, 20 Nov 2004 23:38:36 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from april.chuckr.org (localhost [127.0.0.1]) by april.chuckr.org (8.12.11/8.12.11) with ESMTP id iAL04GDm055471 for ; Sat, 20 Nov 2004 19:04:16 -0500 (EST) (envelope-from chuckr@chuckr.org) Received: from localhost (chuckr@localhost)iAL04GPq055468 for ; Sat, 20 Nov 2004 19:04:16 -0500 (EST) (envelope-from chuckr@chuckr.org) X-Authentication-Warning: april.chuckr.org: chuckr owned process doing -bs Date: Sat, 20 Nov 2004 19:04:16 -0500 (EST) From: Chuck Robey To: freebsd-arch@freebsd.org Message-ID: <20041120185823.O38351@april.chuckr.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2004 23:38:37 -0000 I have been thinking of a private hobby project, to try to implement FreeBSD on a palmtop based upon a version of the xscale processor. I have several good reasons to try this. Currently, there is a version of Linux running on it, so I expect not to have too hard a job of getting it booted, but I haven't really tracked FreeBSD, from a very lo-level standpoint, since FreeBSD-2.2 ... I don't know if FreeBSD remains a good platform for such and item or not. The image has to be, roughly speaking, capabable of running in a 64 Megabyte memory footprint. The spacific machine in my mind is the Zaurus. Am I talking to a bad spot here, abusing the list? Is there a better place to try to launch off this subject? I would like to see if anyone else wants to chat about it. I'm not yet looking for any help on it, I'm not sure it;s a really big enough job for that, but I would like to jaw a bit, if you catch my drift. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@chuckr.org | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary (on the wall at my old fraternity, Signa Phi Nothing). ---------------------------------------------------------------------------- From owner-freebsd-arch@FreeBSD.ORG Sat Nov 20 23:53:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1721916A4CE for ; Sat, 20 Nov 2004 23:53:35 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE6C943D39 for ; Sat, 20 Nov 2004 23:53:34 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iAKNu55f047115; Sat, 20 Nov 2004 16:56:06 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <419FD921.1070605@freebsd.org> Date: Sat, 20 Nov 2004 16:54:09 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Robey References: <20041120185823.O38351@april.chuckr.org> In-Reply-To: <20041120185823.O38351@april.chuckr.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: implementation X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2004 23:53:35 -0000 Chuck Robey wrote: > I have been thinking of a private hobby project, to try to implement > FreeBSD on a palmtop based upon a version of the xscale processor. I have > several good reasons to try this. Currently, there is a version of Linux > running on it, so I expect not to have too hard a job of getting it > booted, but I haven't really tracked FreeBSD, from a very lo-level > standpoint, since FreeBSD-2.2 ... I don't know if FreeBSD remains a good > platform for such and item or not. The image has to be, roughly speaking, > capabable of running in a 64 Megabyte memory footprint. > > The spacific machine in my mind is the Zaurus. > > Am I talking to a bad spot here, abusing the list? Is there a better > place to try to launch off this subject? I would like to see if anyone > else wants to chat about it. I'm not yet looking for any help on it, I'm > not sure it;s a really big enough job for that, but I would like to jaw a > bit, if you catch my drift. > Olivier Houchard has been making quite a bit of progress on the ARM/XScale port recently. I believe that he has an XScale dev board from Intel. You should talk to him to see how portable his work is to the Zaurus. Scott