From owner-freebsd-arch@FreeBSD.ORG Sun Sep 19 07:10:18 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 16B6816A4CE; Sun, 19 Sep 2004 07:10:18 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE29F43D2F; Sun, 19 Sep 2004 07:10:17 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-120-130-250.dsl.snfc21.pacbell.net [68.120.130.250])i8J79sIV017625; Sun, 19 Sep 2004 03:10:03 -0400 Message-ID: <414D30CF.2030309@elischer.org> Date: Sun, 19 Sep 2004 00:10:07 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <1095468747.31297.241.camel@palm.tree.com> <414B8D5E.7000700@elischer.org> <1095529353.31297.1192.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> In-Reply-To: <200409181653.35242.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Stephan Uphoff cc: freebsd-arch@FreeBSD.org Subject: Re: scheduler (sched_4bsd) questions 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, 19 Sep 2004 07:10:18 -0000 John Baldwin wrote: > On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > >>On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: >> >>>Stephan Uphoff wrote: >>> >>>>If this is true kernel threads can be preempted while holding >>>>for example the root vnode lock (or other important kernel >>>>resources) while not getting a chance to run until there are no more >>>>user processes with better priority. >>> >>>This is also true, though it is a slightly more complicated thing than >>>that. >>>Preempting threads are usually interrupt threads and are thus usually >>>short lived,. >> >>But interrupt threads often wake up other threads ... > > > That are lower priority and thus won't be preempted to. Instead, they run > when the interrupt thread goes back to sleep after it finishes. though that may still be before the original preempted thread gets run.. that reminds me.. John, we should add a flag to setrunqueue to add a preempted thread back at the FRONT of it's runqueue.. So that it gets a chance to use the rest of its slot.. the alternative is to keep a special "stack" (per cpu) of preempted threads so that we com back to the thread that we preempted. From owner-freebsd-arch@FreeBSD.ORG Sun Sep 19 07:10:38 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 C9ACA16A4CE; Sun, 19 Sep 2004 07:10:38 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85C3343D39; Sun, 19 Sep 2004 07:10:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-120-130-250.dsl.snfc21.pacbell.net [68.120.130.250])i8J7ANIV018090; Sun, 19 Sep 2004 03:10:23 -0400 Message-ID: <414D30EC.1000104@elischer.org> Date: Sun, 19 Sep 2004 00:10:36 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <1095468747.31297.241.camel@palm.tree.com> <414B8D5E.7000700@elischer.org> <1095529353.31297.1192.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> In-Reply-To: <200409181653.35242.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Stephan Uphoff cc: freebsd-arch@FreeBSD.org Subject: Re: scheduler (sched_4bsd) questions 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, 19 Sep 2004 07:10:38 -0000 John Baldwin wrote: > On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > >>On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: >> >>>Stephan Uphoff wrote: >>> >>>>If this is true kernel threads can be preempted while holding >>>>for example the root vnode lock (or other important kernel >>>>resources) while not getting a chance to run until there are no more >>>>user processes with better priority. >>> >>>This is also true, though it is a slightly more complicated thing than >>>that. >>>Preempting threads are usually interrupt threads and are thus usually >>>short lived,. >> >>But interrupt threads often wake up other threads ... > > > That are lower priority and thus won't be preempted to. Instead, they run > when the interrupt thread goes back to sleep after it finishes. though that may still be before the original preempted thread gets run.. that reminds me.. John, we should add a flag to setrunqueue to add a preempted thread back at the FRONT of it's runqueue.. So that it gets a chance to use the rest of its slot.. the alternative is to keep a special "stack" (per cpu) of preempted threads so that we come back to the thread that we preempted. From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 00:51:53 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 1DDE716A4CE; Mon, 20 Sep 2004 00:51:53 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC23043D2F; Mon, 20 Sep 2004 00:51:52 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C9CPH-0007iV-00; Mon, 20 Sep 2004 02:51:51 +0200 Received: from [217.227.156.246] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C9CPH-0007Jw-00; Mon, 20 Sep 2004 02:51:51 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Mon, 20 Sep 2004 02:50:40 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3113315.aWgR6iTeVk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409200250.49518.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-hackers@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-net@freebsd.org Subject: Global (non _KERNEL) place for sockaddr_union? 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: Mon, 20 Sep 2004 00:51:53 -0000 --nextPart3113315.aWgR6iTeVk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the symptom. Now= I am=20 looking for a clean solution to it. What is needed is an include file that= =20 defines union sockaddr_union in a way that is useable from kernel and=20 userland. Historically it seems that this union first apeared in context of= =20 ipsec within the kernel. pf has adopted it, but uses it in the userland as= =20 well. I am sure that it can be usefull in a lot of places that have to deal= =20 with/store different address formats. My question now is, what would be a good place to define this? Are there an= y=20 fromal standarts that might define it already? (Couldn't find anything) Is= =20 there anything else that I must consider? At some point I though netinet/in.h might be a good place, but that'd requi= re=20 inclusion of sys/socket.h, which certainly is not a good solution. Opinions? Ideas? > #include > #include >=20 > union sockaddr_union { > struct sockaddr sa; > struct sockaddr_in sin; > struct sockaddr_in6 sin6; > struct sockaddr_storage __su_pad; /* maybe not a bad idea */ > }; =46reeBSD: netipsec/keydb.h, line 43 (_KERNEL) NetBSD: netipsec/keydb.h, line 46 (_KERNEL) OpenBSD: netinet/ip_ipsp.h, line 50 (non _KERNEL) KAME: net/pfvar.h, line 699 (non _KERNEL, ! __OpenBSD__) Linux: Doesn't seem to have it. Or has it under a different name? =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 --nextPart3113315.aWgR6iTeVk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBTilpXyyEoT62BG0RAmpDAJ9IVZ1sV1GhHYyMXaAIx2hBZ9Bo1QCfaIYn XH9Pl7Y8VcPBVr9kgjdhvc8= =QH3p -----END PGP SIGNATURE----- --nextPart3113315.aWgR6iTeVk-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 02:26: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 D3C5116A4CE; Mon, 20 Sep 2004 02:26:56 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B033843D2F; Mon, 20 Sep 2004 02:26:56 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8K2SqAq027289; Sun, 19 Sep 2004 19:28:52 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8K2SqpY027288; Sun, 19 Sep 2004 19:28:52 -0700 Date: Sun, 19 Sep 2004 19:28:52 -0700 From: Brooks Davis To: Max Laier Message-ID: <20040920022852.GA21281@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <200409200250.49518.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=3.0 required=8.0 tests=SUSPICIOUS_RECIPS autolearn=no version=2.63 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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: Mon, 20 Sep 2004 02:26:57 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > Hi, >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the symptom. N= ow I am=20 > looking for a clean solution to it. What is needed is an include file tha= t=20 > defines union sockaddr_union in a way that is useable from kernel and=20 > userland. Historically it seems that this union first apeared in context = of=20 > ipsec within the kernel. pf has adopted it, but uses it in the userland a= s=20 > well. I am sure that it can be usefull in a lot of places that have to de= al=20 > with/store different address formats. >=20 > My question now is, what would be a good place to define this? Are there = any=20 > fromal standarts that might define it already? (Couldn't find anything) I= s=20 > there anything else that I must consider? >=20 > At some point I though netinet/in.h might be a good place, but that'd req= uire=20 > inclusion of sys/socket.h, which certainly is not a good solution. >=20 > Opinions? Ideas? >=20 > > #include > > #include > >=20 > > union sockaddr_union { > > struct sockaddr sa; > > struct sockaddr_in sin; > > struct sockaddr_in6 sin6; > > struct sockaddr_storage __su_pad; /* maybe not a bad idea */ > > }; I don't see an elegant solution. Stuffing it off in its own file may be the best thing if you're going to use it. Overall, I'd say it's bad idea that PF be better off without. It appears to save a few casts, but nothing worth the pain of generalizing the declaration. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBTkBkXY6L6fI4GtQRAkN5AJ4vSbihrYfqgTxU4MrgF4vNXFYr6ACeJ0Uh aeCoFMPqPGpWIYLi5DDzc4c= =WKvT -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 03:40:54 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 784C016A4CE; Mon, 20 Sep 2004 03:40:54 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE95643D54; Mon, 20 Sep 2004 03:40:53 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C9F2o-0002Lr-00; Mon, 20 Sep 2004 05:40:50 +0200 Received: from [217.227.156.246] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C9F2n-0007vz-00; Mon, 20 Sep 2004 05:40:50 +0200 From: Max Laier To: Brooks Davis Date: Mon, 20 Sep 2004 05:39:38 +0200 User-Agent: KMail/1.7 References: <200409200250.49518.max@love2party.net> <20040920022852.GA21281@odin.ac.hmc.edu> In-Reply-To: <20040920022852.GA21281@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3010729.AUYAN69HKC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409200539.48073.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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: Mon, 20 Sep 2004 03:40:54 -0000 --nextPart3010729.AUYAN69HKC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 20 September 2004 04:28, Brooks Davis wrote: > On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > > Hi, > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the symptom.= Now > > I am looking for a clean solution to it. What is needed is an include > > file that defines union sockaddr_union in a way that is useable from > > kernel and userland. Historically it seems that this union first apeared > > in context of ipsec within the kernel. pf has adopted it, but uses it in > > the userland as well. I am sure that it can be usefull in a lot of plac= es > > that have to deal with/store different address formats. > > > > My question now is, what would be a good place to define this? Are there > > any fromal standarts that might define it already? (Couldn't find > > anything) Is there anything else that I must consider? > > > > At some point I though netinet/in.h might be a good place, but that'd > > require inclusion of sys/socket.h, which certainly is not a good > > solution. > > > > Opinions? Ideas? > > > > > #include > > > #include > > > > > > union sockaddr_union { > > > struct sockaddr sa; > > > struct sockaddr_in sin; > > > struct sockaddr_in6 sin6; > > > struct sockaddr_storage __su_pad; /* maybe not a bad idea */ > > > }; > > I don't see an elegant solution. Stuffing it off in its own file may > be the best thing if you're going to use it. Overall, I'd say it's bad > idea that PF be better off without. It appears to save a few casts, > but nothing worth the pain of generalizing the declaration. > > -- Brooks =46irst of all, the padding is bogus as sin6 is big enough. Especially sinc= e one=20 point here is to save space. I was a bit confused there, sorry. Especially= =20 since this is an important point: In pf this union is uses to - for example= -=20 store address information in tables. It allows to store IPv4 and IPv6=20 addresses in the same table without creating overhead in the memory footpri= nt=20 or having to deal with different objects for every address type. The fewer= =20 casts are just an additional benefit. Maybe you are right and a new header is the easiest way out. Moving this ou= t=20 of under _KERNEL would require all includer of netipsec/keydb.h to include= =20 sys/socket.h and netinet/in.h. As I was saying, I don't have a good idea=20 either. The only thing that came to my mind just now is to add a protecting= =20 define and #ifdef around the two places that define it. But I have no idea= =20 how clean (in terms of style) such a solution is. =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 --nextPart3010729.AUYAN69HKC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBTlEEXyyEoT62BG0RAr9TAJ42DYbnMVi2Cgj9TICFk7YXCo0YFgCfQdyg ORVq+9JZZUGaOxLFYXMf82U= =cYA3 -----END PGP SIGNATURE----- --nextPart3010729.AUYAN69HKC-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 04:22:20 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 2F71A16A4CE; Mon, 20 Sep 2004 04:22:20 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5D7F43D39; Mon, 20 Sep 2004 04:22:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8K4OHI6010640; Sun, 19 Sep 2004 21:24:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8K4OHbu010635; Sun, 19 Sep 2004 21:24:17 -0700 Date: Sun, 19 Sep 2004 21:24:17 -0700 From: Brooks Davis To: Max Laier Message-ID: <20040920042417.GB9460@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> <20040920022852.GA21281@odin.ac.hmc.edu> <200409200539.48073.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GRPZ8SYKNexpdSJ7" Content-Disposition: inline In-Reply-To: <200409200539.48073.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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: Mon, 20 Sep 2004 04:22:20 -0000 --GRPZ8SYKNexpdSJ7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 05:39:38AM +0200, Max Laier wrote: > On Monday 20 September 2004 04:28, Brooks Davis wrote: > > On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > > > Hi, > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the sympto= m. Now > > > I am looking for a clean solution to it. What is needed is an include > > > file that defines union sockaddr_union in a way that is useable from > > > kernel and userland. Historically it seems that this union first apea= red > > > in context of ipsec within the kernel. pf has adopted it, but uses it= in > > > the userland as well. I am sure that it can be usefull in a lot of pl= aces > > > that have to deal with/store different address formats. > > > > > > My question now is, what would be a good place to define this? Are th= ere > > > any fromal standarts that might define it already? (Couldn't find > > > anything) Is there anything else that I must consider? > > > > > > At some point I though netinet/in.h might be a good place, but that'd > > > require inclusion of sys/socket.h, which certainly is not a good > > > solution. > > > > > > Opinions? Ideas? > > > > > > > #include > > > > #include > > > > > > > > union sockaddr_union { > > > > struct sockaddr sa; > > > > struct sockaddr_in sin; > > > > struct sockaddr_in6 sin6; > > > > struct sockaddr_storage __su_pad; /* maybe not a bad idea */ > > > > }; > > > > I don't see an elegant solution. Stuffing it off in its own file may > > be the best thing if you're going to use it. Overall, I'd say it's bad > > idea that PF be better off without. It appears to save a few casts, > > but nothing worth the pain of generalizing the declaration. >=20 > First of all, the padding is bogus as sin6 is big enough. Especially sinc= e one=20 > point here is to save space. I was a bit confused there, sorry. Especiall= y=20 > since this is an important point: In pf this union is uses to - for examp= le -=20 > store address information in tables. It allows to store IPv4 and IPv6=20 > addresses in the same table without creating overhead in the memory footp= rint=20 > or having to deal with different objects for every address type. The fewe= r=20 > casts are just an additional benefit. > > Maybe you are right and a new header is the easiest way out. Moving this = out=20 > of under _KERNEL would require all includer of netipsec/keydb.h to includ= e=20 > sys/socket.h and netinet/in.h. As I was saying, I don't have a good idea= =20 > either. The only thing that came to my mind just now is to add a protecti= ng=20 > define and #ifdef around the two places that define it. But I have no ide= a=20 > how clean (in terms of style) such a solution is. If it's primairly for well defined storage, why not remove the sa and put it in netinet/in.h? If you're just looking for the family and length, it doesn't matter if you access it as .sa, .sin, or .sin6. You might have to name it something else which could be problematic for portability, but it might be worth the pain if you could push it back to OpenBSD. -- Brooks -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --GRPZ8SYKNexpdSJ7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBTltvXY6L6fI4GtQRApA7AKC4bgZvLAzTVpzVhHVfXEwQd+JWtACgrBrG wdii84flDaNUq1uEym+j+Ms= =P8eR -----END PGP SIGNATURE----- --GRPZ8SYKNexpdSJ7-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 07:39:08 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 A562816A4CE for ; Mon, 20 Sep 2004 07:39:08 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E042643D1F for ; Mon, 20 Sep 2004 07:39:07 +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 i8K7cjfI046042 for ; Mon, 20 Sep 2004 09:39:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@FreeBSD.org From: "Poul-Henning Kamp" Date: Mon, 20 Sep 2004 09:38:45 +0200 Message-ID: <46041.1095665925@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 07:39:08 -0000 I am convinced that it is important that a serial port behaves predictably no matter what driver implements it, and this is far from the case today. The tty cleanup I'm doing now in preparation for being able to pull all the tty stuff out from under Giant is more or less a matter of getting the drivers to do the same thing by using the same code. There is one outstanding issue though: Device naming The traditional BSD naming scheme as far as I can tell was tty[%{adapter}]%{port} Sun (?) introduced the "cua" devices (Calling Unit Attachment in case you wondered) to allow a modem to be used in both in- and out-going direction at once. Our sio driver, which for many intents and purposes is our reference driver, almost follows this convention: tty[il]d0 + cua[il]a0 = port 0 The 'i' and 'l' reference the "init" and "lock" state respectively. Other drivers have resorted to various variations of this scheme (if they were copy&pasted from sio.c) or rolled their own private naming system. In other words: it's a pretty mess right now. We discussed this naming of tty devices earlier this year (on current) and didn't reach a concensus. This is IMO one of those areas where there is no "perfect" solution given backwards compatibility and therefore the closest to perfect we can get is to define a naming scheme which retains as much compatibility as possible and stick to it. My suggestion is the following: All drivers will offer "tty${something}" devices, and generally ${something} will consist of a letter followed by a number, possibly in base 36 ([0-9a-z]). All drivers which attach to external equipment via a serial connector should also offer "cua${thesamething}". "Embedded" serial ports, pseudo drivers etc, do not have to offer the "cua" if DCD state on open is not an issue. The init and lock devices will be called ${base_device}.[init,lock] and they will possibly be provided by on-demand devices so that they do not clutter up /dev. This results in the following major compatibility issues: sio's cuaa* gets renamed to cuad* sio's {tty,cua}[il]%d gets renamed to {tty,cua}%d.{init,lock} ucom's ucom%d gets renamed to ttyU%d ucom gains cuaU%d and .init and .lock devices. uart gains cuau%d and .init and .lock devices. The remaining drivers are pretty obscure and have limited user communities and they will just have to live with things getting straigthend out. I'll admit that this should have been done 10 years ago, but better late than never. Well-argued protests or researched alternatives before friday please. Thanks in advance, Poul-Henning -- 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 Mon Sep 20 08:59:09 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 5E37716A4CE for ; Mon, 20 Sep 2004 08:59:09 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76D9243D58 for ; Mon, 20 Sep 2004 08:59:08 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (oak.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i8K8x7la036461; Mon, 20 Sep 2004 11:59:07 +0300 (EEST) (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 36529-09; Mon, 20 Sep 2004 11:59:06 +0300 (EEST) 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 i8K8x5FL036455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Sep 2004 11:59:06 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8K8x8B6043291; Mon, 20 Sep 2004 11:59:08 +0300 (EEST) (envelope-from ru) Date: Mon, 20 Sep 2004 11:59:08 +0300 From: Ruslan Ermilov To: Poul-Henning Kamp Message-ID: <20040920085908.GA43176@ip.net.ua> References: <46041.1095665925@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <46041.1095665925@critter.freebsd.dk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 08:59:09 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 09:38:45AM +0200, Poul-Henning Kamp wrote: > My suggestion is the following: >=20 > All drivers will offer "tty${something}" devices, and > generally ${something} will consist of a letter followed > by a number, possibly in base 36 ([0-9a-z]). >=20 > All drivers which attach to external equipment via a serial > connector should also offer "cua${thesamething}". "Embedded" > serial ports, pseudo drivers etc, do not have to offer the > "cua" if DCD state on open is not an issue. >=20 > The init and lock devices will be called ${base_device}.[init,lock] > and they will possibly be provided by on-demand devices so that > they do not clutter up /dev. >=20 > This results in the following major compatibility issues: >=20 > sio's cuaa* gets renamed to cuad* >=20 > sio's {tty,cua}[il]%d gets renamed to {tty,cua}%d.{init,lock} >=20 But we now have cuaa0, cuaia0, cuala0, ttyd0, ttyid0, and ttyld0. So, shouldn't the above line be instead: sio's tty[il]d%d gets renamed to ttyd%d.{init,lock} sio's cua[il]a%d gets renamed to cuad%d.{init,lock} You didn't make it clear what ${base_device} should look like, but I'm sure you meant that will it include the driver's "letter". This way we'll have: ttyd0, ttyd0.init, ttyd0.lock, cuad0, cuad0.init, cuad0.lock. > Well-argued protests or researched alternatives before friday please. >=20 If this will be done in both RELENG_5 and HEAD, I suggest to have backward compatibility symlinks under /dev (in RELENG_5 only). I don't know how hard it would be to implement this, just an idea. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBTpvcqRfpzJluFF4RAk8XAJ0ZOP1snrH5nkXkbokjbXf3cgxNfQCgizCo 1ZN5/30QcndPdPqPGuEBN/M= =1Hwi -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 09:01:45 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 3BD6216A4CE; Mon, 20 Sep 2004 09:01:45 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 935BB43D41; Mon, 20 Sep 2004 09:01:44 +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 i8K91fhT074985; Mon, 20 Sep 2004 11:01:42 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Ruslan Ermilov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 20 Sep 2004 11:59:08 +0300." <20040920085908.GA43176@ip.net.ua> Date: Mon, 20 Sep 2004 11:01:41 +0200 Message-ID: <74982.1095670901@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 09:01:45 -0000 In message <20040920085908.GA43176@ip.net.ua>, Ruslan Ermilov writes: >> This results in the following major compatibility issues: >> >> sio's cuaa* gets renamed to cuad* >> >> sio's {tty,cua}[il]%d gets renamed to {tty,cua}%d.{init,lock} >> >But we now have cuaa0, cuaia0, cuala0, ttyd0, ttyid0, and ttyld0. >So, shouldn't the above line be instead: > > sio's tty[il]d%d gets renamed to ttyd%d.{init,lock} > sio's cua[il]a%d gets renamed to cuad%d.{init,lock} > >You didn't make it clear what ${base_device} should look like, but I'm >sure you meant that will it include the driver's "letter". This way >we'll have: ttyd0, ttyd0.init, ttyd0.lock, cuad0, cuad0.init, cuad0.lock. >If this will be done in both RELENG_5 and HEAD, I suggest to have >backward compatibility symlinks under /dev (in RELENG_5 only). I >don't know how hard it would be to implement this, just an idea. It will not be done in RELENG_5. We can consider making a "future compatibility" rc script which creates some strategic symlinks, but that is for discussion down the road. -- 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 Mon Sep 20 09:02:08 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 9515416A4CE; Mon, 20 Sep 2004 09:02:08 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2FB543D2F; Mon, 20 Sep 2004 09:02:07 +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 i8K927i9075623; Mon, 20 Sep 2004 11:02:07 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Ruslan Ermilov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 20 Sep 2004 11:59:08 +0300." <20040920085908.GA43176@ip.net.ua> Date: Mon, 20 Sep 2004 11:02:07 +0200 Message-ID: <75622.1095670927@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 09:02:08 -0000 In message <20040920085908.GA43176@ip.net.ua>, Ruslan Ermilov writes: >> >> sio's cuaa* gets renamed to cuad* >> >> sio's {tty,cua}[il]%d gets renamed to {tty,cua}%d.{init,lock} >> >But we now have cuaa0, cuaia0, cuala0, ttyd0, ttyid0, and ttyld0. >So, shouldn't the above line be instead: > > sio's tty[il]d%d gets renamed to ttyd%d.{init,lock} > sio's cua[il]a%d gets renamed to cuad%d.{init,lock} > >You didn't make it clear what ${base_device} should look like, but I'm >sure you meant that will it include the driver's "letter". This way >we'll have: ttyd0, ttyd0.init, ttyd0.lock, cuad0, cuad0.init, cuad0.lock. OOps: forgot to say: yes, you're right. -- 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 Mon Sep 20 11:27:43 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 9C21C16A4CE for ; Mon, 20 Sep 2004 11:27:43 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7E4343D58 for ; Mon, 20 Sep 2004 11:27:42 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id i8KBRXKf016769; Mon, 20 Sep 2004 14:27:36 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i8KBRXMx016765; Mon, 20 Sep 2004 14:27:33 +0300 (EEST) (envelope-from netch) Date: Mon, 20 Sep 2004 14:27:33 +0300 From: Valentin Nechayev To: Poul-Henning Kamp Message-ID: <20040920112733.GE84228@lucky.net> References: <46041.1095665925@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46041.1095665925@critter.freebsd.dk> X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2004 11:27:43 -0000 Mon, Sep 20, 2004 at 09:38:45, phk wrote about "[HEADSUP] naming of tty devices.": > My suggestion is the following: > All drivers will offer "tty${something}" devices, and > generally ${something} will consist of a letter followed > by a number, possibly in base 36 ([0-9a-z]). There are cases when cua devices are used as login devices, and too many places where 3 first chars of device name are removed without checking them, e.g. /bin/ps: === cut === else { if (strncmp(ttname, "tty", 3) == 0 || strncmp(ttname, "cua", 3) == 0) ttname += 3; === end cut === When restoring terminal device from this name, now it is possible yet to determine terminal testing /dev/tty$x or /dev/cua$x; with your new scheme this will be impossible totally. If we suppose to remain ability of logging in via callout devices, these code pieces must be rewritten to keep "tty"/"cua", or all callout devices must be renamed to terminals. On 4.* I use the latter variant on one host: /dev/cuaa$n are renamed to /dev/ttyOd$n, n=0...3. > This results in the following major compatibility issues: > sio's cuaa* gets renamed to cuad* Basing on written above I propose /dev/ttyOd* -netch- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 12:09: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 CD10416A4CE for ; Mon, 20 Sep 2004 12:09:05 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA9A743D41 for ; Mon, 20 Sep 2004 12:09:04 +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 i8KC92hd099368; Mon, 20 Sep 2004 14:09:02 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: netch@lucky.net From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 20 Sep 2004 14:27:33 +0300." <20040920112733.GE84228@lucky.net> Date: Mon, 20 Sep 2004 14:09:02 +0200 Message-ID: <99367.1095682142@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 12:09:05 -0000 In message <20040920112733.GE84228@lucky.net>, Valentin Nechayev writes: > Mon, Sep 20, 2004 at 09:38:45, phk wrote about "[HEADSUP] naming of tty devices.": > >> My suggestion is the following: > >> All drivers will offer "tty${something}" devices, and >> generally ${something} will consist of a letter followed >> by a number, possibly in base 36 ([0-9a-z]). > >There are cases when cua devices are used as login devices, and too many >places where 3 first chars of device name are removed without checking them, >e.g. /bin/ps: That is one of the reasons why I want consistency. >When restoring terminal device from this name, now it is possible yet >to determine terminal testing /dev/tty$x or /dev/cua$x; with your new >scheme this will be impossible totally. No, that is exactly the way it will work, and which today it doesn't. ttyd0 and cuad0 is the same device. The difference between "tty" and "cua" is how we react to DCD when opening. You can never be logged in vial both ttyd0 and cuad0 at the same time, so there is no logging issue. -- 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 Mon Sep 20 12:19:22 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 BCB7316A4CE for ; Mon, 20 Sep 2004 12:19:22 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D30243D5E for ; Mon, 20 Sep 2004 12:19:22 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id i8KCJD52029483; Mon, 20 Sep 2004 15:19:16 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i8KCJD6c029480; Mon, 20 Sep 2004 15:19:13 +0300 (EEST) (envelope-from netch) Date: Mon, 20 Sep 2004 15:19:13 +0300 From: Valentin Nechayev To: Poul-Henning Kamp Message-ID: <20040920121913.GH89036@lucky.net> References: <20040920112733.GE84228@lucky.net> <99367.1095682142@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99367.1095682142@critter.freebsd.dk> X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2004 12:19:22 -0000 Mon, Sep 20, 2004 at 14:09:02, phk wrote about "Re: [HEADSUP] naming of tty devices.": >>When restoring terminal device from this name, now it is possible yet >>to determine terminal testing /dev/tty$x or /dev/cua$x; with your new >>scheme this will be impossible totally. > No, that is exactly the way it will work, and which today it doesn't. > ttyd0 and cuad0 is the same device. The difference between "tty" > and "cua" is how we react to DCD when opening. > You can never be > logged in vial both ttyd0 and cuad0 at the same time, so there is > no logging issue. I say not for logging, but for restoring full terminal name from short name. E.g. listing processes controlled by this terminal. Whether /bin/ps will list processes for both callin and callout port, when got "-t d1"? -netch- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 13:03: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 AAA5D16A4E8 for ; Mon, 20 Sep 2004 13:03:17 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B353743D6A for ; Mon, 20 Sep 2004 13:03:16 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (oak.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i8KD3FqN042473; Mon, 20 Sep 2004 16:03:15 +0300 (EEST) (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 71523-04; Mon, 20 Sep 2004 16:03:14 +0300 (EEST) 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 i8KD3DaT042470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Sep 2004 16:03:14 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i8KD3Gor044987; Mon, 20 Sep 2004 16:03:16 +0300 (EEST) (envelope-from ru) Date: Mon, 20 Sep 2004 16:03:16 +0300 From: Ruslan Ermilov To: Valentin Nechayev Message-ID: <20040920130316.GA44861@ip.net.ua> References: <20040920112733.GE84228@lucky.net> <99367.1095682142@critter.freebsd.dk> <20040920121913.GH89036@lucky.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20040920121913.GH89036@lucky.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 13:03:17 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 03:19:13PM +0300, Valentin Nechayev wrote: > Mon, Sep 20, 2004 at 14:09:02, phk wrote about "Re: [HEADSUP] naming of = tty devices.":=20 >=20 > >>When restoring terminal device from this name, now it is possible yet > >>to determine terminal testing /dev/tty$x or /dev/cua$x; with your new > >>scheme this will be impossible totally. > > No, that is exactly the way it will work, and which today it doesn't. > > ttyd0 and cuad0 is the same device. The difference between "tty" > > and "cua" is how we react to DCD when opening. > > You can never be > > logged in vial both ttyd0 and cuad0 at the same time, so there is > > no logging issue. >=20 > I say not for logging, but for restoring full terminal name from short na= me. > E.g. listing processes controlled by this terminal. Whether /bin/ps will > list processes for both callin and callout port, when got "-t d1"? >=20 I fail to see what will be different. Currently, it works like this: $ ps -tfoo ps: /dev/ttyfoo and /dev/foo: No such file or directory $ tty =20 /dev/ttypo $ ps -t/dev/ttypo PID TT STAT TIME COMMAND 11104 po Ss 0:00,07 -tcsh (tcsh) 11112 po S 0:00,01 sh 11116 po R+ 0:00,00 ps -t/dev/ttypo /*- * The user can specify a device via one of three formats: * 1) fully qualified, e.g.: /dev/ttyp0 /dev/console * 2) missing "/dev", e.g.: ttyp0 console * 3) two-letters, e.g.: p0 co * (matching letters that would be seen in the "TT" column) */ To answer your question: when given "-t d1", both now and then it will convert it to /dev/ttyd1 and /dev/d1. If you need both callout and callin devices, "-t /dev/ttyd1 -t /dev/cuaa1" should be used. And you can always use "-O tty" to see the full tty name. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD4DBQFBTtUUqRfpzJluFF4RAokPAJi7Hiq056pLPPp+1euIRwB4LxxBAJ4y7ezM t6S93BQNy8V+h6WSFpHnOw== =Lv11 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 13:12:22 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 7A0F016A4CE for ; Mon, 20 Sep 2004 13:12:22 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCF8B43D1F for ; Mon, 20 Sep 2004 13:12:21 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8KD8PlR040788 for arch@FreeBSD.org.checked; (8.12.8/vak/2.1) Mon, 20 Sep 2004 17:08:25 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i8KD5KqN040639; (8.12.8/vak/2.1) Mon, 20 Sep 2004 17:05:20 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <414ED61D.5080607@cronyx.ru> Date: Mon, 20 Sep 2004 17:07:41 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <46041.1095665925@critter.freebsd.dk> In-Reply-To: <46041.1095665925@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 13:12:22 -0000 Just an idea: Why not to add some general device enumeration for all devices, especially if devices would behave the same? tty%{global_port} cua%{global_port} rik Poul-Henning Kamp wrote: >I am convinced that it is important that a serial port behaves >predictably no matter what driver implements it, and this is far >from the case today. The tty cleanup I'm doing now in preparation >for being able to pull all the tty stuff out from under Giant >is more or less a matter of getting the drivers to do the same thing >by using the same code. > >There is one outstanding issue though: Device naming > >The traditional BSD naming scheme as far as I can tell was > > tty[%{adapter}]%{port} > >Sun (?) introduced the "cua" devices (Calling Unit Attachment in case >you wondered) to allow a modem to be used in both in- and out-going >direction at once. > >Our sio driver, which for many intents and purposes is our reference >driver, almost follows this convention: > > tty[il]d0 + cua[il]a0 = port 0 > > The 'i' and 'l' reference the "init" and "lock" state respectively. > >Other drivers have resorted to various variations of this scheme >(if they were copy&pasted from sio.c) or rolled their own private >naming system. In other words: it's a pretty mess right now. > >We discussed this naming of tty devices earlier this year (on >current) and didn't reach a concensus. This is IMO one of those >areas where there is no "perfect" solution given backwards compatibility >and therefore the closest to perfect we can get is to define a >naming scheme which retains as much compatibility as possible and >stick to it. > >My suggestion is the following: > > All drivers will offer "tty${something}" devices, and > generally ${something} will consist of a letter followed > by a number, possibly in base 36 ([0-9a-z]). > > All drivers which attach to external equipment via a serial > connector should also offer "cua${thesamething}". "Embedded" > serial ports, pseudo drivers etc, do not have to offer the > "cua" if DCD state on open is not an issue. > > The init and lock devices will be called ${base_device}.[init,lock] > and they will possibly be provided by on-demand devices so that > they do not clutter up /dev. > >This results in the following major compatibility issues: > > sio's cuaa* gets renamed to cuad* > > sio's {tty,cua}[il]%d gets renamed to {tty,cua}%d.{init,lock} > > ucom's ucom%d gets renamed to ttyU%d > > ucom gains cuaU%d and .init and .lock devices. > > uart gains cuau%d and .init and .lock devices. > >The remaining drivers are pretty obscure and have limited user communities >and they will just have to live with things getting straigthend out. > > >I'll admit that this should have been done 10 years ago, but better late >than never. > >Well-argued protests or researched alternatives before friday please. > >Thanks in advance, > >Poul-Henning > > > From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 13:37:19 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 2BE6D16A4CE for ; Mon, 20 Sep 2004 13:37:19 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 727AF43D2D for ; Mon, 20 Sep 2004 13:37:18 +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 i8KDbDkU002852; Mon, 20 Sep 2004 15:37:13 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Roman Kurakin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 20 Sep 2004 17:07:41 +0400." <414ED61D.5080607@cronyx.ru> Date: Mon, 20 Sep 2004 15:37:13 +0200 Message-ID: <2850.1095687433@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 13:37:19 -0000 In message <414ED61D.5080607@cronyx.ru>, Roman Kurakin writes: >Just an idea: > > Why not to add some general device enumeration for all devices, >especially >if devices would behave the same? > >tty%{global_port} >cua%{global_port} This doesn't work. There _are_ differences between serial devices and for instance PTYs or NMDM devices have very particular semantics. -- 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 Mon Sep 20 13:50:31 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 235DC16A4D9 for ; Mon, 20 Sep 2004 13:50:31 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CDEA43D3F for ; Mon, 20 Sep 2004 13:50:30 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8KDl6WH043104 for arch@freebsd.org.checked; (8.12.8/vak/2.1) Mon, 20 Sep 2004 17:47:06 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i8KDivqN043003; (8.12.8/vak/2.1) Mon, 20 Sep 2004 17:44:57 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <414EDF66.8030907@cronyx.ru> Date: Mon, 20 Sep 2004 17:47:18 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <2850.1095687433@critter.freebsd.dk> In-Reply-To: <2850.1095687433@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 13:50:31 -0000 Poul-Henning Kamp wrote: >In message <414ED61D.5080607@cronyx.ru>, Roman Kurakin writes: > > >>Just an idea: >> >> Why not to add some general device enumeration for all devices, >>especially >>if devices would behave the same? >> >>tty%{global_port} >>cua%{global_port} >> >> > >This doesn't work. > >There _are_ differences between serial devices and for instance >PTYs or NMDM devices have very particular semantics. > > but all tty devices have some generic abilities and behaviour, right? (Sorry, I am a bit sio-centric, I didn't ever look inside ptys.) rik From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 13:51:59 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 B735616A576 for ; Mon, 20 Sep 2004 13:51:59 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FFC243D45 for ; Mon, 20 Sep 2004 13:51: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 i8KDpqal020548; Mon, 20 Sep 2004 15:51:52 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Roman Kurakin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 20 Sep 2004 17:47:18 +0400." <414EDF66.8030907@cronyx.ru> Date: Mon, 20 Sep 2004 15:51:52 +0200 Message-ID: <20547.1095688312@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 13:51:59 -0000 In message <414EDF66.8030907@cronyx.ru>, Roman Kurakin writes: >>> Why not to add some general device enumeration for all devices, >>>especially >>>if devices would behave the same? >>> >>>tty%{global_port} >>>cua%{global_port} >> >>This doesn't work. >> >>There _are_ differences between serial devices and for instance >>PTYs or NMDM devices have very particular semantics. >> >but all tty devices have some generic abilities and behaviour, right? >(Sorry, I am a bit sio-centric, I didn't ever look inside ptys.) Yes, and those generic abilities is why I want systematic naming. But a global numbering gives you no way to know that tty234 is a PTY and tty235 is a USB device. -- 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 Mon Sep 20 14:25:38 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 A506F16A4CE for ; Mon, 20 Sep 2004 14:25:38 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 266B543D54 for ; Mon, 20 Sep 2004 14:25:38 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C9P6m-0001sH-EN; Mon, 20 Sep 2004 18:25:36 +0400 From: Vladimir Grebenschikov To: Poul-Henning Kamp In-Reply-To: <20547.1095688312@critter.freebsd.dk> References: <20547.1095688312@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Mon, 20 Sep 2004 18:25:35 +0400 Message-Id: <1095690335.980.60.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 14:25:38 -0000 =F7 =D0=CE, 20/09/2004 =D7 15:51 +0200, Poul-Henning Kamp =D0=C9=DB=C5=D4: > In message <414EDF66.8030907@cronyx.ru>, Roman Kurakin writes: >=20 > >>> Why not to add some general device enumeration for all devices,=20 > >>>especially > >>>if devices would behave the same? > >>> > >>>tty%{global_port} > >>>cua%{global_port} > >> > >>This doesn't work. > >> > >>There _are_ differences between serial devices and for instance > >>PTYs or NMDM devices have very particular semantics. > >> > >but all tty devices have some generic abilities and behaviour, right? > >(Sorry, I am a bit sio-centric, I didn't ever look inside ptys.) >=20 > Yes, and those generic abilities is why I want systematic naming. >=20 > But a global numbering gives you no way to know that tty234 is a PTY > and tty235 is a USB device. As da3 do not give you any hint is it SCSI disk, USB connected memory card or firewire-connected DV-Camera. I am not vote for uniform ttys numbering, just notice about similar subsystem. Actual another problem - ttys should be allocated from userland as minimum tty/pty (in contrary with disks). One of possible solutions - different dev name-spaces=20 /dev/tty/ZXX - for generic ttys (all other ttys mapped there too) /dev/pty/XX - for pseudo-ttys /dev/sio/XX - for former ttydX /dev/cua/XX - for former cuaaX /dev/nmdm/XX - for null-modem /dev/con/XX - for console etc...=20 But this layout broke any possible compatibility and will only confuse userland (what name should be considered as primary ?) I like pkh@ idea if there still way to list all available tty devices in system. (sysctl or dev entry/directory)=20 --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 14:45:30 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 4D8F116A4CE; Mon, 20 Sep 2004 14:45:30 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94E4543D45; Mon, 20 Sep 2004 14:45:29 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id i8KEjJPe070927; Mon, 20 Sep 2004 17:45:23 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i8KEjJZA070924; Mon, 20 Sep 2004 17:45:19 +0300 (EEST) (envelope-from netch) Date: Mon, 20 Sep 2004 17:45:19 +0300 From: Valentin Nechayev To: Ruslan Ermilov Message-ID: <20040920144519.GJ89036@lucky.net> References: <20040920112733.GE84228@lucky.net> <99367.1095682142@critter.freebsd.dk> <20040920121913.GH89036@lucky.net> <20040920130316.GA44861@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040920130316.GA44861@ip.net.ua> X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2004 14:45:30 -0000 Mon, Sep 20, 2004 at 16:03:16, ru wrote about "Re: [HEADSUP] naming of tty devices.": > To answer your question: when given "-t d1", both now and then > it will convert it to /dev/ttyd1 and /dev/d1. If you need > both callout and callin devices, "-t /dev/ttyd1 -t /dev/cuaa1" > should be used. And you can always use "-O tty" to see the > full tty name. Well, this means a bunch of crutches instead of one simple solution. But if keeping "cua" in naming scheme is so important, I withdrew my comments. -netch- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 15:48:20 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 B6EB916A4CE; Mon, 20 Sep 2004 15:48:20 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C20543D45; Mon, 20 Sep 2004 15:48:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8KFkHg8062404; Mon, 20 Sep 2004 09:46:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 20 Sep 2004 09:47:15 -0600 (MDT) Message-Id: <20040920.094715.95505736.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <74982.1095670901@critter.freebsd.dk> References: <20040920085908.GA43176@ip.net.ua> <74982.1095670901@critter.freebsd.dk> 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: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 15:48:20 -0000 In message: <74982.1095670901@critter.freebsd.dk> "Poul-Henning Kamp" writes: : We can consider making a "future compatibility" rc script which creates : some strategic symlinks, but that is for discussion down the road. or devfs.rules entries. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 15:50:30 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 D10B516A4D1 for ; Mon, 20 Sep 2004 15:50:30 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6877543D54 for ; Mon, 20 Sep 2004 15:50:22 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i8KFlBtp048604 for arch@freebsd.org.checked; (8.12.8/vak/2.1) Mon, 20 Sep 2004 19:47:11 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i8KFjs5X048544; (8.12.8/vak/2.1) Mon, 20 Sep 2004 19:45:54 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <414EFBBF.3050108@cronyx.ru> Date: Mon, 20 Sep 2004 19:48:15 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <20547.1095688312@critter.freebsd.dk> In-Reply-To: <20547.1095688312@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Mon, 20 Sep 2004 15:50:31 -0000 Poul-Henning Kamp wrote: >In message <414EDF66.8030907@cronyx.ru>, Roman Kurakin writes: > > >>>> Why not to add some general device enumeration for all devices, >>>>especially >>>>if devices would behave the same? >>>> >>>>tty%{global_port} >>>>cua%{global_port} >>>> >>>> >>>This doesn't work. >>> >>>There _are_ differences between serial devices and for instance >>>PTYs or NMDM devices have very particular semantics. >>> >>> >>> >>but all tty devices have some generic abilities and behaviour, right? >>(Sorry, I am a bit sio-centric, I didn't ever look inside ptys.) >> >> >Yes, and those generic abilities is why I want systematic naming. > > So if software do not want to know peculiarities, it is enough to it to use ttyXYZ and do not distinguish between various devices. I believe this might be useful for simplicity of management of software. If we use a set of various hardware for same functions, it would be easy to write one template and a range of ttyXYZs for which it would be applied. >But a global numbering gives you no way to know that tty234 is a PTY >and tty235 is a USB device. > > But if software wants to it may ask its real name or type or whatever. From the other hand symlink or alias for device and ioctl "tell me who you are" could do the same. PS. This all not more than just some ideas about what might be useful. rik From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 17:58: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 9A7D516A4CE for ; Mon, 20 Sep 2004 17:58:15 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31B0743D46 for ; Mon, 20 Sep 2004 17:58:15 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8KIvsZx025962 for ; Mon, 20 Sep 2004 13:57:54 -0500 Date: Mon, 20 Sep 2004 13:57:54 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: AoE devices and vinum, 4.x 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: Mon, 20 Sep 2004 17:58:15 -0000 Hello - I've started using AoE devices with Vinum, but have hit a wall or two. Vinum starts in /etc/rc before the network is brought up. This basically means vinum can't be configured with the usual mechanism to use AoE devices. Any opinions on the best methods (set of env. variables) for kicking vinum after AoE is brought up? I'm thinking something like: aoe_iflist="fxp0" aoe_vinum_drives="/dev/aoed0 /dev/aoed1 /dev/aoed2 /dev/aoed3" After the network is brought up I'd: sysctl net.aoe.iflist="$aoe_iflist" vinum read "$aoe_vinum_drives" Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 18:41:53 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 67B2316A4F4 for ; Mon, 20 Sep 2004 18:41:53 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32A0043D2D for ; Mon, 20 Sep 2004 18:41:53 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21149 invoked from network); 20 Sep 2004 18:41:53 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 20 Sep 2004 18:41:52 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8KIfXOD024733; Mon, 20 Sep 2004 14:41:49 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Stephan Uphoff Date: Mon, 20 Sep 2004 14:42:04 -0400 User-Agent: KMail/1.6.2 References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <1095548914.43781.27.camel@palm.tree.com> In-Reply-To: <1095548914.43781.27.camel@palm.tree.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409201442.04525.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions 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: Mon, 20 Sep 2004 18:41:53 -0000 On Saturday 18 September 2004 07:08 pm, Stephan Uphoff wrote: > On Sat, 2004-09-18 at 16:53, John Baldwin wrote: > > On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > > > On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > > > > Stephan Uphoff wrote: > > > > >If this is true kernel threads can be preempted while holding > > > > >for example the root vnode lock (or other important kernel > > > > >resources) while not getting a chance to run until there are no more > > > > >user processes with better priority. > > > > > > > > This is also true, though it is a slightly more complicated thing > > > > than that. > > > > Preempting threads are usually interrupt threads and are thus usually > > > > short lived,. > > > > > > But interrupt threads often wake up other threads ... > > > > That are lower priority and thus won't be preempted to. Instead, they > > run when the interrupt thread goes back to sleep after it finishes. > > Lower priority than the interrupt threads. > They can however have a priority better than the interrupted thread > holding the kernel resource. > In this case the newly awoken threads will be next to run. > If they are compute bound in user space or wake other threads with > better priorities it might take a while until the system switches back > to the interrupted thread. Yes, but that is what the system is supposed to do. If you want the interrupted thread to run sooner because it holds a resource, then you need to adjust its priority when it holds the resource somehow. We do this with mutexes by having a blocking thread lend its priority to the owner of the mutex. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 20:12: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 F391716A4CF for ; Mon, 20 Sep 2004 20:11:59 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C51D243D5C for ; Mon, 20 Sep 2004 20:11:59 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30945 invoked from network); 20 Sep 2004 20:11:59 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 20 Sep 2004 20:11:58 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8KKBt4e025478; Mon, 20 Sep 2004 16:11:55 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Mon, 20 Sep 2004 14:46:15 -0400 User-Agent: KMail/1.6.2 References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> In-Reply-To: <414D30EC.1000104@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409201446.15278.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Julian Elischer cc: Stephan Uphoff Subject: Re: scheduler (sched_4bsd) questions 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: Mon, 20 Sep 2004 20:12:00 -0000 On Sunday 19 September 2004 03:10 am, Julian Elischer wrote: > John Baldwin wrote: > > On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > >>On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > >>>Stephan Uphoff wrote: > >>>>If this is true kernel threads can be preempted while holding > >>>>for example the root vnode lock (or other important kernel > >>>>resources) while not getting a chance to run until there are no more > >>>>user processes with better priority. > >>> > >>>This is also true, though it is a slightly more complicated thing than > >>>that. > >>>Preempting threads are usually interrupt threads and are thus usually > >>>short lived,. > >> > >>But interrupt threads often wake up other threads ... > > > > That are lower priority and thus won't be preempted to. Instead, they > > run when the interrupt thread goes back to sleep after it finishes. > > though that may still be before the original preempted thread gets run.. > > that reminds me.. > John, we should add a flag to setrunqueue to add a preempted thread back at > the FRONT of it's runqueue.. So that it gets a chance to use the rest of > its slot.. The scheduler can already detect this by noting that curthread is being passed to sched_add() when it has quantum left and then put it at the head of the queue for its priority but only with the remaining quanta. This only really works for schedulers that actually track quanta, i.e., not 4BSD. Given that, I think the scheduler is free to implement this how it chooses and doesn't require another flag to setrunqueue(). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 20:48:51 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 D154F16A4CE for ; Mon, 20 Sep 2004 20:48:51 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 6094943D1D for ; Mon, 20 Sep 2004 20:48:51 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 20815 invoked by uid 89); 20 Sep 2004 20:48:49 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 20 Sep 2004 20:48:49 -0000 Received: (qmail 20800 invoked by uid 89); 20 Sep 2004 20:48:49 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 20 Sep 2004 20:48:49 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8KKmlmt054175; Mon, 20 Sep 2004 16:48:47 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: John Baldwin In-Reply-To: <200409201442.04525.jhb@FreeBSD.org> References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <1095548914.43781.27.camel@palm.tree.com> <200409201442.04525.jhb@FreeBSD.org> Content-Type: text/plain Message-Id: <1095713326.53798.71.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 20 Sep 2004 16:48:47 -0400 Content-Transfer-Encoding: 7bit cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions 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: Mon, 20 Sep 2004 20:48:52 -0000 On Mon, 2004-09-20 at 14:42, John Baldwin wrote: > On Saturday 18 September 2004 07:08 pm, Stephan Uphoff wrote: > > On Sat, 2004-09-18 at 16:53, John Baldwin wrote: > > > On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > > > > On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > > > > > Stephan Uphoff wrote: > > > > > >If this is true kernel threads can be preempted while holding > > > > > >for example the root vnode lock (or other important kernel > > > > > >resources) while not getting a chance to run until there are no more > > > > > >user processes with better priority. > > > > > > > > > > This is also true, though it is a slightly more complicated thing > > > > > than that. > > > > > Preempting threads are usually interrupt threads and are thus usually > > > > > short lived,. > > > > > > > > But interrupt threads often wake up other threads ... > > > > > > That are lower priority and thus won't be preempted to. Instead, they > > > run when the interrupt thread goes back to sleep after it finishes. > > > > Lower priority than the interrupt threads. > > They can however have a priority better than the interrupted thread > > holding the kernel resource. > > In this case the newly awoken threads will be next to run. > > If they are compute bound in user space or wake other threads with > > better priorities it might take a while until the system switches back > > to the interrupted thread. > > Yes, but that is what the system is supposed to do. If you want the > interrupted thread to run sooner because it holds a resource, then you need > to adjust its priority when it holds the resource somehow. We do this with > mutexes by having a blocking thread lend its priority to the owner of the > mutex. Adjusting the priority based on resource ownership would be very difficult to implement. Something like: s = raise_priority(new_priority); ... hold and release kernel resource restore_priority(s); will not work as the acquisition/release of different resources overlap. ( Example vnode lock crabbing) The alternative would be tracking of the ownership of resources as in the mutex case. Unfortunately in the most cases this can not be done automatically and would require major efforts. (Verifying the code neighborhoods of all lockmgr(9), sema(9), condvar(9), sx(9), msleep(9) .. users) It would probably also bloat the code. A simple alternative would be to require that a threads priority is at least PRI_MAX_KERN (or better) while holding kernel resources. This could be accomplished my adjusting the priority on trap entries to the kernel before systemcalls,the page fault handling,... is done. ( And modifying uio_yield()) While this can not eliminate all priority inversions it would sharply reduce their duration. This is why I expected the priority adjustment on kernel entry and asked for help when I could not find it. Stephan From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 23:57:46 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 07B7416A4CE for ; Mon, 20 Sep 2004 23:57:46 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38FF743D46 for ; Mon, 20 Sep 2004 23:57:45 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 42741 invoked from network); 20 Sep 2004 23:52:02 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Sep 2004 23:52:02 -0000 Message-ID: <414F6E82.59E5A16@freebsd.org> Date: Tue, 21 Sep 2004 01:57:54 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John-Mark Gurney References: <20040906050435.GA72089@funkthat.com> <41408D4C.E33B6F98@freebsd.org> <20040918231719.GV72089@funkthat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: better MTU support... 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: Mon, 20 Sep 2004 23:57:46 -0000 John-Mark Gurney wrote: > > Andre Oppermann wrote this message on Thu, Sep 09, 2004 at 19:05 +0200: > > Ok, finally got a switch (and gige cards, if_re needs work) capable of > jumbo frames.. > > > John-Mark Gurney wrote: > > > In a recent experiment w/ Jumbo frames, I found out that sending ip > > > frames completely ignores the MTU set on host routes. This makes it > > > difficult (or next to impossible) to support a network that has both > > > regular and jumbo frames on it as you can't restrict some hosts to the > > > smaller frames. > > > > What you should do instead is to set the MTU on the interface to 9018 > > or so and then have a default route with MTU 1500 for everything else. > > Now you can specify larger MTUs for hosts that support it. > > > > Otherwise you are opening a can of worms... > > This doesn't fix it, since the output still doesn't honor the mtu on > the route.. Note, I'm not testing tcp, only udp and icmp since I've > seen that TCP already works fine... > # netstat -rnWfinet > Routing tables > > Internet: > Destination Gateway Flags Refs Use Mtu Netif Expire > default 192.168.0.14 UGS 0 11 1500 em0 > 127.0.0.1 127.0.0.1 UH 0 40 16384 lo0 > 192.168.0 link#5 UC 0 0 9000 em0 > 192.168.0.1 00:a0:c9:59:8b:6c UHLW 0 33 1500 em0 175 > 192.168.0.3 00:0a:95:9e:8b:88 UHLW 0 1988 9000 em0 374 > 192.168.0.14 00:a0:c9:31:30:5e UHLW 1 8 1500 em0 955 > 192.168.0.20 00:07:e9:0d:aa:ca UHLW 0 18 9000 em0 187 > 192.168.0.21 00:07:e9:0d:ad:06 UHLW 0 2 9000 lo0 > > tcpdump output: > 16:02:14.311079 IP 192.168.0.21 > 192.168.0.1: icmp 5008: echo request seq 14 > 16:02:15.320981 IP 192.168.0.21 > 192.168.0.1: icmp 5008: echo request seq 15 > 16:04:54.720890 IP 192.168.0.21 > 128.223.122.47: icmp 5008: echo request seq 0 > 16:04:55.727148 IP 192.168.0.21 > 128.223.122.47: icmp 5008: echo request seq 1 > 16:05:02.288989 IP 192.168.0.21 > 192.168.0.20: icmp 5008: echo request seq 0 > 16:05:02.289856 IP 192.168.0.20 > 192.168.0.21: icmp 5008: echo reply seq 0 > 16:05:03.296481 IP 192.168.0.21 > 192.168.0.20: icmp 5008: echo request seq 1 > 16:05:03.297282 IP 192.168.0.20 > 192.168.0.21: icmp 5008: echo reply seq 1 > > So, as you can see, it's broken... > > with my patch, ip properly fragments the packets to machines with > smaller mtu... > > > > I now have a patch to ip_output that makes it obay the MTU set on the > > > route instead of that of the interface. > > > > Your patch corrects a problem in ip_output where a smaller MTU on an > > rtentry was ignored but that is only for the non-TCP cases. When you > > open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu). > > If not it would be a bug. > > > > Could you try your large MTU setup again using the procedure I desribed > > above? > > > > That should solve your immediate problem. > > Nope, it doesn't... > > > For the general 'bug' in ip_output that it doesn't honour a smaller MTU > > on a route I'd like to do a more throughout fix. Routes should be > > created with MTU 0 if the MTU is not different from the if_mtu. Only > > in those cases where you want to have a lower MTU you set it. For cloned > > routes the MTU would be cloned from the parent. This range of changes is > > more intrusive. On top of that comes the new ARP code which will have a > > MTU field as well. This one is supposed to store different MTUs for mixed > > MTU L2 networks. How to transport the MTU information is a separate > > discussion. > > > > If the fix above works for you I'd like to do the real fix later (< end > > of year) and not change the current behaviour in ip_output at the moment. > > It wouldn't be hard to add to my patch the check to see if the route's > mtu is 0 and just use the if mtu... which then solves the ip part of > your more complete fix... Then when you finally fix the route/arp stuff > nothing else should be necessary... > > Sound good? Moving the check upwards as you have done in ip_output() works in your case but is not a real and clean fix. Ideally the routes should never have any MTU assigned to them unless someone explicitly sets it. So the MTU for the routes should always be zero and ignored. If it is zero then only the link MTU will be used. If there is an MTU on a route it should be observed not only for host routes (as you do in your patch) but also for network routes. Getting this right requires disabling the copying of the MTU when a route is cloned or created. We also have to check that all consumers of the MTU field in the kernel and userland can cope with zero MTU and these semantics (ignoring it). I'll get to doing that till end of the week. If get some of those earlier please send me the patches so we don't duplicate work. Then we have next week something ready to commit to 6-current. -- Andre From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 01:02:29 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 504CF16A4CE; Tue, 21 Sep 2004 01:02:29 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FC6B43D5C; Tue, 21 Sep 2004 01:02:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 3A2827A3E1; Mon, 20 Sep 2004 18:02:28 -0700 (PDT) Message-ID: <414F7DA3.6090409@elischer.org> Date: Mon, 20 Sep 2004 18:02:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> <200409201446.15278.jhb@FreeBSD.org> In-Reply-To: <200409201446.15278.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Stephan Uphoff cc: freebsd-arch@FreeBSD.org Subject: Re: scheduler (sched_4bsd) questions 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: Tue, 21 Sep 2004 01:02:29 -0000 > > >On Sunday 19 September 2004 03:10 am, Julian Elischer wrote: > > >>John Baldwin wrote: >> >> >>>On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: >>> >>> >>>>On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: >>>> >>>> >>>>>Stephan Uphoff wrote: >>>>> >>>>> >>>>>>If this is true kernel threads can be preempted while holding >>>>>>for example the root vnode lock (or other important kernel >>>>>>resources) while not getting a chance to run until there are no more >>>>>>user processes with better priority. >>>>>> >>>>>> >>>>>This is also true, though it is a slightly more complicated thing than >>>>>that. >>>>>Preempting threads are usually interrupt threads and are thus usually >>>>>short lived,. >>>>> >>>>> >>>>But interrupt threads often wake up other threads ... >>>> >>>> >>>That are lower priority and thus won't be preempted to. Instead, they >>>run when the interrupt thread goes back to sleep after it finishes. >>> >>> >>though that may still be before the original preempted thread gets run.. >> >>that reminds me.. >>John, we should add a flag to setrunqueue to add a preempted thread back at >>the FRONT of it's runqueue.. So that it gets a chance to use the rest of >>its slot.. >> >> > >The scheduler can already detect this by noting that curthread is being passed >to sched_add() when it has quantum left and then put it at the head of the >queue for its priority but only with the remaining quanta. This only really >works for schedulers that actually track quanta, i.e., not 4BSD. Given that, >I think the scheduler is free to implement this how it chooses and doesn't >require another flag to setrunqueue(). > Just for kicks I implemented this in my p4 branch to see if it would help the problem with atapi cdroms failing to work when premption is turned on.. but it didn't help.. (it's a very strange problem.. turning on preemption makes my test machine's cdrom time out so much in boot that it takes 5 minutes to probe during boot.) From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 10:02:25 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 D87CF16A4CE; Tue, 21 Sep 2004 10:02:25 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9051743D4C; Tue, 21 Sep 2004 10:02:25 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id B72AD653B5; Tue, 21 Sep 2004 11:02:24 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22905-02; Tue, 21 Sep 2004 11:02:24 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-65.dsl.snfc21.pacbell.net [67.121.95.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id A265E65213; Tue, 21 Sep 2004 11:02:23 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 0F3BA6455; Tue, 21 Sep 2004 03:02:20 -0700 (PDT) Date: Tue, 21 Sep 2004 03:02:20 -0700 From: Bruce M Simpson To: Max Laier Message-ID: <20040921100220.GC842@empiric.icir.org> Mail-Followup-To: Max Laier , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org, freebsd-net@freebsd.org References: <200409200250.49518.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <200409200250.49518.max@love2party.net> cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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: Tue, 21 Sep 2004 10:02:26 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > My question now is, what would be a good place to define this? Are there = any=20 > fromal standarts that might define it already? (Couldn't find anything) I= s=20 > there anything else that I must consider? I think Brooks' recommendation is sound and should probably be followed as it's fairly close to my original recommendation to you in private. The problem is that the definition of the union depends on what you wish to use it for, and which address families are visible to the application or kernel module which is using the definition. You may find that such a definition has to have conditionalized members. This is usually not a problem so long as they are all the same size. And a sockaddr union embedded in a struct probably should have a member with type 'struct sockaddr_storage' if it's to support all address families in future, although this commits more storage in the enclosing struct and may waste space in some cases. As you point out, you cannot do this in pf, as it defeats the intent of keeping larger members out of the table in the first place, and the union is there to make some casts go away. If it's any consolation, I'm going through very similar pain with XORP's new firewall manager right now with respect to address families (and templatized C++ classes). Regards, BMS --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBT/wsueUpAYYNtTsRAnCbAKCZrI2SsVz6q/Uu0loceoJREQc/zACggs6O e98ZL0h6Z/r8TWtUkJ8P+30= =buDH -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 10:08:04 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 4028316A4CF for ; Tue, 21 Sep 2004 10:08:04 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0EC143D41 for ; Tue, 21 Sep 2004 10:08:01 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id EE1FD65458; Tue, 21 Sep 2004 11:08:00 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23118-01; Tue, 21 Sep 2004 11:08:00 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-65.dsl.snfc21.pacbell.net [67.121.95.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 9D890651F4; Tue, 21 Sep 2004 11:07:56 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 762DD6455; Tue, 21 Sep 2004 03:07:52 -0700 (PDT) Date: Tue, 21 Sep 2004 03:07:51 -0700 From: Bruce M Simpson To: Poul-Henning Kamp Message-ID: <20040921100751.GD842@empiric.icir.org> References: <46041.1095665925@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46041.1095665925@critter.freebsd.dk> cc: arch@FreeBSD.org Subject: Re: [HEADSUP] naming of tty devices. 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: Tue, 21 Sep 2004 10:08:04 -0000 On Mon, Sep 20, 2004 at 09:38:45AM +0200, Poul-Henning Kamp wrote: > Other drivers have resorted to various variations of this scheme > (if they were copy&pasted from sio.c) or rolled their own private > naming system. In other words: it's a pretty mess right now. I've noticed the third-party software modem drivers in ports have this problem. I looked at what it would take if we were to rewrite them as uart(4) attachments and was pleasantly surprised to find it'd eliminate the reckless forking of sio(4). However, eliminating the naming inconsistency here can only be a good thing; if uart(4) can be kept in sync with these tty changes so much the better. Regards, BMS From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 10:14:38 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 0E3DC16A4CE for ; Tue, 21 Sep 2004 10:14:38 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61A6743D2D for ; Tue, 21 Sep 2004 10:14:37 +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 i8LAEZWg070627; Tue, 21 Sep 2004 12:14:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce M Simpson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 21 Sep 2004 03:07:51 PDT." <20040921100751.GD842@empiric.icir.org> Date: Tue, 21 Sep 2004 12:14:35 +0200 Message-ID: <70626.1095761675@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Tue, 21 Sep 2004 10:14:38 -0000 In message <20040921100751.GD842@empiric.icir.org>, Bruce M Simpson writes: >On Mon, Sep 20, 2004 at 09:38:45AM +0200, Poul-Henning Kamp wrote: >> Other drivers have resorted to various variations of this scheme >> (if they were copy&pasted from sio.c) or rolled their own private >> naming system. In other words: it's a pretty mess right now. > >I've noticed the third-party software modem drivers in ports have this >problem. I looked at what it would take if we were to rewrite them as >uart(4) attachments and was pleasantly surprised to find it'd eliminate >the reckless forking of sio(4). > >However, eliminating the naming inconsistency here can only be a good >thing; if uart(4) can be kept in sync with these tty changes so much >the better. uart is one of our tty drivers and as such it will be part of this. (That also means that uart drivers will get cua* and init/lock functionality). To some extent I'm not entirely sure that lumping anything uart finds into one name-category (ttyu*) makes sense, but that is a detail decision which can be looked at in the isolated context of uart later. -- 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 Tue Sep 21 10:42:43 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 250E116A4CE for ; Tue, 21 Sep 2004 10:42:43 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42B8943D49 for ; Tue, 21 Sep 2004 10:42:42 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.34) id 1C9iOa-0001Dj-30; Tue, 21 Sep 2004 18:01:16 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i8LAgmoI077808; Tue, 21 Sep 2004 17:42:48 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i8LAgkxK077724; Tue, 21 Sep 2004 17:42:46 +0700 (NOVST) (envelope-from danfe) Date: Tue, 21 Sep 2004 17:42:46 +0700 From: Alexey Dokuchaev To: Poul-Henning Kamp Message-ID: <20040921104246.GA75823@regency.nsu.ru> References: <46041.1095665925@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46041.1095665925@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i cc: arch@FreeBSD.org Subject: Re: [HEADSUP] naming of tty devices. 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: Tue, 21 Sep 2004 10:42:43 -0000 On Mon, Sep 20, 2004 at 09:38:45AM +0200, Poul-Henning Kamp wrote: > > My suggestion is the following: > > All drivers will offer "tty${something}" devices, and > generally ${something} will consist of a letter followed > by a number, possibly in base 36 ([0-9a-z]). > > All drivers which attach to external equipment via a serial > connector should also offer "cua${thesamething}". "Embedded" > serial ports, pseudo drivers etc, do not have to offer the > "cua" if DCD state on open is not an issue. > > The init and lock devices will be called ${base_device}.[init,lock] > and they will possibly be provided by on-demand devices so that > they do not clutter up /dev. What about contracting `.init|lock' to just `i|l', like we have with all (most) other device names out there (i.e., acd0t0, not acd0track0) -- long device names is a thing to avoid, IMHO. ./danfe From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 10:51:08 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 7E49416A4CE for ; Tue, 21 Sep 2004 10:51:08 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAAAB43D1F for ; Tue, 21 Sep 2004 10:51:07 +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 i8LAp4Wx042229; Tue, 21 Sep 2004 12:51:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alexey Dokuchaev From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 21 Sep 2004 17:42:46 +0700." <20040921104246.GA75823@regency.nsu.ru> Date: Tue, 21 Sep 2004 12:51:04 +0200 Message-ID: <42228.1095763864@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Tue, 21 Sep 2004 10:51:08 -0000 In message <20040921104246.GA75823@regency.nsu.ru>, Alexey Dokuchaev writes: >On Mon, Sep 20, 2004 at 09:38:45AM +0200, Poul-Henning Kamp wrote: >> >> My suggestion is the following: >> >> All drivers will offer "tty${something}" devices, and >> generally ${something} will consist of a letter followed >> by a number, possibly in base 36 ([0-9a-z]). >> >> All drivers which attach to external equipment via a serial >> connector should also offer "cua${thesamething}". "Embedded" >> serial ports, pseudo drivers etc, do not have to offer the >> "cua" if DCD state on open is not an issue. >> >> The init and lock devices will be called ${base_device}.[init,lock] >> and they will possibly be provided by on-demand devices so that >> they do not clutter up /dev. > >What about contracting `.init|lock' to just `i|l', like we have with all >(most) other device names out there (i.e., acd0t0, not acd0track0) -- long >device names is a thing to avoid, IMHO. The problem with just a 'i' or 'l' is that it creates confusion as to what is the device name and what is the extension. I like the concept of a big fat '.' in there to tell the extension apart. Shortening the extension from "init" to "i" and "lock" to "l" would be confusing at best, and of little real saving in practice. My plan is for the ".init" and ".lock" devices to be "on-demand", in other words, they won't show up until first time you try to access them. -- 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 Tue Sep 21 10:58:33 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 493A416A4CE for ; Tue, 21 Sep 2004 10:58:33 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B07B43D58 for ; Tue, 21 Sep 2004 10:58:32 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.34) id 1C9idx-0002Se-UO; Tue, 21 Sep 2004 18:17:09 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i8LAwfoI083254; Tue, 21 Sep 2004 17:58:41 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i8LAwdQ6083215; Tue, 21 Sep 2004 17:58:39 +0700 (NOVST) (envelope-from danfe) Date: Tue, 21 Sep 2004 17:58:39 +0700 From: Alexey Dokuchaev To: Poul-Henning Kamp Message-ID: <20040921105839.GA82522@regency.nsu.ru> References: <20040921104246.GA75823@regency.nsu.ru> <42228.1095763864@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42228.1095763864@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org Subject: Re: [HEADSUP] naming of tty devices. 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: Tue, 21 Sep 2004 10:58:33 -0000 On Tue, Sep 21, 2004 at 12:51:04PM +0200, Poul-Henning Kamp wrote: > In message <20040921104246.GA75823@regency.nsu.ru>, Alexey Dokuchaev writes: > >On Mon, Sep 20, 2004 at 09:38:45AM +0200, Poul-Henning Kamp wrote: > >> > >> My suggestion is the following: > >> > >> All drivers will offer "tty${something}" devices, and > >> generally ${something} will consist of a letter followed > >> by a number, possibly in base 36 ([0-9a-z]). > >> > >> All drivers which attach to external equipment via a serial > >> connector should also offer "cua${thesamething}". "Embedded" > >> serial ports, pseudo drivers etc, do not have to offer the > >> "cua" if DCD state on open is not an issue. > >> > >> The init and lock devices will be called ${base_device}.[init,lock] > >> and they will possibly be provided by on-demand devices so that > >> they do not clutter up /dev. > > > >What about contracting `.init|lock' to just `i|l', like we have with all > >(most) other device names out there (i.e., acd0t0, not acd0track0) -- long > >device names is a thing to avoid, IMHO. > > The problem with just a 'i' or 'l' is that it creates confusion as to > what is the device name and what is the extension. I like the concept > of a big fat '.' in there to tell the extension apart. Shortening the > extension from "init" to "i" and "lock" to "l" would be confusing at > best, and of little real saving in practice. > > My plan is for the ".init" and ".lock" devices to be "on-demand", in > other words, they won't show up until first time you try to access them. Sounds fair enough. Thanks! ./danfe From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 11:41:49 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 B335416A4CF for ; Tue, 21 Sep 2004 11:41:49 +0000 (GMT) Received: from srv01.sparkit.no (srv01.sparkit.no [193.69.116.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 172EF43D1F for ; Tue, 21 Sep 2004 11:41:49 +0000 (GMT) (envelope-from eivind@FreeBSD.org) Received: from ws.nada ([193.69.114.88]) by srv01.sparkit.no (8.12.11/8.12.11) with ESMTP id i8LBfhgK090878; Tue, 21 Sep 2004 13:41:43 +0200 (CEST) (envelope-from eivind@FreeBSD.org) Received: from ws.nada (localhost [127.0.0.1]) by ws.nada (8.12.9/8.12.10) with ESMTP id i8LBc372041929; Tue, 21 Sep 2004 11:38:03 GMT (envelope-from eivind@ws.nada) Received: (from eivind@localhost) by ws.nada (8.12.9/8.12.10/Submit) id i8LBc35P041928; Tue, 21 Sep 2004 11:38:03 GMT (envelope-from eivind) Date: Tue, 21 Sep 2004 11:38:03 +0000 From: Eivind Eklund To: Alexey Dokuchaev Message-ID: <20040921113802.GF27299@FreeBSD.org> References: <46041.1095665925@critter.freebsd.dk> <20040921104246.GA75823@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040921104246.GA75823@regency.nsu.ru> User-Agent: Mutt/1.5.4i cc: arch@FreeBSD.org Subject: Re: [HEADSUP] naming of tty devices. 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: Tue, 21 Sep 2004 11:41:49 -0000 On Tue, Sep 21, 2004 at 05:42:46PM +0700, Alexey Dokuchaev wrote: > What about contracting `.init|lock' to just `i|l', like we have with all > (most) other device names out there (i.e., acd0t0, not acd0track0) -- long > device names is a thing to avoid, IMHO. Please state a rationale for this. To me, long device names often means device names that tell me what is going on. And these days, EVERYBODY has a shell with filename completion - so one of the reasons for the initial choice of short names has gone. I don't think that names should be long for their own sake, but I think they should be intuitive "enough". Extra learning cost and recognition cost should only be taken if it has a specific benefit. Eivind. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 16:12:10 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 9A32916A4D1; Tue, 21 Sep 2004 16:12:10 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65E9343D1F; Tue, 21 Sep 2004 16:12:06 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8LGEKR4023672; Tue, 21 Sep 2004 09:14:21 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8LGEKi4023671; Tue, 21 Sep 2004 09:14:20 -0700 Date: Tue, 21 Sep 2004 09:14:20 -0700 From: Brooks Davis To: Max Laier , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org, freebsd-net@freebsd.org Message-ID: <20040921161420.GA17290@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> <20040921100220.GC842@empiric.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20040921100220.GC842@empiric.icir.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=3.0 required=8.0 tests=SUSPICIOUS_RECIPS autolearn=no version=2.63 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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: Tue, 21 Sep 2004 16:12:11 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2004 at 03:02:20AM -0700, Bruce M Simpson wrote: > On Mon, Sep 20, 2004 at 02:50:40AM +0200, Max Laier wrote: > > My question now is, what would be a good place to define this? Are ther= e any=20 > > fromal standarts that might define it already? (Couldn't find anything)= Is=20 > > there anything else that I must consider? >=20 > I think Brooks' recommendation is sound and should probably be followed > as it's fairly close to my original recommendation to you in private. >=20 > The problem is that the definition of the union depends on what you wish > to use it for, and which address families are visible to the application > or kernel module which is using the definition. The real problem may be that KAME mistakenly gave sockaddr_union a general name when it isn't and such a type would be hell to actually work with. A custom union that does exactly what pf needs may be the best approach. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUFNcXY6L6fI4GtQRAmqKAKDCDS6aW5tOLvwi5OE7cOny3qj6xgCfRBDr 0QaUauCEGn2Ij3DHL0SBPwg= =5V32 -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 17:09:29 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 0EA5416A4CE; Tue, 21 Sep 2004 17:09:29 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77B2043D3F; Tue, 21 Sep 2004 17:09:28 +0000 (GMT) (envelope-from ume@FreeBSD.org) Received: from lyrics.mahoroba.org (IDENT:9kBdVg6hWs9CTiaZ5lSoJ4DoJ3SyWu3oLpw0YErULbFeN7uGd/W9zJAlIDdVvliL@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)i8LH9CAr031165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2004 02:09:20 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Wed, 22 Sep 2004 02:09:11 +0900 Message-ID: From: Hajimu UMEMOTO To: Brooks Davis In-Reply-To: <20040921161420.GA17290@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> <20040921100220.GC842@empiric.icir.org> <20040921161420.GA17290@odin.ac.hmc.edu> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.3-BETA5 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cheer.mahoroba.org cc: Max Laier cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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: Tue, 21 Sep 2004 17:09:29 -0000 Hi, >>>>> On Tue, 21 Sep 2004 09:14:20 -0700 >>>>> Brooks Davis said: brooks> The real problem may be that KAME mistakenly gave sockaddr_union a brooks> general name when it isn't and such a type would be hell to actually brooks> work with. A custom union that does exactly what pf needs may be the brooks> best approach. I believe KAME doesn't use non standard struct such as sock_union. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 17:13:24 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 AE7CD16A4CE; Tue, 21 Sep 2004 17:13:24 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCDF43D31; Tue, 21 Sep 2004 17:13:24 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8LHFdOe031312; Tue, 21 Sep 2004 10:15:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8LHFd0h031311; Tue, 21 Sep 2004 10:15:39 -0700 Date: Tue, 21 Sep 2004 10:15:39 -0700 From: Brooks Davis To: Hajimu UMEMOTO Message-ID: <20040921171539.GA30996@odin.ac.hmc.edu> References: <200409200250.49518.max@love2party.net> <20040921100220.GC842@empiric.icir.org> <20040921161420.GA17290@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-net@FreeBSD.org cc: freebsd-arch@FreeBSD.org cc: freebsd-hackers@FreeBSD.org cc: Max Laier cc: freebsd-standards@FreeBSD.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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: Tue, 21 Sep 2004 17:13:24 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 22, 2004 at 02:09:11AM +0900, Hajimu UMEMOTO wrote: > Hi, >=20 > >>>>> On Tue, 21 Sep 2004 09:14:20 -0700 > >>>>> Brooks Davis said: >=20 > brooks> The real problem may be that KAME mistakenly gave sockaddr_union a > brooks> general name when it isn't and such a type would be hell to actua= lly > brooks> work with. A custom union that does exactly what pf needs may be= the > brooks> best approach. >=20 > I believe KAME doesn't use non standard struct such as sock_union. Oops, you are correct, it's part of fastipsec, not KAME. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUGG7XY6L6fI4GtQRAmuhAJ9RmMTuSRuAs9YIhRNJ55xq0k1KgwCfY/y3 zqiSVO6mzuxWu2C7MB4GKi8= =lDSM -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 17:41: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 9062516A4CF for ; Tue, 21 Sep 2004 17:41:11 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 1367B43D3F for ; Tue, 21 Sep 2004 17:41:11 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 12993 invoked by uid 89); 21 Sep 2004 17:41:10 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 21 Sep 2004 17:41:10 -0000 Received: (qmail 12970 invoked by uid 89); 21 Sep 2004 17:41:09 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 21 Sep 2004 17:41:09 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8LHf8mt059050; Tue, 21 Sep 2004 13:41:09 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <414F7DA3.6090409@elischer.org> References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> <200409201446.15278.jhb@FreeBSD.org> <414F7DA3.6090409@elischer.org> Content-Type: text/plain Message-Id: <1095788468.53798.92.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 21 Sep 2004 13:41:08 -0400 Content-Transfer-Encoding: 7bit cc: John Baldwin cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions 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: Tue, 21 Sep 2004 17:41:11 -0000 On Mon, 2004-09-20 at 21:02, Julian Elischer wrote: > > > > > >On Sunday 19 September 2004 03:10 am, Julian Elischer wrote: > > > > > >>John Baldwin wrote: > >> > >> > >>>On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote: > >>> > >>> > >>>>On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > >>>> > >>>> > >>>>>Stephan Uphoff wrote: > >>>>> > >>>>> > >>>>>>If this is true kernel threads can be preempted while holding > >>>>>>for example the root vnode lock (or other important kernel > >>>>>>resources) while not getting a chance to run until there are no more > >>>>>>user processes with better priority. > >>>>>> > >>>>>> > >>>>>This is also true, though it is a slightly more complicated thing than > >>>>>that. > >>>>>Preempting threads are usually interrupt threads and are thus usually > >>>>>short lived,. > >>>>> > >>>>> > >>>>But interrupt threads often wake up other threads ... > >>>> > >>>> > >>>That are lower priority and thus won't be preempted to. Instead, they > >>>run when the interrupt thread goes back to sleep after it finishes. > >>> > >>> > >>though that may still be before the original preempted thread gets run.. > >> > >>that reminds me.. > >>John, we should add a flag to setrunqueue to add a preempted thread back at > >>the FRONT of it's runqueue.. So that it gets a chance to use the rest of > >>its slot.. > >> > >> > > > >The scheduler can already detect this by noting that curthread is being passed > >to sched_add() when it has quantum left and then put it at the head of the > >queue for its priority but only with the remaining quanta. This only really > >works for schedulers that actually track quanta, i.e., not 4BSD. Given that, > >I think the scheduler is free to implement this how it chooses and doesn't > >require another flag to setrunqueue(). > > > > Just for kicks I implemented this in my p4 branch to see if it would help the problem > with atapi cdroms failing to work when premption is turned on.. > > but it didn't help.. > > (it's a very strange problem.. turning on preemption makes my test machine's cdrom > time out so much in boot that it takes 5 minutes to probe during boot.) Great news ! - I actually switched target machines just when this started to happen and thought the cdrom of the new target was bad and disconnected it ;-) I reconnected it this morning and did a little debugging. Looks like an interrupt race condition in the ata code. Can you try the following patch? Stephan Index: sys/dev/ata/ata-lowlevel.c =================================================================== RCS file: /cvsroot/src/sys/dev/ata/ata-lowlevel.c,v retrieving revision 1.47 diff -u -r1.47 ata-lowlevel.c --- sys/dev/ata/ata-lowlevel.c 3 Sep 2004 12:10:44 -0000 1.47 +++ sys/dev/ata/ata-lowlevel.c 21 Sep 2004 17:36:27 -0000 @@ -88,11 +88,15 @@ (ATA_R_ATAPI | ATA_R_DMA | ATA_R_WRITE))) request->flags &= ~ATA_R_DMA; + ch->running = request; + switch (request->flags & (ATA_R_ATAPI | ATA_R_DMA)) { /* ATA PIO data transfer and control commands */ default: { + + /* record command direction here as our request might be gone later */ int write = (request->flags & ATA_R_WRITE); @@ -136,7 +140,7 @@ } /* record the request as running and return for interrupt */ - ch->running = request; + // ch->running = request; return ATA_OP_CONTINUES; /* ATA DMA data transfer commands */ @@ -167,7 +171,7 @@ } /* record the request as running and return for interrupt */ - ch->running = request; + //ch->running = request; return ATA_OP_CONTINUES; /* ATAPI PIO commands */ @@ -192,7 +196,7 @@ /* command interrupt device ? just return and wait for interrupt */ if ((request->device->param->config & ATA_DRQ_MASK) == ATA_DRQ_INTR) { - ch->running = request; + // ch->running = request; return ATA_OP_CONTINUES; } @@ -226,7 +230,7 @@ ATA_PROTO_ATAPI_12 ? 6 : 8); /* record the request as running and return for interrupt */ - ch->running = request; + //ch->running = request; return ATA_OP_CONTINUES; case ATA_R_ATAPI|ATA_R_DMA: @@ -292,9 +296,11 @@ } /* record the request as running and return for interrupt */ - ch->running = request; + // ch->running = request; return ATA_OP_CONTINUES; } + + ch->running = NULL; /* request finish here */ if (ch->dma && ch->dma->flags & ATA_DMA_LOADED) From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 19:15:06 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 C62BE16A4CE; Tue, 21 Sep 2004 19:15:06 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A43C243D2D; Tue, 21 Sep 2004 19:15:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id CB4E97A3D2; Tue, 21 Sep 2004 12:15:05 -0700 (PDT) Message-ID: <41507DB9.4030007@elischer.org> Date: Tue, 21 Sep 2004 12:15:05 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Stephan Uphoff References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> <200409201446.15278.jhb@FreeBSD.org> <414F7DA3.6090409@elischer.org> <1095788468.53798.92.camel@palm.tree.com> In-Reply-To: <1095788468.53798.92.camel@palm.tree.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: sos@freebsd.org cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions 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: Tue, 21 Sep 2004 19:15:06 -0000 > > >Great news ! - I actually switched target machines just when this >started to happen and thought the cdrom of the new target was bad and >disconnected it ;-) > >I reconnected it this morning and did a little debugging. >Looks like an interrupt race condition in the ata code. >Can you try the following patch? > awsome! ---------------- ad0: 9541MB [19386/16/63] at ata0-master UDMA100 ATAPI_RESET time = 50us acd0: CDROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s1a ------------------ notice there is still a single reset message, that doesn't appear without PREEMPTION but now boots take less than 5 minutes :-) From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 19:19:30 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 CB4E616A4CE; Tue, 21 Sep 2004 19:19:30 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A91A743D1F; Tue, 21 Sep 2004 19:19:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 4E22E7A3D2; Tue, 21 Sep 2004 12:19:30 -0700 (PDT) Message-ID: <41507EC2.8030805@elischer.org> Date: Tue, 21 Sep 2004 12:19:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Julian Elischer References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> <200409201446.15278.jhb@FreeBSD.org> <414F7DA3.6090409@elischer.org> <1095788468.53798.92.camel@palm.tree.com> <41507DB9.4030007@elischer.org> In-Reply-To: <41507DB9.4030007@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" cc: sos@freebsd.org cc: Stephan Uphoff Subject: Re: scheduler (sched_4bsd) questions 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: Tue, 21 Sep 2004 19:19:30 -0000 Julian Elischer wrote: >> >> >> Great news ! - I actually switched target machines just when this >> started to happen and thought the cdrom of the new target was bad and >> disconnected it ;-) >> >> I reconnected it this morning and did a little debugging. >> Looks like an interrupt race condition in the ata code. >> Can you try the following patch? >> > > awsome! > ---------------- > ad0: 9541MB [19386/16/63] at ata0-master UDMA100 > ATAPI_RESET time = 50us > acd0: CDROM at ata1-master PIO4 > Mounting root from ufs:/dev/ad0s1a > ------------------ > > notice there is still a single reset message, that doesn't appear > without PREEMPTION > but now boots take less than 5 minutes :-) I stand corrected.. the message does appear with no preemption. (I was certain that it didn't but.. I can't argue with my eyes..) > > > > > _______________________________________________ > 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 Tue Sep 21 19:33:45 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 53BA816A4CE for ; Tue, 21 Sep 2004 19:33:45 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5A7443D1D for ; Tue, 21 Sep 2004 19:33:42 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8LKXIfw001832 for ; Tue, 21 Sep 2004 15:33:18 -0500 Date: Tue, 21 Sep 2004 15:33:18 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: AoE for 4.x 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: Tue, 21 Sep 2004 19:33:45 -0000 I'd like to get my changes and driver to support AoE into the 4.x kernel. Can I get a willing committer? Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 19:40:50 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 AB8C216A4CF for ; Tue, 21 Sep 2004 19:40:50 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1225843D49 for ; Tue, 21 Sep 2004 19:40:50 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 49496 invoked from network); 21 Sep 2004 19:34:58 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Sep 2004 19:34:58 -0000 Message-ID: <415083CC.7C041DFD@freebsd.org> Date: Tue, 21 Sep 2004 21:41:00 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 19:40:50 -0000 Sam wrote: > > I'd like to get my changes and driver to support AoE into the > 4.x kernel. Can I get a willing committer? Do you have a tar somewhere so we can have a look at it? -- Andre From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 19:44:41 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 027B216A4CE; Tue, 21 Sep 2004 19:44:41 +0000 (GMT) Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id C44F143D31; Tue, 21 Sep 2004 19:44:40 +0000 (GMT) (envelope-from tedu@stanford.edu) Received: from elaine31.Stanford.EDU (elaine31.Stanford.EDU [171.64.15.106]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i8LJib3m020455; Tue, 21 Sep 2004 12:44:37 -0700 Date: Tue, 21 Sep 2004 12:44:36 -0700 (PDT) From: Ted Unangst To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-arch@freebsd.org Subject: Re: diff(1) 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: Tue, 21 Sep 2004 19:44:41 -0000 On Fri, 17 Sep 2004, Dag-Erling Sm=F8rgrav wrote: > I don't know how much they've changed it, but I do know that it still > uses whichever regexp engine you happen to have in libc. In our case, nothing earth-shaking changed. it avoids regex for simple patterns which places it roughly in the same speed bracket as gnu grep. (depends on how many megabytes you're grepping if you'll notice a difference). plus an assortment of flags and corner cases which pop up when you make it system default and lots of people start using it. --=20 From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 19:45:38 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 B3E6316A4CE; Tue, 21 Sep 2004 19:45:38 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A47E43D5D; Tue, 21 Sep 2004 19:45:38 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8LKjE7o001923; Tue, 21 Sep 2004 15:45:14 -0500 Date: Tue, 21 Sep 2004 15:45:14 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Andre Oppermann In-Reply-To: <415083CC.7C041DFD@freebsd.org> Message-ID: References: <415083CC.7C041DFD@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 19:45:38 -0000 Well, part of finding a committer was for me to ask what you'd want to see and how you want to see it. I have changes to: /usr/src/sys/net/ethernet.h /usr/src/sys/net/if_ethersubr.c /usr/src/sys/net/netisr.h /dev/MAKEDEV /etc/rc /etc/defaults/rc.conf and have created (and populated) /usr/src/sys/dev/aoe/ /usr/src/sys/modules/aoe/ So ... a tar of the source and a diff -u patch of all the changes? Sam On Tue, 21 Sep 2004, Andre Oppermann wrote: > Sam wrote: >> >> I'd like to get my changes and driver to support AoE into the >> 4.x kernel. Can I get a willing committer? > > Do you have a tar somewhere so we can have a look at it? > > -- > Andre > _______________________________________________ > 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 Tue Sep 21 19:59: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 F268F16A4CE; Tue, 21 Sep 2004 19:59:35 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD7FC43D48; Tue, 21 Sep 2004 19:59:35 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id B5EAF7A3E1; Tue, 21 Sep 2004 12:59:35 -0700 (PDT) Message-ID: <41508827.8010007@elischer.org> Date: Tue, 21 Sep 2004 12:59:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Sam References: <415083CC.7C041DFD@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 19:59:36 -0000 Sam wrote: > Well, part of finding a committer was for me to ask what you'd > want to see and how you want to see it. I have changes to: > > /usr/src/sys/net/ethernet.h > /usr/src/sys/net/if_ethersubr.c > /usr/src/sys/net/netisr.h > /dev/MAKEDEV > /etc/rc > /etc/defaults/rc.conf > > and have created (and populated) > > /usr/src/sys/dev/aoe/ > /usr/src/sys/modules/aoe/ > > So ... a tar of the source and a diff -u patch of all the changes? the really best way t do this is to use cvsup to mirror teh cvs tree to somewhere you have locally.. then check out a 4.x tree from that. edit it, and then ask it to produce a diff for you. If you do it right it will make a single diff that includes the new files.. it will also allow you to merge in changes as they come in from FreeBSD, and regenerate current diff sets. I'm sure you mentionned this before, but why ar eyou not doing it against -current first? We generally don't allow changes to 4.x untill they have settled a bit in -current. (or 5.x) > > > Sam > > On Tue, 21 Sep 2004, Andre Oppermann wrote: > >> Sam wrote: >> >>> >>> I'd like to get my changes and driver to support AoE into the >>> 4.x kernel. Can I get a willing committer? >> >> >> Do you have a tar somewhere so we can have a look at it? >> >> -- >> Andre >> _______________________________________________ >> 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 Tue Sep 21 20:11:16 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 44AD516A4CE; Tue, 21 Sep 2004 20:11:16 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id D653943D4C; Tue, 21 Sep 2004 20:11:15 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8LLAh6e002079; Tue, 21 Sep 2004 16:10:43 -0500 Date: Tue, 21 Sep 2004 16:10:43 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Julian Elischer In-Reply-To: <41508827.8010007@elischer.org> Message-ID: References: <415083CC.7C041DFD@freebsd.org><41508827.8010007@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 20:11:16 -0000 > I'm sure you mentionned this before, but why ar eyou not doing it against > -current first? > > We generally don't allow changes to 4.x untill they have settled a bit in > -current. (or 5.x) I decided to write a 4.x driver thinking it would a) be easier to port forward than backward, and b) would give me experience in the old kernel to understand why certain changes were made for the new. [Thompson's Rule for First-Time Telescope Makers] It is faster to make a four-inch mirror and then a six-inch mirror than to make a six-inch mirror. As for the single patch, I'll cook one up shortly. I just figured it would be more of a pain to look through. Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 20:15: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 B28EA16A4CE; Tue, 21 Sep 2004 20:15:35 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8643743D2F; Tue, 21 Sep 2004 20:15:35 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8LKHper030565; Tue, 21 Sep 2004 13:17:51 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8LKHpXe030564; Tue, 21 Sep 2004 13:17:51 -0700 Date: Tue, 21 Sep 2004 13:17:51 -0700 From: Brooks Davis To: Julian Elischer Message-ID: <20040921201751.GA28852@odin.ac.hmc.edu> References: <415083CC.7C041DFD@freebsd.org> <41508827.8010007@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <41508827.8010007@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Sam cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 20:15:35 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 21, 2004 at 12:59:35PM -0700, Julian Elischer wrote: >=20 > I'm sure you mentionned this before, but why ar eyou not doing it=20 > against -current first? >=20 > We generally don't allow changes to 4.x untill they have settled a bit=20 > in -current. (or 5.x) We also specifically do not allow new functionality in branches other then current without a VERY good reason[0]. This is to avoid losing the functionality in later releases which annoys the users. -- Brooks [0] For example, we might allow a 80386 only feature (if such a thing existed) to be implemented in 5-STABLE without going in to 6-CURRENT since there would be no point in adding it to a branch without 80386 support. --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUIxuXY6L6fI4GtQRAmYkAJ4tlolUCuA/O6fWiekNLtEpN1M9CQCfQkA0 PbLm8p4bdXgg88RcSzu14U0= =dQhY -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 20:32:43 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 B9D8C16A4CE; Tue, 21 Sep 2004 20:32:43 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BB7F43D1F; Tue, 21 Sep 2004 20:32:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 7EEC27A3E1; Tue, 21 Sep 2004 13:32:43 -0700 (PDT) Message-ID: <41508FEB.6030203@elischer.org> Date: Tue, 21 Sep 2004 13:32:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Sam References: <415083CC.7C041DFD@freebsd.org> <41508827.8010007@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 20:32:43 -0000 Sam wrote: >> I'm sure you mentionned this before, but why ar eyou not doing it >> against -current first? >> >> We generally don't allow changes to 4.x untill they have settled a >> bit in -current. (or 5.x) > > > I decided to write a 4.x driver thinking it would a) be easier to port > forward than backward, and b) would give me experience in the old kernel > to understand why certain changes were made for the new. > > [Thompson's Rule for First-Time Telescope Makers] > It is faster to make a four-inch mirror and then a six-inch mirror than > to make a six-inch mirror. hmmmm it might be the other way around here... > > > As for the single patch, I'll cook one up shortly. I just figured it > would be more of a pain to look through. I guess we are used to it. I can't recommend enough the utility of having a cvs mirror and using cvs to keep your work trees sync'd against FreeBSD. It is also a goodd way of making sure that you don't forget parts of the diff (e.g. Makefiles etc.) as CVS will pick up all the changed files. > > > Cheers, > > Sam From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 21:04:01 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 A8FE216A4CF for ; Tue, 21 Sep 2004 21:04:01 +0000 (GMT) Received: from mail.ambrisko.com (adsl-64-174-51-43.dsl.snfc21.pacbell.net [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C06643D53 for ; Tue, 21 Sep 2004 21:04:01 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) (192.168.1.2) by mail.ambrisko.com with ESMTP; 21 Sep 2004 14:03:59 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.9p2/8.12.9) with ESMTP id i8LL3xkT051822; Tue, 21 Sep 2004 14:03:59 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.9p2/8.12.9/Submit) id i8LL3xOW051821; Tue, 21 Sep 2004 14:03:59 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200409212103.i8LL3xOW051821@ambrisko.com> In-Reply-To: To: Sam Date: Tue, 21 Sep 2004 14:03:59 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 21:04:01 -0000 Sam writes: | Well, part of finding a committer was for me to ask what you'd | want to see and how you want to see it. I have changes to: | | /usr/src/sys/net/ethernet.h | /usr/src/sys/net/if_ethersubr.c | /usr/src/sys/net/netisr.h | /dev/MAKEDEV | /etc/rc | /etc/defaults/rc.conf | | and have created (and populated) | | /usr/src/sys/dev/aoe/ | /usr/src/sys/modules/aoe/ | | So ... a tar of the source and a diff -u patch of all the changes? You can do a diff -upr --newfile of all of that. Then it is one big patch that can be applied via patch -p0 This makes it trivial for other people to apply it. You can all do this via: cvs diff -up --newfile if you are working in a CVS tree like Julian suggests. Doug A. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 22:26:42 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 EE8DA16A4CE; Tue, 21 Sep 2004 22:26:42 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E19643D39; Tue, 21 Sep 2004 22:26:42 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8LNQASQ002989; Tue, 21 Sep 2004 18:26:10 -0500 Date: Tue, 21 Sep 2004 18:26:10 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Julian Elischer In-Reply-To: <41508FEB.6030203@elischer.org> Message-ID: References: <415083CC.7C041DFD@freebsd.org><41508827.8010007@elischer.org> <41508FEB.6030203@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 22:26:43 -0000 > Sam wrote: > >>> I'm sure you mentionned this before, but why ar eyou not doing it against >>> -current first? >>> >>> We generally don't allow changes to 4.x untill they have settled a bit in >>> -current. (or 5.x) >> >> >> I decided to write a 4.x driver thinking it would a) be easier to port >> forward than backward, and b) would give me experience in the old kernel >> to understand why certain changes were made for the new. >> >> [Thompson's Rule for First-Time Telescope Makers] >> It is faster to make a four-inch mirror and then a six-inch mirror than >> to make a six-inch mirror. > > > hmmmm it might be the other way around here... > >> >> >> As for the single patch, I'll cook one up shortly. I just figured it >> would be more of a pain to look through. > > > I guess we are used to it. > > I can't recommend enough the utility of having a cvs mirror and using cvs to > keep your > work trees sync'd against FreeBSD. It is also a goodd way of making sure that > you don't > forget parts of the diff (e.g. Makefiles etc.) as CVS will pick up all the > changed files. > And I can't thank you enough. I forgot about a few other (rather) important file changes this picked up. A patchfile for aoe against today's 4.10 source tree is at: http://www.coraid.com/support/freebsd/aoe.patch A few notes: The file sys/dev/aoe/aoe4bsd.dd is basic documentation for the driver. All references to chr major 200 will have to be changed to whatever gets assigned, obviously. The netisr selected in sys/net/netisr.h was picked at random. Is it OK? The label typeunknown in sys/net/if_ethersubr.c is added to give netgraph a chance to get the packets if AoE is not loaded. Appropriate? I dinna know how to fill out the copyright/license comment in the headers, but i gave it a shot. Thoughts here would be appreciated. TIA to all the curious eyes that skim the driver for glaring flaws. Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 22:50:40 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 AB12916A4CE; Tue, 21 Sep 2004 22:50:40 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8068643D53; Tue, 21 Sep 2004 22:50:40 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 6356D7A3E1; Tue, 21 Sep 2004 15:50:40 -0700 (PDT) Message-ID: <4150B03F.4070207@elischer.org> Date: Tue, 21 Sep 2004 15:50:39 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Sam References: <415083CC.7C041DFD@freebsd.org> <41508827.8010007@elischer.org> <41508FEB.6030203@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 22:50:41 -0000 Sam wrote: >> >> >> I guess we are used to it. >> >> I can't recommend enough the utility of having a cvs mirror and using >> cvs to keep your >> work trees sync'd against FreeBSD. It is also a goodd way of making >> sure that you don't >> forget parts of the diff (e.g. Makefiles etc.) as CVS will pick up >> all the changed files. >> > > And I can't thank you enough. I forgot about a few other (rather) > important file changes this picked up. > > A patchfile for aoe against today's 4.10 source tree > is at: > http://www.coraid.com/support/freebsd/aoe.patch > > A few notes: > > The file sys/dev/aoe/aoe4bsd.dd is basic documentation for > the driver. > > All references to chr major 200 will have to be changed to whatever > gets assigned, obviously. > > The netisr selected in sys/net/netisr.h was picked at random. Is it > OK? > > The label typeunknown in sys/net/if_ethersubr.c is added to give > netgraph a chance to get the packets if AoE is not loaded. Appropriate? > > I dinna know how to fill out the copyright/license comment in the > headers, > but i gave it a shot. Thoughts here would be appreciated. > > TIA to all the curious eyes that skim the driver for glaring flaws. haven't read it yet, just skimmed.. Very CLEAN looking code.. style(9) complient to a large extent.. (you do know about 'man 9 style' right?) now that it is written, this is the time to go through it and write down everything that comes to mind in comments.. Everything that a person trying to decode the driver might want to know. Including comments about the standards, tricky bits of code, reasons you decided to do things in certain ways. etc. > > > Cheers, > > Sam From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 23:22:33 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 0C0FF16A4CE; Tue, 21 Sep 2004 23:22:33 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF71943D2D; Tue, 21 Sep 2004 23:22:32 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8M0LxE4003290; Tue, 21 Sep 2004 19:21:59 -0500 Date: Tue, 21 Sep 2004 19:21:59 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Julian Elischer In-Reply-To: <4150B03F.4070207@elischer.org> Message-ID: References: <415083CC.7C041DFD@freebsd.org><41508827.8010007@elischer.org> <41508FEB.6030203@elischer.org><4150B03F.4070207@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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: Tue, 21 Sep 2004 23:22:33 -0000 > Sam wrote: > >>> >>> >>> I guess we are used to it. >>> >>> I can't recommend enough the utility of having a cvs mirror and using cvs >>> to keep your >>> work trees sync'd against FreeBSD. It is also a goodd way of making sure >>> that you don't >>> forget parts of the diff (e.g. Makefiles etc.) as CVS will pick up all the >>> changed files. >>> >> >> And I can't thank you enough. I forgot about a few other (rather) >> important file changes this picked up. >> >> A patchfile for aoe against today's 4.10 source tree >> is at: >> http://www.coraid.com/support/freebsd/aoe.patch >> >> A few notes: >> >> The file sys/dev/aoe/aoe4bsd.dd is basic documentation for >> the driver. >> >> All references to chr major 200 will have to be changed to whatever >> gets assigned, obviously. >> >> The netisr selected in sys/net/netisr.h was picked at random. Is it >> OK? >> >> The label typeunknown in sys/net/if_ethersubr.c is added to give >> netgraph a chance to get the packets if AoE is not loaded. Appropriate? >> >> I dinna know how to fill out the copyright/license comment in the headers, >> but i gave it a shot. Thoughts here would be appreciated. >> >> TIA to all the curious eyes that skim the driver for glaring flaws. > > haven't read it yet, just skimmed.. > > Very CLEAN looking code.. style(9) complient to a large extent.. > (you do know about 'man 9 style' right?) Thanks - I didn't, but I do now. :) > now that it is written, this is the time to > go through it and write down everything that comes to mind in comments.. > Everything that a person trying to decode the driver might want to know. > Including comments about the standards, tricky bits of code, > reasons you decided to do things in certain ways. etc. I tend towards the side that says you write a short paper about a chunk of code as comments can (and do) get out of sync. When in Rome, though ... I'll have to digest the style page a little more to see what types of comments are requested. I'm choking a bit on some of the other requirements. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Sep 22 03:40:14 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 CE2DE16A4CE; Wed, 22 Sep 2004 03:40:14 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6377F43D31; Wed, 22 Sep 2004 03:40:14 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8M4deCY004775; Tue, 21 Sep 2004 23:39:40 -0500 Date: Tue, 21 Sep 2004 23:39:40 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Julian Elischer In-Reply-To: Message-ID: References: <415083CC.7C041DFD@freebsd.org><41508827.8010007@elischer.org> <41508FEB.6030203@elischer.org><4150B03F.4070207@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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, 22 Sep 2004 03:40:14 -0000 I once said: > I'll have to digest the style page a little more to see what > types of comments are requested. I'm choking a bit on some > of the other requirements. but discovered in style(9): New core kernel code should be reasonably compliant with the style guides. The guidelines for third-party maintained modules and device drivers are more relaxed but at a minimum should be internally consistent with their style. I like "reasonably compliant." Lots of wriggle room. ;) Sam From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 00:15:20 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 6643B16A4CF; Thu, 23 Sep 2004 00:15:07 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C60443D49; Thu, 23 Sep 2004 00:15:07 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CAHGM-0004lG-00; Thu, 23 Sep 2004 02:15:06 +0200 Received: from [217.83.8.169] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CAHGM-0007dJ-00; Thu, 23 Sep 2004 02:15:06 +0200 From: Max Laier To: freebsd-arch@freebsd.org Date: Thu, 23 Sep 2004 02:14:00 +0200 User-Agent: KMail/1.7 References: <200409200250.49518.max@love2party.net> In-Reply-To: <200409200250.49518.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2497037.U2RBP6rdQP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409230214.08477.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-hackers@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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, 23 Sep 2004 00:15:20 -0000 --nextPart2497037.U2RBP6rdQP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 20 September 2004 02:50, Max Laier wrote: > Hi, > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/71836 is the symptom. N= ow I > am looking for a clean solution to it. What is needed is an include file > that defines union sockaddr_union in a way that is useable from kernel and > userland. Historically it seems that this union first apeared in context = of > ipsec within the kernel. pf has adopted it, but uses it in the userland as > well. I am sure that it can be usefull in a lot of places that have to de= al > with/store different address formats. > > My question now is, what would be a good place to define this? Are there > any fromal standarts that might define it already? (Couldn't find anythin= g) > Is there anything else that I must consider? > > At some point I though netinet/in.h might be a good place, but that'd > require inclusion of sys/socket.h, which certainly is not a good solution. > > Opinions? Ideas? As no real solution has come up and we couldn't agree what to do with it=20 either, I'll resort to an easy hack:=20 http://people.freebsd.org/~mlaier/sockaddr_union.fix.diff This will fix the issue and not create new problems. With the small excepti= on=20 for userland programs that try to include before=20 and make use of sockaddr_union. Those programs do not exist,= =20 however, and have been broken before. Any objections? [ I know it's ugly already. ] =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 --nextPart2497037.U2RBP6rdQP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBUhVQXyyEoT62BG0RAoYnAJ9SzMK7ZPV3NYZ36DYJlj53KFNqjgCfQ2YO J3R7FE7EG21pdyvCi0DM6aA= =I8lU -----END PGP SIGNATURE----- --nextPart2497037.U2RBP6rdQP-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 02:01:19 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 D7AE216A548 for ; Thu, 23 Sep 2004 02:01:19 +0000 (GMT) Received: from smtp14.singnet.com.sg (smtp14.singnet.com.sg [165.21.6.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3663F43D39 for ; Thu, 23 Sep 2004 02:01:19 +0000 (GMT) (envelope-from mikecck@singnet.com.sg) Received: from Thinkpad (bb220-255-76-92.singnet.com.sg [220.255.76.92]) by smtp14.singnet.com.sg (8.13.1/8.13.1) with ESMTP id i8N218wn004200 for ; Thu, 23 Sep 2004 10:01:18 +0800 Message-Id: <200409230201.i8N218wn004200@smtp14.singnet.com.sg> From: "Mike Chan" To: Date: Thu, 23 Sep 2004 10:01:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcShETUAeFod1jdSTPWvc8FZroNFJg== Subject: Survey on Open Source 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, 23 Sep 2004 02:01:20 -0000 Dear all, I am conducting a survey on open source software. This is for my academic coursework and dissertation. It will be great to have your support and participation in this survey. This survey has two separate questionnaires, focusing on the following areas: 1) OSS development (Developers or those who contribute in coding or documentation), and 2) IT/IS costs (CIOs or IT Managers). You are free to go for the questionnaire that is appropriate for you. Below are the links: 1) Brief introduction page: http://web.singnet.com.sg/~mikecck/opensource/Introduction1.htm 2) Questionnaire 1(Open Source Development): http://web.singnet.com.sg/~mikecck/opensource/WebFormA1.htm 3) Questionnaire 2(Open Source and IT/IS Cost): http://web.singnet.com.sg/~mikecck/opensource/WebFormB1.htm Thank you for your time. Mike Chan Student Curtin University of Technology From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 06:19:46 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 B094B16A4CE; Thu, 23 Sep 2004 06:19:46 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B62E43D2F; Thu, 23 Sep 2004 06:19:46 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 63E04651F7; Thu, 23 Sep 2004 07:19:44 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 56232-03; Thu, 23 Sep 2004 07:19:43 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-185-240.dsl.snfc21.pacbell.net [64.171.185.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 49AA5651F4; Thu, 23 Sep 2004 07:19:43 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 4E70F63D3; Wed, 22 Sep 2004 23:19:40 -0700 (PDT) Date: Wed, 22 Sep 2004 23:19:40 -0700 From: Bruce M Simpson To: Max Laier Message-ID: <20040923061940.GA870@empiric.icir.org> Mail-Followup-To: Max Laier , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-standards@freebsd.org, freebsd-net@freebsd.org References: <200409200250.49518.max@love2party.net> <200409230214.08477.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <200409230214.08477.max@love2party.net> cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Global (non _KERNEL) place for sockaddr_union? 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, 23 Sep 2004 06:19:46 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings earthmen, On Thu, Sep 23, 2004 at 02:14:00AM +0200, Max Laier wrote: > As no real solution has come up and we couldn't agree what to do with it= =20 > either, I'll resort to an easy hack:=20 > http://people.freebsd.org/~mlaier/sockaddr_union.fix.diff =2E.. > Any objections? [ I know it's ugly already. ] Looks fine to me; I agree that this workaround is not ideal but it is acceptable given the circumstances. Regards, BMS --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBUmr7ueUpAYYNtTsRAk91AJ4/PL+dXh5v+8ne91fS0n/RGtZlkgCfavC8 I38NJmMOCN9m0ZgiR8+uQX8= =mtHb -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 14:07:19 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 6759F16A4CF for ; Thu, 23 Sep 2004 14:07:19 +0000 (GMT) Received: from mailserv1.neuroflux.com (mailserv1.neuroflux.com [204.228.228.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E88543D5A for ; Thu, 23 Sep 2004 14:07:19 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 34754 invoked by uid 89); 23 Sep 2004 14:14:01 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 23 Sep 2004 14:14:01 -0000 Received: from 208.4.77.15 (SquirrelMail authenticated user ryans@gamersimpact.com) by www2.neuroflux.com with HTTP; Thu, 23 Sep 2004 08:14:01 -0600 (MDT) Message-ID: <61632.208.4.77.15.1095948841.squirrel@www2.neuroflux.com> Date: Thu, 23 Sep 2004 08:14:01 -0600 (MDT) From: "Ryan Sommers" To: arch@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: Non-GNU Sort 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, 23 Sep 2004 14:07:19 -0000 Is anyone, or does anyone know of anyone, working on a non-GNU licensed version of sort? I'm going to try and devote some of my free time to beginning this project and I'd rather not reinvent the wheel if anyone has already gotten started. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 14:17:30 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 68D2416A4CE for ; Thu, 23 Sep 2004 14:17:30 +0000 (GMT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 064C043D1F for ; Thu, 23 Sep 2004 14:17:30 +0000 (GMT) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.34) id 1CAUi0-0005za-Tu; Thu, 23 Sep 2004 21:36:32 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.10/8.12.10) with ESMTP id i8NEHkoI044502; Thu, 23 Sep 2004 21:17:46 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.10/8.12.10/Submit) id i8NEHkYY044440; Thu, 23 Sep 2004 21:17:46 +0700 (NOVST) (envelope-from danfe) Date: Thu, 23 Sep 2004 21:17:46 +0700 From: Alexey Dokuchaev To: Ryan Sommers Message-ID: <20040923141745.GA42205@regency.nsu.ru> References: <61632.208.4.77.15.1095948841.squirrel@www2.neuroflux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61632.208.4.77.15.1095948841.squirrel@www2.neuroflux.com> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org Subject: Re: Non-GNU Sort 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, 23 Sep 2004 14:17:30 -0000 On Thu, Sep 23, 2004 at 08:14:01AM -0600, Ryan Sommers wrote: > Is anyone, or does anyone know of anyone, working on a non-GNU licensed > version of sort? I'm going to try and devote some of my free time to > beginning this project and I'd rather not reinvent the wheel if anyone has > already gotten started. I think that NetBSD have BSD-licensed sort(1), but it seems we went on with GNU for some reason(s). I suspect multibyte character support is one of them, probably performance also. I believe ache@ and/or tjr@ are the right persons to contact WRT this. ./danfe From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 14:26: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 6AA1F16A4CE for ; Thu, 23 Sep 2004 14:26:17 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05DD043D46 for ; Thu, 23 Sep 2004 14:26:17 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id C6E4438EE; Thu, 23 Sep 2004 16:26:57 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 0DFCAB873; Thu, 23 Sep 2004 16:26:16 +0200 (CEST) To: "Ryan Sommers" References: <61632.208.4.77.15.1095948841.squirrel@www2.neuroflux.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 23 Sep 2004 16:26:15 +0200 In-Reply-To: <61632.208.4.77.15.1095948841.squirrel@www2.neuroflux.com> (Ryan Sommers's message of "Thu, 23 Sep 2004 08:14:01 -0600 (MDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: arch@freebsd.org Subject: Re: Non-GNU Sort 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, 23 Sep 2004 14:26:17 -0000 "Ryan Sommers" writes: > Is anyone, or does anyone know of anyone, working on a non-GNU licensed > version of sort? I'm going to try and devote some of my free time to > beginning this project and I'd rather not reinvent the wheel if anyone has > already gotten started. des@dwp ~/projects/openbsd/src/usr.bin/sort% egrep 'GNU|GPL' *.c || echo no= pe nope DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 14:52: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 40FCF16A4CE; Thu, 23 Sep 2004 14:52:39 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id A60C443D55; Thu, 23 Sep 2004 14:52:38 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8NFpxtX020317; Thu, 23 Sep 2004 10:52:00 -0500 Date: Thu, 23 Sep 2004 10:51:59 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Julian Elischer In-Reply-To: <41508FEB.6030203@elischer.org> Message-ID: References: <415083CC.7C041DFD@freebsd.org><41508827.8010007@elischer.org> <41508FEB.6030203@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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, 23 Sep 2004 14:52:39 -0000 >>> I'm sure you mentionned this before, but why ar eyou not doing it against >>> -current first? >>> >>> We generally don't allow changes to 4.x untill they have settled a bit in >>> -current. (or 5.x) I'm about to update the coraid web site announcing support for freebsd 4.x and would like to at least get a major number assigned so customers don't start running the patch with major 200. Is this possible in advance of incorporation into the kernel? I'm hoping to have a 5.x driver ready in the next month or two, probably patched against 5.3-stable when it's ready. Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 15:11:34 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 5711D16A4CE for ; Thu, 23 Sep 2004 15:11:34 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 069CF43D45 for ; Thu, 23 Sep 2004 15:11:34 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 4AA09ACAFE; Thu, 23 Sep 2004 17:11:32 +0200 (CEST) Date: Thu, 23 Sep 2004 17:11:32 +0200 From: Pawel Jakub Dawidek To: freebsd-arch@freebsd.org Message-ID: <20040923151132.GA9550@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Subject: CTASSERT(9). 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, 23 Sep 2004 15:11:34 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. It would be quite cool to have CTASSERT() also in userland. Are there any problems that I'm missing? If no, where can we move it? To sys/param.h? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBUuekForvXbEpPzQRAu0oAJ9IOCC0C1GolwoQ9XkK45leHs/LAwCgylKf cX+Iy7pD5c1LBqXl2AUT1Yw= =wKc7 -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 19:18:20 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 F21A716A4CE for ; Thu, 23 Sep 2004 19:18:20 +0000 (GMT) Received: from srv01.sparkit.no (srv01.sparkit.no [193.69.116.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E50243D53 for ; Thu, 23 Sep 2004 19:18:20 +0000 (GMT) (envelope-from eivind@FreeBSD.org) Received: from ws.nada ([193.69.114.88]) by srv01.sparkit.no (8.12.11/8.12.11) with ESMTP id i8NJICnE001098; Thu, 23 Sep 2004 21:18:12 +0200 (CEST) (envelope-from eivind@FreeBSD.org) Received: from ws.nada (localhost [127.0.0.1]) by ws.nada (8.12.9/8.12.10) with ESMTP id i8NJEQ72067037; Thu, 23 Sep 2004 19:14:26 GMT (envelope-from eivind@ws.nada) Received: (from eivind@localhost) by ws.nada (8.12.9/8.12.10/Submit) id i8NJEOmS067036; Thu, 23 Sep 2004 19:14:24 GMT (envelope-from eivind) Date: Thu, 23 Sep 2004 19:14:24 +0000 From: Eivind Eklund To: Sam Message-ID: <20040923191423.GE61631@FreeBSD.org> References: <41508FEB.6030203@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@FreeBSD.org Subject: Re: AoE for 4.x 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, 23 Sep 2004 19:18:21 -0000 On Thu, Sep 23, 2004 at 10:51:59AM -0500, Sam wrote: > I'm hoping to have a 5.x driver ready in the next month or two, > probably patched against 5.3-stable when it's ready. Drivers go into the system in the order -current -stable This is basically the order we ALWAYS force, to avoid people doing development on older branches and a continual loss of functionality. This means that you (or somebody else) will need to port it to -current before it can go into 5.3-stable. Eivind. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 19:20:34 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 4A02716A4CE; Thu, 23 Sep 2004 19:20:34 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07FAD43D4C; Thu, 23 Sep 2004 19:20:34 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8NJNCcd004484; Thu, 23 Sep 2004 12:23:12 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8NJNCJD004477; Thu, 23 Sep 2004 12:23:12 -0700 Date: Thu, 23 Sep 2004 12:23:12 -0700 From: Brooks Davis To: Sam Message-ID: <20040923192312.GI25699@odin.ac.hmc.edu> References: <41508FEB.6030203@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0XMZdl/q8hSSmFeD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Andre Oppermann cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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, 23 Sep 2004 19:20:34 -0000 --0XMZdl/q8hSSmFeD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 23, 2004 at 10:51:59AM -0500, Sam wrote: > >>>I'm sure you mentionned this before, but why ar eyou not doing it=20 > >>>against -current first? > >>> > >>>We generally don't allow changes to 4.x untill they have settled a bit= =20 > >>>in -current. (or 5.x) >=20 > I'm about to update the coraid web site announcing support > for freebsd 4.x and would like to at least get a major number > assigned so customers don't start running the patch with > major 200. Is this possible in advance of incorporation into > the kernel? I'd suggest asking re@freebsd.org about this. It seems fairly reasionable to me. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --0XMZdl/q8hSSmFeD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBUyKfXY6L6fI4GtQRAo+vAKCYfrk73E9hhCSAB3b3yx6J2UuZ6wCg0FSu C9wMbPoBq9GNOBrJQNncbVw= =/5UX -----END PGP SIGNATURE----- --0XMZdl/q8hSSmFeD-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 20:04:29 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 9859516A4CE; Thu, 23 Sep 2004 20:04:29 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52F9C43D41; Thu, 23 Sep 2004 20:04:29 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8NL3wfw022203; Thu, 23 Sep 2004 16:03:58 -0500 Date: Thu, 23 Sep 2004 16:03:58 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Eivind Eklund In-Reply-To: <20040923191423.GE61631@FreeBSD.org> Message-ID: References: <41508FEB.6030203@elischer.org><20040923191423.GE61631@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@FreeBSD.org Subject: Re: AoE for 4.x 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, 23 Sep 2004 20:04:29 -0000 >> I'm hoping to have a 5.x driver ready in the next month or two, >> probably patched against 5.3-stable when it's ready. > > Drivers go into the system in the order > -current > -stable > > This is basically the order we ALWAYS force, to avoid people doing > development on older branches and a continual loss of functionality. > > This means that you (or somebody else) will need to port it to -current > before it can go into 5.3-stable. The flip side of this argument is that I can't reasonably ask customers to pull up -current sources to use a storage product. They've got to be able to rely on it and I've got to be able to manage the service calls. Eventually I'll have patches against a -stable that's close enough to a -current that the patch will apply to both. I'm hoping 5.3 will be this way. This isn't news to me; I got the same thing from the linux folks. Sam From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 20:18:42 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 0107C16A4CE; Thu, 23 Sep 2004 20:18:42 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B07343D3F; Thu, 23 Sep 2004 20:18:41 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id CD1207A403; Thu, 23 Sep 2004 13:18:40 -0700 (PDT) Message-ID: <41532FA0.6030405@elischer.org> Date: Thu, 23 Sep 2004 13:18:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Sam References: <41508FEB.6030203@elischer.org><20040923191423.GE61631@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: re@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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, 23 Sep 2004 20:18:42 -0000 I think that if you have a working driver we can assign you a number. I do have some questions however.. this is AoE.. is it not possible at all to combne it with either the CAM framework (such as the atapicam stuff) or the existing ATA stuff.. Don't take this the wrong way.. it's just a question.. CAM is being used to talk to drives over firewire, usb, ata, scsi, fibrechannel. it would seem that to unify this would be something that we should look at.. Of course CAM itslef is showing its age in soem places and it could do with some work itself.. Sam wrote: >>> I'm hoping to have a 5.x driver ready in the next month or two, >>> probably patched against 5.3-stable when it's ready. >> >> >> Drivers go into the system in the order >> -current >> -stable >> >> This is basically the order we ALWAYS force, to avoid people doing >> development on older branches and a continual loss of functionality. >> >> This means that you (or somebody else) will need to port it to -current >> before it can go into 5.3-stable. > > > The flip side of this argument is that I can't reasonably > ask customers to pull up -current sources to use a storage > product. They've got to be able to rely on it and I've got > to be able to manage the service calls. > > Eventually I'll have patches against a -stable that's close enough > to a -current that the patch will apply to both. I'm hoping 5.3 > will be this way. > > This isn't news to me; I got the same thing from the linux folks. > > Sam > _______________________________________________ > 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 Thu Sep 23 20:36:52 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 69F3416A4CE for ; Thu, 23 Sep 2004 20:36:52 +0000 (GMT) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15A0943D54 for ; Thu, 23 Sep 2004 20:36:52 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.216.98) by smtp02.syd.iprimus.net.au (7.0.031.3) id 4148EDE50032DEF6; Fri, 24 Sep 2004 06:36:50 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 414E24251; Fri, 24 Sep 2004 06:37:59 +1000 (EST) Date: Fri, 24 Sep 2004 06:37:59 +1000 From: Tim Robbins To: Ryan Sommers Message-ID: <20040923203759.GA32833@cat.robbins.dropbear.id.au> References: <61632.208.4.77.15.1095948841.squirrel@www2.neuroflux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61632.208.4.77.15.1095948841.squirrel@www2.neuroflux.com> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org Subject: Re: Non-GNU Sort 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, 23 Sep 2004 20:36:52 -0000 On Thu, Sep 23, 2004 at 08:14:01AM -0600, Ryan Sommers wrote: > Is anyone, or does anyone know of anyone, working on a non-GNU licensed > version of sort? I'm going to try and devote some of my free time to > beginning this project and I'd rather not reinvent the wheel if anyone has > already gotten started. I've written a working replacement for GNU sort that I've mentioned on hackers@ a few times: http://lists.freebsd.org/pipermail/freebsd-hackers/2003-September/003126.html (the .tar.gz URL is broken -- I'll roll another tarball & upload it later tonight). I'll commit it to CURRENT after I add multibyte character support. Tim From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 21:14:09 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 90E0B16A4CE; Thu, 23 Sep 2004 21:14:09 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43A0343D53; Thu, 23 Sep 2004 21:14:09 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8NMDTAc022627; Thu, 23 Sep 2004 17:13:29 -0500 Date: Thu, 23 Sep 2004 17:13:29 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Julian Elischer In-Reply-To: <41532FA0.6030405@elischer.org> Message-ID: References: <41508FEB.6030203@elischer.org><20040923191423.GE61631@FreeBSD.org> <41532FA0.6030405@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: re@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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, 23 Sep 2004 21:14:09 -0000 On Thu, 23 Sep 2004, Julian Elischer wrote: > I think that if you have a working driver we can assign you a number. > I do have some questions however.. > > this is AoE.. is it not possible at all to combne it with either the CAM > framework (such as the atapicam stuff) or the existing ATA stuff.. > Don't take this the wrong way.. it's just a question.. > CAM is being used to talk to drives over firewire, usb, ata, scsi, > fibrechannel. > it would seem that to unify this would be something that we should look at.. > Of course CAM itslef is showing its age in soem places and it could do with > some work itself.. It might be possible to plug into the CAM; I only briefly glanced at it and it didn't appear appropriate. The ATA layer definitely isn't as parts of ATA don't make sense in this context (Read DMA, Read Multiple, eg) and AoE devices don't conform to the simple hardware probe/attach methodology (as I understand it). I would love to be proved wrong. I'm always willing to try a new approach if it's demonstrably better. Sam From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 21:20:14 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 BCD0216A4CE; Thu, 23 Sep 2004 21:20:14 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6522243D31; Thu, 23 Sep 2004 21:20:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id BB9367A403; Thu, 23 Sep 2004 14:20:13 -0700 (PDT) Message-ID: <41533E0D.9000908@elischer.org> Date: Thu, 23 Sep 2004 14:20:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Sam References: <41508FEB.6030203@elischer.org><20040923191423.GE61631@FreeBSD.org> <41532FA0.6030405@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: re@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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, 23 Sep 2004 21:20:14 -0000 you could look at the sbp driver that is part of the firewire code.. I think that may be the closest analog. Sam wrote: > On Thu, 23 Sep 2004, Julian Elischer wrote: > >> I think that if you have a working driver we can assign you a number. >> I do have some questions however.. >> >> this is AoE.. is it not possible at all to combne it with either the CAM >> framework (such as the atapicam stuff) or the existing ATA stuff.. >> Don't take this the wrong way.. it's just a question.. >> CAM is being used to talk to drives over firewire, usb, ata, scsi, >> fibrechannel. >> it would seem that to unify this would be something that we should >> look at.. >> Of course CAM itslef is showing its age in soem places and it could >> do with some work itself.. > > > It might be possible to plug into the CAM; I only briefly > glanced at it and it didn't appear appropriate. The ATA > layer definitely isn't as parts of ATA don't make sense > in this context (Read DMA, Read Multiple, eg) and AoE > devices don't conform to the simple hardware probe/attach > methodology (as I understand it). > > I would love to be proved wrong. I'm always willing to > try a new approach if it's demonstrably better. > > Sam From owner-freebsd-arch@FreeBSD.ORG Thu Sep 23 21:51:53 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 E2FBB16A4CE for ; Thu, 23 Sep 2004 21:51:53 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 496AB43D45 for ; Thu, 23 Sep 2004 21:51:53 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 9036 invoked by uid 89); 23 Sep 2004 21:51:52 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 23 Sep 2004 21:51:52 -0000 Received: (qmail 9013 invoked by uid 89); 23 Sep 2004 21:51:51 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 23 Sep 2004 21:51:51 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8NLpnmt074069; Thu, 23 Sep 2004 17:51:50 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <41533E0D.9000908@elischer.org> References: <41508FEB.6030203@elischer.org><20040923191423.GE61631@FreeBSD.org> <41532FA0.6030405@elischer.org><41533E0D.9000908@elischer.org> Content-Type: text/plain Message-Id: <1095976309.53798.8390.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 23 Sep 2004 17:51:49 -0400 Content-Transfer-Encoding: 7bit cc: Sam cc: re@freebsd.org cc: "freebsd-arch@freebsd.org" Subject: Re: AoE for 4.x 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, 23 Sep 2004 21:51:54 -0000 Since a complete disk operation in AoE is encapsulated in a single Ethernet request/response pair - The data size of a read/write operation is smaller than a single page. I don't think any existing framework can deal with this efficiently. Stephan On Thu, 2004-09-23 at 17:20, Julian Elischer wrote: > you could look at the sbp driver that is part of the firewire code.. > I think that may be the closest analog. > > > Sam wrote: > > > On Thu, 23 Sep 2004, Julian Elischer wrote: > > > >> I think that if you have a working driver we can assign you a number. > >> I do have some questions however.. > >> > >> this is AoE.. is it not possible at all to combne it with either the CAM > >> framework (such as the atapicam stuff) or the existing ATA stuff.. > >> Don't take this the wrong way.. it's just a question.. > >> CAM is being used to talk to drives over firewire, usb, ata, scsi, > >> fibrechannel. > >> it would seem that to unify this would be something that we should > >> look at.. > >> Of course CAM itslef is showing its age in soem places and it could > >> do with some work itself.. > > > > > > It might be possible to plug into the CAM; I only briefly > > glanced at it and it didn't appear appropriate. The ATA > > layer definitely isn't as parts of ATA don't make sense > > in this context (Read DMA, Read Multiple, eg) and AoE > > devices don't conform to the simple hardware probe/attach > > methodology (as I understand it). > > > > I would love to be proved wrong. I'm always willing to > > try a new approach if it's demonstrably better. > > > > Sam > > > _______________________________________________ > 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 Fri Sep 24 09:01:08 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 CB1AB16A4CF for ; Fri, 24 Sep 2004 09:01:08 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1614643D53 for ; Fri, 24 Sep 2004 09:01:08 +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 i8O9158C041459 for ; Fri, 24 Sep 2004 11:01:06 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: "Poul-Henning Kamp" Date: Fri, 24 Sep 2004 11:01:05 +0200 Message-ID: <41458.1096016465@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: I'm counting my threads, one, two, three, four, five... [1] 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, 24 Sep 2004 09:01:08 -0000 I've completed my sweep of the kernel and I belive that we now have a reliable count of the number of threads currently inside any particular cdev and consequently, with a bit of adding up, also for each cdevsw. There are two soft spots marked with XXX (devfs_rule and vm_mmap) and one big hack, snp(4). The next step is to add a new method to the cdevsw which purges threads from the driver. The best name I can come up with is d_evict(). The drivers should make this function wakeup(9) on anything a thread could be sleeping on for the relevant cdev and the tread on waking up should examine whatever bits it can, realize the hw/driver/whatever is gone and exit the driver with ENXIO error return. If this cdevsw method is present, destroy_dev() will use it and will sleep until all threads have cleared out. So for a typical driver things will look like this: foo_evict(struct cdev *dev) { struct foo_sc *sc; /* XXX: NB: no locks, only wakeups */ sc = dev->si_drv1; wakeup(sc->bing); wakeup(sc->bongle); wakeup(sc->bang); } foo_detach(dev) { ... sc->flags |= GONE; destroy_dev(sc->cdev); /* XXX: we now know there are no threads involved with this cdev */ ... } destroy_dev() will work more or less this way: ... dev_lock(); csw = cdev->si_devsw; cdev->si_devsw = NULL while (csw->d_evict != NULL && cdev->si_threacount > 0) { (csw->d_evict)(cdev); msleep(&dev_lock, ..., hz/10); } dev_unlock(); ... I will also add a convenience function called destroy_cdevsw() which will call destroy_dev() on all cdevs using the cdevsw in question. I belive this gives us the handle we need to unload drivers and remove hardware without panicing in the lower layers of the kernel. The higher layers may still have a thing or two to learn in this respect. Poul-Henning [1] It used to be possible to legally download the D:A:D tune which inspired the subject, but I can't find the link anymore, sorry :-( -- 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 Fri Sep 24 10:27:01 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 A237A16A4CE for ; Fri, 24 Sep 2004 10:27:01 +0000 (GMT) Received: from srv01.sparkit.no (srv01.sparkit.no [193.69.116.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06F2643D4C for ; Fri, 24 Sep 2004 10:27:01 +0000 (GMT) (envelope-from eivind@FreeBSD.org) Received: from ws.nada ([193.69.114.88]) by srv01.sparkit.no (8.12.11/8.12.11) with ESMTP id i8OAQsa5026117; Fri, 24 Sep 2004 12:26:54 +0200 (CEST) (envelope-from eivind@FreeBSD.org) Received: from ws.nada (localhost [127.0.0.1]) by ws.nada (8.12.9/8.12.10) with ESMTP id i8OAN572067776; Fri, 24 Sep 2004 10:23:05 GMT (envelope-from eivind@ws.nada) Received: (from eivind@localhost) by ws.nada (8.12.9/8.12.10/Submit) id i8OAN5uA067775; Fri, 24 Sep 2004 10:23:05 GMT (envelope-from eivind) Date: Fri, 24 Sep 2004 10:23:04 +0000 From: Eivind Eklund To: Sam Message-ID: <20040924102303.GF61631@FreeBSD.org> References: <41508FEB.6030203@elischer.org> <20040923191423.GE61631@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@FreeBSD.org Subject: Re: AoE for 4.x 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, 24 Sep 2004 10:27:01 -0000 On Thu, Sep 23, 2004 at 04:03:58PM -0500, Sam wrote: > >>I'm hoping to have a 5.x driver ready in the next month or two, > >>probably patched against 5.3-stable when it's ready. > > > >Drivers go into the system in the order > >-current > >-stable > > > >This is basically the order we ALWAYS force, to avoid people doing > >development on older branches and a continual loss of functionality. > > > >This means that you (or somebody else) will need to port it to -current > >before it can go into 5.3-stable. > > The flip side of this argument is that I can't reasonably > ask customers to pull up -current sources to use a storage > product. They've got to be able to rely on it and I've got > to be able to manage the service calls. Of course. This isn't the flip side, though - it's a argument about something completely different. The way this usually goes is that (A) Somebody develop a driver for whatever branch they can easily do so on - either -current or -stable. (A.2) Port it to -current if it was not developed there (C) Get it committed to -current (D) Let it sit in -current for a while, fixing any bugs that may turn up (D.2) Port the driver to -stable if it was not developed there (if it was developed there, the person just provide the patches for that branch with the bugs found since commit fixed) (D) Commit it into the relevant -stable branch Often, for author-maintained drivers, the driver over time gets some ifdefs etc added to make it possible to use the essentially same sources on both the -stable and -current branch. But the commit to -current is always done before -stable, because FreeBSD (as a vendor) will not allow the backwards slippage that WOULD happen if we did not strictly enforce this. > Eventually I'll have patches against a -stable that's close enough > to a -current that the patch will apply to both. I'm hoping 5.3 > will be this way. You will probably never have a better chance than 5.3. My guess is that the next -stable branching (6.x-stable) will be at least two years in the future, and 5.4+-stable will be much further diverged from 6.0-current than 5.3-stable will be. Please take this as friendly information; we have policies that we have to follow to keep the quality of FreeBSD high, and unfortunately these have to add some extra hardship for authors :-( Eivind. From owner-freebsd-arch@FreeBSD.ORG Fri Sep 24 17:39:45 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 D677816A4CE; Fri, 24 Sep 2004 17:39:45 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5B0843D2F; Fri, 24 Sep 2004 17:39:45 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8OHgaJm029191; Fri, 24 Sep 2004 10:42:36 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8OHga7m029190; Fri, 24 Sep 2004 10:42:36 -0700 Date: Fri, 24 Sep 2004 10:42:36 -0700 From: Brooks Davis To: Eivind Eklund Message-ID: <20040924174236.GC6672@odin.ac.hmc.edu> References: <41508FEB.6030203@elischer.org> <20040923191423.GE61631@FreeBSD.org> <20040924102303.GF61631@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline In-Reply-To: <20040924102303.GF61631@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Sam cc: freebsd-arch@freebsd.org Subject: Re: AoE for 4.x 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, 24 Sep 2004 17:39:46 -0000 --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 24, 2004 at 10:23:04AM +0000, Eivind Eklund wrote: > But the commit to -current is always done before -stable, because > FreeBSD (as a vendor) will not allow the backwards slippage that WOULD > happen if we did not strictly enforce this. s/WOULD happen if/HAS happened when/ For instance the NFS code was split into client and server portions in 2.x but not in 3.x and those changes were lost. Peter did it all over again in 5.x. -- Brooks > > Eventually I'll have patches against a -stable that's close enough > > to a -current that the patch will apply to both. I'm hoping 5.3 > > will be this way. >=20 > You will probably never have a better chance than 5.3. My guess is that > the next -stable branching (6.x-stable) will be at least two years in > the future, and 5.4+-stable will be much further diverged from > 6.0-current than 5.3-stable will be. >=20 > Please take this as friendly information; we have policies that we have > to follow to keep the quality of FreeBSD high, and unfortunately these > have to add some extra hardship for authors :-( >=20 > Eivind. > _______________________________________________ > 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 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBVFyLXY6L6fI4GtQRAngmAKC+f1X/Zd/OkKB8o2TiMaoo3yLQewCfd0go m4tsQhY2hFctwRgfvx3yTVE= =IcQk -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 25 17:29: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 D8D2916A4CE for ; Sat, 25 Sep 2004 17:29:17 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B56A43D3F for ; Sat, 25 Sep 2004 17:29:17 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 27735 invoked by uid 89); 25 Sep 2004 17:29:15 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 25 Sep 2004 17:29:15 -0000 Received: (qmail 27700 invoked by uid 89); 25 Sep 2004 17:29:15 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 25 Sep 2004 17:29:15 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8PHTEmt093562; Sat, 25 Sep 2004 13:29:14 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: "freebsd-arch@freebsd.org" Content-Type: multipart/mixed; boundary="=-Z7rROyI9E4Q5Yr8GPP56" Message-Id: <1096133353.53798.17613.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 25 Sep 2004 13:29:14 -0400 cc: Julian Elischer Subject: sched_userret priority adjustment patch for sched_4bsd 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, 25 Sep 2004 17:29:18 -0000 --=-Z7rROyI9E4Q5Yr8GPP56 Content-Type: text/plain Content-Transfer-Encoding: 7bit When a thread is about to return to user space it resets its priority to the user level priority. However after lowering the permission its priority it needs to check if its priority is still better than all other runable threads. This is currently not implemented. Without the check the thread can block kernel or user threads with better priority until a switch is forced by by an interrupt. The attached patch checks the relevant runqueues and threads without slots in the same ksegrp and forces a thread switch if the currently running thread is no longer the best thread to run after it changed its priority. The patch should improve interactive response under heavy load somewhat. It needs a lot of testing. Stephan --=-Z7rROyI9E4Q5Yr8GPP56 Content-Disposition: attachment; filename=sched_userret_patch Content-Type: text/x-patch; name=sched_userret_patch; charset=ASCII Content-Transfer-Encoding: 7bit Index: sched_4bsd.c =================================================================== RCS file: /cvsroot/src/sys/kern/sched_4bsd.c,v retrieving revision 1.65 diff -u -r1.65 sched_4bsd.c --- sched_4bsd.c 16 Sep 2004 07:12:59 -0000 1.65 +++ sched_4bsd.c 25 Sep 2004 15:28:58 -0000 @@ -1102,10 +1102,64 @@ return (ke); } + +/* + * Find if a better (lower numeric priority) non-empty queue then indicated by + * queue_pri exists. This is done by scanning the status bits, a set bit + * indicates a non-empty queue. + */ +static __inline int +runq_better_priority_exists(struct runq *rq,int queue_pri) +{ + struct rqbits *rqb; + int i; + int word_index; + rqb_word_t mask; + + word_index = RQB_WORD(queue_pri); + + rqb = &rq->rq_status; + for (i = 0; i < word_index ; i++) + if (rqb->rqb_bits[i]) + return 1; + + /* XXXX Need a machine macro for this ? */ + mask = (RQB_BIT(queue_pri) - 1); + + if (rqb->rqb_bits[word_index] & mask) + return 1; + + return 0; +} + +static __inline int +sched_should_giveup_slot(struct thread *td) +{ + struct ksegrp *kg; + struct thread *td2; + + kg = td->td_ksegrp; + td2 = kg->kg_last_assigned; + if (td2 != NULL) { + td2 = TAILQ_NEXT(td2, td_runq); + } else { + td2 = TAILQ_FIRST(&kg->kg_runq); + } + + if (td2 != NULL && td2->td_priority < td->td_priority) { + /* There is a runable thread in the ksegrp without a slot + * and its priority is better than the current thread. + */ + return 1; + } + return 0; +} + void sched_userret(struct thread *td) { - struct ksegrp *kg; + int queue_pri; + struct ksegrp *kg; /* * XXX we cheat slightly on the locking here to avoid locking in * the usual case. Setting td_priority here is essentially an @@ -1119,6 +1173,22 @@ if (td->td_priority != kg->kg_user_pri) { mtx_lock_spin(&sched_lock); td->td_priority = kg->kg_user_pri; + + /* Since we changed the priority we might need to switch to other threads + * first check the global and cpu runqueue - then check against best thread + * in own ksegrp without slot */ + + queue_pri = td->td_priority / RQ_PPQ; + + if (runq_better_priority_exists(&runq,queue_pri) || +#ifdef SMP + runq_better_priority_exists(&runq_pcpu[PCPU_GET(cpuid)],queue_pri) || +#endif + sched_should_giveup_slot(td)) { + /* Need to run a thread with better priority */ + mi_switch(SW_INVOL, NULL); + } + mtx_unlock_spin(&sched_lock); } } --=-Z7rROyI9E4Q5Yr8GPP56-- From owner-freebsd-arch@FreeBSD.ORG Sat Sep 25 18:00:23 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 2F01216A4CE for ; Sat, 25 Sep 2004 18:00:23 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id CEB9F43D2D for ; Sat, 25 Sep 2004 18:00:22 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 5102 invoked by uid 89); 25 Sep 2004 18:00:22 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 25 Sep 2004 18:00:22 -0000 Received: (qmail 5097 invoked by uid 89); 25 Sep 2004 18:00:21 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 25 Sep 2004 18:00:21 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8PI0Kmt093708; Sat, 25 Sep 2004 14:00:20 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <1095529353.31297.1192.camel@palm.tree.com> References: <1095468747.31297.241.camel@palm.tree.com> <1095529353.31297.1192.camel@palm.tree.com> Content-Type: text/plain Message-Id: <1096135220.53798.17754.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 25 Sep 2004 14:00:20 -0400 Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions 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, 25 Sep 2004 18:00:23 -0000 On Sat, 2004-09-18 at 13:42, Stephan Uphoff wrote: > On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > > Stephan Uphoff wrote: > > >I am also stomped by the special case of adding a thread X with better > > >priority than the current thread to the runqueue if they belong to the > > >same ksegroup. In this case both kg_last_assigned and kg_avail_opennings > > >might be zero and setrunqueue() will not call sched_add(). > > >Because of this it looks like the current thread will neither be > > >preempted not will TDF_NEEDRESCHED be set to force rescheduling at the > > >kernel boundary. > > >This situation should resolve itself at the next sched_switch - however > > >this might take a long time. (Especially if essential interrupt threads > > >are blocked by mutexes held by thread X) > > > > > > > you are correct. I am not yet preempting a running thread with a lesser > > priority if they are siblings > > (unless there is a slot available) Thsi is not becasue I don't want to > > do it, but simply because it has not been done yet.. > > we did have NO preemption, so having "some" preemption is still better > > than where we were. > > Special case code to check curthread for a preemption could be done but > > at the moment the decision code for > > whether to preempt or not is in maybe_preempt() and I don't want to > > duplicate that. it is on th edrawing board though. > > The other thing is, that even if we should be able to preempt a running > > thread, there is no guarantee that it is on THIS > > CPU. It may be on another CPU and that gets nasty in a hurry. > > Yes .. this could get nasty. > This happens when the thread is bound to another cpu or someone changed > thr_concurrency - otherwise the current thread must be a sibling right ? > > Maybe something brutal like: > if ((curthread->td_ksegrp == kg) && > (td->td_priority > curthread->td_priority)) > curthread->td_flags |= TDF_NEEDRESCHED; > > in setrunqueue for > the else case of "if (kg->kg_avail_opennings > 0)" > would do the trick (without preemption) for the easy but probably more > common cases? > > Maybe I can find some time next week to think about a clean > fix. I find it always helpful having a small task in mind while reading > source code. I wrote a fix that should cover all cases. However I would like to test it a little bit before posting the patch. Is there any multi-threaded kernel torture program that you can recommend? Thanks Stephan