From owner-freebsd-arch Sun Feb 3 0:41:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C67AB37B400 for ; Sun, 3 Feb 2002 00:41:39 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA02424; Sun, 3 Feb 2002 18:41:34 +1100 Date: Sun, 3 Feb 2002 18:43:51 +1100 (EST) From: Bruce Evans X-X-Sender: To: "M. Warner Losh" Cc: , , Subject: Re: __P macro question In-Reply-To: <20020202.153941.85552167.imp@village.org> Message-ID: <20020203183334.C18280-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 2 Feb 2002, M. Warner Losh wrote: > In message: <20020131231008.P4085-100000@gamplex.bde.org> > Bruce Evans writes: > : Don't do it all. Some people prefer old-style decls, and unlike __P(()), > : they don't involve any preprocessor hackery; they are part of ISO C. > > >From The last draft of the latest C standard: > Introduction > > [#2] Certain features are obsolescent, which means that they > may be considered for withdrawal in future revisions of this > International Standard. They are retained because of their > widespread use, but their use in new implementations (for > implementation features) or new programs (for language > [6.11] or library features [7.26]) is discouraged. > > 6.11.4 Function definitions > > [#1] The use of function definitions with separate parameter > identifier and declaration lists (not prototype-format > parameter type and identifier declarators) is an obsolescent > feature. > > I'm going to the trouble of doing it now because we'll have to do it > eventually. It is sufficiently painful that I may stop doing it for > the larger src.bin, src.sbin directories. You probably have at least 30 years to change them. Look at how long it took to convert K&R code (13 years so far). I expect code that assumes the C90 standard will take even longer to convert to C99. standard to live much longer. There is much more of it, and fewer reasons to convert. Say 15 years. Then another 15 to convert C99... > At some point we're going to have to do this, why not now. I know > that standard is a bit vague about the timeframe, but I suspect that It costs too much to convert old (working) code IMO. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 3 3: 5:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 97F1637B400 for ; Sun, 3 Feb 2002 03:05:51 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id g13B5jj92908; Sun, 3 Feb 2002 11:05:45 GMT (envelope-from mark@grondar.za) Received: from greenpeace.grondar.org (greenpeace [192.168.42.2]) by gratis.grondar.org (Postfix) with ESMTP id 497E757; Sun, 3 Feb 2002 11:04:31 +0000 (GMT) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.org (8.11.6/8.11.6) with ESMTP id g13B4TE45364; Sun, 3 Feb 2002 11:04:30 GMT (envelope-from mark@grondar.za) Message-Id: <200202031104.g13B4TE45364@greenpeace.grondar.org> To: Bruce Evans Cc: "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: __P macro question References: <20020203183334.C18280-100000@gamplex.bde.org> In-Reply-To: <20020203183334.C18280-100000@gamplex.bde.org> ; from Bruce Evans "Sun, 03 Feb 2002 18:43:51 +1100." Date: Sun, 03 Feb 2002 11:04:24 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Said Bruce Evans : > On Sat, 2 Feb 2002, M. Warner Losh wrote: > > I'm going to the trouble of doing it now because we'll have to do it > > eventually. It is sufficiently painful that I may stop doing it for > > the larger src.bin, src.sbin directories. > > You probably have at least 30 years to change them. Look at how long > it took to convert K&R code (13 years so far). I expect code that > assumes the C90 standard will take even longer to convert to C99. > standard to live much longer. There is much more of it, and fewer > reasons to convert. Say 15 years. Then another 15 to convert C99... > > > At some point we're going to have to do this, why not now. I know > > that standard is a bit vague about the timeframe, but I suspect that > > It costs too much to convert old (working) code IMO. If it can be done easily (willingly), I see no reason that we should not be part of the solution instead of the problem. (Perhaps that should be "solution" and "problem"). Anyway, we pride ourselves on being better than anyone else (or at least we should!), and setting a forward-looking precedent like this is an excellsent idea. Code gets copied, and if good code gets copied, then more good code gets created. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 3 7:22:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 55C3537B404 for ; Sun, 3 Feb 2002 07:22:46 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g13FMho53910; Sun, 3 Feb 2002 08:22:44 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g13FMfL17850; Sun, 3 Feb 2002 08:22:42 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 03 Feb 2002 08:22:21 -0700 (MST) Message-Id: <20020203.082221.95822540.imp@village.org> To: bde@zeta.org.au Cc: drosih@rpi.edu, deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question From: "M. Warner Losh" In-Reply-To: <20020203183334.C18280-100000@gamplex.bde.org> References: <20020202.153941.85552167.imp@village.org> <20020203183334.C18280-100000@gamplex.bde.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020203183334.C18280-100000@gamplex.bde.org> Bruce Evans writes: : > At some point we're going to have to do this, why not now. I know : > that standard is a bit vague about the timeframe, but I suspect that : : It costs too much to convert old (working) code IMO. So far this old working code has had a number of minor issues with type mismatches. These type mismatches have been found when moving to a full prototype. Someone with a deep knowledge of what is going on behind the scenes will understand, but the new prototype code is clearer without that need for deep understanding. talkd is one of the programs I've had the most problems with, mostly due to its not having an extern.h file where all the function prototypes were defined. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 3 15:39: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id 7DAF837B41D for ; Sun, 3 Feb 2002 15:38:56 -0800 (PST) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id 9E60A1D169; Sun, 3 Feb 2002 23:38:54 +0000 (GMT) Subject: Re: install(1) to use a cross strip(1) From: Paul Richards To: Marcel Moolenaar Cc: arch@FreeBSD.org In-Reply-To: <20020201231306.A670@dhcp01.pn.xcllnt.net> References: <20020201231306.A670@dhcp01.pn.xcllnt.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 03 Feb 2002 23:38:54 +0000 Message-Id: <1012779534.18110.0.camel@lobster.originative.co.uk> Mime-Version: 1.0 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 2002-02-02 at 07:13, Marcel Moolenaar wrote: > Gang, > > As part of doing cross development with our source tree I hit upon > the nasty habit of install(1) to want to use strip(1) and specificly > by that name. To make my live easier, I have made install(1) look > for an envvar first. Is this kind of flexibility generic enough to > have it committed? > > --- xinstall.c 19 Dec 2001 06:05:42 -0000 1.47 > +++ xinstall.c 27 Jan 2002 08:54:51 -0000 > @@ -702,6 +702,7 @@ > strip(to_name) > const char *to_name; > { > + char *stripbin; > int serrno, status; > > switch (fork()) { > @@ -711,7 +712,10 @@ > errno = serrno; > err(EX_TEMPFAIL, "fork"); > case 0: > - execlp("strip", "strip", to_name, (char *)NULL); > + stripbin = getenv("STRIPBIN"); > + if (stripbin == NULL) > + stripbin = "strip"; > + execlp(stripbin, stripbin, to_name, (char *)NULL); > err(EX_OSERR, "exec(strip)"); > default: > if (wait(&status) == -1 || status) { It's strikes me as being to risky from a security perspective. You'd have to be really sure that there wasn't a trojan generator masquerading as STRIPBIN. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 3 16:22: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id DC61737B420 for ; Sun, 3 Feb 2002 16:21:44 -0800 (PST) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g140Li654943; Sun, 3 Feb 2002 16:21:44 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.6) id g13F7nf25396; Sun, 3 Feb 2002 07:07:49 -0800 (PST) (envelope-from marcel) Date: Sun, 3 Feb 2002 07:07:49 -0800 From: Marcel Moolenaar To: Paul Richards Cc: arch@FreeBSD.org Subject: Re: install(1) to use a cross strip(1) Message-ID: <20020203070749.A25330@dhcp01.pn.xcllnt.net> References: <20020201231306.A670@dhcp01.pn.xcllnt.net> <1012779534.18110.0.camel@lobster.originative.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1012779534.18110.0.camel@lobster.originative.co.uk> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Feb 03, 2002 at 11:38:54PM +0000, Paul Richards wrote: > > > > --- xinstall.c 19 Dec 2001 06:05:42 -0000 1.47 > > +++ xinstall.c 27 Jan 2002 08:54:51 -0000 > > @@ -702,6 +702,7 @@ > > strip(to_name) > > const char *to_name; > > { > > + char *stripbin; > > int serrno, status; > > > > switch (fork()) { > > @@ -711,7 +712,10 @@ > > errno = serrno; > > err(EX_TEMPFAIL, "fork"); > > case 0: > > - execlp("strip", "strip", to_name, (char *)NULL); > > + stripbin = getenv("STRIPBIN"); > > + if (stripbin == NULL) > > + stripbin = "strip"; > > + execlp(stripbin, stripbin, to_name, (char *)NULL); > > err(EX_OSERR, "exec(strip)"); > > default: > > if (wait(&status) == -1 || status) { > > It's strikes me as being to risky from a security perspective. > > You'd have to be really sure that there wasn't a trojan generator > masquerading as STRIPBIN. I've been thinking about this as well. I couldn't quite figure out how an environment variable that allows any binary to be used as a strip(1) alternative would be more insecure than depending on PATH for finding where strip(1) is. In both cases the system administrator has to make sure a known environment exists (ie known PATH vs known setting (or absence) of STRIPBIN). On the other hand, adding an insecure mechanism, even when not more insecure than an existing one, will add an extra item to the check- list and thus will increase the likelyhood of a hole... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 3 18:25:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C245437B405 for ; Sun, 3 Feb 2002 18:25:46 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g142Pji01277; Sun, 3 Feb 2002 19:25:45 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g142PgL20265; Sun, 3 Feb 2002 19:25:43 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 03 Feb 2002 19:25:21 -0700 (MST) Message-Id: <20020203.192521.127666006.imp@village.org> To: paul@freebsd-services.com Cc: marcel@xcllnt.net, arch@FreeBSD.ORG Subject: Re: install(1) to use a cross strip(1) From: "M. Warner Losh" In-Reply-To: <1012779534.18110.0.camel@lobster.originative.co.uk> References: <20020201231306.A670@dhcp01.pn.xcllnt.net> <1012779534.18110.0.camel@lobster.originative.co.uk> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <1012779534.18110.0.camel@lobster.originative.co.uk> Paul Richards writes: : It's strikes me as being to risky from a security perspective. : : You'd have to be really sure that there wasn't a trojan generator : masquerading as STRIPBIN. How is this different than having strip in the path before the real strip? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 3 20:57:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 36A6137B4AD for ; Sun, 3 Feb 2002 20:56:55 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020204045654.FMAC10199.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Mon, 4 Feb 2002 04:56:54 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g144uss71742 for ; Sun, 3 Feb 2002 20:56:54 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id CCDEA3809; Sun, 3 Feb 2002 20:56:53 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bruce Evans Cc: Juha Juntunen , arch@FreeBSD.ORG Subject: Re: __P macro question In-Reply-To: <20020202012011.U3304-100000@gamplex.bde.org> Date: Sun, 03 Feb 2002 20:56:53 -0800 From: Peter Wemm Message-Id: <20020204045653.CCDEA3809@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Fri, 1 Feb 2002, Juha Juntunen wrote: > > > >>>static int sendfile __P((struct printer *pp, int type, char *file, > > >>> int format)); > > >>> > > >>>for a procedure declaration of: > > >>> static int > > >>> sendfile(pp, type, file, format) > > >>> struct printer *pp; > > >>> int type; > > >>> char *file; > > >>> char format; > > >>> { > > >> > > >>That's *EXCATLY* why I'm converting the old, but still legal in c89, > > >>style to new style. You get warnings that you didn't get before. > > > > > >The compiler is broken, if it accepts the second when the > > >first prototype is in scope. > > > > > >It's a broken compiler, period. > > > > How is the compiler broken, question mark. > > > > Are you perhaps objecting to the type of the last parameter > > ("int format" vs "char format")? Please see Ansi Classic, chapter > > "3.5.4.3 Function declarators (including prototypes)", in particular > > page 69 lines 19-22. In C99, 6.7.5.3 paragraph #11 seems to apply > > similarly. > > Right. I don't trust anyone who is not familiar with this point to > globally remove __P. > > People removing __P should also be familiar with the gcc conterpoint: > > void foo(char); /* Wrong; should be "void foo(int);". */ > void foo(c) char c; {} > > gives undefined behaviour in Standard C, but gcc defines its behaviour > to be do-what-naive-programmer-expects. This is only safe provided the > wrong prototype for foo() is always in scope before foo() is called; > otherwise foo() is sometimes passed an int and sometimes a char, but > foo() expects to be passed either an int or a char depending on whether > the wrong prototype is in scope for the function body. There are also variations depending on CPU ABI as well. For the i386 ABI that we use on FreeBSD, a "char" argument (prototyped even) is passed as an "int", always, period. On the Alpha, integral types are passed as 64 bit types. Same on the ia64. I am not sure about sparc64, ppc. Ironically, this means that most of the 'long/int' stuff that upsets people for argument passing on all the 64 bit platforms that I know about, is actually [mostly] harmless. printf("%d %d", (long)i, (long)j) works fine on alpha and ia64, for example.. even though long = 64 bit and int = 32 bit. The bottom line is that using -Wmissing-prototypes and having it compile cleanly is the only safe option that we have. This is doubly important on ansi-fied code as we pass over it. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 3 22:53: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 57A6837B416 for ; Sun, 3 Feb 2002 22:53:07 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 9146B216F; Mon, 4 Feb 2002 07:53:04 +0100 (CET) Date: Mon, 4 Feb 2002 07:53:03 +0100 From: Jeroen Ruigrok/asmodai To: Bruce Evans Cc: "M. Warner Losh" , drosih@rpi.edu, deatley@apple.com, arch@FreeBSD.ORG Subject: Re: __P macro question Message-ID: <20020204065303.GI52378@daemon.ninth-circle.org> References: <20020202.153941.85552167.imp@village.org> <20020203183334.C18280-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020203183334.C18280-100000@gamplex.bde.org> User-Agent: Mutt/1.3.24i Organisation: Ninth Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20020203 09:45], Bruce Evans (bde@zeta.org.au) wrote: >Look at how long it took to convert K&R code (13 years so far). If you mean in the FreeBSD source tree it was partially due to a person with this K&R-only compiler who kept `unbreaking K&R support'. ;))) -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ When you have eliminated the impossible, whatever remains, however improbable, must be the truth... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 4 14:50:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 8D0CC37B42C for ; Mon, 4 Feb 2002 14:50:47 -0800 (PST) Received: from user-38lc2pf.dialup.mindspring.com ([209.86.11.47] helo=gohan.cjclark.org) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Xrwh-0006RM-00 for freebsd-arch@freebsd.org; Mon, 04 Feb 2002 14:50:46 -0800 Received: (from cjc@localhost) by gohan.cjclark.org (8.11.6/8.11.1) id g14MoNP04046 for freebsd-arch@freebsd.org; Mon, 4 Feb 2002 14:50:23 -0800 (PST) (envelope-from cjc) Date: Mon, 4 Feb 2002 14:50:21 -0800 From: "Crist J. Clark" To: freebsd-arch@freebsd.org Subject: Setting sysctl(8)'s in rc.conf Message-ID: <20020204145021.B3722@gohan.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There are a number of rc.conf(5) variables whose sole purpose is to set sysctl(8) knobs. When I recently changed how the 'log_in_vain' rc.conf variable worked, it was suggested I remove it completely from the rc.conf and rc.network. It is something the user should be setting in /etc/rc.sysctl. For that specific sysctl(8) it seems to make sense. But what about ones like, net.inet.tcp.rfc1323 net.inet.icmp.bmcastecho net.inet.icmp.drop_redirect ... Should we drop their support from rc.conf(5) and expect the administrator to put them in /etc/rc.sysctl too? Note that some sysctl(8)s should NOT be removed like ones that depend on modules being loaded by conditionals in the rc-scripts. And there are others where order is important, don't flip 'net.inet.ip.forwading' and some others until the firewall has started. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 4 21:20:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id A1CC337B41B; Mon, 4 Feb 2002 21:20:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020205052017.HXVA3578.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 5 Feb 2002 05:20:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA83859; Mon, 4 Feb 2002 21:08:39 -0800 (PST) Date: Mon, 4 Feb 2002 21:08:38 -0800 (PST) From: Julian Elischer To: peter@freebsd.org Cc: arch@freebsd.org Subject: Peter.. KSE/M3 cosmetic diffs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter, I have posted to http://www.freebsd.org/~julian/ the set of 'semi-cosmetic' diffs we discussed. with these compiled in the system seems to act teh same as -current. The effect of the diffs is to remove all teh places in the code which assume that the thread structure is embedded in the process structure. (as we discussed). If you have a chance to go through them I'd like to commit these so that the actual KSE/M3 diffs get all these cosmetic changes removed from them and hopefully we can see better what is actually going on. (Others are welcome to comment also) (arch CC'd) BTW the horrid Macro name "FIRST_THREAD_IN_PROC(p)" is deliberatly horrid. Use of this macro indicates a place that will need some rewriting before multi threading can be fully utilised. In some cases (e.g. linux emulation) this may be permanent as linux only has 1 thread per process) in which case it may eventually be changed in these places to P_THRD(p) or something nicer on the eyes, but until then they are designed to "stand out and hurt". :-) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 4 22:58: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id A3D1237B41A for ; Mon, 4 Feb 2002 22:58:06 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g156sCt90293; Tue, 5 Feb 2002 01:54:12 -0500 (EST) (envelope-from mike) Date: Tue, 5 Feb 2002 01:54:12 -0500 From: Mike Barcroft To: cjclark@alum.mit.edu Cc: freebsd-arch@freebsd.org Subject: Re: Setting sysctl(8)'s in rc.conf Message-ID: <20020205015412.H6496@espresso.q9media.com> References: <20020204145021.B3722@gohan.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020204145021.B3722@gohan.cjclark.org>; from cristjc@earthlink.net on Mon, Feb 04, 2002 at 02:50:21PM -0800 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Crist J. Clark writes: > There are a number of rc.conf(5) variables whose sole purpose is to > set sysctl(8) knobs. When I recently changed how the 'log_in_vain' > rc.conf variable worked, it was suggested I remove it completely from > the rc.conf and rc.network. It is something the user should be setting > in /etc/rc.sysctl. For that specific sysctl(8) it seems to make > sense. But what about ones like, Just as a side note, I recommend we create a `/usr/share/examples/etc/sysctl.conf' file to store examples and descriptions of the various tunables. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 7:19:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8777A37B43C; Tue, 5 Feb 2002 07:19:08 -0800 (PST) Received: from vigrid.com (pm3-pt78.pcnet.net [206.105.29.152]) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g15FJ665029834; Tue, 5 Feb 2002 10:19:06 -0500 (EST) Message-ID: <3C5FF99D.87719821@vigrid.com> Date: Tue, 05 Feb 2002 10:26:21 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 Cc: bde@freebsd.org, peter@freebsd.org, arch@freebsd.org Subject: getsetcontext system call Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've turned {get,set,swap}context into a system call after peter's suggestion and it now looks similar to Solaris' getsetcontext. Ours is: int getsetcontext(ucontext_t *oucp, const ucontext_t *ucp); It's similar to sigprocmask. If oucp is null, then it behaves as getcontext. If ucp is null, it behaves as setcontext. And if both args are non-null, then it behaves as swapcontext. It returns 0 upon success, 1 if the context was swapped (like longjmp), otherwise returns with errno set accordingly. Some glue is needed in libc to call this appropriately for {get,set,swap}context. Diffs are at: http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs Compiled and tested on i386, just compiled on alpha. Regarding the floating point state. I didn't change the lazy FP switching, but I did tag each mcontext as to the FP format (in the case of i386), and from where the FPU state came. The FPU state, if present, can come from either the PCB or directly dumped from the FPU. If it came from the PCB, the process owned the FPU in the past but didn't own it at the time the context was retrieved. If it came from the FPU, the process did own the FPU. When restoring FPU state ({set,swap}context), we attempt to leave the FPU state in the same state it was in when the context was originally retrieved: o FPU state from PCB: If the process currently owns the FPU, the FPU state is loaded into the FPU. Otherwise it is copied to the PCB and the next FPU not enabled trap will load it. o FPU state from FPU: If the process doesn't own the FPU, the current FPU owner (if there is one) is dropped and its state saved. The calling process becomes the new owner of the FPU and the FPU state is loaded. I use "process" above, but in reality it is "thread". I also changed the alpha a bit. When delivering signals, it dropped the FPU if it was currently owned. This wasn't done on i386, and I didn't see a reason why it would need to be done for alpha. For i386, signal deliver now includes the FPU context. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 7:54:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5DB2F37B405; Tue, 5 Feb 2002 07:54:44 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g15Fsgi09421; Tue, 5 Feb 2002 08:54:43 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g15FsfL30041; Tue, 5 Feb 2002 08:54:42 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Feb 2002 08:54:12 -0700 (MST) Message-Id: <20020205.085412.88169750.imp@village.org> To: mike@FreeBSD.ORG Cc: cjclark@alum.mit.edu, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf From: "M. Warner Losh" In-Reply-To: <20020205015412.H6496@espresso.q9media.com> References: <20020204145021.B3722@gohan.cjclark.org> <20020205015412.H6496@espresso.q9media.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG We also need to fix setting sysctl variables late in the boot process, maybe after modules have been loaded early in the process. I've punted on doing this right becuase of the bikeshed around the name for /etc/sysctl.conf's companion that would be done late in the process... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 12:14:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id B663737B416; Tue, 5 Feb 2002 12:14:19 -0800 (PST) Received: from user-2ivfo5m.dialup.mindspring.com ([165.247.224.182] helo=gohan.cjclark.org) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16YByj-0001fn-00; Tue, 05 Feb 2002 12:14:11 -0800 Received: (from cjc@localhost) by gohan.cjclark.org (8.11.6/8.11.6) id g15KDlI01492; Tue, 5 Feb 2002 12:13:47 -0800 (PST) (envelope-from cjc) Date: Tue, 5 Feb 2002 12:13:45 -0800 From: "Crist J. Clark" To: "M. Warner Losh" Cc: mike@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf Message-ID: <20020205121345.B368@gohan.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020204145021.B3722@gohan.cjclark.org> <20020205015412.H6496@espresso.q9media.com> <20020205.085412.88169750.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020205.085412.88169750.imp@village.org>; from imp@village.org on Tue, Feb 05, 2002 at 08:54:12AM -0700 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Feb 05, 2002 at 08:54:12AM -0700, M. Warner Losh wrote: > We also need to fix setting sysctl variables late in the boot process, > maybe after modules have been loaded early in the process. I've > punted on doing this right becuase of the bikeshed around the name for > /etc/sysctl.conf's companion that would be done late in the process... Perhaps a better approach would be to put them all in /etc/sysctl.conf, but change /etc/sysctl.conf's format to support grouping different variables to be loaded at different times (maintaining back-compatibility of course). But deciding on a good way to do that might just be a bikeshed of another color. Here is just what comes to me as I write this. Each grouping in /etc/sysctl.conf is separated by a keyword followed by a token. Say, =Group Preload Where '=Group' is a keyword (start it with a non-alphanumeric so it is not likely to ever look like a real sysctl variable) and 'Preload' will be our token. Modify rc.sysctl to take an argument (you see it coming) which will be a token for a grouping. All of the sysctl variables from the specified group are loaded until we hit the next keyword-token line. Then one can just drop rc.sysctl calls into rc-scripts anywhere. After we kldload nfs (or whatever) we do, rc.sysctl nfs And the nfs sysctls, separated from the others by a '=Group nfs' in sysctl.conf, are loaded. Here's what rc.sysctl might look like to do this, if [ -f /etc/sysctl.conf ]; then if [ "$1" ]; then while read keyword token comments; do if [ "${keyword}" = '=Group' -a "${token}" = "$1" ] then break fi done fi while read var comments do case ${var} in \#*|'') ;; '=Group') exit 0 ;; *) sysctl ${var} ;; esac done fi < /etc/sysctl.conf -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 12:57:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E8CAB37B404; Tue, 5 Feb 2002 12:57:27 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g15KvQi10950; Tue, 5 Feb 2002 13:57:26 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g15KvML31943; Tue, 5 Feb 2002 13:57:22 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Feb 2002 13:56:58 -0700 (MST) Message-Id: <20020205.135658.102576700.imp@village.org> To: cjclark@alum.mit.edu, cristjc@earthlink.net Cc: mike@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf From: "M. Warner Losh" In-Reply-To: <20020205121345.B368@gohan.cjclark.org> References: <20020205015412.H6496@espresso.q9media.com> <20020205.085412.88169750.imp@village.org> <20020205121345.B368@gohan.cjclark.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020205121345.B368@gohan.cjclark.org> "Crist J. Clark" writes: : Perhaps a better approach would be to put them all in : /etc/sysctl.conf, but change /etc/sysctl.conf's format to support : grouping different variables to be loaded at different times : (maintaining back-compatibility of course). No. A better approach would be to make those items that are sysctls in modules also TUNABLES, and then the problem goes away. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 13:47:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 919D937B427; Tue, 5 Feb 2002 13:47:12 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g15LlAM30476; Tue, 5 Feb 2002 13:47:10 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Feb 2002 13:47:10 -0800 (PST) From: Matthew Dillon Message-Id: <200202052147.g15LlAM30476@apollo.backplane.com> To: "M. Warner Losh" Cc: mike@FreeBSD.ORG, cjclark@alum.mit.edu, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf References: <20020204145021.B3722@gohan.cjclark.org> <20020205015412.H6496@espresso.q9media.com> <20020205.085412.88169750.imp@village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :We also need to fix setting sysctl variables late in the boot process, :maybe after modules have been loaded early in the process. I've :punted on doing this right becuase of the bikeshed around the name for :/etc/sysctl.conf's companion that would be done late in the process... : :Warner It occurs to me that somebody might try to set the boot-time tunable kern.maxusers to 0, a case I do not currently handle. Right now I only handle the kernel config's maxusers being set to 0. Perhaps something like the below is better. Comments? -Matt Matthew Dillon Index: kern/subr_param.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_param.c,v retrieving revision 1.51 diff -u -r1.51 subr_param.c --- kern/subr_param.c 25 Jan 2002 01:54:16 -0000 1.51 +++ kern/subr_param.c 5 Feb 2002 21:45:51 -0000 @@ -133,14 +133,15 @@ { /* Base parameters */ - if ((maxusers = MAXUSERS) == 0) { + maxusers = MAXUSERS; + TUNABLE_INT_FETCH("kern.maxusers", &maxusers); + if (maxusers == 0) { maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE); if (maxusers < 32) maxusers = 32; if (maxusers > 384) maxusers = 384; } - TUNABLE_INT_FETCH("kern.maxusers", &maxusers); /* * The following can be overridden after boot via sysctl. Note: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 13:51:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4ED1337B416; Tue, 5 Feb 2002 13:51:06 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g15Lp4S30546; Tue, 5 Feb 2002 13:51:04 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Feb 2002 13:51:04 -0800 (PST) From: Matthew Dillon Message-Id: <200202052151.g15Lp4S30546@apollo.backplane.com> To: Dan Eischen Cc: bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call References: <3C5FF99D.87719821@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I thought we were trying to avoid having to make any system calls on a userland thread context switch. -Matt Matthew Dillon :I've turned {get,set,swap}context into a system call after peter's :suggestion and it now looks similar to Solaris' getsetcontext. Ours is: : : int getsetcontext(ucontext_t *oucp, const ucontext_t *ucp); : :It's similar to sigprocmask. If oucp is null, then it behaves as :getcontext. If ucp is null, it behaves as setcontext. And if :both args are non-null, then it behaves as swapcontext. It returns :0 upon success, 1 if the context was swapped (like longjmp), otherwise :returns with errno set accordingly. Some glue is needed in libc :to call this appropriately for {get,set,swap}context. : :Diffs are at: : : http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs : http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs : :Compiled and tested on i386, just compiled on alpha. : :Regarding the floating point state. I didn't change the lazy :FP switching, but I did tag each mcontext as to the FP format :(in the case of i386), and from where the FPU state came. The :FPU state, if present, can come from either the PCB or directly :dumped from the FPU. If it came from the PCB, the process :owned the FPU in the past but didn't own it at the time the :context was retrieved. If it came from the FPU, the process :did own the FPU. When restoring FPU state ({set,swap}context), :we attempt to leave the FPU state in the same state it was in :when the context was originally retrieved: : : o FPU state from PCB: : If the process currently owns the FPU, the FPU state is : loaded into the FPU. Otherwise it is copied to the PCB : and the next FPU not enabled trap will load it. : : o FPU state from FPU: : If the process doesn't own the FPU, the current FPU owner : (if there is one) is dropped and its state saved. The : calling process becomes the new owner of the FPU and the : FPU state is loaded. : :I use "process" above, but in reality it is "thread". : :I also changed the alpha a bit. When delivering signals, it :dropped the FPU if it was currently owned. This wasn't done :on i386, and I didn't see a reason why it would need to be done :for alpha. For i386, signal deliver now includes the FPU :context. : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-arch" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 13:59:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2F18537B404; Tue, 5 Feb 2002 13:59:33 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g15LxTXm025158; Tue, 5 Feb 2002 16:59:29 -0500 (EST) Date: Tue, 5 Feb 2002 16:59:29 -0500 (EST) From: Daniel Eischen To: Matthew Dillon Cc: Dan Eischen , bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: <200202052151.g15Lp4S30546@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Feb 2002, Matthew Dillon wrote: > I thought we were trying to avoid having to make any system calls on > a userland thread context switch. In the threads library, we'll use our own library routines to do this (hopefully) without having to make a system call. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 14:20:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 3199337B404; Tue, 5 Feb 2002 14:20:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020205222006.TVCL7443.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 5 Feb 2002 22:20:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA87364; Tue, 5 Feb 2002 14:09:43 -0800 (PST) Date: Tue, 5 Feb 2002 14:09:42 -0800 (PST) From: Julian Elischer To: Daniel Eischen Cc: Matthew Dillon , Dan Eischen , bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Feb 2002, Daniel Eischen wrote: > On Tue, 5 Feb 2002, Matthew Dillon wrote: > > I thought we were trying to avoid having to make any system calls on > > a userland thread context switch. > > In the threads library, we'll use our own library routines to > do this (hopefully) without having to make a system call. Or maybe use kernel entries that are already hapenning anyway..... > > -- > Dan Eischen > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 14:29:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0F30037B420; Tue, 5 Feb 2002 14:29:44 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g15MTeq8028801; Tue, 5 Feb 2002 17:29:40 -0500 (EST) Date: Tue, 5 Feb 2002 17:29:40 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: Matthew Dillon , Dan Eischen , bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Feb 2002, Julian Elischer wrote: > On Tue, 5 Feb 2002, Daniel Eischen wrote: > > > On Tue, 5 Feb 2002, Matthew Dillon wrote: > > > I thought we were trying to avoid having to make any system calls on > > > a userland thread context switch. > > > > In the threads library, we'll use our own library routines to > > do this (hopefully) without having to make a system call. > > Or maybe use kernel entries that are already hapenning anyway..... Huh? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 14:40:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 7E09437B419; Tue, 5 Feb 2002 14:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020205224008.YFRY10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 5 Feb 2002 22:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA87480; Tue, 5 Feb 2002 14:36:58 -0800 (PST) Date: Tue, 5 Feb 2002 14:36:57 -0800 (PST) From: Julian Elischer To: Daniel Eischen Cc: Matthew Dillon , Dan Eischen , bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Feb 2002, Daniel Eischen wrote: > On Tue, 5 Feb 2002, Julian Elischer wrote: > > On Tue, 5 Feb 2002, Daniel Eischen wrote: > > > > > On Tue, 5 Feb 2002, Matthew Dillon wrote: > > > > I thought we were trying to avoid having to make any system calls on > > > > a userland thread context switch. > > > > > > In the threads library, we'll use our own library routines to > > > do this (hopefully) without having to make a system call. > > > > Or maybe use kernel entries that are already hapenning anyway..... > > Huh? > I was thinking that when saving thread context back to userland after completing a syscall but before going on to another syscall, we can save lots of FP state etc as well. Maybe I'm confused on the topic of conversation. > -- > Dan Eischen > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 14:53:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 7BA8437B41D; Tue, 5 Feb 2002 14:53:05 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g15Mr1hR001434; Tue, 5 Feb 2002 17:53:01 -0500 (EST) Date: Tue, 5 Feb 2002 17:53:01 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: Matthew Dillon , Dan Eischen , bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Feb 2002, Julian Elischer wrote: > On Tue, 5 Feb 2002, Daniel Eischen wrote: > > > On Tue, 5 Feb 2002, Julian Elischer wrote: > > > On Tue, 5 Feb 2002, Daniel Eischen wrote: > > > > > > > On Tue, 5 Feb 2002, Matthew Dillon wrote: > > > > > I thought we were trying to avoid having to make any system calls on > > > > > a userland thread context switch. > > > > > > > > In the threads library, we'll use our own library routines to > > > > do this (hopefully) without having to make a system call. > > > > > > Or maybe use kernel entries that are already hapenning anyway..... > > > > Huh? > > I was thinking that when saving thread context back to userland > after completing a syscall but before going on to another > syscall, we can save lots of FP state etc as well. Yeah, I was assuming that under a KSE enabled process, the state of blocked threads gets saved out to userland in mcontext_t format (which would include the FPU state, if used). But the threads library can also force a context switch without having it blocked in the kernel, so the threads library needs the equivalent of a getcontext() as well as setcontext(). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 15: 0:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 7507E37B477; Tue, 5 Feb 2002 15:00:18 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020205230018.UVBB7443.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 5 Feb 2002 23:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA87522; Tue, 5 Feb 2002 14:41:52 -0800 (PST) Date: Tue, 5 Feb 2002 14:41:51 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Dan Eischen , bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: <200202052151.g15Lp4S30546@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dan, if you can apply the posted KSE changes, then you can start working on fitting your call into the test program. You should also alter the single function cpu_export_context() in the kernel which is the in-kernel version of the same call. If you do that, you can start testing your stuff immediatly.. The test program is doing full KSE multithreading. On Tue, 5 Feb 2002, Matthew Dillon wrote: > I thought we were trying to avoid having to make any system calls on > a userland thread context switch. > > -Matt > Matthew Dillon > > > :I've turned {get,set,swap}context into a system call after peter's > :suggestion and it now looks similar to Solaris' getsetcontext. Ours is: > : > : int getsetcontext(ucontext_t *oucp, const ucontext_t *ucp); > : > :It's similar to sigprocmask. If oucp is null, then it behaves as > :getcontext. If ucp is null, it behaves as setcontext. And if > :both args are non-null, then it behaves as swapcontext. It returns > :0 upon success, 1 if the context was swapped (like longjmp), otherwise > :returns with errno set accordingly. Some glue is needed in libc > :to call this appropriately for {get,set,swap}context. > : > :Diffs are at: > : > : http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > : http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs > : > :Compiled and tested on i386, just compiled on alpha. > : > :Regarding the floating point state. I didn't change the lazy > :FP switching, but I did tag each mcontext as to the FP format > :(in the case of i386), and from where the FPU state came. The > :FPU state, if present, can come from either the PCB or directly > :dumped from the FPU. If it came from the PCB, the process > :owned the FPU in the past but didn't own it at the time the > :context was retrieved. If it came from the FPU, the process > :did own the FPU. When restoring FPU state ({set,swap}context), > :we attempt to leave the FPU state in the same state it was in > :when the context was originally retrieved: > : > : o FPU state from PCB: > : If the process currently owns the FPU, the FPU state is > : loaded into the FPU. Otherwise it is copied to the PCB > : and the next FPU not enabled trap will load it. > : > : o FPU state from FPU: > : If the process doesn't own the FPU, the current FPU owner > : (if there is one) is dropped and its state saved. The > : calling process becomes the new owner of the FPU and the > : FPU state is loaded. > : > :I use "process" above, but in reality it is "thread". > : > :I also changed the alpha a bit. When delivering signals, it > :dropped the FPU if it was currently owned. This wasn't done > :on i386, and I didn't see a reason why it would need to be done > :for alpha. For i386, signal deliver now includes the FPU > :context. > : > :To Unsubscribe: send mail to majordomo@FreeBSD.org > :with "unsubscribe freebsd-arch" in the body of the message > : > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 15:54:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2FD2737B428; Tue, 5 Feb 2002 15:54:53 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g15NsjD68077; Tue, 5 Feb 2002 18:54:45 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 5 Feb 2002 18:54:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Dillon Cc: "M. Warner Losh" , mike@FreeBSD.ORG, cjclark@alum.mit.edu, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf In-Reply-To: <200202052147.g15LlAM30476@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sounds good to me. I really meant to ask you about that when you originally did the auto-tuning, but it apparently skipped my mind. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Tue, 5 Feb 2002, Matthew Dillon wrote: > > :We also need to fix setting sysctl variables late in the boot process, > :maybe after modules have been loaded early in the process. I've > :punted on doing this right becuase of the bikeshed around the name for > :/etc/sysctl.conf's companion that would be done late in the process... > : > :Warner > > It occurs to me that somebody might try to set the boot-time tunable > kern.maxusers to 0, a case I do not currently handle. Right now I > only handle the kernel config's maxusers being set to 0. > > Perhaps something like the below is better. Comments? > > -Matt > Matthew Dillon > > > Index: kern/subr_param.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/subr_param.c,v > retrieving revision 1.51 > diff -u -r1.51 subr_param.c > --- kern/subr_param.c 25 Jan 2002 01:54:16 -0000 1.51 > +++ kern/subr_param.c 5 Feb 2002 21:45:51 -0000 > @@ -133,14 +133,15 @@ > { > > /* Base parameters */ > - if ((maxusers = MAXUSERS) == 0) { > + maxusers = MAXUSERS; > + TUNABLE_INT_FETCH("kern.maxusers", &maxusers); > + if (maxusers == 0) { > maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE); > if (maxusers < 32) > maxusers = 32; > if (maxusers > 384) > maxusers = 384; > } > - TUNABLE_INT_FETCH("kern.maxusers", &maxusers); > > /* > * The following can be overridden after boot via sysctl. Note: > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 17:22:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by hub.freebsd.org (Postfix) with ESMTP id 3222437B489 for ; Tue, 5 Feb 2002 17:21:22 -0800 (PST) Received: from user-1120bk3.dsl.mindspring.com ([66.32.46.131] helo=europa2) by smtp6.mindspring.com with smtp (Exim 3.33 #1) id 16YGlt-00073R-00; Tue, 05 Feb 2002 20:21:13 -0500 Message-Id: <3.0.6.32.20020205201946.00d9eef8@imatowns.com> X-Sender: ggombert@imatowns.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 05 Feb 2002 20:19:46 -0500 To: Julian Elischer , arch@freebsd.org From: Glenn Gombert Subject: Re: simple KSE test program In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a kernel running with all the latest kse changes from cvsup10 running on my dual PIII system (with SMP support commented out of the kernel config file) and it appears to be running most things well in 'uni-processor' mode. I am trying to get the protoype test program compiled below and was wondering if you had a compiled version working yet? Or shall I post mine as soon as I get it working..... Glenn G. At 01:41 AM 1/24/2002 -0800, Julian Elischer wrote: > >Several people have asked how a KSE program would look. > >Here is a program I am writing for testing KSEs: >I hope to be using it within a day or two. >it includes 2 new syscalls (kse_new() and kse_yield()). >One function not yet written is the function loadthread() >which reads the registers in from the saved context in a user_thread >structure, in a similar way to how longjmp() does, but with >more to load. I need to add that in a .s file. > > >First I include the kse include file: > >#ifndef SYS_KSE_H >#define SYS_KSE_H > >/* > * This file defines the structures needed for communication between > * the userland and the kernel when running a KSE-based threading system. > * The only programs that should see this file are the UTS and the kernel. > */ > >/* > * Each userland thread has one of these buried in it's > * Thread control structure somewhere. > */ >struct thread_mailbox >{ > struct thread_mailbox *next_completed; > unsigned int flags; > void *UTS_handle; /* UTS can use this for anything */ > mcontext_t ctx; /* thread's saved context goes here. */ >/* The ctx field will become a union of types trapframe and mcontext_t >aligned accordingly. */ >}; > > >/* > * You need to supply one of these as the argument to the > * kse_new() system call. > */ >struct kse_mailbox >{ > struct thread_mailbox *current_thread; > struct thread_mailbox *completed_threads; > unsigned int flags; > void *UTS_handle; /* The UTS can use this for >anything */ >}; >#define KEMBXF_CRITICAL 0x00000001 > >struct kse_global_mailbox >{ > unsigned int flags; >}; >#define GMBXF_CRITICAL 0x00000001 > >/* some provisional sycalls: */ > >int kse_new(struct kse_mailbox *mbx, int new_grp_flag); >int kse_exit(void); /* last will clear KSE mode */ >int thread_wakeup(struct thread_mailbox *tmbx); /* make it complete */ >int kse_wakeup(void); /* wake any idle KSEs */ >void kse_yield(void); /* this kse can become idle */ > >--------------------------------------------------------------- >and here is the program. > >Only the last 4 functions should be in the program itself. >All the rest make up the basis of what would be in a library. >In fact some of what is done in main() might even be abstracted too. > >I hope to be testing this within a couple of days (given a few cleanups >and loose-ends to fix) >---------- > > >#include >#include >#include >#include > >/************************************************************* > * These should probably be in a .h file > **************************************************************/ >typedef void thread_fn(void *arg); > >struct user_thread { > struct thread_mailbox mbox; > char *stack; > int stack_size; > struct user_thread *runq_next; >}; > >struct per_kse { > struct kse_mailbox *mbox; > struct user_thread *curthread >}; >/************************************************************* > * Debug stuff > **************************************************************/ > >#if 0 >jmp_buf jb3; >#define DUMPREGS(desc) do {_setjmp(jb3); printjb(jb3, desc); } while (0) > >char *regname[] = {"%eip","%ebx","%esp","%ebp", > "%esi","%edi","fpcr","MSK0", > "MSK1","MSK2","MSK3"}; > > >static >printjb(struct _jmp_buf *jb, char *desc) >{ > > int i; > printf("jb (%s) is at 0x%x\n", desc, jb); > for( i = 0; i< _JBLEN-4; i++) { > printf("jb[%d] (%s) = 0x%x\n", i, regname[i], >jb[0]._jb[i]); > } >} >#endif >/************************************************************* > * Globals > **************************************************************/ >struct per_kse first_kse; /* for NOW cheat and make it global */ >struct user_thread *runqueue; >struct user_thread **runq_last; >/************************************************************* > * Implementation parameters > **************************************************************/ >#define T_STACKSIZE (16*4096) /* thread stacksize */ >#define K_STACKSIZE (1*4096) /* KSE (UTS) stacksize */ > >/************************************************************* > * UTS funcions. > * Simple round_robin for now. > **************************************************************/ >static void >runq_insert(struct user_thread *thread) >{ > thread->runq_next = NULL; > *runq_last = thread; > runq_last = &thread->runq_next; >} > >static struct user_thread * >select_thread(void) >{ > struct user_thread *thread; > if ((thread = runqueue)) { > if ((runqueue = thread->runq_next) == NULL) { > runq_last = &runqueue; > } > } > return (thread); >} > >/************************************************************* > * The UTS upcall entrypoint > * Called once on startup (and left by longjump) > * and there-after, returned to by the upcall many times. > **************************************************************/ >static void >UTS(struct _jmp_buf *jb1, struct per_kse *ksedata, int newgroup) >{ > struct kse_mailbox ke_mbox; > struct user_thread *thread; > struct thread_mailbox *completed; > > /* Let the caller know where our mailbox is */ > ksedata->mbox = &ke_mbox; > ke_mbox.UTS_handle = ksedata; > > if (kse_new(&ke_mbox, newgroup)) { /* initial call returns */ > _longjmp(jb1, 1); /* go back to caller's stack and caller >*/ > /* NOTREACHED */ > } > > /**********************************/ > /* UTS upcall starts running here. */ > /**********************************/ > /**********************************/ > printf("we are in the UTS with mailbox at 0x%x\n", &ke_mbox); > > /* If there are returned syscall threads, put them on the run >queue */ > if ((completed = ke_mbox.completed_threads)) { > ke_mbox.completed_threads = NULL; > while (completed) { > thread = completed->UTS_handle; > completed = completed->next_completed; > runq_insert(thread); > } > } > > /* find highest priority thread and load it */ > if ((thread = select_thread())) { > > ksedata->curthread = thread; > ke_mbox.current_thread = &thread->mbox; > loadthread(thread) /* loads context similar to >longjmp() */ > /* NOTREACHED */ > } > kse_yeild(); /* in the kernel it does a thread_exit() */ > /* NOTREACHED */ >} > > >/************************************************************* > * Startup mechanism functions > **************************************************************/ >static int; >kickkse(struct per_kse *ksedata, int newgroup) >{ > char * newstack; > jmp_buf jb1; > jmp_buf jb2; > struct kse_mailbox *mboxaddr; > int i; > > newstack = malloc(K_STACKSIZE); > printf("newstack is at 0x%x-0x%x\n", > newstack, newstack + K_STACKSIZE); > if (_setjmp(jb1) == 0) { > if (_setjmp(jb2) == 0) { > jb2[0]._jb[2] = &newstack[K_STACKSIZE - 16]; > _longjmp(jb2, 1); > } > /* running with a different SP */ > { > /* Get all the rest set up. */ > UTS(&jb1[0], ksedata, newgroup); > /* NOTREACHED */ > } > } > return(1); >} > > >static struct kse_mailbox * >startkse(struct per_kse *ksedata) >{ > return (kickkse(ksedata, 0)); >} > >static struct kse_mailbox * >startksegrp(struct per_kse *ksedata); >{ > return(kickkse(ksedata, 1)); >} > >void badreturn() >{ > printf("thread returned when shouldn't\n"); > exit(1); >} > >__inline__ void >pushontostack(struct user_thread *tcb, int value) >{ > int *SP; > > SP = (int *)(tcb->mbox.ctx.trapframe.tf_isp); > *--SP = value; > tcb->mbox.ctx.trapframe.tf.tf_isp = (int)SP; >} > >struct user_thread * >makethread(thread_fn *fn, int arg1, void *arg2) >{ > struct user_thread *tcb; > > /* We could combine these mallocs */ > tcb = malloc(sizeof *tcb); > bzero(tcb, sizeof(*tcb)); > tcb->mbox.UTS_handle = tcb; /* back pointer */ > > /* malloc the thread's stack */ > /* We COULD mmap it with STACK characteristics */ > /* Then we could add a guard page. */ > tcb->stack_size = T_STACKSIZE; /* set the size we want */ > tcb->stack = malloc(tcb->stack_size); > > > /* set the PC to the fn */ > tcb->mbox.ctx.trapframe.tf_eip = fn; > > /* Set the stack and push on the args and a dammy return address >*/ > tcb->mbox.ctx.trapframe.tf_isp = tcb->stack + tcb->stack_size - >16; > pushontostack(tcb, (int)arg2); > pushontostack(tcb, (int)arg1); > pushontostack(tcb, (int)&badreturn); /* safety return address */ >} > >/************************************************************* > * code for three separate threads. (so we can see if it works) > *************************************************************/ >static void >thread1_code(void *arg) >{ > for(;;) { > sleep (1); > write(1,".",1); > } >} > >static void >thread2_code(void *arg) >{ > for(;;) { > sleep (3); > write(1,"+",1); > } >} > >static void >thread3_code(void *arg) >{ > for(;;) { > sleep (5); > write(1,"=",1); > } >} > > > >static struct thread_mailbox * >main() >{ > struct kse_mailbox *k_mbox; > > /* set up global structures */ > runq_last = &runqueue; > runqueue = NULL; > > /* define two threads to run, they are runnable but not yet >running */ > runq_insert( makethread(&thread1_code, 0, NULL)); > runq_insert( makethread(&thread2_code, 0, NULL)); > /* and one which we will run ourself */ > firstkse->curthread = makethread(&thread3_code, 0, NULL); > > /* start two KSEs in different KSEGRPs */ > k_mbox = startkse(&first_kse); > > /* startksegrp(&second_kse); */ /* we can't do 2 KSEs yet */ > /* One will be sufficient */ > > /* we are a thread, start the ball rolling */ > /* let the kernel know we are it */ > firstkse->mbox->current_thread = curthread->mbox; > thread3_code(NULL); >} > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-arch" in the body of the message > Glenn Gombert ggombert@imatowns.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 18:55:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id BCA2F37B426; Tue, 5 Feb 2002 18:55:44 -0800 (PST) Received: from pool0362.cvx40-bradley.dialup.earthlink.net ([216.244.43.107] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16YIFJ-0000eD-00; Tue, 05 Feb 2002 18:55:41 -0800 Message-ID: <3C609B28.4B040672@mindspring.com> Date: Tue, 05 Feb 2002 18:55:36 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: cjclark@alum.mit.edu, cristjc@earthlink.net, mike@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf References: <20020205015412.H6496@espresso.q9media.com> <20020205.085412.88169750.imp@village.org> <20020205121345.B368@gohan.cjclark.org> <20020205.135658.102576700.imp@village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > In message: <20020205121345.B368@gohan.cjclark.org> > "Crist J. Clark" writes: > : Perhaps a better approach would be to put them all in > : /etc/sysctl.conf, but change /etc/sysctl.conf's format to support > : grouping different variables to be loaded at different times > : (maintaining back-compatibility of course). > > No. > > A better approach would be to make those items that are sysctls in > modules also TUNABLES, and then the problem goes away. Will this let them be set before load? There's a bad assumption in tunables, that they may be tuned after boot time, which is not true for things like sizes of zalloci() zones, which must be contiguous, and whose size prevents reallocation, and whose use before reallocation would lead to fragmentation. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 19: 4:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 8444037B42A; Tue, 5 Feb 2002 19:04:15 -0800 (PST) Received: from pool0362.cvx40-bradley.dialup.earthlink.net ([216.244.43.107] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16YINX-0001wv-00; Tue, 05 Feb 2002 19:04:11 -0800 Message-ID: <3C609D1C.B0AD70F2@mindspring.com> Date: Tue, 05 Feb 2002 19:03:56 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: Julian Elischer , Matthew Dillon , Dan Eischen , bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > > > > I thought we were trying to avoid having to make any system calls on > > > > a userland thread context switch. > > > > > > In the threads library, we'll use our own library routines to > > > do this (hopefully) without having to make a system call. > > > > Or maybe use kernel entries that are already hapenning anyway..... > > Huh? "Batch async call gates". In other words, if you are calling anyway, push more than one call across the user/kernel boundary at a time. The answer to his suggestion is "it won't work, because that's not how system calls work today". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 19:11:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 654) id A1A8937B41E; Tue, 5 Feb 2002 19:11:05 -0800 (PST) Date: Tue, 5 Feb 2002 19:11:05 -0800 From: Mike Smith To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf Message-ID: <20020205191105.A25310@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > A better approach would be to make those items that are sysctls in > > modules also TUNABLES, and then the problem goes away. > > Will this let them be set before load? Why not go read up on tunables? /* * Infrastructure for tunable 'constants'. Value may be specified at compile * time or kernel load time. Rules relating tunables together can be placed * in a SYSINIT function at SI_SUB_TUNABLES with SI_ORDER_LAST. */ > There's a bad assumption in tunables, that they may be > tuned after boot time, which is not true for things > like sizes of zalloci() zones, which must be contiguous, There is? Since you don't actually know what TUNABLEs actually are, aren't you going out on a bit of a limb here? > and whose size prevents reallocation, and whose use > before reallocation would lead to fragmentation. This is the entire rationale behind the existence of TUNABLEs. I fail to comprehend why you're even posting this message, since you don't just have the wrong end of the stick but also appear to have missed the fact that it's a rattlesnake. For those reading this that are confused; the TUNABLE mechanism is provided to make it easy to adjust parameters that affect systems or algorithms that would not respond well to having these parameters adjusted after initialisation. Prior to TUNABLEs (which are really a very trivial thing), you would have to either recompile the kernel or patch the kernel image. TUNABLEs take a default value at compile time, and can be overridden using the loader. They occupy the same namespace as sysctl variables (this is not enforced, just a convention), and the value is often exported via sysctl so that the administrator can obtain the current value for reference purposes. - - - With regard to the original suggestion, I'm not in agreement that module arguments should be tunables either. Many module arguments should actually be hints (since they relate to instances of something supported by a module). Those that are truly generic, or in the case of a module which only creates a single instance should be passed at module load time either directly (as with the loader's 'load' command, via kldload, etc) or indirectly from a configuration file. TUNABLEs really exist to deal with the problem described above, not the issue of module arguments. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 19:20:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id A480A37B41E for ; Tue, 5 Feb 2002 19:20:19 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020206032013.CEXX7443.rwcrmhc54.attbi.com@InterJet.elischer.org>; Wed, 6 Feb 2002 03:20:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA88481; Tue, 5 Feb 2002 19:17:38 -0800 (PST) Date: Tue, 5 Feb 2002 19:17:36 -0800 (PST) From: Julian Elischer To: Glenn Gombert Cc: arch@freebsd.org Subject: Re: simple KSE test program In-Reply-To: <3.0.6.32.20020205201946.00d9eef8@imatowns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG the version off my freebsd web page compiles and runs correctly you need to make a new libc for it to link of course (and need to have the new syscall definitions in teh kernel tree for libc to find them. On Tue, 5 Feb 2002, Glenn Gombert wrote: > > > I have a kernel running with all the latest kse changes from cvsup10 > running on my dual PIII system (with SMP support commented out of the > kernel config file) and it appears to be running most things well in > 'uni-processor' mode. I am trying to get the protoype test program compiled > below and was wondering if you had a compiled version working yet? Or shall > I post mine as soon as I get it working..... > > Glenn G. > > At 01:41 AM 1/24/2002 -0800, Julian Elischer wrote: > > > >Several people have asked how a KSE program would look. > > > >Here is a program I am writing for testing KSEs: > >I hope to be using it within a day or two. > >it includes 2 new syscalls (kse_new() and kse_yield()). > >One function not yet written is the function loadthread() > >which reads the registers in from the saved context in a user_thread > >structure, in a similar way to how longjmp() does, but with > >more to load. I need to add that in a .s file. > > > > > >First I include the kse include file: > > > >#ifndef SYS_KSE_H > >#define SYS_KSE_H > > > >/* > > * This file defines the structures needed for communication between > > * the userland and the kernel when running a KSE-based threading system. > > * The only programs that should see this file are the UTS and the kernel. > > */ > > > >/* > > * Each userland thread has one of these buried in it's > > * Thread control structure somewhere. > > */ > >struct thread_mailbox > >{ > > struct thread_mailbox *next_completed; > > unsigned int flags; > > void *UTS_handle; /* UTS can use this for anything */ > > mcontext_t ctx; /* thread's saved context goes here. */ > >/* The ctx field will become a union of types trapframe and mcontext_t > >aligned accordingly. */ > >}; > > > > > >/* > > * You need to supply one of these as the argument to the > > * kse_new() system call. > > */ > >struct kse_mailbox > >{ > > struct thread_mailbox *current_thread; > > struct thread_mailbox *completed_threads; > > unsigned int flags; > > void *UTS_handle; /* The UTS can use this for > >anything */ > >}; > >#define KEMBXF_CRITICAL 0x00000001 > > > >struct kse_global_mailbox > >{ > > unsigned int flags; > >}; > >#define GMBXF_CRITICAL 0x00000001 > > > >/* some provisional sycalls: */ > > > >int kse_new(struct kse_mailbox *mbx, int new_grp_flag); > >int kse_exit(void); /* last will clear KSE mode */ > >int thread_wakeup(struct thread_mailbox *tmbx); /* make it complete */ > >int kse_wakeup(void); /* wake any idle KSEs */ > >void kse_yield(void); /* this kse can become idle */ > > > >--------------------------------------------------------------- > >and here is the program. > > > >Only the last 4 functions should be in the program itself. > >All the rest make up the basis of what would be in a library. > >In fact some of what is done in main() might even be abstracted too. > > > >I hope to be testing this within a couple of days (given a few cleanups > >and loose-ends to fix) > >---------- > > > > > >#include > >#include > >#include > >#include > > > >/************************************************************* > > * These should probably be in a .h file > > **************************************************************/ > >typedef void thread_fn(void *arg); > > > >struct user_thread { > > struct thread_mailbox mbox; > > char *stack; > > int stack_size; > > struct user_thread *runq_next; > >}; > > > >struct per_kse { > > struct kse_mailbox *mbox; > > struct user_thread *curthread > >}; > >/************************************************************* > > * Debug stuff > > **************************************************************/ > > > >#if 0 > >jmp_buf jb3; > >#define DUMPREGS(desc) do {_setjmp(jb3); printjb(jb3, desc); } while (0) > > > >char *regname[] = {"%eip","%ebx","%esp","%ebp", > > "%esi","%edi","fpcr","MSK0", > > "MSK1","MSK2","MSK3"}; > > > > > >static > >printjb(struct _jmp_buf *jb, char *desc) > >{ > > > > int i; > > printf("jb (%s) is at 0x%x\n", desc, jb); > > for( i = 0; i< _JBLEN-4; i++) { > > printf("jb[%d] (%s) = 0x%x\n", i, regname[i], > >jb[0]._jb[i]); > > } > >} > >#endif > >/************************************************************* > > * Globals > > **************************************************************/ > >struct per_kse first_kse; /* for NOW cheat and make it global */ > >struct user_thread *runqueue; > >struct user_thread **runq_last; > >/************************************************************* > > * Implementation parameters > > **************************************************************/ > >#define T_STACKSIZE (16*4096) /* thread stacksize */ > >#define K_STACKSIZE (1*4096) /* KSE (UTS) stacksize */ > > > >/************************************************************* > > * UTS funcions. > > * Simple round_robin for now. > > **************************************************************/ > >static void > >runq_insert(struct user_thread *thread) > >{ > > thread->runq_next = NULL; > > *runq_last = thread; > > runq_last = &thread->runq_next; > >} > > > >static struct user_thread * > >select_thread(void) > >{ > > struct user_thread *thread; > > if ((thread = runqueue)) { > > if ((runqueue = thread->runq_next) == NULL) { > > runq_last = &runqueue; > > } > > } > > return (thread); > >} > > > >/************************************************************* > > * The UTS upcall entrypoint > > * Called once on startup (and left by longjump) > > * and there-after, returned to by the upcall many times. > > **************************************************************/ > >static void > >UTS(struct _jmp_buf *jb1, struct per_kse *ksedata, int newgroup) > >{ > > struct kse_mailbox ke_mbox; > > struct user_thread *thread; > > struct thread_mailbox *completed; > > > > /* Let the caller know where our mailbox is */ > > ksedata->mbox = &ke_mbox; > > ke_mbox.UTS_handle = ksedata; > > > > if (kse_new(&ke_mbox, newgroup)) { /* initial call returns */ > > _longjmp(jb1, 1); /* go back to caller's stack and caller > >*/ > > /* NOTREACHED */ > > } > > > > /**********************************/ > > /* UTS upcall starts running here. */ > > /**********************************/ > > /**********************************/ > > printf("we are in the UTS with mailbox at 0x%x\n", &ke_mbox); > > > > /* If there are returned syscall threads, put them on the run > >queue */ > > if ((completed = ke_mbox.completed_threads)) { > > ke_mbox.completed_threads = NULL; > > while (completed) { > > thread = completed->UTS_handle; > > completed = completed->next_completed; > > runq_insert(thread); > > } > > } > > > > /* find highest priority thread and load it */ > > if ((thread = select_thread())) { > > > > ksedata->curthread = thread; > > ke_mbox.current_thread = &thread->mbox; > > loadthread(thread) /* loads context similar to > >longjmp() */ > > /* NOTREACHED */ > > } > > kse_yeild(); /* in the kernel it does a thread_exit() */ > > /* NOTREACHED */ > >} > > > > > >/************************************************************* > > * Startup mechanism functions > > **************************************************************/ > >static int; > >kickkse(struct per_kse *ksedata, int newgroup) > >{ > > char * newstack; > > jmp_buf jb1; > > jmp_buf jb2; > > struct kse_mailbox *mboxaddr; > > int i; > > > > newstack = malloc(K_STACKSIZE); > > printf("newstack is at 0x%x-0x%x\n", > > newstack, newstack + K_STACKSIZE); > > if (_setjmp(jb1) == 0) { > > if (_setjmp(jb2) == 0) { > > jb2[0]._jb[2] = &newstack[K_STACKSIZE - 16]; > > _longjmp(jb2, 1); > > } > > /* running with a different SP */ > > { > > /* Get all the rest set up. */ > > UTS(&jb1[0], ksedata, newgroup); > > /* NOTREACHED */ > > } > > } > > return(1); > >} > > > > > >static struct kse_mailbox * > >startkse(struct per_kse *ksedata) > >{ > > return (kickkse(ksedata, 0)); > >} > > > >static struct kse_mailbox * > >startksegrp(struct per_kse *ksedata); > >{ > > return(kickkse(ksedata, 1)); > >} > > > >void badreturn() > >{ > > printf("thread returned when shouldn't\n"); > > exit(1); > >} > > > >__inline__ void > >pushontostack(struct user_thread *tcb, int value) > >{ > > int *SP; > > > > SP = (int *)(tcb->mbox.ctx.trapframe.tf_isp); > > *--SP = value; > > tcb->mbox.ctx.trapframe.tf.tf_isp = (int)SP; > >} > > > >struct user_thread * > >makethread(thread_fn *fn, int arg1, void *arg2) > >{ > > struct user_thread *tcb; > > > > /* We could combine these mallocs */ > > tcb = malloc(sizeof *tcb); > > bzero(tcb, sizeof(*tcb)); > > tcb->mbox.UTS_handle = tcb; /* back pointer */ > > > > /* malloc the thread's stack */ > > /* We COULD mmap it with STACK characteristics */ > > /* Then we could add a guard page. */ > > tcb->stack_size = T_STACKSIZE; /* set the size we want */ > > tcb->stack = malloc(tcb->stack_size); > > > > > > /* set the PC to the fn */ > > tcb->mbox.ctx.trapframe.tf_eip = fn; > > > > /* Set the stack and push on the args and a dammy return address > >*/ > > tcb->mbox.ctx.trapframe.tf_isp = tcb->stack + tcb->stack_size - > >16; > > pushontostack(tcb, (int)arg2); > > pushontostack(tcb, (int)arg1); > > pushontostack(tcb, (int)&badreturn); /* safety return address */ > >} > > > >/************************************************************* > > * code for three separate threads. (so we can see if it works) > > *************************************************************/ > >static void > >thread1_code(void *arg) > >{ > > for(;;) { > > sleep (1); > > write(1,".",1); > > } > >} > > > >static void > >thread2_code(void *arg) > >{ > > for(;;) { > > sleep (3); > > write(1,"+",1); > > } > >} > > > >static void > >thread3_code(void *arg) > >{ > > for(;;) { > > sleep (5); > > write(1,"=",1); > > } > >} > > > > > > > >static struct thread_mailbox * > >main() > >{ > > struct kse_mailbox *k_mbox; > > > > /* set up global structures */ > > runq_last = &runqueue; > > runqueue = NULL; > > > > /* define two threads to run, they are runnable but not yet > >running */ > > runq_insert( makethread(&thread1_code, 0, NULL)); > > runq_insert( makethread(&thread2_code, 0, NULL)); > > /* and one which we will run ourself */ > > firstkse->curthread = makethread(&thread3_code, 0, NULL); > > > > /* start two KSEs in different KSEGRPs */ > > k_mbox = startkse(&first_kse); > > > > /* startksegrp(&second_kse); */ /* we can't do 2 KSEs yet */ > > /* One will be sufficient */ > > > > /* we are a thread, start the ball rolling */ > > /* let the kernel know we are it */ > > firstkse->mbox->current_thread = curthread->mbox; > > thread3_code(NULL); > >} > > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-arch" in the body of the message > > > Glenn Gombert > ggombert@imatowns.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 19:48:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id C7BB637B421; Tue, 5 Feb 2002 19:48:13 -0800 (PST) Received: from pool0362.cvx40-bradley.dialup.earthlink.net ([216.244.43.107] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16YJ47-0005Ql-00; Tue, 05 Feb 2002 19:48:11 -0800 Message-ID: <3C60A776.F4B0F660@mindspring.com> Date: Tue, 05 Feb 2002 19:48:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf References: <20020205191105.A25310@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > > > A better approach would be to make those items that are sysctls in > > > modules also TUNABLES, and then the problem goes away. > > > > Will this let them be set before load? > > Why not go read up on tunables? > > /* > * Infrastructure for tunable 'constants'. Value may be specified at compile > * time or kernel load time. Rules relating tunables together can be placed > * in a SYSINIT function at SI_SUB_TUNABLES with SI_ORDER_LAST. > */ It still doesn't tell me if I can set them before I load a particular *kernel module*, which was the context in which the question was asked. I think it can be done, as long as it is not done on a SYSCTL declared variable, which is a BSS initialization. > > There's a bad assumption in tunables, that they may be > > tuned after boot time, which is not true for things > > like sizes of zalloci() zones, which must be contiguous, > > There is? Since you don't actually know what TUNABLEs actually are, > aren't you going out on a bit of a limb here? No, I know what they are; you were just misunderstanding my previous questions context. The tunables are fetched later in the boot process than some initializations and allocations (e.g. anything before SI_UB_TUNABLES, which is most of the boot process). For example, none of the allocations in locore.s can be changed via a tunable, and they are some of the most interesting ones to want to change. If you'll remember, I was the one that provided the patch for the tunable tuning of the maxsockets and maxfiles and seperate tuning for max udp and tcp sockets, and wrote the SYSINIT and init_main.c code, which is what results in the SI_SUB_TUNABLES call occuring at all. > With regard to the original suggestion, I'm not in agreement that > module arguments should be tunables either. Many module arguments > should actually be hints (since they relate to instances of something > supported by a module). Those that are truly generic, or in the case > of a module which only creates a single instance should be passed at > module load time either directly (as with the loader's 'load' command, > via kldload, etc) or indirectly from a configuration file. > > TUNABLEs really exist to deal with the problem described above, not > the issue of module arguments. This is really the heart of the problem at hand: how do I do a tunable that I set in the loader that then effects the behaviour of, for example, ipfw.ko. The implication is that anything that is SYSCTL'able would need to go into the TUNABLE space; we can dismiss this idea (below), but we will find that we should try to make this as true as we can, anyway. The problem here is that you don't want to imply that you can change something you are OK to change at boot time, at runtime, when it's not OK. The other problem is that there are things that *aren't* tunable, and will always remain compile time. You aren't going to be able to change anything used before the call at SI_SUB_TUNABLES runs, and be able to expect a loader value change to have effect. So really, there are several sets of options: [ CTVs (compile time values) ] [ CTVs after SI_SUB_TUNABLES ] [ tunables ] [ readable sysctls ] [ read/write sysctls ] [ invisible] (the reverse overlap on tunables vs. read/write sysctls is because there are some things that are set before the call to SI_SUB_TUNABLES that can be reset via sysctl anyway) It makes sense to me to want to expose the entire set of tunables into the sysctl space, at all times. It also makes some sense to consider the tunables as "boot environment" -- that is, that you can set environment variables in the loader, which may or may not be used later by a module that is loaded (perhaps weeks) later. This kind of implies a need to break up the name space by module, rather than by function provided by the module, to avoid collisions. There is still a missing chunk, which is the ability to access this space before the SI_SUB_TUNABLES space, early on in the boot initialization process. I view this as "work to do". Also, some things will still never be tunable, e.g. you could tune the KVA space size, if you were willing to make the loader itself respect some tunables, like kernel base address, and PIC the entire kernel code, but doing this would make things run slower, since it is a well known (but infrequently revisited) assumption that PIC code is slower than absolute code. I would like to see several things: 1) Tunables treated as an environment 2) No tunables hidden from sysctl space 3) Seperation of tunables name space by module, rather than by function, if such modules are optional 4) Tunables respected at the start of the boot process, rather than after SI_SUB_TUNABLES 5) A more clear border between read-only and read-write (e.g. upping "maxfiles" does not up the number of network connections, because it does not change inpcb and tcpcb pool sizes, which are not adjustable at runtime, only at boot time). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 20: 0:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C91C737B426; Tue, 5 Feb 2002 20:00:54 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1640ri12907; Tue, 5 Feb 2002 21:00:53 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1640kL34391; Tue, 5 Feb 2002 21:00:47 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Feb 2002 21:00:25 -0700 (MST) Message-Id: <20020205.210025.88474927.imp@village.org> To: tlambert2@mindspring.com Cc: cjclark@alum.mit.edu, cristjc@earthlink.net, mike@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf From: "M. Warner Losh" In-Reply-To: <3C609B28.4B040672@mindspring.com> References: <20020205121345.B368@gohan.cjclark.org> <20020205.135658.102576700.imp@village.org> <3C609B28.4B040672@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <3C609B28.4B040672@mindspring.com> Terry Lambert writes: : Will this let them be set before load? Yes. : There's a bad assumption in tunables, that they may be : tuned after boot time, which is not true for things : like sizes of zalloci() zones, which must be contiguous, : and whose size prevents reallocation, and whose use : before reallocation would lead to fragmentation. No. Tunables can't be set after boot time. They are hints in the kenrel env that people get to with the TUNABLE* macros. Maybe you are thinking of sysctls? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 20: 5:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D2CC737B423; Tue, 5 Feb 2002 20:05:35 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1645Yi12935; Tue, 5 Feb 2002 21:05:34 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1645XL34425; Tue, 5 Feb 2002 21:05:33 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Feb 2002 21:05:11 -0700 (MST) Message-Id: <20020205.210511.58456203.imp@village.org> To: msmith@hub.freebsd.org Cc: tlambert2@mindspring.com, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf From: "M. Warner Losh" In-Reply-To: <20020205191105.A25310@hub.freebsd.org> References: <20020205191105.A25310@hub.freebsd.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020205191105.A25310@hub.freebsd.org> Mike Smith writes: : With regard to the original suggestion, I'm not in agreement that : module arguments should be tunables either. Many module arguments : should actually be hints (since they relate to instances of something : supported by a module). Those that are truly generic, or in the case : of a module which only creates a single instance should be passed at : module load time either directly (as with the loader's 'load' command, : via kldload, etc) or indirectly from a configuration file. True. If hints have been MFC'd, then this would be great (I lost track of if they had or not after getting them into MFC shape and having Peter rework them, I never got back to the MFC). I agree that hints are a better mechanism for some things. I guess what I was really saying was "using some mechanism that uses loader variables such as hints or TUNABLE." Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 20: 7:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E926837B416; Tue, 5 Feb 2002 20:07:14 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1647Di12953; Tue, 5 Feb 2002 21:07:13 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1647CL34438; Tue, 5 Feb 2002 21:07:12 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 05 Feb 2002 21:06:51 -0700 (MST) Message-Id: <20020205.210651.35502362.imp@village.org> To: tlambert2@mindspring.com Cc: msmith@hub.freebsd.org, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf From: "M. Warner Losh" In-Reply-To: <3C60A776.F4B0F660@mindspring.com> References: <20020205191105.A25310@hub.freebsd.org> <3C60A776.F4B0F660@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <3C60A776.F4B0F660@mindspring.com> Terry Lambert writes: : I would like to see several things: : : 1) Tunables treated as an environment They already are. : 2) No tunables hidden from sysctl space Only those tunables that are specifically exported to sysctl space are not hidden. : 3) Seperation of tunables name space by module, : rather than by function, if such modules are : optional That's already done too, but hints provide an even better mechanism because that can be done on a per instance basis. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 20:14:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 9495237B42B for ; Tue, 5 Feb 2002 20:14:13 -0800 (PST) Received: (qmail 24341 invoked from network); 6 Feb 2002 04:14:11 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([65.91.155.10]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Feb 2002 04:14:11 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <79300.1012474898@axl.seasidesoftware.co.za> Date: Tue, 05 Feb 2002 23:14:10 -0500 (EST) From: John Baldwin To: Sheldon Hearn Subject: RE: Adding support for a global src tree serial number Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 31-Jan-02 Sheldon Hearn wrote: > > Hi folks, > > I'd like to propose the addition of a global src tree serial number that > uniquely identifies an imaginary snapshot of the src tree. p4 Each commit has a change number that is depot-wide, thus you always have a current change number you can check out to. It also means that a commit that touches 10 files is one logical change so you can merge an entire chagne in one sweep rather than having to hunt for all teh files affected like we do now. It also means it's easy to get a diff of an entire commit. The p4 client still needs some work to be truly useful, but that is a better long term goal. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 20:28:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id A798737B421; Tue, 5 Feb 2002 20:28:09 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 696B410DDF7; Tue, 5 Feb 2002 20:28:09 -0800 (PST) Date: Tue, 5 Feb 2002 20:28:09 -0800 From: Alfred Perlstein To: "M. Warner Losh" Cc: tlambert2@mindspring.com, cjclark@alum.mit.edu, cristjc@earthlink.net, mike@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf Message-ID: <20020205202809.C59017@elvis.mu.org> References: <20020205121345.B368@gohan.cjclark.org> <20020205.135658.102576700.imp@village.org> <3C609B28.4B040672@mindspring.com> <20020205.210025.88474927.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020205.210025.88474927.imp@village.org>; from imp@village.org on Tue, Feb 05, 2002 at 09:00:25PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * M. Warner Losh [020205 20:01] wrote: > In message: <3C609B28.4B040672@mindspring.com> > Terry Lambert writes: > : Will this let them be set before load? > > Yes. > > : There's a bad assumption in tunables, that they may be > : tuned after boot time, which is not true for things > : like sizes of zalloci() zones, which must be contiguous, > : and whose size prevents reallocation, and whose use > : before reallocation would lead to fragmentation. > > No. Tunables can't be set after boot time. They are hints in the > kenrel env that people get to with the TUNABLE* macros. Maybe you are > thinking of sysctls? No, I think he meant compile time instead of boot time, someone may set maxuser = 0 via loader and cause bad behaviour, he seems to want a loader tunable for this. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 5 22:33: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 5DB5737B425; Tue, 5 Feb 2002 22:32:56 -0800 (PST) Received: from pool0120.cvx22-bradley.dialup.earthlink.net ([209.179.198.120] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16YLdT-0003W2-00; Tue, 05 Feb 2002 22:32:52 -0800 Message-ID: <3C60CE0D.34F10210@mindspring.com> Date: Tue, 05 Feb 2002 22:32:45 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: "M. Warner Losh" , cjclark@alum.mit.edu, cristjc@earthlink.net, mike@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf References: <20020205121345.B368@gohan.cjclark.org> <20020205.135658.102576700.imp@village.org> <3C609B28.4B040672@mindspring.com> <20020205.210025.88474927.imp@village.org> <20020205202809.C59017@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > No, I think he meant compile time instead of boot time, someone may > set maxuser = 0 via loader and cause bad behaviour, he seems to > want a loader tunable for this. Yes. Basically: o I want to be able to change everything I can at compile time. o I want to be able to change everything I can at boot time, except those things that can *only* be changed at compile time. o I want to be able to change everything I can at run time, except those things that can *only* be changed at boot time or compile time. In other words, the set of things increases towards boot time, and the set of modifiable things decreases towards run time. The change that Matt suggested for the loader tunable is OK to do this, but... it really points up the difference between tunable space (loader environment), sysctl space, and compile time options. Obviously, the ideal situation is that everything is tunable at runtime, without restriction. The next best thing is that the set of stuff which can be tunable is a group of nested sets, with the set being delimited by read/write vs. read-only. Right now there are about 6 different sets; this _could_ be collapsed to 3. Is there any good reason that all tunables should not be in sysctl space, or that all sysctl values should not be capable of having inital values set in the loader, and that the set of compile time things be limited to the compiler technology limits (e.g. kernel base address, KVA space size, etc.)? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 4:51:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from businessconnect.businessconnect.nl (www.bconnect.nl [194.109.100.125]) by hub.freebsd.org (Postfix) with ESMTP id 8182037B42C for ; Wed, 6 Feb 2002 04:51:31 -0800 (PST) Received: from [195.38.249.132] by businessconnect.businessconnect.nl (Post.Office MTA v3.5 release 215 ID# 0-53760U1000L100S0V35) with SMTP id nl for ; Wed, 6 Feb 2002 13:44:25 +0000 From: Kempen Jobs BV To: freebsd-arch@FreeBSD.org Subject: De Banenladder X-Mailer: TOS 6.0 SMTP SERVER Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 6 Feb 2002 13:44:25 +0000 Message-ID: <20020206134425531.DDA312@businessconnect.businessconnect.nl@[195.38.249.132]> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Op zoek naar een baan, opleiding, personeel of informatie over een bedrijf? Kijk dan op www.banenladder.nl De Banenladder To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 7:23:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 44EB537B41F for ; Wed, 6 Feb 2002 07:23:15 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id B45BD47; Wed, 6 Feb 2002 09:23:14 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g16FNBZ66140; Wed, 6 Feb 2002 09:23:11 -0600 (CST) (envelope-from nectar) Date: Wed, 6 Feb 2002 09:23:11 -0600 From: "Jacques A. Vidrine" To: John Hay Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/contrib/bind FREEBSD-Xlist Message-ID: <20020206152311.GB66083@madman.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , John Hay , freebsd-arch@freebsd.org References: <20020206144913.GC65827@madman.nectar.cc> <200202061514.g16FE3A70349@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202061514.g16FE3A70349@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Feb 06, 2002 at 05:14:03PM +0200, John Hay wrote: > What about going to v9.x? At least for -current, although looking at > the security history of 8.x, I think we should really think about > doing it even for -stable. Leave the bind8 port for those guys that > need some of its features. That's something that is worthy of being discussed. Personally, I use BIND 9. But I know many people still run BIND 8 --- including heavy hitters like the root name servers operators. FWIW, I stepped in to update BIND to 8.3.1-REL as Security Officer, because of recent security bug fixes. In other words, I did it to fix something broken. Moving to BIND 9 is a feature enhancement that will require work on the part of our users. I'd like to see some discussion about the tradeoffs before we decide to make such a move. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 7:31: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id E1A9537B422; Wed, 6 Feb 2002 07:30:55 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g16FUq970877; Wed, 6 Feb 2002 17:30:52 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200202061530.g16FUq970877@zibbi.icomtek.csir.co.za> Subject: Re: cvs commit: src/contrib/bind FREEBSD-Xlist In-Reply-To: <20020206152311.GB66083@madman.nectar.cc> from "Jacques A. Vidrine" at "Feb 6, 2002 09:23:11 am" To: nectar@freebsd.org (Jacques A. Vidrine) Date: Wed, 6 Feb 2002 17:30:52 +0200 (SAT) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Wed, Feb 06, 2002 at 05:14:03PM +0200, John Hay wrote: > > What about going to v9.x? At least for -current, although looking at > > the security history of 8.x, I think we should really think about > > doing it even for -stable. Leave the bind8 port for those guys that > > need some of its features. > > That's something that is worthy of being discussed. Personally, I use > BIND 9. But I know many people still run BIND 8 --- including heavy > hitters like the root name servers operators. > > FWIW, I stepped in to update BIND to 8.3.1-REL as Security Officer, > because of recent security bug fixes. In other words, I did it to fix > something broken. Moving to BIND 9 is a feature enhancement that will > require work on the part of our users. I'd like to see some > discussion about the tradeoffs before we decide to make such a move. Well like I tried to imply in my previous email, you can look at "upgrading to v9.x" as a feature enhancement or measured against the history of v8 as preventative security fixes. :-) I say let those who want to live on the security edge do so from ports/packages. :-) Just MHO. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 9:42:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1536937B433 for ; Wed, 6 Feb 2002 09:42:18 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id g16HdCM10991 for ; Wed, 6 Feb 2002 18:39:12 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: Timecounter patch for review... From: Poul-Henning Kamp Date: Wed, 06 Feb 2002 18:39:12 +0100 Message-ID: <10989.1013017152@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As I have warned about earlier, I have modfied the timecounter code to simplify the arithmetic at the bottom of it. http://phk.freebsd.dk/patch/timecounter.patch This patch changes timecounters to run off a fundamental data type "struct bintime" which is "time_t with 64 bit fractional seconds". This avoids a lot of the maddening constructs needed for arithmetic on timeval/timespec values: if (foo.tv_usec > 1000000) { foo.tv_usec -= 1000000; foo.tv_sec++; } In particular delta times as used for I/O statistics or process resource usage will be cheaper to computer. Conversions to/from the struct timeval/timespec is done with a single multiplication. 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 11:59:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 0B27E37B419 for ; Wed, 6 Feb 2002 11:59:24 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020206195923.SKSE7443.rwcrmhc54.attbi.com@peter3.wemm.org> for ; Wed, 6 Feb 2002 19:59:23 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g16JxNs82275 for ; Wed, 6 Feb 2002 11:59:23 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 6350039F1; Wed, 6 Feb 2002 11:59:18 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dan Eischen Cc: arch@freebsd.org Subject: Re: getsetcontext system call In-Reply-To: <3C5FF99D.87719821@vigrid.com> Date: Wed, 06 Feb 2002 11:59:18 -0800 From: Peter Wemm Message-Id: <20020206195918.6350039F1@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dan Eischen wrote: > Diffs are at: > > http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs Possible problem: +struct fp387 { + unsigned long fp387_regs[44]; +}; + +struct fpxmm { + unsigned long fpxmm_regs[126]; +} __attribute__((aligned(16))); ... - unsigned long fpr_env[7]; - unsigned char fpr_acc[8][10]; - unsigned long fpr_ex_sw; - unsigned char fpr_pad[64]; + union { + struct fp387 fps_87; + struct fpxmm fps_xmm; + } fpu_state; .... - int sc_fpregs[28]; /* machine state (FPU): */ - int sc_spare[17]; + int sc_fpformat; + int sc_ownedfp; + int sc_spare1[1]; + int sc_fpregs[128]; + int sc_spare2[8]; ... and: #ifdef CPU_ENABLE_SSE if (cpu_fxsr) { - set_fpregs_xmm((struct save87 *)fpregs, - &td->td_pcb->pcb_save.sv_xmm); + set_fpregs_xmm((struct save87 *)&fpregs->fpu_state.fps_87, + &td->td_pcb->pcb_save.sv_xmm); return (0); } #endif /* CPU_ENABLE_SSE */ - bcopy(fpregs, &td->td_pcb->pcb_save.sv_87, sizeof *fpregs); + bcopy(&fpregs->fpu_state.fps_87, &td->td_pcb->pcb_save.sv_87, + sizeof(fpregs->fpu_state.fps_87)); return (0); The 'long fpxmm_regs[126];' looks mighty suspicious.. I think it should be 128, since the fxsave dump area is 512 bytes long. Secondly, why does the xmm state save/restore code use the fps_87 union member instead of the fps_xmm member? #if 0 +#ifdef _KERNEL +/* grrr, arghh, what's the correct way to ensure struct thread is declared? */ +#include +#include + +void get_mcontext(struct thread *, mcontext_t *mcp); +int set_mcontext(struct thread *, const mcontext_t *mcp); +#endif +#endif #endif /* !_MACHINE_UCONTEXT_H_ */ just forward declare 'struct thread;' - you've done that elsewhere. eg: #ifdef _KERNEL +struct fpreg; struct pcb; .. do the same for 'struct thread;' right there instead. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 14:26:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 780DE37B41E for ; Wed, 6 Feb 2002 14:26:17 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g16MQFCv002321; Wed, 6 Feb 2002 17:26:16 -0500 (EST) Date: Wed, 6 Feb 2002 17:26:15 -0500 (EST) From: Daniel Eischen To: Peter Wemm Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: <20020206195918.6350039F1@overcee.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Feb 2002, Peter Wemm wrote: > Dan Eischen wrote: > > > Diffs are at: > > > > http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > > http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs > > Possible problem: > > +struct fp387 { > + unsigned long fp387_regs[44]; > +}; > + > +struct fpxmm { > + unsigned long fpxmm_regs[126]; > +} __attribute__((aligned(16))); > > ... > - unsigned long fpr_env[7]; > - unsigned char fpr_acc[8][10]; > - unsigned long fpr_ex_sw; > - unsigned char fpr_pad[64]; > + union { > + struct fp387 fps_87; > + struct fpxmm fps_xmm; > + } fpu_state; > > .... > > - int sc_fpregs[28]; /* machine state (FPU): */ > - int sc_spare[17]; > + int sc_fpformat; > + int sc_ownedfp; > + int sc_spare1[1]; > + int sc_fpregs[128]; > + int sc_spare2[8]; > > ... > > and: > > #ifdef CPU_ENABLE_SSE > if (cpu_fxsr) { > - set_fpregs_xmm((struct save87 *)fpregs, > - &td->td_pcb->pcb_save.sv_xmm); > + set_fpregs_xmm((struct save87 *)&fpregs->fpu_state.fps_87, > + &td->td_pcb->pcb_save.sv_xmm); > return (0); > } > #endif /* CPU_ENABLE_SSE */ > - bcopy(fpregs, &td->td_pcb->pcb_save.sv_87, sizeof *fpregs); > + bcopy(&fpregs->fpu_state.fps_87, &td->td_pcb->pcb_save.sv_87, > + sizeof(fpregs->fpu_state.fps_87)); > return (0); > > The 'long fpxmm_regs[126];' looks mighty suspicious.. I think it should be > 128, since the fxsave dump area is 512 bytes long. Secondly, why does the > xmm state save/restore code use the fps_87 union member instead of the > fps_xmm member? Concur; will change size of pxmm_regs to 128. As to set_fpregs(), it looks like it wants to convert an x87 FPU state to an SSE FPU state. The opposite seems to be the case for fill_fpregs(). I'm not exactly sure how and why fill_fpregs() and set_fpregs() are used. Since we make struct fpreg large enough to hold either x87 or SSE FPU state, do we even care about converting between the two different formats any longer? > #if 0 > +#ifdef _KERNEL > +/* grrr, arghh, what's the correct way to ensure struct thread is declared? */ > +#include > +#include > + > +void get_mcontext(struct thread *, mcontext_t *mcp); > +int set_mcontext(struct thread *, const mcontext_t *mcp); > +#endif > +#endif > #endif /* !_MACHINE_UCONTEXT_H_ */ > > just forward declare 'struct thread;' - you've done that elsewhere. eg: OK. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 14:41:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by hub.freebsd.org (Postfix) with ESMTP id DEBD237B405 for ; Wed, 6 Feb 2002 14:41:13 -0800 (PST) Received: from kanpc.gte.com (localhost [127.0.0.1]) by h132-197-179-27.gte.com (8.11.6/8.11.6) with SMTP id g16Mew129115; Wed, 6 Feb 2002 17:40:58 -0500 (EST) (envelope-from ak03@gte.com) Date: Wed, 6 Feb 2002 17:40:58 -0500 From: Alexander Kabaev To: Daniel Eischen Cc: peter@wemm.org, eischen@vigrid.com, arch@FreeBSD.ORG Subject: Re: getsetcontext system call Message-Id: <20020206174058.60c8cf14.ak03@gte.com> In-Reply-To: References: <20020206195918.6350039F1@overcee.wemm.org> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.7.0claws49 (GTK+ 1.2.10; i386--freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > As to set_fpregs(), it looks like it wants to convert an x87 > FPU state to an SSE FPU state. The opposite seems to be the > case for fill_fpregs(). I'm not exactly sure how and why > fill_fpregs() and set_fpregs() are used. Since we make struct > fpreg large enough to hold either x87 or SSE FPU state, do we > even care about converting between the two different formats > any longer? These functions are used by ptrace and consequently by GDB. GDB expects to get floating point register state in predictable format regardless of whether SSE has been enabled in CPU or not. Linux also adds new GET/SET_FPXREGS requests to get complete SSE floating point registers for use by SSE aware debuggers. As far as I can tell, GDB 5.x is using these new requests on Linux, while 4.18 doesn't. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 19:22: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id DD37537B405 for ; Wed, 6 Feb 2002 19:22:05 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020207032205.EIQA7443.rwcrmhc54.attbi.com@peter3.wemm.org> for ; Thu, 7 Feb 2002 03:22:05 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g173M5s83604 for ; Wed, 6 Feb 2002 19:22:05 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 73E9239F1; Wed, 6 Feb 2002 19:22:05 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Daniel Eischen Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: Date: Wed, 06 Feb 2002 19:22:05 -0800 From: Peter Wemm Message-Id: <20020207032205.73E9239F1@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > On Wed, 6 Feb 2002, Peter Wemm wrote: > > Dan Eischen wrote: > > > > > Diffs are at: > > > > > > http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > > > http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs > > [..] > As to set_fpregs(), it looks like it wants to convert an x87 > FPU state to an SSE FPU state. The opposite seems to be the > case for fill_fpregs(). I'm not exactly sure how and why > fill_fpregs() and set_fpregs() are used. Since we make struct > fpreg large enough to hold either x87 or SSE FPU state, do we > even care about converting between the two different formats > any longer? I think we have to, because xmm state is a superset of the x87 state, and we need to not f*ck up defined interface to ptrace(PT_SETFPREGS etc and procfs where you supply an entire 'struct fpregs' to these calls. Imagine running a 4.x binary where it does a ptrace(PT_GETFPREGS, &fpregs); where '&fpregs' points to the traditional sized structure. You cant just change the size of it without doing things like assigning new syscall numbers to ptrace(2) etc and adding some workaround glue to procfs. We may need to do what linux does (SET/SET_FPXREGS) and maybe /proc/*/fpxregs. Ugh. Anyway, I dont see that you can just change 'struct fpregs' that easily. The union may have to be moved up higher for x86.. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 20:50: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D277837B428 for ; Wed, 6 Feb 2002 20:49:46 -0800 (PST) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.1/8.12.1) with ESMTP id g174njEj010722; Wed, 6 Feb 2002 23:49:46 -0500 (EST) Date: Wed, 6 Feb 2002 23:49:45 -0500 (EST) From: Daniel Eischen To: Peter Wemm Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: <20020207032205.73E9239F1@overcee.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Feb 2002, Peter Wemm wrote: > Daniel Eischen wrote: > > On Wed, 6 Feb 2002, Peter Wemm wrote: > > > Dan Eischen wrote: > > > > > > > Diffs are at: > > > > > > > > http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > > > > http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs > > > > [..] > > As to set_fpregs(), it looks like it wants to convert an x87 > > FPU state to an SSE FPU state. The opposite seems to be the > > case for fill_fpregs(). I'm not exactly sure how and why > > fill_fpregs() and set_fpregs() are used. Since we make struct > > fpreg large enough to hold either x87 or SSE FPU state, do we > > even care about converting between the two different formats > > any longer? > > I think we have to, because xmm state is a superset of the x87 state, and > we need to not f*ck up defined interface to ptrace(PT_SETFPREGS etc and > procfs where you supply an entire 'struct fpregs' to these calls. OK, what if we leave struct fpreg unchanged? > Imagine running a 4.x binary where it does a ptrace(PT_GETFPREGS, &fpregs); > where '&fpregs' points to the traditional sized structure. You cant just > change the size of it without doing things like assigning new syscall numbers > to ptrace(2) etc and adding some workaround glue to procfs. Right, I don't want to get into that now. Some time later we could add the format specifier in struct fpreg and teach consumers how to decipher it. How else could users of ptrace(PT_GETFPREGS, &fpregs) know what the FP format was? If the format was included in the struct, then they could figure out on their own which format to use. > We may need to do what linux does (SET/SET_FPXREGS) and maybe /proc/*/fpxregs. > Ugh. Anyway, I dont see that you can just change 'struct fpregs' that > easily. The union may have to be moved up higher for x86.. Is it OK to leave struct fpreg unchanged for now? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 22:36:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id C8F5937B423 for ; Wed, 6 Feb 2002 22:36:14 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020207063614.IXAQ7443.rwcrmhc54.attbi.com@peter3.wemm.org> for ; Thu, 7 Feb 2002 06:36:14 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g176aEs84271 for ; Wed, 6 Feb 2002 22:36:14 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id C1C9839F1; Wed, 6 Feb 2002 22:36:13 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Daniel Eischen Cc: Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: Date: Wed, 06 Feb 2002 22:36:13 -0800 From: Peter Wemm Message-Id: <20020207063613.C1C9839F1@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Eischen wrote: > On Wed, 6 Feb 2002, Peter Wemm wrote: > > Daniel Eischen wrote: > > > On Wed, 6 Feb 2002, Peter Wemm wrote: > > > > Dan Eischen wrote: > > > > > > > > > Diffs are at: > > > > > > > > > > http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs > > > > > http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs > > > > > > [..] > > > As to set_fpregs(), it looks like it wants to convert an x87 > > > FPU state to an SSE FPU state. The opposite seems to be the > > > case for fill_fpregs(). I'm not exactly sure how and why > > > fill_fpregs() and set_fpregs() are used. Since we make struct > > > fpreg large enough to hold either x87 or SSE FPU state, do we > > > even care about converting between the two different formats > > > any longer? > > > > I think we have to, because xmm state is a superset of the x87 state, and > > we need to not f*ck up defined interface to ptrace(PT_SETFPREGS etc and > > procfs where you supply an entire 'struct fpregs' to these calls. > > OK, what if we leave struct fpreg unchanged? > > > Imagine running a 4.x binary where it does a ptrace(PT_GETFPREGS, &fpregs); > > where '&fpregs' points to the traditional sized structure. You cant just > > change the size of it without doing things like assigning new syscall numbe rs > > to ptrace(2) etc and adding some workaround glue to procfs. > > Right, I don't want to get into that now. Some time later we could > add the format specifier in struct fpreg and teach consumers how to > decipher it. How else could users of ptrace(PT_GETFPREGS, &fpregs) > know what the FP format was? If the format was included in the struct, > then they could figure out on their own which format to use. > > > We may need to do what linux does (SET/SET_FPXREGS) and maybe /proc/*/fpxre gs. > > Ugh. Anyway, I dont see that you can just change 'struct fpregs' that > > easily. The union may have to be moved up higher for x86.. > > Is it OK to leave struct fpreg unchanged for now? To be quite honest, I think that's the right thing to do for now, until it is clear what the "right" thing to do is. ptrace(2) isn't going to survive KSE unscathed, so perhaps we need an enhanced ptrace interface at some point that doesn't suffer from this kind of interface fragility. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 6 23:59:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail3.rambler.ru (mail3.rambler.ru [217.73.192.32]) by hub.freebsd.org (Postfix) with SMTP id 83EEC37B427 for ; Wed, 6 Feb 2002 23:59:15 -0800 (PST) Received: from 216.5.73.30 by rambler.ru with SMTP id AA25025 for freebsd-arch@freebsd.org; Thu, 7 Feb 2002 10:52:57 +0300 (MSK) From: Доброжелатель To: "" <> Subject: как люди зарабатывают в интернете??? Organization: нету такой! :) Reply-To: S-AS@yandex.ru X-Mailer: X-Mailer Mime-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Date: Thu, 7 Feb 2002 10:55:05 +0300 Message-Id: <3C623259.AA25025@mail3.rambler.ru> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Доброго времени суток! Если Вам интересно, как люди зарабатывают деньги в сети интернет и вы сами хотите ихзарабатывать... То $5 + немного усердия = получайте деньги всю жизнь Подробности: http://5dolors.non.ru или http://5dolors.maza.ru/ Зарегистрировавшись, вы получите бесплатную консультацию и набор программ необходимых для работы!!! Желаю удачи! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 7 22:54:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 172FC37B404; Thu, 7 Feb 2002 22:54:44 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id AAB63216F; Fri, 8 Feb 2002 07:54:41 +0100 (CET) Date: Fri, 8 Feb 2002 07:54:41 +0100 From: Jeroen Ruigrok/asmodai To: John Hay Cc: "Jacques A. Vidrine" , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/contrib/bind FREEBSD-Xlist Message-ID: <20020208065440.GB52378@daemon.ninth-circle.org> References: <20020206152311.GB66083@madman.nectar.cc> <200202061530.g16FUq970877@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202061530.g16FUq970877@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.3.24i Organisation: Ninth Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20020206 16:45], John Hay (jhay@icomtek.csir.co.za) wrote: >Well like I tried to imply in my previous email, you can look at >"upgrading to v9.x" as a feature enhancement or measured against the >history of v8 as preventative security fixes. :-) That argument does not hold much ground. When I discussed BIND 9 with Kris Kennaway a bunch of months ago he decided to look at the code a bit. A day later the BIND folks had a patchset to fix a lot of security problems noted by one auditor. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ A woman either loves or hates; she knows no medium. - Publilius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 8 0:53:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id B642A37B41B; Fri, 8 Feb 2002 00:53:36 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g188rRO39489; Fri, 8 Feb 2002 10:53:27 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200202080853.g188rRO39489@zibbi.icomtek.csir.co.za> Subject: Re: cvs commit: src/contrib/bind FREEBSD-Xlist In-Reply-To: <20020208065440.GB52378@daemon.ninth-circle.org> from Jeroen Ruigrok/asmodai at "Feb 8, 2002 07:54:41 am" To: asmodai@wxs.nl (Jeroen Ruigrok/asmodai) Date: Fri, 8 Feb 2002 10:53:27 +0200 (SAT) Cc: nectar@freebsd.org, freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > -On [20020206 16:45], John Hay (jhay@icomtek.csir.co.za) wrote: > >Well like I tried to imply in my previous email, you can look at > >"upgrading to v9.x" as a feature enhancement or measured against the > >history of v8 as preventative security fixes. :-) > > That argument does not hold much ground. > > When I discussed BIND 9 with Kris Kennaway a bunch of months ago he > decided to look at the code a bit. A day later the BIND folks had a > patchset to fix a lot of security problems noted by one auditor. So are they then selective of what they put on their security page? http://www.isc.org/products/BIND/bind-security.html Or are we just lucky that the dark side haven't turned their efforts to v9 servers yet? John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 8 2:19:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 7C1F537B41B; Fri, 8 Feb 2002 02:19:25 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id D9466216F; Fri, 8 Feb 2002 11:19:23 +0100 (CET) Date: Fri, 8 Feb 2002 11:19:23 +0100 From: Jeroen Ruigrok/asmodai To: John Hay Cc: nectar@freebsd.org, freebsd-arch@freebsd.org Subject: Re: cvs commit: src/contrib/bind FREEBSD-Xlist Message-ID: <20020208101923.GE52378@daemon.ninth-circle.org> References: <20020208065440.GB52378@daemon.ninth-circle.org> <200202080853.g188rRO39489@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202080853.g188rRO39489@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.3.24i Organisation: Ninth Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20020208 10:15], John Hay (jhay@icomtek.csir.co.za) wrote: >So are they then selective of what they put on their security page? > >http://www.isc.org/products/BIND/bind-security.html I am not saying they're selective, but I know Kris did some fixing for potential problems. >Or are we just lucky that the dark side haven't turned their efforts >to v9 servers yet? I think so. BIND 8 is still the major player out there. As soon as, say, FreeBSD would ship with BIND 9 in the base, you can be sure attention will shift. I mean, it is ironic that one person already found a heap of potential problem areas on a single sweep, whereas the piece of software claims to have been rewritten from scratch to ensure more security [IIRC the texts correctly]. Of course, a rewrite is a daunting task, but do not flaunt around stating the improved security and auditing when one person points out a bunch of problematic cases. Caveat emptor. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ Love will draw us in, to wipe our Tears away... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 8 3:57:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-165-226-40.dsl.lsan03.pacbell.net [64.165.226.40]) by hub.freebsd.org (Postfix) with ESMTP id E206537B41D; Fri, 8 Feb 2002 03:57:34 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C6FD966C76; Fri, 8 Feb 2002 03:57:34 -0800 (PST) Date: Fri, 8 Feb 2002 03:57:34 -0800 From: Kris Kennaway To: Jeroen Ruigrok/asmodai Cc: John Hay , nectar@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/contrib/bind FREEBSD-Xlist Message-ID: <20020208035734.A79602@xor.obsecurity.org> References: <20020208065440.GB52378@daemon.ninth-circle.org> <200202080853.g188rRO39489@zibbi.icomtek.csir.co.za> <20020208101923.GE52378@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020208101923.GE52378@daemon.ninth-circle.org>; from asmodai@wxs.nl on Fri, Feb 08, 2002 at 11:19:23AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 08, 2002 at 11:19:23AM +0100, Jeroen Ruigrok/asmodai wrote: > I mean, it is ironic that one person already found a heap of potential > problem areas on a single sweep, whereas the piece of software claims to > have been rewritten from scratch to ensure more security [IIRC the texts > correctly]. Of course, a rewrite is a daunting task, but do not flaunt > around stating the improved security and auditing when one person points > out a bunch of problematic cases. I don't think it's as bad as you're suggesting; I found a bunch of format string errors in bind9, but AFAICT none of them were exploitable. bind8 had some scarier ones, but fortunately they also seemed to be non-exploitable. I haven't spent much time auditing bind code, but from what I saw of bind9 it seems better-written. Kris --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8Y70uWry0BWjoQKURAs2eAKCHBU1wncVLOUwTkeaSBBADhqFwgwCgkwuE a7zeF2UzC73TcRiS4xS7gMM= =x1k7 -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 8 10: 0:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 20AA637B422; Fri, 8 Feb 2002 10:00:15 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id g18Hxxp08992; Fri, 8 Feb 2002 12:59:59 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020208065440.GB52378@daemon.ninth-circle.org> References: <20020206152311.GB66083@madman.nectar.cc> <200202061530.g16FUq970877@zibbi.icomtek.csir.co.za> <20020208065440.GB52378@daemon.ninth-circle.org> Date: Fri, 8 Feb 2002 12:59:58 -0500 To: Jeroen Ruigrok/asmodai , John Hay From: Garance A Drosihn Subject: Re: cvs commit: src/contrib/bind FREEBSD-Xlist Cc: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:54 AM +0100 2/8/02, Jeroen Ruigrok/asmodai wrote: >-On [20020206 16:45], John Hay (jhay@icomtek.csir.co.za) wrote: >>Well like I tried to imply in my previous email, you can look at >>"upgrading to v9.x" as a feature enhancement or measured against the >>history of v8 as preventative security fixes. :-) > >That argument does not hold much ground. > >When I discussed BIND 9 with Kris Kennaway a bunch of months ago he >decided to look at the code a bit. A day later the BIND folks had a >patchset to fix a lot of security problems noted by one auditor. This tells me that a bunch of months ago, they were taking the prudent step of paying attention to someone who audited their code, and they tried to fix the problems which were found. Are they still coming out with frequent patchsets to fix a lot of security problems? [I don't have idea idea if they are or they are not, I just think it might be worthwhile to revisit the idea if this has not been considered for several months...] -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 9 0: 5:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7209737B405 for ; Sat, 9 Feb 2002 00:05:29 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g1984xD26126; Sat, 9 Feb 2002 03:05:24 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 9 Feb 2002 03:04:58 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Peter Wemm Cc: Daniel Eischen , Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: <20020207063613.C1C9839F1@overcee.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Feb 2002, Peter Wemm wrote: > To be quite honest, I think that's the right thing to do for now, until > it is clear what the "right" thing to do is. ptrace(2) isn't going to > survive KSE unscathed, so perhaps we need an enhanced ptrace interface > at some point that doesn't suffer from this kind of interface fragility. Preferably one that doesn't require procfs, given how hard we've been trying to eliminate it :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 9 0:20:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id D123637B416; Sat, 9 Feb 2002 00:20:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020209082008.VLBK2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Sat, 9 Feb 2002 08:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA05826; Sat, 9 Feb 2002 00:10:21 -0800 (PST) Date: Sat, 9 Feb 2002 00:10:19 -0800 (PST) From: Julian Elischer To: Robert Watson Cc: Peter Wemm , Daniel Eischen , Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ptrace doesn't use procfs as it is... On Sat, 9 Feb 2002, Robert Watson wrote: > > On Wed, 6 Feb 2002, Peter Wemm wrote: > > > To be quite honest, I think that's the right thing to do for now, until > > it is clear what the "right" thing to do is. ptrace(2) isn't going to > > survive KSE unscathed, so perhaps we need an enhanced ptrace interface > > at some point that doesn't suffer from this kind of interface fragility. > > Preferably one that doesn't require procfs, given how hard we've been > trying to eliminate it :-). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 9 3:25:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0964437B41A; Sat, 9 Feb 2002 03:25:43 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 63CA25341; Sat, 9 Feb 2002 12:25:40 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Julian Elischer Cc: Robert Watson , Peter Wemm , Daniel Eischen , Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call References: From: Dag-Erling Smorgrav Date: 09 Feb 2002 12:25:39 +0100 In-Reply-To: Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer writes: > ptrace doesn't use procfs as it is... s/as it is/any more/, thanks to y.t. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 9 8:40:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4DF2A37B417 for ; Sat, 9 Feb 2002 08:40:18 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g19Gd2D32061; Sat, 9 Feb 2002 11:39:02 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 9 Feb 2002 11:39:02 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: Peter Wemm , Daniel Eischen , Dan Eischen , arch@FreeBSD.ORG Subject: Re: getsetcontext system call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 9 Feb 2002, Julian Elischer wrote: > ptrace doesn't use procfs as it is... It used to be the case that the majority of our debugging tools relied heavily on /proc to function, and that the ptrace() implementation had hooks into the procfs implementation (although it didn't actually require that /proc be mounted). Happily, DES has invested time in both reducing dependencies (truss, for example), and cleaning up procfs, so things are much improved. There are still a few dependencies, but the only one that really comes to mind is that 'procfs -e' relies on /proc/pid/mem to find environmental variables. Mind you, I'm not objecting to procfs learning about KSE, threads, etc, I just want to avoid requiring it in order to have a useful debugging environment. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message