From owner-freebsd-arch Sun Jan 19 7:43:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB13937B419 for ; Sun, 19 Jan 2003 07:43:40 -0800 (PST) Received: from postbode02.zonnet.nl (postbode02.zonnet.nl [62.58.50.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 605EB43FC2 for ; Sun, 19 Jan 2003 07:43:27 -0800 (PST) (envelope-from lijst10sec@hotmail.com) Received: (qmail 25769 invoked by uid 0); 19 Jan 2003 15:43:25 -0000 Received: from unknown (HELO smtp.com) ([62.59.141.29]) (envelope-sender ) by postbode02.zonnet.nl (qmail-ldap-1.03) with SMTP for ; 19 Jan 2003 15:43:25 -0000 Date: Sun, 19 Jan 2003 15:54:13 +0100 From: lijst10sec@hotmail.com Subject: First Seconds: 40+ dating To: lijst10sec@hotmail.com Reply-To: info@firstseconds.nl X-Bulkmail: 2.05 Message-Id: <20030119154329.605EB43FC2@mx1.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 L.s. Onder single dertigers is "speeddating" een trend. Het snelle daten is een vrolijke en spannende manier om in korte tijd veel mensen te ontmoeten. First Seconds organiseert deze vorm van kennismaken voor alleenstaanden van begin 40 tot eind 50. In Hotel New York te Rotterdam op 23 februari zullen 25 dames 25 heren ontmoeten. Gedurende enkele minuten knopen zij een gesprekje aan, stellen wat vragen, beslissen of ze hun gespreksparter nog eens willen ontmoeten en gaan naar de volgende persoon. Aan het einde van de middag geeft men aan First Seconds door wie men leuk genoeg vindt voor een vervolg. Als er een 'match' is, ontvangen deelnemers de volgende dag het e-mailadres of telefoonnummer van de andere partij. Interesse in een vrolijk en spannend middagje uit? Bezoek onze site: http://www.firstseconds.nl Met vriendelijke groet, First Seconds To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 19 13:37:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBCA337B405 for ; Sun, 19 Jan 2003 13:37:48 -0800 (PST) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 397EA43F18 for ; Sun, 19 Jan 2003 13:37:48 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-7-62-147-153-16.dial.proxad.net [62.147.153.16]) by postfix3-1.free.fr (Postfix) with SMTP id 90BAAC166 for ; Sun, 19 Jan 2003 22:37:46 +0100 (CET) Received: (qmail 6970 invoked by uid 1001); 19 Jan 2003 21:51:29 -0000 Date: Sun, 19 Jan 2003 22:51:29 +0100 From: Nicolas Souchu To: arch@freebsd.org Subject: Newbusifying kbd? Message-ID: <20030119225129.A6948@armor.fastether> 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 Hi, Has anyone already thought about newbusifying kbd? I'm currently working on that part and need a different instance of the kbd.c code. By newbus implementation, I imagine having kbd a parent of atkbd, ukbd... Each instance of kbd would have different kbdsw, keyboards(...) data. The tree of parent-childs would be started by syscons and genkbd. I have currently duplicated kbd.c with different symbol names :( Thoughts? Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 19 15:30:37 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD92837B401 for ; Sun, 19 Jan 2003 15:30:36 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31CB243F18 for ; Sun, 19 Jan 2003 15:30:36 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0JNUPMW013285; Sun, 19 Jan 2003 15:30:26 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0JNUVjf024414; Sun, 19 Jan 2003 15:30:31 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0JNUVP6024413; Sun, 19 Jan 2003 15:30:31 -0800 (PST) Date: Sun, 19 Jan 2003 15:30:31 -0800 From: Marcel Moolenaar To: Nicolas Souchu Cc: arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030119233031.GA24377@dhcp01.pn.xcllnt.net> References: <20030119225129.A6948@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030119225129.A6948@armor.fastether> User-Agent: Mutt/1.5.3i 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, Jan 19, 2003 at 10:51:29PM +0100, Nicolas Souchu wrote: > > Hi, > > Has anyone already thought about newbusifying kbd? I've been playing with the scary thought of redoing syscons completely; whether rewriting or importing. It's not only kbd that needs newbusification and fb(4) is really full of ISA/BIOS stuff. Anyway: this is beyond just newbusification... -- 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 Jan 19 16:25:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22B7D37B405 for ; Sun, 19 Jan 2003 16:25:20 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACDE843ED8 for ; Sun, 19 Jan 2003 16:25:18 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0K0P71e069298; Sun, 19 Jan 2003 17:25:10 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 19 Jan 2003 17:23:31 -0700 (MST) Message-Id: <20030119.172331.11474060.imp@bsdimp.com> To: marcel@xcllnt.net Cc: nsouch@free.fr, arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? From: "M. Warner Losh" In-Reply-To: <20030119233031.GA24377@dhcp01.pn.xcllnt.net> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030119233031.GA24377@dhcp01.pn.xcllnt.net> Marcel Moolenaar writes: : On Sun, Jan 19, 2003 at 10:51:29PM +0100, Nicolas Souchu wrote: : > : > Hi, : > : > Has anyone already thought about newbusifying kbd? : : I've been playing with the scary thought of redoing syscons completely; : whether rewriting or importing. It's not only kbd that needs : newbusification and fb(4) is really full of ISA/BIOS stuff. : : Anyway: this is beyond just newbusification... We can't support the various PCMCIA/CardBus docking stations easily in FreeBSD right now because kbd and other 'basic' things haven't been newbusified. Maybe we should just do a wscons port, now that it has shown its use in NetBSD. wscons is very portable, but a little less user friendly than syscons. syscons gives a better user experience, but tends to be a little x86 centric. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 19 16:45: 5 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4751E37B405 for ; Sun, 19 Jan 2003 16:45:04 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-179.dsl.lsan03.pacbell.net [64.169.106.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BFC043ED8 for ; Sun, 19 Jan 2003 16:45:03 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 1D68566B60; Sun, 19 Jan 2003 16:45:03 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id F172C162A; Sun, 19 Jan 2003 16:45:02 -0800 (PST) Date: Sun, 19 Jan 2003 16:45:02 -0800 From: Kris Kennaway To: "M. Warner Losh" Cc: marcel@xcllnt.net, nsouch@free.fr, arch@FreeBSD.ORG Subject: Porting wscons (Re: Newbusifying kbd?) Message-ID: <20030120004502.GA90257@rot13.obsecurity.org> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030119.172331.11474060.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <20030119.172331.11474060.imp@bsdimp.com> User-Agent: Mutt/1.4i 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 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 19, 2003 at 05:23:31PM -0700, M. Warner Losh wrote: > Maybe we should just do a wscons port, now that it has shown its use > in NetBSD. wscons is very portable, but a little less user friendly > than syscons. syscons gives a better user experience, but tends to be > a little x86 centric. Jake and I have been talking about this a bit for sparc64 too..I made a start on trying to port it over from OpenBSD (NetBSD doesn't appear to support wscons on sparc64), but didn't get very far yet. Kris --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+K0aOWry0BWjoQKURApXeAKDcp1pBEN/iYwTHZp836gqqXnLD+wCeIgYm vE5yk9pHOq0O7Uvc0z7RfaQ= =9NBt -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 19 17:10:31 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 082D937B401 for ; Sun, 19 Jan 2003 17:10:30 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3215E43F18 for ; Sun, 19 Jan 2003 17:10:29 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0K1AEMW013734; Sun, 19 Jan 2003 17:10:14 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0K1AEMa001125; Sun, 19 Jan 2003 17:10:14 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0K1AElS001124; Sun, 19 Jan 2003 17:10:14 -0800 (PST) Date: Sun, 19 Jan 2003 17:10:14 -0800 From: Marcel Moolenaar To: "M. Warner Losh" Cc: nsouch@free.fr, arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030120011014.GB989@athlon.pn.xcllnt.net> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030119.172331.11474060.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030119.172331.11474060.imp@bsdimp.com> User-Agent: Mutt/1.5.3i 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, Jan 19, 2003 at 05:23:31PM -0700, M. Warner Losh wrote: > In message: <20030119233031.GA24377@dhcp01.pn.xcllnt.net> > Marcel Moolenaar writes: > : On Sun, Jan 19, 2003 at 10:51:29PM +0100, Nicolas Souchu wrote: > : > > : > Has anyone already thought about newbusifying kbd? > : > : I've been playing with the scary thought of redoing syscons completely; > : whether rewriting or importing. It's not only kbd that needs > : newbusification and fb(4) is really full of ISA/BIOS stuff. > : > : Anyway: this is beyond just newbusification... > > We can't support the various PCMCIA/CardBus docking stations easily in > FreeBSD right now because kbd and other 'basic' things haven't been > newbusified. > > Maybe we should just do a wscons port, now that it has shown its use > in NetBSD. wscons is very portable, but a little less user friendly > than syscons. syscons gives a better user experience, but tends to be > a little x86 centric. Yes. The sparc64 port also struggles with this. Jake was thinking about importing wscons from NetBSD as well. I decided to replace the x86/ISA centric VGA driver on the ia64 branch with a new PCI driver and to make sc(4) itself not dependent on ISA. For some strange reason we attach sc(4) to ISA, even though sc(4) itself is not an ISA device. It sort of works, but no really. It's a hack in any case... I like to call for a console project where all the issues can be raised and discussed so that we have a good understanding of requirements and problems before we do anything else. At the same time I realize that we're all busy enough for yet another project... -- 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 Jan 19 19:40:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A952837B401 for ; Sun, 19 Jan 2003 19:40:37 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7095343F3F for ; Sun, 19 Jan 2003 19:40:37 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 46B34AE25C; Sun, 19 Jan 2003 19:40:37 -0800 (PST) Date: Sun, 19 Jan 2003 19:40:37 -0800 From: Alfred Perlstein To: arch@freebsd.org Subject: removal of M_WAIT, M_WAITOK, M_TRYWAIT. Message-ID: <20030120034037.GA33821@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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'm tired of seeing programming errors because of the M_* flags to malloc and mget being weird. I'm removing the "0" flags, meaning M_WAIT, M_WAITOK, M_TRYWAIT. I am also consolidating both M_NOWAIT and M_DONTWAIT into a single flag. Only M_NOWAIT will be available any more. I've been meaning to do this for several years now. Any third parties can simply define them as the "wait" args to zero if they really need them. But I think we've been burned enough times now to get rid of it. I'm cleaning up my generated diff now, and I'll be posting it shortly -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 19 22:32:51 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB8B637B401 for ; Sun, 19 Jan 2003 22:32:50 -0800 (PST) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A8843E4A for ; Sun, 19 Jan 2003 22:32:50 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-8-62-147-157-52.dial.proxad.net [62.147.157.52]) by postfix4-1.free.fr (Postfix) with SMTP id 91276FF0D for ; Mon, 20 Jan 2003 07:32:43 +0100 (CET) Received: (qmail 11093 invoked by uid 1001); 20 Jan 2003 06:46:39 -0000 Date: Mon, 20 Jan 2003 07:46:39 +0100 From: Nicolas Souchu To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030120074638.A11055@armor.fastether> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030119233031.GA24377@dhcp01.pn.xcllnt.net>; from marcel@xcllnt.net on Sun, Jan 19, 2003 at 03:30:31PM -0800 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, Jan 19, 2003 at 03:30:31PM -0800, Marcel Moolenaar wrote: > On Sun, Jan 19, 2003 at 10:51:29PM +0100, Nicolas Souchu wrote: > > > > Hi, > > > > Has anyone already thought about newbusifying kbd? > > I've been playing with the scary thought of redoing syscons completely; > whether rewriting or importing. It's not only kbd that needs > newbusification and fb(4) is really full of ISA/BIOS stuff. Indeed. I'm currently working on KGI (http://www.kgi-project.org and http://wwww.freebsd.org/~nsouch/ggiport.html) and try to port it to FreeBSD. The console (graphic and input resources), focus management, and all this kind of stuff are the suject of the KGI project. KGI already have its way to control inputs vs process/console focuses independently from graphic drivers and any console implementation. Maybe we could look at it? But that's all. KGI provides a console implementation but I doubt it fits FreeBSD needs. Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@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 Jan 20 13:11:52 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C6E737B401 for ; Mon, 20 Jan 2003 13:11:51 -0800 (PST) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 786C643F43 for ; Mon, 20 Jan 2003 13:11:50 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-8-62-147-157-163.dial.proxad.net [62.147.157.163]) by postfix4-1.free.fr (Postfix) with SMTP id 7A59AFFF7 for ; Mon, 20 Jan 2003 22:11:48 +0100 (CET) Received: (qmail 1317 invoked by uid 1001); 20 Jan 2003 21:25:38 -0000 Date: Mon, 20 Jan 2003 22:25:38 +0100 From: Nicolas Souchu To: "M. Warner Losh" Cc: marcel@xcllnt.net, arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030120222538.B1263@armor.fastether> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030119.172331.11474060.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030119.172331.11474060.imp@bsdimp.com>; from imp@bsdimp.com on Sun, Jan 19, 2003 at 05:23:31PM -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 On Sun, Jan 19, 2003 at 05:23:31PM -0700, M. Warner Losh wrote: > : Anyway: this is beyond just newbusification... > > We can't support the various PCMCIA/CardBus docking stations easily in > FreeBSD right now because kbd and other 'basic' things haven't been > newbusified. > > Maybe we should just do a wscons port, now that it has shown its use > in NetBSD. wscons is very portable, but a little less user friendly > than syscons. syscons gives a better user experience, but tends to be > a little x86 centric. But does wscons offer dynamic allocation as needed for CardBus docking? Would wscons make kbd disapear? Or is it more than syscons? Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@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 Jan 20 13:39:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F8A637B401 for ; Mon, 20 Jan 2003 13:39:53 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 796F043EB2 for ; Mon, 20 Jan 2003 13:39:52 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0KLdm1e077466; Mon, 20 Jan 2003 14:39:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 20 Jan 2003 14:38:56 -0700 (MST) Message-Id: <20030120.143856.39770089.imp@bsdimp.com> To: nsouch@free.fr Cc: marcel@xcllnt.net, arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? From: "M. Warner Losh" In-Reply-To: <20030120222538.B1263@armor.fastether> References: <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030119.172331.11474060.imp@bsdimp.com> <20030120222538.B1263@armor.fastether> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030120222538.B1263@armor.fastether> Nicolas Souchu writes: : On Sun, Jan 19, 2003 at 05:23:31PM -0700, M. Warner Losh wrote: : > : Anyway: this is beyond just newbusification... : > : > We can't support the various PCMCIA/CardBus docking stations easily in : > FreeBSD right now because kbd and other 'basic' things haven't been : > newbusified. : > : > Maybe we should just do a wscons port, now that it has shown its use : > in NetBSD. wscons is very portable, but a little less user friendly : > than syscons. syscons gives a better user experience, but tends to be : > a little x86 centric. : : But does wscons offer dynamic allocation as needed for CardBus docking? I think so, but I've not checked exactly. : Would wscons make kbd disapear? Or is it more than syscons? Well, "wscons" is a collection of interfaces that various devices provide. These include many different keyboard drivers, many different screen drivers, and many differnet mouse drivers. Wanrer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 20 13:44:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC6BA37B401 for ; Mon, 20 Jan 2003 13:44:20 -0800 (PST) Received: from web13401.mail.yahoo.com (web13401.mail.yahoo.com [216.136.175.59]) by mx1.FreeBSD.org (Postfix) with SMTP id 5C35543F6B for ; Mon, 20 Jan 2003 13:44:20 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20030120214420.83623.qmail@web13401.mail.yahoo.com> Received: from [200.24.79.136] by web13401.mail.yahoo.com via HTTP; Mon, 20 Jan 2003 22:44:19 CET Date: Mon, 20 Jan 2003 22:44:19 +0100 (CET) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Subject: Re: Porting wscons (Re: Newbusifying kbd?) To: arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Hi; There is an interesting (but difficult to find) discussion on the mail archives about supporting several different virtual consoles at the same time, and an object oriented design from the 386BSD days. It was never implemented, and I couldn't dig it out anymore, but do keep in mind there was a design once ;). cheers, Pedro. ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 20 14:20:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DAF537B401 for ; Mon, 20 Jan 2003 14:20:37 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F6EA43F13 for ; Mon, 20 Jan 2003 14:20:36 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0KMKSMW018885; Mon, 20 Jan 2003 14:20:28 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0KMKSZf000669; Mon, 20 Jan 2003 14:20:28 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0KMKSxm000668; Mon, 20 Jan 2003 14:20:28 -0800 (PST) Date: Mon, 20 Jan 2003 14:20:27 -0800 From: Marcel Moolenaar To: Nicolas Souchu Cc: arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030120222027.GA597@athlon.pn.xcllnt.net> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030120074638.A11055@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030120074638.A11055@armor.fastether> User-Agent: Mutt/1.5.3i 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 Mon, Jan 20, 2003 at 07:46:39AM +0100, Nicolas Souchu wrote: > On Sun, Jan 19, 2003 at 03:30:31PM -0800, Marcel Moolenaar wrote: > > On Sun, Jan 19, 2003 at 10:51:29PM +0100, Nicolas Souchu wrote: > > > > > > Hi, > > > > > > Has anyone already thought about newbusifying kbd? > > > > I've been playing with the scary thought of redoing syscons completely; > > whether rewriting or importing. It's not only kbd that needs > > newbusification and fb(4) is really full of ISA/BIOS stuff. > > Indeed. > > I'm currently working on KGI (http://www.kgi-project.org and > http://wwww.freebsd.org/~nsouch/ggiport.html) and try to port it to FreeBSD. > The console (graphic and input resources), focus management, and all this > kind of stuff are the suject of the KGI project. > > KGI already have its way to control inputs vs process/console focuses > independently from graphic drivers and any console implementation. > > Maybe we could look at it? I took a quick look at it. I'm not opposed to having graphics support in the kernel. The problem I think I see is that we probably have enough interest to make standard VGA work, but never really have the people or interest to keep up with the latest and greatest graphics engine. So, I think this would be useful only in a model where the graphics drivers are contributed and the X server makes use of it. So, if XFree86 changes to this model, then I see potential... -- 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 Mon Jan 20 15: 1:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A95D937B401 for ; Mon, 20 Jan 2003 15:01:35 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6F8743F43 for ; Mon, 20 Jan 2003 15:01:34 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0KN1YMW019029; Mon, 20 Jan 2003 15:01:34 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0KN1gFq000674; Mon, 20 Jan 2003 15:01:42 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0KN1f86000673; Mon, 20 Jan 2003 15:01:41 -0800 (PST) Date: Mon, 20 Jan 2003 15:01:41 -0800 From: Marcel Moolenaar To: "Pedro F. Giffuni" Cc: arch@FreeBSD.ORG Subject: Re: Porting wscons (Re: Newbusifying kbd?) Message-ID: <20030120230141.GA641@dhcp01.pn.xcllnt.net> References: <20030120214420.83623.qmail@web13401.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030120214420.83623.qmail@web13401.mail.yahoo.com> User-Agent: Mutt/1.5.3i 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 Mon, Jan 20, 2003 at 10:44:19PM +0100, Pedro F. Giffuni wrote: > Hi; > > There is an interesting (but difficult to find) > discussion on the mail archives about supporting > several different virtual consoles at the same time, > and an object oriented design from the 386BSD days. > > It was never implemented, and I couldn't dig it out > anymore, but do keep in mind there was a design once > ;). So are you saying that wscons doesn't have virtual consoles at all or are you saying that it supports virtual consoles, but not in a way that allows each of them to have different properties (graphics vs text, vt100 vs ansi, foo vs bar)? -- 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 Mon Jan 20 18:47: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C41137B401 for ; Mon, 20 Jan 2003 18:47:07 -0800 (PST) Received: from web13408.mail.yahoo.com (web13408.mail.yahoo.com [216.136.175.66]) by mx1.FreeBSD.org (Postfix) with SMTP id 0272243EB2 for ; Mon, 20 Jan 2003 18:47:07 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20030121024706.91681.qmail@web13408.mail.yahoo.com> Received: from [200.24.79.171] by web13408.mail.yahoo.com via HTTP; Tue, 21 Jan 2003 03:47:06 CET Date: Tue, 21 Jan 2003 03:47:06 +0100 (CET) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Subject: Re: Porting wscons (Re: Newbusifying kbd?) To: Marcel Moolenaar Cc: arch@FreeBSD.ORG In-Reply-To: <20030120230141.GA641@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 --- Marcel Moolenaar ha scritto: ... > > So are you saying that wscons doesn't have virtual > consoles at all > or are you saying that it supports virtual consoles, > but not in a > way that allows each of them to have different > properties (graphics > vs text, vt100 vs ansi, foo vs bar)? > None of those, I wasn't talking about wscons (which I understand is a replacement of pcvt) but about FreeBSD. I would have prefered to let the actors of that thread explain it better, but well... let's hope my memory doesn't betray me: The discussion back then ocurred right after Yokota's syscons redesign. Jonathan Mini suggested modifying the console code so that, for example, provided a pcvt console and an sco-like console. Julian Elischer posted a nice OO design of a discussion that was dated back from the 386BSD days. The interesting document is not easy to find and I'm not sure if it's on -current or on -hackers. I'll look for the link and I'll post it to the list. cheers, Pedro. ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 20 19:37:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6744C37B401 for ; Mon, 20 Jan 2003 19:37:33 -0800 (PST) Received: from web13402.mail.yahoo.com (web13402.mail.yahoo.com [216.136.175.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 0F7F343F5B for ; Mon, 20 Jan 2003 19:37:33 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20030121033732.39183.qmail@web13402.mail.yahoo.com> Received: from [200.24.79.171] by web13402.mail.yahoo.com via HTTP; Tue, 21 Jan 2003 04:37:32 CET Date: Tue, 21 Jan 2003 04:37:32 +0100 (CET) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Subject: Re: Newbusifying kbd? To: arch@FreeBSD.org Cc: Marcel Moolenaar , nsouch@free.fr In-Reply-To: <20030120230141.GA641@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 think the problem we have right now, and in fact the problem that Nicholas is addressing, is that we are not handling consistently the drivers that syscons needs to work. Without this elements properly abstracted any alternative console project reinvents the wheel. I guess what I'm saying here is that we should port wscons so that it consistently uses our kbd, vga, and vesa drivers (assuming everything is properly newbussified). I wish we could run many console types at the same time, but this is not really the same problem. cheers, Pedro. ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 20 20:13:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05C1937B401 for ; Mon, 20 Jan 2003 20:13:34 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE4B843E4A for ; Mon, 20 Jan 2003 20:13:31 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0L4DOMW020148; Mon, 20 Jan 2003 20:13:24 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0L4DVB6000715; Mon, 20 Jan 2003 20:13:32 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0L4DVU8000714; Mon, 20 Jan 2003 20:13:31 -0800 (PST) Date: Mon, 20 Jan 2003 20:13:31 -0800 From: Marcel Moolenaar To: "Pedro F. Giffuni" Cc: arch@FreeBSD.org, nsouch@free.fr Subject: Re: Newbusifying kbd? Message-ID: <20030121041331.GA628@dhcp01.pn.xcllnt.net> References: <20030120230141.GA641@dhcp01.pn.xcllnt.net> <20030121033732.39183.qmail@web13402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030121033732.39183.qmail@web13402.mail.yahoo.com> User-Agent: Mutt/1.5.3i 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, Jan 21, 2003 at 04:37:32AM +0100, Pedro F. Giffuni wrote: > > I wish we could run many console types at the same > time, but this is not really the same problem. Well, if you're discussing one problem it's always good to review possibly unrelated issues while you're at it. It's always better to choose not to deal with certain problems than to find out afterwards that you were ignorant of them... And, yes. I agree; The kind of terminal emulation should never be made a fixed property of the implementation. Properly layered, there's also no reason to not have multiple different TEs at the same time for different physical or virtual console devices). -- 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 Mon Jan 20 20:47:15 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86EB937B401 for ; Mon, 20 Jan 2003 20:47:14 -0800 (PST) Received: from web13406.mail.yahoo.com (web13406.mail.yahoo.com [216.136.175.64]) by mx1.FreeBSD.org (Postfix) with SMTP id E95BF43F43 for ; Mon, 20 Jan 2003 20:47:13 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20030121044713.95115.qmail@web13406.mail.yahoo.com> Received: from [200.24.79.171] by web13406.mail.yahoo.com via HTTP; Tue, 21 Jan 2003 05:47:13 CET Date: Tue, 21 Jan 2003 05:47:13 +0100 (CET) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Subject: the mythical syscons redesign document ( was Re: Porting wscons ) To: Marcel Moolenaar Cc: arch@FreeBSD.ORG In-Reply-To: <20030120230141.GA641@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 OK, I found it: http://www.freebsd.org/cgi/getmsg.cgi?fetch=302402+322879+/usr/local/www/db/text/1998/freebsd-current/19980802.freebsd-current (sorry if it wraps) enjoy, Pedro. ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 1:47:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50A1937B401 for ; Tue, 21 Jan 2003 01:47:49 -0800 (PST) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 878EA43F18 for ; Tue, 21 Jan 2003 01:47:47 -0800 (PST) (envelope-from netchild@graphics.cs.uni-sb.de) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.12.7/2002112700) with ESMTP id h0L9lhQw022446; Tue, 21 Jan 2003 10:47:43 +0100 (CET) Received: from mail.cs.uni-sb.de (mail.cs.uni-sb.de [134.96.254.200]) by cs.uni-sb.de (8.12.7/2002120200) with ESMTP id h0L9lgm1026475; Tue, 21 Jan 2003 10:47:42 +0100 (CET) Received: from graphics.cs.uni-sb.de (graphics.cs.uni-sb.de [134.96.249.10]) by mail.cs.uni-sb.de (8.12.7/2002112700) with ESMTP id h0L9lfCY015778; Tue, 21 Jan 2003 10:47:41 +0100 (CET) Received: from radiosity.cs.uni-sb.de (radiosity.cs.uni-sb.de [134.96.249.12]) by graphics.cs.uni-sb.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0L9lf8Y025300; Tue, 21 Jan 2003 10:47:41 +0100 Received: from graphics.cs.uni-sb.de (localhost [127.0.0.1]) by radiosity.cs.uni-sb.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0L9leek005447; Tue, 21 Jan 2003 10:47:41 +0100 Message-ID: <3E2D173C.3040507@graphics.cs.uni-sb.de> Date: Tue, 21 Jan 2003 10:47:40 +0100 From: Alexander Leidinger Reply-To: Alexander@Leidinger.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: de MIME-Version: 1.0 To: Marcel Moolenaar Cc: Nicolas Souchu , arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030120074638.A11055@armor.fastether> <20030120222027.GA597@athlon.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Marcel Moolenaar wrote: [KGI] > I took a quick look at it. I'm not opposed to having graphics support > in the kernel. The problem I think I see is that we probably have > enough interest to make standard VGA work, but never really have the > people or interest to keep up with the latest and greatest graphics > engine. So, I think this would be useful only in a model where the > graphics drivers are contributed and the X server makes use of it. > So, if XFree86 changes to this model, then I see potential... Chicken and egg problem... as far as I remember (I looked at it looong ago) they have a X server too... or at least they want to provide one. Bye, Alexander. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 3:58:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F025637B401 for ; Tue, 21 Jan 2003 03:58:43 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AF2443E4A for ; Tue, 21 Jan 2003 03:58:43 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0LBwC6Z012968 for ; Tue, 21 Jan 2003 12:58:12 +0100 (CET) (envelope-from phk@freebsd.org) Cc: arch@freebsd.org Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. From: phk@freebsd.org In-Reply-To: Your message of "Wed, 15 Jan 2003 13:37:33 +0100." <14715.1042634253@critter.freebsd.dk> Date: Tue, 21 Jan 2003 12:58:12 +0100 Message-ID: <12967.1043150292@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 I have uploaded two patchfiles: http://phk.freebsd.dk/patch/small.patch Removes just the options from sys/conf http://phk.freebsd.dk/patch/big.patch unifdef -UNODEVFS -UNO_GEOM Removes roughly 2800 lines of code. -- 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 Tue Jan 21 9:28:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FDC337B401; Tue, 21 Jan 2003 09:28:52 -0800 (PST) Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E94143F13; Tue, 21 Jan 2003 09:28:52 -0800 (PST) (envelope-from kris@citusc.usc.edu) Received: (from kris@localhost) by citusc.usc.edu (8.11.6/8.11.2) id h0LHSpc27242; Tue, 21 Jan 2003 09:28:51 -0800 Date: Tue, 21 Jan 2003 09:28:51 -0800 From: Kris Kennaway To: phk@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. Message-ID: <20030121092851.A27172@citusc.usc.edu> References: <14715.1042634253@critter.freebsd.dk> <12967.1043150292@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <12967.1043150292@critter.freebsd.dk>; from phk@FreeBSD.ORG on Tue, Jan 21, 2003 at 12:58:12PM +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 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 21, 2003 at 12:58:12PM +0100, phk@FreeBSD.ORG wrote: >=20 > I have uploaded two patchfiles: >=20 > http://phk.freebsd.dk/patch/small.patch > Removes just the options from sys/conf >=20 > http://phk.freebsd.dk/patch/big.patch > unifdef -UNODEVFS -UNO_GEOM > Removes roughly 2800 lines of code. To the best of your knowledge, there are no remaining serious bugs or missing functionality with GEOM (like the disklabel editing problems found before 5.0, etc)? Kris --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+LYNTWry0BWjoQKURArIBAJ9vmyqvTq09KfVPnDj/CdiYZOA+HwCgqjmZ i+JT57xHWmfDPBwyT1lE3OI= =Ev7L -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 10: 1:32 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AAEB37B401 for ; Tue, 21 Jan 2003 10:01:31 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8858B43F3F for ; Tue, 21 Jan 2003 10:01:30 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id h0LI1BP4017725; Tue, 21 Jan 2003 13:01:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 21 Jan 2003 13:01:11 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Dillon Cc: "Alan L. Cox" , Peter Wemm , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301140411.h0E4BgpN078032@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 Ok, so lemme revise my thinking. Could we take this patch, rename the API from getsysfd(various things) to memfd(size), and simply provide anonymous swap-backed memory only? Call it kern_memfd, sys_memfd or the like. I guess part of what was rubbing me the wrong way with this was that it seemed like it was becoming a kitchen sink: message queues, timer access, etc: all stuff that can already be supported using existing APIs. The novel thing about this API that has me drooling -- perhaps not literally -- is an easy way to create sharable memory references to objects larger than addressable space w/o getting files in the mix, and pass them around. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 10: 6:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CA7537B401; Tue, 21 Jan 2003 10:06:41 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8D3F43E4A; Tue, 21 Jan 2003 10:06:40 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 956922A7EA; Tue, 21 Jan 2003 10:06:40 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: phk@freebsd.org Cc: Robert Watson , Matthew Dillon , Terry Lambert , "Alan L. Cox" , arch@freebsd.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <3077.1042730640@critter.freebsd.dk> Date: Tue, 21 Jan 2003 10:06:40 -0800 From: Peter Wemm Message-Id: <20030121180640.956922A7EA@canning.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 phk@freebsd.org wrote: > In message , Ro be > rt Watson writes: > > > >On Wed, 15 Jan 2003, Matthew Dillon wrote: > > > >> I think we've established the usefulness of a VM Object descriptor. N ow > >> what about the system call API? At the moment I have: > > > >Since we appear to be building a new API and IPC semantic from the ground > >up, I think it would be worthwhile to look at some of the other weird, > >wonderful, or perhaps just bizarre, things that others have done in the > >past. > > I would like to see it being developed, tested, benchmarked and find > at least one application before we add YAIPC to FreeBSD's sources... Also, I think the proposed API where this stuff is overloaded into a single syscall is a bad idea, *especially* when we have millions of syscalls available. Personally, I'd prefer a simpler: #include int fd = memfd(off_t size); type API, and if a compelling need for the timer stuff (or whatever) turns up, then create the correct syscalls for those. I dont much care if they use a single common DTYPE_SYSFD file type or something, but please lets not paint ourselves into a corner like what happened with semsys(), msgsys(), etc. We're still paying for that syscall overloading mistake and still have not recovered from it. 5.0-RELEASE still tries to use them.. check out all the nasty code in libc for it (and on the other platforms). I'm not saying the timer stuff isn't needed, just that it should be exposed to userland seperately with the correct (to be determined for timers) API. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Tue Jan 21 10:26:52 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58D5737B405; Tue, 21 Jan 2003 10:26:51 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D78243F13; Tue, 21 Jan 2003 10:26:50 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0LIQD6Z016712; Tue, 21 Jan 2003 19:26:14 +0100 (CET) (envelope-from phk@freebsd.org) To: Robert Watson Cc: Matthew Dillon , "Alan L. Cox" , Peter Wemm , arch@freebsd.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) From: phk@freebsd.org In-Reply-To: Your message of "Tue, 21 Jan 2003 13:01:11 EST." Date: Tue, 21 Jan 2003 19:26:13 +0100 Message-ID: <16711.1043173573@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 In message , Robe rt Watson writes: > >Ok, so lemme revise my thinking. Could we take this patch, rename the API >from getsysfd(various things) to memfd(size), and simply provide anonymous >swap-backed memory only? The traditional design would be: fd = open("/dev/shmem", ...); ptr = mmap(..., fd, ...) -- 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 Tue Jan 21 10:28: 2 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF73F37B401 for ; Tue, 21 Jan 2003 10:28:01 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC8BD43F3F for ; Tue, 21 Jan 2003 10:28:00 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0LIRO6Z016729; Tue, 21 Jan 2003 19:27:29 +0100 (CET) (envelope-from phk@freebsd.org) To: Kris Kennaway Cc: arch@freebsd.org Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. From: phk@freebsd.org In-Reply-To: Your message of "Tue, 21 Jan 2003 09:28:51 PST." <20030121092851.A27172@citusc.usc.edu> Date: Tue, 21 Jan 2003 19:27:24 +0100 Message-ID: <16728.1043173644@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 In message <20030121092851.A27172@citusc.usc.edu>, Kris Kennaway writes: > >--rwEMma7ioTxnRzrJ >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Tue, Jan 21, 2003 at 12:58:12PM +0100, phk@FreeBSD.ORG wrote: >>=20 >> I have uploaded two patchfiles: >>=20 >> http://phk.freebsd.dk/patch/small.patch >> Removes just the options from sys/conf >>=20 >> http://phk.freebsd.dk/patch/big.patch >> unifdef -UNODEVFS -UNO_GEOM >> Removes roughly 2800 lines of code. > >To the best of your knowledge, there are no remaining serious bugs or >missing functionality with GEOM (like the disklabel editing problems >found before 5.0, etc)? There is one errata point (can't rewrite BSD boot code on a disk which is in use) which I am testing a patch for. I know of no bugs at present. -- 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 Tue Jan 21 10:32:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 593AC37B48F; Tue, 21 Jan 2003 10:32:33 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A99643E4A; Tue, 21 Jan 2003 10:32:32 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id h0LIWPP4026877; Tue, 21 Jan 2003 13:32:25 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 21 Jan 2003 13:32:25 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: phk@freebsd.org Cc: Matthew Dillon , "Alan L. Cox" , Peter Wemm , arch@freebsd.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <16711.1043173573@critter.freebsd.dk> 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, 21 Jan 2003 phk@freebsd.org wrote: > In message , Robe > rt Watson writes: > > > >Ok, so lemme revise my thinking. Could we take this patch, rename the API > >from getsysfd(various things) to memfd(size), and simply provide anonymous > >swap-backed memory only? > > The traditional design would be: > > fd = open("/dev/shmem", ...); > ptr = mmap(..., fd, ...) Well, it struck me the three implementations that came to mind would be: (1) shmfs. mount -t shmfs foo /shmfs Handle the implementation using vnodes and DTYPE_VNODE (2) /dev/shm Handle the implementation using cloning devices and device pager magic. (3) DTYPE_MEMFD Handle the implementation using a special file descriptor type creating using a special creation primitive (similar to kqueue, pipe, etc). Of the three, (3) appears to be simplist to implement, (1) the most complicated. I'm probably not qualified to comment on (2), but have to say that (3) would be the easiest to stick in MAC magic for :-). But only if (3) completely avoids the kitchensinkfd() approach. From the API perspective, you could easily hide any of these behind a memfd() library call. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 10:52:11 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F15137B401; Tue, 21 Jan 2003 10:52:09 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD42843E4A; Tue, 21 Jan 2003 10:52:08 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id A82EB2A7EA; Tue, 21 Jan 2003 10:52:08 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Robert Watson Cc: phk@freebsd.org, Matthew Dillon , "Alan L. Cox" , arch@freebsd.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: Date: Tue, 21 Jan 2003 10:52:08 -0800 From: Peter Wemm Message-Id: <20030121185208.A82EB2A7EA@canning.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 Robert Watson wrote: > > On Tue, 21 Jan 2003 phk@freebsd.org wrote: > > > In message , Robe > > rt Watson writes: > > > > > >Ok, so lemme revise my thinking. Could we take this patch, rename the API > > >from getsysfd(various things) to memfd(size), and simply provide anonymous > > >swap-backed memory only? > > > > The traditional design would be: > > > > fd = open("/dev/shmem", ...); > > ptr = mmap(..., fd, ...) > > Well, it struck me the three implementations that came to mind would be: > > (1) shmfs. > > mount -t shmfs foo /shmfs > > Handle the implementation using vnodes and DTYPE_VNODE Umm.... > (2) /dev/shm > > Handle the implementation using cloning devices and device pager > magic. > > (3) DTYPE_MEMFD > > Handle the implementation using a special file descriptor type > creating using a special creation primitive (similar to kqueue, > pipe, etc). > > Of the three, (3) appears to be simplist to implement, (1) the most > complicated. I'm probably not qualified to comment on (2), but have to > say that (3) would be the easiest to stick in MAC magic for :-). But only > if (3) completely avoids the kitchensinkfd() approach. From the API > perspective, you could easily hide any of these behind a memfd() library > call. (2) and (3) are not all that different, except that (2) requires another hack in the mmap syscall code to recognize and magically convert. (3) is cleaner but requires a more code to add the DTYPE_xxxFD stuff and affects more places in the kernel where we switch() on fd types. I personally prefer (3) - which is what Matt has implemented, but could live with (2). (1) is way more complicated than I want to think about especially if it goes near vnodes. What I'm objecting to though is the syscall that is wrapped around (3) in Matt's patch. I'd rather use a seperate syscall for any new uses of the system (timers, whatever) rather than try and come up with a future proof uber-syscall. What if down the track we discover that we could do something nifty and reuse part of this, but we need two configuration args to the syscall.. What then? getsysfd2(....)? I'd rather that we just create the syscalls for the specific purpose that they're needed for. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Tue Jan 21 13:21:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5DC837B401 for ; Tue, 21 Jan 2003 13:21:34 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E6A43F6B for ; Tue, 21 Jan 2003 13:21:34 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0LLLPMW024295; Tue, 21 Jan 2003 13:21:25 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0LLLYgZ000880; Tue, 21 Jan 2003 13:21:34 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0LLLXtI000879; Tue, 21 Jan 2003 13:21:33 -0800 (PST) Date: Tue, 21 Jan 2003 13:21:32 -0800 From: Marcel Moolenaar To: "Pedro F. Giffuni" Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030121212132.GA593@dhcp01.pn.xcllnt.net> References: <20030120230141.GA641@dhcp01.pn.xcllnt.net> <20030121044713.95115.qmail@web13406.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030121044713.95115.qmail@web13406.mail.yahoo.com> User-Agent: Mutt/1.5.3i 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, Jan 21, 2003 at 05:47:13AM +0100, Pedro F. Giffuni wrote: > OK, I found it: > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=302402+322879+/usr/local/www/db/text/1998/freebsd-current/19980802.freebsd-current It makes perfect sense to me why this hasn't been implemented. Not because it's wrong, but because it's impractical. For example, the ext/int mapper is not wrong per se, but it not specific to consoles. It should not be made part of the definition. The problem of encoding should be referenced or mentioned as a sidenoot or footnote, but lack of experience, practical value or even feasibility to address it in its entirety should have resulted in it being abstracted away. I'm not aware of any implementation that has it, which is exactly the point I'm getting at. An interesting read for historical reasons, but not really for the problem at hand. I still don't know how X is or would be affected if we would change our console implementation... -- 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 Tue Jan 21 13:44:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 851A237B401 for ; Tue, 21 Jan 2003 13:44:33 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD0A43F5F for ; Tue, 21 Jan 2003 13:44:32 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0LLiR1e086752 for ; Tue, 21 Jan 2003 14:44:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Jan 2003 14:42:43 -0700 (MST) Message-Id: <20030121.144243.52206100.imp@bsdimp.com> To: arch@freebsd.org Subject: Alfre's malloc changes: the next step From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.2 / 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 IRC there's much concern over alfred's changes from a cross os portability standpoint, as well as a SMP standpoint. I'd like to propose that we do something like the following: 1) Make M_WAITOK and M_NOWAIT mandatory and exclusive in malloc.c. You must specify one or the other, but not both. 2) We assign both M_WAITOK and M_NOWAIT values that aren't 0, let's say 0x10 and 0x20. 3) We assign both M_DONTWAIT and M_TRYWAIT from mbuf.h values 0x40 and 0x80. 4) We back out the bulk of the changes made, except where they were real bugs. 5) Hack the mbuf routines to reject M_DONTWAIT and M_TRYWAIT that aren't the right value in flags. 6) Hack all the places where we did a boolean test before to do the right testing of the new bits. I think there'd be strong support for this. I've done 1, 2, 3, 5 in my tree and am looking for #6 as well. I'll post a patch once #6 is done. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 13:46:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEC1937B405 for ; Tue, 21 Jan 2003 13:46:41 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10AAB43F1E for ; Tue, 21 Jan 2003 13:46:41 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0LLk66Z018556; Tue, 21 Jan 2003 22:46:07 +0100 (CET) (envelope-from phk@freebsd.org) To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: Alfre's malloc changes: the next step From: phk@freebsd.org In-Reply-To: Your message of "Tue, 21 Jan 2003 14:42:43 MST." <20030121.144243.52206100.imp@bsdimp.com> Date: Tue, 21 Jan 2003 22:46:06 +0100 Message-ID: <18555.1043185566@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 In message <20030121.144243.52206100.imp@bsdimp.com>, "M. Warner Losh" writes: >I think there'd be strong support for this. vote++; -- 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 Tue Jan 21 14: 1:51 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87D9537B483 for ; Tue, 21 Jan 2003 14:01:43 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA09843ED8 for ; Tue, 21 Jan 2003 14:01:42 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0LM3Kb74276; Tue, 21 Jan 2003 17:03:20 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 21 Jan 2003 17:03:19 -0500 From: Bosko Milekic To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030121170319.B74210@unixdaemons.com> References: <20030121.144243.52206100.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030121.144243.52206100.imp@bsdimp.com>; from imp@bsdimp.com on Tue, Jan 21, 2003 at 02:42:43PM -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 On Tue, Jan 21, 2003 at 02:42:43PM -0700, M. Warner Losh wrote: > In IRC there's much concern over alfred's changes from a cross os > portability standpoint, as well as a SMP standpoint. I'd like to Good! I'm glad there is concern. It's exactly what I think should happen because, quite frankly, there are significant subsystem differences right now that there *should* be ample concern about what happens when you make calls with M_DONTWAIT, M_TRYWAIT, M_WAITOK, or M_NOWAIT. > propose that we do something like the following: > > 1) Make M_WAITOK and M_NOWAIT mandatory and exclusive in malloc.c. > You must specify one or the other, but not both. > 2) We assign both M_WAITOK and M_NOWAIT values that aren't 0, let's > say 0x10 and 0x20. > 3) We assign both M_DONTWAIT and M_TRYWAIT from mbuf.h values 0x40 > and 0x80. > 4) We back out the bulk of the changes made, except where they were > real bugs. > 5) Hack the mbuf routines to reject M_DONTWAIT and M_TRYWAIT that > aren't the right value in flags. I'm not sure I understand point (5) here. What do you mean "that aren't the right value in flags?" > 6) Hack all the places where we did a boolean test before to do the > right testing of the new bits. > > I think there'd be strong support for this. > > I've done 1, 2, 3, 5 in my tree and am looking for #6 as well. I'll > post a patch once #6 is done. > > Comments? > > Warner -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 21 14:10:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7283237B407 for ; Tue, 21 Jan 2003 14:10:15 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F2D743F18 for ; Tue, 21 Jan 2003 14:10:14 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0LMAC1e086994; Tue, 21 Jan 2003 15:10:12 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Jan 2003 15:08:28 -0700 (MST) Message-Id: <20030121.150828.121894335.imp@bsdimp.com> To: bmilekic@unixdaemons.com Cc: arch@freebsd.org Subject: Re: Alfre's malloc changes: the next step From: "M. Warner Losh" In-Reply-To: <20030121170319.B74210@unixdaemons.com> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121170319.B74210@unixdaemons.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030121170319.B74210@unixdaemons.com> Bosko Milekic writes: : > 1) Make M_WAITOK and M_NOWAIT mandatory and exclusive in malloc.c. : > You must specify one or the other, but not both. : > 2) We assign both M_WAITOK and M_NOWAIT values that aren't 0, let's : > say 0x10 and 0x20. : > 3) We assign both M_DONTWAIT and M_TRYWAIT from mbuf.h values 0x40 : > and 0x80. : > 4) We back out the bulk of the changes made, except where they were : > real bugs. : > 5) Hack the mbuf routines to reject M_DONTWAIT and M_TRYWAIT that : > aren't the right value in flags. : : I'm not sure I understand point (5) here. What do you mean "that : aren't the right value in flags?" if (flags & ~(M_DONTWAIT | M_TRYWAIT)) panic("you used the interface wrong"); if ((flags & (M_DONTWAIT | M_TRYWAIT)) == 0) panic("you used the interface wrong"); if ((flags & (M_DONTWAIT | M_TRYWAIT)) == (M_DONTWAIT | M_TRYWAIT)) panic("you used the interface wrong"); Maybe ifdef's INVARIANT or some such. Similarly in malloc and M_WAITOK and M_NOWAIT Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 14:40:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A82D537B401 for ; Tue, 21 Jan 2003 14:40:24 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E75343F13 for ; Tue, 21 Jan 2003 14:40:23 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0LMeFMW024715; Tue, 21 Jan 2003 14:40:15 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0LMeOgZ001137; Tue, 21 Jan 2003 14:40:24 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0LMeODk001136; Tue, 21 Jan 2003 14:40:24 -0800 (PST) Date: Tue, 21 Jan 2003 14:40:24 -0800 From: Marcel Moolenaar To: "M. Warner Losh" Cc: arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030121224024.GA1095@dhcp01.pn.xcllnt.net> References: <20030121.144243.52206100.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030121.144243.52206100.imp@bsdimp.com> User-Agent: Mutt/1.5.3i 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, Jan 21, 2003 at 02:42:43PM -0700, M. Warner Losh wrote: > In IRC there's much concern over alfred's changes from a cross os > portability standpoint, as well as a SMP standpoint. I'd like to > propose that we do something like the following: [snip] > 4) We back out the bulk of the changes made, except where they were > real bugs. [snip] > > Comments? I tend to prefer a backout as the first step if we like to clean up the M_*WAIT* stuff in a different way. Not reverting first may result in bugs that we're introduced by the first makeover, and then subsequently hidden by the second makeover. I don't say there are any bugs, just that in the case of there being bugs this could happen. Just an observation... -- 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 Tue Jan 21 14:53:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E661F37B401 for ; Tue, 21 Jan 2003 14:53:33 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 431B943EB2 for ; Tue, 21 Jan 2003 14:53:33 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0LMrWhk018740 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 21 Jan 2003 17:53:32 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0LMrVhA018739; Tue, 21 Jan 2003 17:53:31 -0500 (EST) (envelope-from wollman) Date: Tue, 21 Jan 2003 17:53:31 -0500 (EST) From: Garrett Wollman Message-Id: <200301212253.h0LMrVhA018739@khavrinen.lcs.mit.edu> To: peter@wemm.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <20030121185208.A82EB2A7EA@canning.wemm.org> References: Organization: MIT Laboratory for Computer Science 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 In article <20030121185208.A82EB2A7EA@canning.wemm.org>, Peter Wemm quoted Robert Watson who said: >> (3) DTYPE_MEMFD >> Handle the implementation using a special file descriptor type >> creating using a special creation primitive (similar to kqueue, >> pipe, etc). >(3) is cleaner but requires a more code to add the DTYPE_xxxFD stuff and >affects more places in the kernel where we switch() on fd types. I >personally prefer (3) (3) is certainly closer to what the designers of the POSIX IPC interface were thinking. It has the significant benefit of not creating any additional kernel namespaces (which I think we would all agree was one of the worst mistakes in the SVR3 IPC model). Given (3), the implementation of shm_open() and shm_unlink() should move into the kernel, and those functions (rather than a special-purpose system call) should be used to provide this interface. shm_open() effectively looks like this: - examine first byte of path parameter - if c == '/' return open(...) - copy in path - use path to find/create shm object - create file descriptor a la open() with DTYPE_SHM We will need to find a spare bit in struct stat so that fstat() on one of these descriptors can indicate to S_TYPEISSHM() what it is. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 15:39:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E30A37B405 for ; Tue, 21 Jan 2003 15:39:33 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3A4243E4A for ; Tue, 21 Jan 2003 15:39:32 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id BE5DFAE25C; Tue, 21 Jan 2003 15:39:32 -0800 (PST) Date: Tue, 21 Jan 2003 15:39:32 -0800 From: Alfred Perlstein To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030121233932.GI42333@elvis.mu.org> References: <20030121.144243.52206100.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030121.144243.52206100.imp@bsdimp.com> User-Agent: Mutt/1.4i 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 [030121 13:44] wrote: > In IRC there's much concern over alfred's changes from a cross os > portability standpoint, as well as a SMP standpoint. I'd like to > propose that we do something like the following: Let's address the portability issue. Just add this to the top of your module and you can get back the "non-flag" for waiting. #ifndef M_WAITOK #define M_WAITOK 0 #endif Not hard. > 1) Make M_WAITOK and M_NOWAIT mandatory and exclusive in malloc.c. > You must specify one or the other, but not both. I keep hearing people say that having M_WAITOK implicit when M_NOWAIT is absent as a problem, it is not a problem, it's how things should be. One should only, if ever use M_NOWAIT from interrupt context. You should not be using M_NOWAIT because your locking is incorrect and you're holding a mutex when you need to call malloc/mget in user context. > 2) We assign both M_WAITOK and M_NOWAIT values that aren't 0, let's > say 0x10 and 0x20. > 3) We assign both M_DONTWAIT and M_TRYWAIT from mbuf.h values 0x40 > and 0x80. What a load of wasted flags. :( We've lost 4 bits because people don't understand the API, have read the manpage or the 4.4 BSD book. > 4) We back out the bulk of the changes made, except where they were > real bugs. There were no bugs that I caught atm, however there will be if we revert the delta. > 5) Hack the mbuf routines to reject M_DONTWAIT and M_TRYWAIT that > aren't the right value in flags. This will allow more mistakes to creep into modules that are seldom used or codepaths that aren't excersized often. It's a good way to have a DoS in the code without realizing it, now typos become fatal boobytraps instead of just harmless typos. > 6) Hack all the places where we did a boolean test before to do the > right testing of the new bits. > > I think there'd be strong support for this. I'm sure there will be, but that doesn't make it the right thing to do. Perhaps because the code md5s fine and I neglected to break a whole slew of device drivers is giving people the mistaken impression that they know what they're talking about here. They don't. While not asthetically pleasing this is the most correct solution and I wish you'd all damn well leave it alone. There's a lot of other stuff to fix out there. > I've done 1, 2, 3, 5 in my tree and am looking for #6 as well. I'll > post a patch once #6 is done. > > Comments? > Yes. Leave it alone, people may be shocked, but it's the right thing. thank you, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 15:43:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D825737B401 for ; Tue, 21 Jan 2003 15:43:24 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EEF043F18 for ; Tue, 21 Jan 2003 15:43:24 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id h0LNhGnN075903 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 21 Jan 2003 15:43:17 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <072501c2c1a6$df798450$52557f42@errno.com> From: "Sam Leffler" To: "Marcel Moolenaar" , "M. Warner Losh" Cc: References: <20030121.144243.52206100.imp@bsdimp.com> <20030121224024.GA1095@dhcp01.pn.xcllnt.net> Subject: Re: Alfre's malloc changes: the next step Date: Tue, 21 Jan 2003 15:43:16 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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, Jan 21, 2003 at 02:42:43PM -0700, M. Warner Losh wrote: > > In IRC there's much concern over alfred's changes from a cross os > > portability standpoint, as well as a SMP standpoint. I'd like to > > propose that we do something like the following: > [snip] > > 4) We back out the bulk of the changes made, except where they were > > real bugs. > [snip] > > > > Comments? > > I tend to prefer a backout as the first step if we like to clean > up the M_*WAIT* stuff in a different way. Not reverting first > may result in bugs that we're introduced by the first makeover, > and then subsequently hidden by the second makeover. I don't > say there are any bugs, just that in the case of there being > bugs this could happen. I prefer this too. This commit should never have been done w/o review. OTOH I understand what an incredible PITA it is to back out this muck and your patch will probably have to be done. Sigh. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 15:44:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42FDD37B401 for ; Tue, 21 Jan 2003 15:44:41 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF1D643E4A for ; Tue, 21 Jan 2003 15:44:40 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id h0LNicnN075908 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 21 Jan 2003 15:44:38 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <072d01c2c1a7$0fbba490$52557f42@errno.com> From: "Sam Leffler" To: "Alfred Perlstein" , "M. Warner Losh" Cc: References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> Subject: Re: Alfre's malloc changes: the next step Date: Tue, 21 Jan 2003 15:44:38 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 > Yes. Leave it alone, people may be shocked, but it's the right thing. You cannot commit stuff like this w/o calling for a review. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 15:53:16 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07DD837B401 for ; Tue, 21 Jan 2003 15:53:16 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4942E43F18 for ; Tue, 21 Jan 2003 15:53:15 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0LNr91e087834; Tue, 21 Jan 2003 16:53:10 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Jan 2003 16:51:25 -0700 (MST) Message-Id: <20030121.165125.29485504.imp@bsdimp.com> To: sam@errno.com Cc: bright@mu.org, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step From: "M. Warner Losh" In-Reply-To: <072d01c2c1a7$0fbba490$52557f42@errno.com> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <072d01c2c1a7$0fbba490$52557f42@errno.com> "Sam Leffler" writes: : > Yes. Leave it alone, people may be shocked, but it's the right thing. : : You cannot commit stuff like this w/o calling for a review. Based on the feedback I've gotten so far, it looks like there's widespread support for the backout + direction change. The reason there's support is that it has been thought out and is bulletproof, not a one-off hack. We've got to start using interfaces that are more robust if we are to get the smp/kse work done. While your changes are well intentioned, they take us away from a robust interface to a hackish one that is sufficeint, but unverifiable. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 16:16:18 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 930E537B401 for ; Tue, 21 Jan 2003 16:16:17 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4810B43F1E for ; Tue, 21 Jan 2003 16:16:17 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 14447AE163; Tue, 21 Jan 2003 16:16:12 -0800 (PST) Date: Tue, 21 Jan 2003 16:16:11 -0800 From: Alfred Perlstein To: Sam Leffler Cc: "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122001611.GJ42333@elvis.mu.org> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072d01c2c1a7$0fbba490$52557f42@errno.com> User-Agent: Mutt/1.4i 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 * Sam Leffler [030121 15:44] wrote: > > Yes. Leave it alone, people may be shocked, but it's the right thing. > > You cannot commit stuff like this w/o calling for a review. I did call for review to the -arch list. No one replied except a single positive email i got privately. There was 24 hours for this to be addressed. I am also available on IRC most of the time and no one made negative comments about the proposal there either. -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 16:23:41 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFBC737B401 for ; Tue, 21 Jan 2003 16:23:40 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E0FB43ED8 for ; Tue, 21 Jan 2003 16:23:40 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 2C235AE28D; Tue, 21 Jan 2003 16:23:40 -0800 (PST) Date: Tue, 21 Jan 2003 16:23:40 -0800 From: Alfred Perlstein To: "M. Warner Losh" Cc: sam@errno.com, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122002340.GK42333@elvis.mu.org> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030121.165125.29485504.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030121.165125.29485504.imp@bsdimp.com> User-Agent: Mutt/1.4i 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 [030121 15:53] wrote: > In message: <072d01c2c1a7$0fbba490$52557f42@errno.com> > "Sam Leffler" writes: > : > Yes. Leave it alone, people may be shocked, but it's the right thing. > : > : You cannot commit stuff like this w/o calling for a review. > > Based on the feedback I've gotten so far, it looks like there's > widespread support for the backout + direction change. The reason > there's support is that it has been thought out and is bulletproof, > not a one-off hack. We've got to start using interfaces that are more > robust if we are to get the smp/kse work done. While your changes are > well intentioned, they take us away from a robust interface to a > hackish one that is sufficeint, but unverifiable. It's obivous that you either haven't even read or are too overwhelmed by whining to considered my points. I expect you to at least feign enough respect for me to consider the points I brought up in response to your post. The old interface was a hack to "remind" people too stupid to RTFM/UTSL about how the allocators worked. And they didn't work, there were still mistakes. This "hack" makes it _impossible_ to make any of the mistakes done previously. Your "fix" makes the same mistakes possible, but now will panic()s instead of doing what was intended if not written. -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 16:25: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E44F37B401 for ; Tue, 21 Jan 2003 16:25:05 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54E0E43EB2 for ; Tue, 21 Jan 2003 16:25:04 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0M0OiMW025156; Tue, 21 Jan 2003 16:24:44 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0M0OrgZ001441; Tue, 21 Jan 2003 16:24:53 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0M0Orcb001440; Tue, 21 Jan 2003 16:24:53 -0800 (PST) Date: Tue, 21 Jan 2003 16:24:53 -0800 From: Marcel Moolenaar To: Alfred Perlstein Cc: Sam Leffler , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122002453.GA1290@dhcp01.pn.xcllnt.net> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030122001611.GJ42333@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122001611.GJ42333@elvis.mu.org> User-Agent: Mutt/1.5.3i 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, Jan 21, 2003 at 04:16:11PM -0800, Alfred Perlstein wrote: > * Sam Leffler [030121 15:44] wrote: > > > Yes. Leave it alone, people may be shocked, but it's the right thing. > > > > You cannot commit stuff like this w/o calling for a review. > > I did call for review to the -arch list. > > No one replied except a single positive email i got privately. > > There was 24 hours for this to be addressed. > > I am also available on IRC most of the time and no one made negative > comments about the proposal there either. The last sentence of your original email was: \begin{quote} I'm cleaning up my generated diff now, and I'll be posting it shortly \end{quote} Committing the diff without posting it first looks to me like the hacking equivalent of premature ejaculation: just too eager and exited... -- 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 Tue Jan 21 16:28: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58BD237B405 for ; Tue, 21 Jan 2003 16:27:59 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E65343F18 for ; Tue, 21 Jan 2003 16:27:58 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 4B4AEAE2AC; Tue, 21 Jan 2003 16:27:58 -0800 (PST) Date: Tue, 21 Jan 2003 16:27:58 -0800 From: Alfred Perlstein To: Marcel Moolenaar Cc: Sam Leffler , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122002758.GL42333@elvis.mu.org> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030122001611.GJ42333@elvis.mu.org> <20030122002453.GA1290@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122002453.GA1290@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4i 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 * Marcel Moolenaar [030121 16:25] wrote: > > The last sentence of your original email was: > > \begin{quote} > I'm cleaning up my generated diff now, and I'll be posting it shortly > \end{quote} > > Committing the diff without posting it first looks to me like the > hacking equivalent of premature ejaculation: just too eager and > exited... The md5s on the generated object files for LINT didn't change except for 2 or 3 files where I had to update strings. But more to the point, do you actually have a technical reason to back it out or are you just feeding on the mass hysteria and picking nits? -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 16:38: 2 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36CDE37B401 for ; Tue, 21 Jan 2003 16:38:01 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D7F643ED8 for ; Tue, 21 Jan 2003 16:38:00 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id h0M0bwnN076210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 21 Jan 2003 16:37:58 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <082501c2c1ae$83015c90$52557f42@errno.com> From: "Sam Leffler" To: "Alfred Perlstein" , "Marcel Moolenaar" Cc: "M. Warner Losh" , References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030122001611.GJ42333@elvis.mu.org> <20030122002453.GA1290@dhcp01.pn.xcllnt.net> <20030122002758.GL42333@elvis.mu.org> Subject: Re: Alfre's malloc changes: the next step Date: Tue, 21 Jan 2003 16:37:28 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 > * Marcel Moolenaar [030121 16:25] wrote: > > > > The last sentence of your original email was: > > > > \begin{quote} > > I'm cleaning up my generated diff now, and I'll be posting it shortly > > \end{quote} > > > > Committing the diff without posting it first looks to me like the > > hacking equivalent of premature ejaculation: just too eager and > > exited... > > The md5s on the generated object files for LINT didn't change except > for 2 or 3 files where I had to update strings. > > But more to the point, do you actually have a technical reason to > back it out or are you just feeding on the mass hysteria and picking > nits? I disagree with your changes but that's immaterial. To make widespread changes w/o any review is contrary to the way a _GROUP_ project like this works. Then to react as you have simply compounds the matter. I value the contributions you make but you've got to work with folks. I don't know of anyone involved in FreeBSD that has the right to say f*ck off; and that's what I hear you saying. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 16:41:18 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61C2037B401 for ; Tue, 21 Jan 2003 16:41:17 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A55E743F13 for ; Tue, 21 Jan 2003 16:41:16 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0M0f3MW025245; Tue, 21 Jan 2003 16:41:03 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0M0fCgZ001483; Tue, 21 Jan 2003 16:41:12 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0M0fCxv001482; Tue, 21 Jan 2003 16:41:12 -0800 (PST) Date: Tue, 21 Jan 2003 16:41:12 -0800 From: Marcel Moolenaar To: Alfred Perlstein Cc: Sam Leffler , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122004112.GA1450@dhcp01.pn.xcllnt.net> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030122001611.GJ42333@elvis.mu.org> <20030122002453.GA1290@dhcp01.pn.xcllnt.net> <20030122002758.GL42333@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122002758.GL42333@elvis.mu.org> User-Agent: Mutt/1.5.3i 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, Jan 21, 2003 at 04:27:58PM -0800, Alfred Perlstein wrote: > But more to the point, do you actually have a technical reason to > back it out or are you just feeding on the mass hysteria and picking > nits? I'm feeding on mass hysteria. You appear insensitive to technical reason. -- 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 Tue Jan 21 16:48:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7BE737B401 for ; Tue, 21 Jan 2003 16:48:46 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E985243F5F for ; Tue, 21 Jan 2003 16:48:45 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id A145AAE25C; Tue, 21 Jan 2003 16:48:45 -0800 (PST) Date: Tue, 21 Jan 2003 16:48:45 -0800 From: Alfred Perlstein To: Sam Leffler Cc: Marcel Moolenaar , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122004845.GM42333@elvis.mu.org> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030122001611.GJ42333@elvis.mu.org> <20030122002453.GA1290@dhcp01.pn.xcllnt.net> <20030122002758.GL42333@elvis.mu.org> <082501c2c1ae$83015c90$52557f42@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <082501c2c1ae$83015c90$52557f42@errno.com> User-Agent: Mutt/1.4i 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 * Sam Leffler [030121 16:38] wrote: > > * Marcel Moolenaar [030121 16:25] wrote: > > > > > The md5s on the generated object files for LINT didn't change except > > for 2 or 3 files where I had to update strings. > > > > But more to the point, do you actually have a technical reason to > > back it out or are you just feeding on the mass hysteria and picking > > nits? > > I disagree with your changes but that's immaterial. To make widespread > changes w/o any review is contrary to the way a _GROUP_ project like this > works. Then to react as you have simply compounds the matter. I value the > contributions you make but you've got to work with folks. I don't know of > anyone involved in FreeBSD that has the right to say f*ck off; and that's > what I hear you saying. I haven't said that. What I keep asking for is a solution other than "back it out". Do I really need to give a message that implies premature ejactulation as much respect as I already have? The only other solution that makes some sense would be to do this: restore M_WAITOK, but make it a bit, 0x02 Now either just share them with the mbuf subsystem... or make the mbuf flags MB_WAIT/MB_NOWAIT. Without looking at the manpages I'd like you to try to remeber which of the old flags went with which interface. Of course we'll still have people making mistakes, and if assertions are sprinkled in to "catch" this, we'll have user or even remote DoS's when it creeps into uncommon code paths. Before we even go down that path, can you show me some code that is not completely obviously wrong that can cause a problem with the current change? There's plenty of cvs history that shows that old flags/interface caused problems. -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 17: 1:11 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AFAE37B401 for ; Tue, 21 Jan 2003 17:01:10 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id A95B143F13 for ; Tue, 21 Jan 2003 17:01:09 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0M12hi74716; Tue, 21 Jan 2003 20:02:43 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 21 Jan 2003 20:02:43 -0500 From: Bosko Milekic To: Alfred Perlstein Cc: "M. Warner Losh" , arch@freebsd.org Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030121200243.A74685@unixdaemons.com> References: <20030121.144243.52206100.imp@bsdimp.com> <20030121233932.GI42333@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030121233932.GI42333@elvis.mu.org>; from bright@mu.org on Tue, Jan 21, 2003 at 03:39:32PM -0800 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, Jan 21, 2003 at 03:39:32PM -0800, Alfred Perlstein wrote: > > 1) Make M_WAITOK and M_NOWAIT mandatory and exclusive in malloc.c. > > You must specify one or the other, but not both. > > I keep hearing people say that having M_WAITOK implicit when M_NOWAIT > is absent as a problem, it is not a problem, it's how things should > be. One should only, if ever use M_NOWAIT from interrupt context. > > You should not be using M_NOWAIT because your locking is incorrect > and you're holding a mutex when you need to call malloc/mget in > user context. I agree. [...] I think that this change should not be backed out until people agree what they want to do and only after the agreement is reached should we even consider HOW to properly make the change (e.g., either back out the current one and then commit the new one or just apply a new delta to the existing code). Personally, I don't think it should be backed out. The default behavior should be to wait (or in the mbuf case, try to wait). The only exception should, strictly speaking, be interrupt code. I think this is pretty clear from an API perspective. But my ears (or eyes in this case) are wide open for compelling reasons to keep the old 'behavior' (besides for the common and rather lame "compatibility" which by the way makes no sense at all given that our semantics are different anyway, forget about API differences). -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 21 17: 2:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 209CE37B401 for ; Tue, 21 Jan 2003 17:02:47 -0800 (PST) Received: from web13404.mail.yahoo.com (web13404.mail.yahoo.com [216.136.175.62]) by mx1.FreeBSD.org (Postfix) with SMTP id C866043EB2 for ; Tue, 21 Jan 2003 17:02:46 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20030122010246.52789.qmail@web13404.mail.yahoo.com> Received: from [200.24.79.98] by web13404.mail.yahoo.com via HTTP; Wed, 22 Jan 2003 02:02:46 CET Date: Wed, 22 Jan 2003 02:02:46 +0100 (CET) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) To: Marcel Moolenaar Cc: arch@FreeBSD.ORG In-Reply-To: <20030121212132.GA593@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 --- Marcel Moolenaar ha scritto: > On Tue, Jan 21, 2003 at 05:47:13AM +0100, Pedro F. > Giffuni wrote: > > OK, I found it: > > > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=302402+322879+/usr/local/www/db/text/1998/freebsd-current/19980802.freebsd-current > > It makes perfect sense to me why this hasn't been > implemented. Not > because it's wrong, but because it's impractical. Ahem... the original document is from 1993. By those years it was probably ahead of it's time :-). I think there is one important thing that must be learned: What ever is done nowadays, must be based on an OO design. In support to this, Newbus (which wasn't even a plan in those years) is our friend. I propose the following approach: 1) properly newbussify all the devices used by our console. 2) newbussify syscons (it doesn't use methods, does it?) and clean the PC specifics as much as possible. 3) port and newbussify wscons. 4) find a way to run the both at the same time. I don't think we should go directly to (3). FWIW, the last time I tried running pcvt I got really scared by the incompatibilities: X didn't run, screensavers would block the console and even pine wasn't functional either. Moving everyone by default to another console would be hectic. > > An interesting read for historical reasons, but not > really for the > problem at hand. I still don't know how X is or > would be affected if > we would change our console implementation... > There are security issues too, and that's why libSVGA is considered ugly. For the time being we should continue doing what everyone does ;-). KGI is perhaps the only opensource project that has considered several important issues. I think it's the way to go for the future, although it still requires more hacking cycles. cheers, Pedro. ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 17:10:32 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC1DE37B401; Tue, 21 Jan 2003 17:10:31 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id E31AA43F1E; Tue, 21 Jan 2003 17:10:30 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.6/8.12.6) with ESMTP id h0M1AJwN016678; Wed, 22 Jan 2003 01:10:19 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.6/8.12.6/Submit) with UUCP id h0M1AJsV016677; Wed, 22 Jan 2003 01:10:19 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.6/8.12.6) with ESMTP id h0M15BaX081212; Wed, 22 Jan 2003 03:05:12 +0200 (SAST) (envelope-from mark@grondar.org) Message-Id: <200301220105.h0M15BaX081212@grimreaper.grondar.org> To: phk@FreeBSD.ORG Cc: "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step In-Reply-To: Your message of "Tue, 21 Jan 2003 22:46:06 +0100." <18555.1043185566@critter.freebsd.dk> Date: Wed, 22 Jan 2003 01:05:11 +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 > In message <20030121.144243.52206100.imp@bsdimp.com>, "M. Warner Losh" writes : > > >I think there'd be strong support for this. > > vote++; vote++; M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 17:17:16 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A4D037B401; Tue, 21 Jan 2003 17:17:14 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id B095B43F18; Tue, 21 Jan 2003 17:17:13 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0M1Ijj74848; Tue, 21 Jan 2003 20:18:45 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 21 Jan 2003 20:18:45 -0500 From: Bosko Milekic To: Mark Murray Cc: phk@FreeBSD.ORG, "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030121201845.A74822@unixdaemons.com> References: <18555.1043185566@critter.freebsd.dk> <200301220105.h0M15BaX081212@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200301220105.h0M15BaX081212@grimreaper.grondar.org>; from mark@grondar.org on Wed, Jan 22, 2003 at 01:05:11AM +0000 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, Jan 22, 2003 at 01:05:11AM +0000, Mark Murray wrote: > > In message <20030121.144243.52206100.imp@bsdimp.com>, "M. Warner Losh" writes > : > > > > >I think there'd be strong support for this. > > > > vote++; > > vote++; > > M > -- > Mark Murray > iumop ap!sdn w,I idlaH I don't get it. What's the point of this "vote++" thing? Can you people state what your technical arguments are, for a change? Instead of arguing "this should have been done this way and this is not right and oh my G-d somebody call the fire department" why don't we sit back a little, take a few deep breaths, consider that OK, yes, the change should have been posted for review but it was not and now we have to decide on what the best approach is, based on TECHNICAL merit. Yes, I agree, it should have probably been given more of a review period but what's done is done so instead of backing out something that you may just end up recommitting anyway, tell us why you think it's technically wrong. I think that everyone ought to have the right to argue either case, but it has to be a technical discussion. Stop blindly urging a backout when all it may end up doing is bloating the repo even more than it already is. Regards, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 21 17:26:20 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A615437B401; Tue, 21 Jan 2003 17:26:18 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 594F743E4A; Tue, 21 Jan 2003 17:26:18 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 471A02A7EA; Tue, 21 Jan 2003 17:26:18 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bosko Milekic Cc: Mark Murray , phk@FreeBSD.ORG, "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step In-Reply-To: <20030121201845.A74822@unixdaemons.com> Date: Tue, 21 Jan 2003 17:26:18 -0800 From: Peter Wemm Message-Id: <20030122012618.471A02A7EA@canning.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 Bosko Milekic wrote: > > On Wed, Jan 22, 2003 at 01:05:11AM +0000, Mark Murray wrote: > > > In message <20030121.144243.52206100.imp@bsdimp.com>, "M. Warner Losh" wr ites > > : > > > > > > >I think there'd be strong support for this. > > > > > > vote++; > > > > vote++; > > > > M > > -- > > Mark Murray > > iumop ap!sdn w,I idlaH > > I don't get it. What's the point of this "vote++" thing? Can you > people state what your technical arguments are, for a change? Instead > of arguing "this should have been done this way and this is not right > and oh my G-d somebody call the fire department" why don't we sit back > a little, take a few deep breaths, consider that OK, yes, the change > should have been posted for review but it was not and now we have to > decide on what the best approach is, based on TECHNICAL merit. Yes, I > agree, it should have probably been given more of a review period but > what's done is done so instead of backing out something that you may > just end up recommitting anyway, tell us why you think it's > technically wrong. > > I think that everyone ought to have the right to argue either case, > but it has to be a technical discussion. Stop blindly urging a > backout when all it may end up doing is bloating the repo even more > than it already is. With my cvs hat on, I firmly support this. Dont back this out until an alternative course of action has been decided. Go from "here" to "there", not "here" to "back to square 1" and then "there". Repository whiplash serves nobody. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Tue Jan 21 18:14:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86D5D37B401; Tue, 21 Jan 2003 18:14:58 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8686543F18; Tue, 21 Jan 2003 18:14:57 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0M2Ep1e088617; Tue, 21 Jan 2003 19:14:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Jan 2003 19:13:06 -0700 (MST) Message-Id: <20030121.191306.48471392.imp@bsdimp.com> To: peter@wemm.org Cc: bmilekic@unixdaemons.com, mark@grondar.org, phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step From: "M. Warner Losh" In-Reply-To: <20030122012618.471A02A7EA@canning.wemm.org> References: <20030121201845.A74822@unixdaemons.com> <20030122012618.471A02A7EA@canning.wemm.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030122012618.471A02A7EA@canning.wemm.org> Peter Wemm writes: : With my cvs hat on, I firmly support this. Dont back this out until : an alternative course of action has been decided. Go from "here" to "there", : not "here" to "back to square 1" and then "there". Repository whiplash : serves nobody. That's why I posted what I did, to get the discussion rolling. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 18:24:58 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DFFE37B401 for ; Tue, 21 Jan 2003 18:24:56 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DC0843E4A for ; Tue, 21 Jan 2003 18:24:55 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0M2Or1e088675; Tue, 21 Jan 2003 19:24:54 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Jan 2003 19:23:09 -0700 (MST) Message-Id: <20030121.192309.127431911.imp@bsdimp.com> To: bright@mu.org Cc: arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step From: "M. Warner Losh" In-Reply-To: <20030122004845.GM42333@elvis.mu.org> References: <20030122002758.GL42333@elvis.mu.org> <082501c2c1ae$83015c90$52557f42@errno.com> <20030122004845.GM42333@elvis.mu.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030122004845.GM42333@elvis.mu.org> Alfred Perlstein writes: : I haven't said that. What I keep asking for is a solution other than : "back it out". Do I really need to give a message that implies premature : ejactulation as much respect as I already have? I already gave an alternative to do that. Only part of my proposal was a backout, but that was mostly to restore the M_ flags that were there prior to the commit. I don't consider that whining. I consider that proposing an alterative. : The only other solution that makes some sense would be to do this: : : restore M_WAITOK, but make it a bit, 0x02 Can't make it bit 0x2 because that's already M_USE_RESERVE, which is why I picked 0x10 and 0x20 for M_NOWAIT and M_WAITOK. I also specifically didn't make M_WAITOK and M_DOWAIT the same because they have subtly different semantics that the users of them should know. : Now either just share them with the mbuf subsystem... or make the mbuf : flags MB_WAIT/MB_NOWAIT. The MB_ flag option is appealing, but has compatibility issues with other systems. It wouldn't be a huge deal to add #ifdefs to those files that are shared, but then you get the problem in a subset of files. There was some agreement to change these, but not much when I was talking it over. If enough people think this is a good idea, I'd go with it, but I'm not sure that enough want it. : Without looking at the manpages I'd like you to try to remeber which of : the old flags went with which interface. One could argue that using an interface w/o looking at the man page is asking for problems. : Of course we'll still have people making mistakes, and if assertions are : sprinkled in to "catch" this, we'll have user or even remote DoS's when : it creeps into uncommon code paths. We already have that, except that people are silently doing the wrong thing and we only die in rare cases. : Before we even go down that path, can you show me some code that : is not completely obviously wrong that can cause a problem with the : current change? There's plenty of cvs history that shows that old : flags/interface caused problems. Sure. I'll post something later tonight. Finally, this isn't an attack on you personally. I saw a lot of people having concerns about the changes you made and went in and proposed an alternative and am working on coding it up. I'll post diffs and get a consensus (or as much of one as I can) before I change anything. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 18:26:27 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6B0937B405 for ; Tue, 21 Jan 2003 18:26:26 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F84B43F43 for ; Tue, 21 Jan 2003 18:26:26 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0M2QK1e088689; Tue, 21 Jan 2003 19:26:20 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Jan 2003 19:24:36 -0700 (MST) Message-Id: <20030121.192436.65876718.imp@bsdimp.com> To: bright@mu.org Cc: sam@errno.com, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step From: "M. Warner Losh" In-Reply-To: <20030122002340.GK42333@elvis.mu.org> References: <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030121.165125.29485504.imp@bsdimp.com> <20030122002340.GK42333@elvis.mu.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030122002340.GK42333@elvis.mu.org> Alfred Perlstein writes: : It's obivous that you either haven't even read or are too overwhelmed by : whining to considered my points. I think you are taking it way too personally. I told you exactly what I thought of the interface: It was not verifiably correct. : The old interface was a hack to "remind" people too stupid to RTFM/UTSL : about how the allocators worked. And they didn't work, there were still : mistakes. This "hack" makes it _impossible_ to make any of the mistakes : done previously. Your "fix" makes the same mistakes possible, but now : will panic()s instead of doing what was intended if not written. The old interface was a hack, as is your new interface. There are a lot of people that would like to make it less of a hack. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 18:32:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A481237B401 for ; Tue, 21 Jan 2003 18:32:46 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69D8343EB2 for ; Tue, 21 Jan 2003 18:32:46 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 465E9AE275; Tue, 21 Jan 2003 18:32:46 -0800 (PST) Date: Tue, 21 Jan 2003 18:32:46 -0800 From: Alfred Perlstein To: arch@freebsd.org Subject: M_ flags summary. Message-ID: <20030122023246.GP42333@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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 First I would like to apologize for my responses, I should have tried to maintian more of a professional attitude and approach. The fact of the matter is that everyone that has been involved I respect greatly and would hate to have soured what should have been a good working relationship. Moving along, it seems that we have the primary caretakers of the allocation subsystems and cvs (bmilekic, jeff, peter) mostly in favor of this change or at least moving forward rather than backward on the issue. We have binary compatibility because the WAIT "flag" was actually zero and that hasn't changed. Remeber, only 5 files have changed md5s from LINT, one has a __DATE__ tag in it and the other is vers.o, the rest were because of string changes I made. Peter has made a suggestion that we ressurect the WAIT "flags" for KLD_MODULES. I'm do not object to it, but I do not think it's needed. Reasons for not bringing back or changing the flags: 1) we'll go back to having the same problems. 2) if we change the 0'd flag to 0x2 then we: waste a bit and have a failure case where the default was fine. 3) garbage in cvs. Personally I would like to see M_NOWAIT defined in a single place rather than in both malloc.h and mbuf.h, anyone have a suggestion for that? -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 19: 4:33 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35ADD37B401; Tue, 21 Jan 2003 19:04:31 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4E9D43E4A; Tue, 21 Jan 2003 19:04:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0M34T0i099695; Tue, 21 Jan 2003 19:04:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0M34TMB099694; Tue, 21 Jan 2003 19:04:29 -0800 (PST) Date: Tue, 21 Jan 2003 19:04:29 -0800 (PST) From: Matthew Dillon Message-Id: <200301220304.h0M34TMB099694@apollo.backplane.com> To: Peter Wemm Cc: Robert Watson , phk@FreeBSD.ORG, "Alan L. Cox" , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030121185208.A82EB2A7EA@canning.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 :> (1) shmfs. :> :> mount -t shmfs foo /shmfs :> :> Handle the implementation using vnodes and DTYPE_VNODE : :> (2) /dev/shm :> :> Handle the implementation using cloning devices and device pager :> magic. :> :> (3) DTYPE_MEMFD :> :> Handle the implementation using a special file descriptor type :> creating using a special creation primitive (similar to kqueue, :> pipe, etc). :> :> Of the three, (3) appears to be simplist to implement, (1) the most :> complicated. I'm probably not qualified to comment on (2), but have to :> say that (3) would be the easiest to stick in MAC magic for :-). But only :> if (3) completely avoids the kitchensinkfd() approach. From the API :> perspective, you could easily hide any of these behind a memfd() library :> call. : :(2) and (3) are not all that different, except that (2) requires another :hack in the mmap syscall code to recognize and magically convert. :(3) is cleaner but requires a more code to add the DTYPE_xxxFD stuff and :affects more places in the kernel where we switch() on fd types. I :personally prefer (3) - which is what Matt has implemented, but could :live with (2). (1) is way more complicated than I want to think about :especially if it goes near vnodes. : :What I'm objecting to though is the syscall that is wrapped around (3) in :Matt's patch. I'd rather use a seperate syscall for any new uses of the :system (timers, whatever) rather than try and come up with a future proof :uber-syscall. What if down the track we discover that we could do :something nifty and reuse part of this, but we need two configuration args :to the syscall.. What then? getsysfd2(....)? I'd rather that we just :create the syscalls for the specific purpose that they're needed for. : :Cheers, :-Peter :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com I don't mind implementing (3) and making it MEMFD specific (not trying to make the syscall capable of more general purpose ops). I will note that (1) would be a step backwards rather then forwards, mainly because we already have a great security paradigm with the normal filesystem and the normal filesystem already spans user-writable filespace (their home directory). All it would take to support a memory-specific namespace rendezvous would be one additional field in the vnode structure (which IMHO is how FIFOs should have been implemented). So, for example: fd = getmemfd(const char *path, off_t size) fd = getmemfd(NULL, size); fd = getmemfd("/var/db/blah.rendezvous", size); xfd = open("/var/db/blah.rendezvous", O_CREAT|O_TRUNC, 0666); fd = fgetmemfd(xfd, size); The memory descriptor 'fd' would not in any way be associated with the file's data space (i.e. the file's size is irrelevant), the file would simply act as a rendezvous. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 19:18:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3924137B401 for ; Tue, 21 Jan 2003 19:18:40 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CB9D43F18 for ; Tue, 21 Jan 2003 19:18:39 -0800 (PST) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.6/8.12.5) with ESMTP id h0M3IXP3077920 for ; Tue, 21 Jan 2003 22:18:33 -0500 (EST) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.12.6/8.12.6/Submit) with SMTP id h0M3IXOZ077917 for ; Tue, 21 Jan 2003 22:18:33 -0500 (EST) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Tue, 21 Jan 2003 22:18:32 -0500 (EST) From: "Andrew R. Reiter" To: arch@FreeBSD.ORG Subject: Re: M_ flags summary. In-Reply-To: <20030122023246.GP42333@elvis.mu.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 I've already responded to Alfred regarding this and he sort of nod'd his head to this question/thought... (and I also should say that I've not been around BSD long enough or been around recently to say anything .. but.. :)) has anyone emailed the bsd-api list to see if this is some change that is/should be made across the board? I know I corrected a few various pieces in the sys/ code that had the incorrect define being used (despite the correct value) and that some of what I fixed was in KAME code (iirc) which I assume to be a bsd-wide deal. Nevertheless, ignore me if Im out of the loop. Cheers, Andrew On Tue, 21 Jan 2003, Alfred Perlstein wrote: :First I would like to apologize for my responses, I should have :tried to maintian more of a professional attitude and approach. :The fact of the matter is that everyone that has been involved I :respect greatly and would hate to have soured what should have been :a good working relationship. : :Moving along, it seems that we have the primary caretakers of the :allocation subsystems and cvs (bmilekic, jeff, peter) mostly in :favor of this change or at least moving forward rather than backward :on the issue. : :We have binary compatibility because the WAIT "flag" was actually :zero and that hasn't changed. Remeber, only 5 files have changed :md5s from LINT, one has a __DATE__ tag in it and the other is vers.o, :the rest were because of string changes I made. : :Peter has made a suggestion that we ressurect the WAIT "flags" for :KLD_MODULES. I'm do not object to it, but I do not think it's :needed. : :Reasons for not bringing back or changing the flags: : 1) we'll go back to having the same problems. : 2) if we change the 0'd flag to 0x2 then we: : waste a bit and : have a failure case where the default was fine. : 3) garbage in cvs. : :Personally I would like to see M_NOWAIT defined in a single place :rather than in both malloc.h and mbuf.h, anyone have a suggestion :for that? : :-- :-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.' : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-arch" in the body of the message : -- Andrew R. Reiter arr@watson.org arr@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 Jan 21 19:40: 5 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A9FE37B401 for ; Tue, 21 Jan 2003 19:40:04 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F72B43E4A for ; Tue, 21 Jan 2003 19:40:03 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0M3fms75257; Tue, 21 Jan 2003 22:41:48 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Tue, 21 Jan 2003 22:41:48 -0500 From: Bosko Milekic To: Alfred Perlstein Cc: arch@freebsd.org Subject: Re: M_ flags summary. Message-ID: <20030121224148.A75236@unixdaemons.com> References: <20030122023246.GP42333@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030122023246.GP42333@elvis.mu.org>; from bright@mu.org on Tue, Jan 21, 2003 at 06:32:46PM -0800 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, Jan 21, 2003 at 06:32:46PM -0800, Alfred Perlstein wrote: [...] > Peter has made a suggestion that we ressurect the WAIT "flags" for > KLD_MODULES. I'm do not object to it, but I do not think it's > needed. > > Reasons for not bringing back or changing the flags: > 1) we'll go back to having the same problems. > 2) if we change the 0'd flag to 0x2 then we: > waste a bit and > have a failure case where the default was fine. > 3) garbage in cvs. I think that defining M_TRYWAIT and M_WAITOK to 0 for KLD_MODULES is fine but I do not think that defining them to anything other than 0 is fine just so that we could add that KASSERT() that Warren suggested in the allocation code. As you point out, defining it to anything other than 0 would actually break ABI compatibility. Defining it to 0 for KLD_MODULES would preserve both API and ABI compatibility for those who actually care. Certainly, both M_TRYWAIT and M_WAITOK would have to be defined in order to maintain full backwards-API compatibility. This would solve the compatibility issue, it would give us the default "wait" behavior that your change introduced, and it would be a very small delta to what has already been committed. > Personally I would like to see M_NOWAIT defined in a single place > rather than in both malloc.h and mbuf.h, anyone have a suggestion > for that? Ditto. I don't have a suggestion, though. :-( > -- > -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.' -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 21 20:15:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1E1A37B401; Tue, 21 Jan 2003 20:15:51 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CBAB43F18; Tue, 21 Jan 2003 20:15:51 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 393AF2A8A5; Tue, 21 Jan 2003 20:15:46 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Robert Watson , phk@FreeBSD.ORG, "Alan L. Cox" , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301220304.h0M34TMB099694@apollo.backplane.com> Date: Tue, 21 Jan 2003 20:15:46 -0800 From: Peter Wemm Message-Id: <20030122041546.393AF2A8A5@canning.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 Matthew Dillon wrote: > :> (1) shmfs. > :> > :> mount -t shmfs foo /shmfs > :> > :> Handle the implementation using vnodes and DTYPE_VNODE > : > :> (2) /dev/shm > :> > :> Handle the implementation using cloning devices and device pager > :> magic. > :> > :> (3) DTYPE_MEMFD > :> > :> Handle the implementation using a special file descriptor type > :> creating using a special creation primitive (similar to kqueue, > :> pipe, etc). > :> > :> Of the three, (3) appears to be simplist to implement, (1) the most > :> complicated. I'm probably not qualified to comment on (2), but have to > :> say that (3) would be the easiest to stick in MAC magic for :-). But only > :> if (3) completely avoids the kitchensinkfd() approach. From the API > :> perspective, you could easily hide any of these behind a memfd() library > :> call. > : > :(2) and (3) are not all that different, except that (2) requires another > :hack in the mmap syscall code to recognize and magically convert. > :(3) is cleaner but requires a more code to add the DTYPE_xxxFD stuff and > :affects more places in the kernel where we switch() on fd types. I > :personally prefer (3) - which is what Matt has implemented, but could > :live with (2). (1) is way more complicated than I want to think about > :especially if it goes near vnodes. > : > :What I'm objecting to though is the syscall that is wrapped around (3) in > :Matt's patch. I'd rather use a seperate syscall for any new uses of the > :system (timers, whatever) rather than try and come up with a future proof > :uber-syscall. What if down the track we discover that we could do > :something nifty and reuse part of this, but we need two configuration args > :to the syscall.. What then? getsysfd2(....)? I'd rather that we just > :create the syscalls for the specific purpose that they're needed for. > : > :Cheers, > :-Peter > :-- > :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > > I don't mind implementing (3) and making it MEMFD specific (not > trying to make the syscall capable of more general purpose ops). > > I will note that (1) would be a step backwards rather then forwards, > mainly because we already have a great security paradigm with the > normal filesystem and the normal filesystem already spans user-writable > filespace (their home directory). All it would take to support a > memory-specific namespace rendezvous would be one additional field > in the vnode structure (which IMHO is how FIFOs should have been > implemented). So, for example: > > fd = getmemfd(const char *path, off_t size) > > fd = getmemfd(NULL, size); > fd = getmemfd("/var/db/blah.rendezvous", size); > > xfd = open("/var/db/blah.rendezvous", O_CREAT|O_TRUNC, 0666); > fd = fgetmemfd(xfd, size); > > The memory descriptor 'fd' would not in any way be associated with the > file's data space (i.e. the file's size is irrelevant), the file would > simply act as a rendezvous. I always kinda liked the SVR4 fattach(2) and fdetach(2) syscalls. You could do arbitary things like this: pipe(fds); fattach("/var/inpipe", pfd[0]); and so on. I think this was how fifos were actually implemented. The rendesvous point counted as an "open" reference count. If all the processes closed it, the file entity wouldn't go away till the node was rm'ed. fdetach(2) also did the obvious thing. I'd rather do that than add another arg to the memfd syscall. Otherwise we're heading into shm_open() look and feel territory. Hmm. I wonder if the POSIX folks would object to us calling the syscall shm_openfd() ? Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Tue Jan 21 20:24:46 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A9A737B401; Tue, 21 Jan 2003 20:24:45 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC72243EB2; Tue, 21 Jan 2003 20:24:44 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0M4Od0i000392; Tue, 21 Jan 2003 20:24:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0M4OdZn000391; Tue, 21 Jan 2003 20:24:39 -0800 (PST) Date: Tue, 21 Jan 2003 20:24:39 -0800 (PST) From: Matthew Dillon Message-Id: <200301220424.h0M4OdZn000391@apollo.backplane.com> To: Peter Wemm Cc: Robert Watson , phk@FreeBSD.ORG, "Alan L. Cox" , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030122041546.393AF2A8A5@canning.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 :I always kinda liked the SVR4 fattach(2) and fdetach(2) syscalls. You :could do arbitary things like this: : : pipe(fds); : fattach("/var/inpipe", pfd[0]); : :and so on. I think this was how fifos were actually implemented. The :rendesvous point counted as an "open" reference count. If all the processes :closed it, the file entity wouldn't go away till the node was rm'ed. :fdetach(2) also did the obvious thing. : :I'd rather do that than add another arg to the memfd syscall. Otherwise :we're heading into shm_open() look and feel territory. Hmm. I wonder if :the POSIX folks would object to us calling the syscall shm_openfd() ? : :Cheers, :-Peter :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com Hmm. Well, the opengroup manual page for fattach() basically says that you fattach(filedes, path) to an existing file and operations on the file are then operations on filedes, but the manual page is specifically STREAM oriented. We could use it for other types of file descriptors but I'm somewhat worried about how error conditions would be detected... for a memory descriptor how do you know you are mmap()ing the memory descriptor rather then the file? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 20:42:18 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE91D37B401 for ; Tue, 21 Jan 2003 20:42:17 -0800 (PST) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id B421C43F3F for ; Tue, 21 Jan 2003 20:42:11 -0800 (PST) (envelope-from hm@kts.org) Received: from fwd01.sul.t-online.de by mailout11.sul.t-online.com with smtp id 18bCiE-0007uE-03; Wed, 22 Jan 2003 05:42:06 +0100 Received: from ernie.kts.org (520021727764-0001@[217.227.44.189]) by fmrl01.sul.t-online.com with esmtp id 18bCi8-1yPVqKC; Wed, 22 Jan 2003 05:42:00 +0100 Received: from bert.int.kts.org (bert.int.kts.org [172.31.42.2]) by ernie.kts.org (Postfix) with ESMTP id 93ED04CB07; Wed, 22 Jan 2003 05:41:59 +0100 (CET) Received: by bert.int.kts.org (Postfix, from userid 100) id 79AC45499; Wed, 22 Jan 2003 05:41:59 +0100 (CET) Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) In-Reply-To: <20030122010246.52789.qmail@web13404.mail.yahoo.com> To: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Date: Wed, 22 Jan 2003 05:41:59 +0100 (CET) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20030122044159.79AC45499@bert.int.kts.org> From: hm@kts.org (Hellmuth Michaelis) X-Sender: 520021727764-0001@t-dialin.net 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 =?iso-8859-1?q?Pedro=20F.=20Giffuni?= wrote: > I don't think we should go directly to (3). FWIW, the > last time I tried running pcvt I got really scared by > the incompatibilities: X didn't run, screensavers > would block the console and even pine wasn't > functional either. Please don't blame pcvt in case you are not able to set it up properly. X runs fine and without any problems (even in cases when syscons has one of its quarterly hickups ..), nothing "blocks" the console and pine runs fine - as does any other program runing on a properly setup pcvt, termcap and TERM variable. hellmuth -- Hellmuth Michaelis Hamburg, Europe hm@kts.org www.kts.org There is a difference between an open mind and a hole in the head. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 20:49: 2 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C71CD37B401 for ; Tue, 21 Jan 2003 20:49:01 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B8C243F13 for ; Tue, 21 Jan 2003 20:49:01 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0M4mv0i000622; Tue, 21 Jan 2003 20:48:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0M4mvMh000621; Tue, 21 Jan 2003 20:48:57 -0800 (PST) Date: Tue, 21 Jan 2003 20:48:57 -0800 (PST) From: Matthew Dillon Message-Id: <200301220448.h0M4mvMh000621@apollo.backplane.com> To: "M. Warner Losh" Cc: bright@mu.org, sam@errno.com, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step References: <072d01c2c1a7$0fbba490$52557f42@errno.com> <20030121.165125.29485504.imp@bsdimp.com> <20030122002340.GK42333@elvis.mu.org> <20030121.192436.65876718.imp@bsdimp.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 Would making the malloc flags an enum and the mbuf flags another enum be sufficient to catch API crossover problems at compile time? For the record, I like the idea of a mandatory M_WAIT or M_NOWAIT, not because it's good design theory, but because this particular interface has been misused so often that we really have to make it explicit. But we shouldn't panic in this case, instead we should printf() (else third party modules may create unecessary crashes for the next couple of years). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 21: 0:11 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8DA737B42B for ; Tue, 21 Jan 2003 21:00:09 -0800 (PST) Received: from web13402.mail.yahoo.com (web13402.mail.yahoo.com [216.136.175.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 5A54343F13 for ; Tue, 21 Jan 2003 21:00:09 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20030122050009.99891.qmail@web13402.mail.yahoo.com> Received: from [200.24.79.130] by web13402.mail.yahoo.com via HTTP; Wed, 22 Jan 2003 06:00:09 CET Date: Wed, 22 Jan 2003 06:00:09 +0100 (CET) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) To: Hellmuth Michaelis Cc: arch@FreeBSD.ORG In-Reply-To: <20030122044159.79AC45499@bert.int.kts.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 OK, That was a LONG time ago and to be honest I didn't take the time to configure it properly. I got too scared when nothing seemed to work and I went back to the syscons kernel. I didn't mean to touch sensitive fibers, in fact I'd like it if it were not a matter of choosing between pcvt and syscons, but rather sharing them. What I do think is that changing the default type to any other would cause pain for many users. cheers, Pedro. --- Hellmuth Michaelis ha scritto: > > Please don't blame pcvt in case you are not able to > set it up properly. > > X runs fine and without any problems (even in cases > when syscons has > one of its quarterly hickups ..), nothing "blocks" > the console and > pine runs fine - as does any other program runing on > a properly > setup pcvt, termcap and TERM variable. > > hellmuth > -- > Hellmuth Michaelis Hamburg, Europe > hm@kts.org www.kts.org > There is a difference between an open mind and > a hole in the head. ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 21:11:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98F7E37B401; Tue, 21 Jan 2003 21:11:37 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-48.dsl.lsan03.pacbell.net [64.169.106.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD04A43E4A; Tue, 21 Jan 2003 21:11:36 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 2A1F466B3A; Tue, 21 Jan 2003 21:11:36 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 08B29165C; Tue, 21 Jan 2003 21:11:36 -0800 (PST) Date: Tue, 21 Jan 2003 21:11:35 -0800 From: Kris Kennaway To: phk@FreeBSD.ORG Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. Message-ID: <20030122051135.GA24850@rot13.obsecurity.org> References: <20030121092851.A27172@citusc.usc.edu> <16728.1043173644@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <16728.1043173644@critter.freebsd.dk> User-Agent: Mutt/1.4i 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 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 21, 2003 at 07:27:24PM +0100, phk@FreeBSD.ORG wrote: > >To the best of your knowledge, there are no remaining serious bugs or > >missing functionality with GEOM (like the disklabel editing problems > >found before 5.0, etc)? >=20 > There is one errata point (can't rewrite BSD boot code on a disk > which is in use) which I am testing a patch for. >=20 > I know of no bugs at present. Thanks, good work. Kris --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+LigHWry0BWjoQKURAhaXAKDqdnaR3U3q0+/6glFSvEzoMJ99kQCgkKLS jNQX2iyb2vdDc0GNwY1srNo= =drC0 -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 21:12:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A253537B401 for ; Tue, 21 Jan 2003 21:12:12 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B306543EB2 for ; Tue, 21 Jan 2003 21:12:10 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0M5Bv1e089458; Tue, 21 Jan 2003 22:11:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Jan 2003 22:11:40 -0700 (MST) Message-Id: <20030121.221140.78708845.imp@bsdimp.com> To: dillon@apollo.backplane.com Cc: bright@mu.org, sam@errno.com, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step From: "M. Warner Losh" In-Reply-To: <200301220448.h0M4mvMh000621@apollo.backplane.com> References: <20030122002340.GK42333@elvis.mu.org> <20030121.192436.65876718.imp@bsdimp.com> <200301220448.h0M4mvMh000621@apollo.backplane.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <200301220448.h0M4mvMh000621@apollo.backplane.com> Matthew Dillon writes: : has been misused so often that we really have to make it explicit. But : we shouldn't panic in this case, instead we should printf() (else third : party modules may create unecessary crashes for the next couple of years). This is actually better than my original idea (which seems to have been misunderstood). My original idea was to have the extra checks only if INVARIANTS was set. However, I like the idea of having a printf like we do now with LOR and the sleep warnings better (maybe with the option to drop into the debugger/panic like the witness stuff does). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 21 21:20:46 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A318437B401 for ; Tue, 21 Jan 2003 21:20:45 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE09243ED8 for ; Tue, 21 Jan 2003 21:20:44 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0M5Kh1e089525; Tue, 21 Jan 2003 22:20:44 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 21 Jan 2003 22:20:25 -0700 (MST) Message-Id: <20030121.222025.101592442.imp@bsdimp.com> To: bmilekic@unixdaemons.com Cc: bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. From: "M. Warner Losh" In-Reply-To: <20030121224148.A75236@unixdaemons.com> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030121224148.A75236@unixdaemons.com> Bosko Milekic writes: : I think that defining M_TRYWAIT and M_WAITOK to 0 for KLD_MODULES is : fine but I do not think that defining them to anything other than 0 is : fine just so that we could add that KASSERT() that Warren suggested in : the allocation code. As you point out, defining it to anything other : than 0 would actually break ABI compatibility. Defining it to 0 for : KLD_MODULES would preserve both API and ABI compatibility for those : who actually care. Certainly, both M_TRYWAIT and M_WAITOK would have : to be defined in order to maintain full backwards-API compatibility. Actually, I think that we shouldn't define them to be 0 for modules. Instead, we should define them to the new values. However, we should accpet '0' with the old meaning for a while (maybe with a printf). There are going to be enough ABI changes between 5.0 and 5.branch that worrying about this one is likely not worth the effort to do special things for the modules. It isn't going to be too much longer before it becomes impossible for 5.0-RELEASE compiled modules to not operate with 5.0-CURRENT. I think we need to go fartehr than Alfred[*] is wanting to go, but until I post a patch I'm going to be quiet. Warner [*] I'd like to appologize for the Alfre's in the last subject line. My keyboard is sometimes producing 0 d's or 2 d's when I hit the 'd' key and I didn't notice. It wasn't intended to be an insult. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 0: 1:18 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8FF237B401 for ; Wed, 22 Jan 2003 00:01:17 -0800 (PST) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1565243F3F for ; Wed, 22 Jan 2003 00:01:17 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-11-62-147-120-213.dial.proxad.net [62.147.120.213]) by postfix3-2.free.fr (Postfix) with SMTP id 009ADC0B5 for ; Wed, 22 Jan 2003 09:01:15 +0100 (CET) Received: (qmail 6837 invoked by uid 1001); 22 Jan 2003 08:15:19 -0000 Date: Wed, 22 Jan 2003 09:15:19 +0100 From: Nicolas Souchu To: Alexander@Leidinger.net Cc: Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030122091519.B6700@armor.fastether> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030120074638.A11055@armor.fastether> <20030120222027.GA597@athlon.pn.xcllnt.net> <3E2D173C.3040507@graphics.cs.uni-sb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3E2D173C.3040507@graphics.cs.uni-sb.de>; from netchild@graphics.cs.uni-sb.de on Tue, Jan 21, 2003 at 10:47:40AM +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 On Tue, Jan 21, 2003 at 10:47:40AM +0100, Alexander Leidinger wrote: > Marcel Moolenaar wrote: > > [KGI] > > > I took a quick look at it. I'm not opposed to having graphics support > > in the kernel. The problem I think I see is that we probably have > > enough interest to make standard VGA work, but never really have the > > people or interest to keep up with the latest and greatest graphics > > engine. So, I think this would be useful only in a model where the > > graphics drivers are contributed and the X server makes use of it. > > So, if XFree86 changes to this model, then I see potential... > > Chicken and egg problem... as far as I remember (I looked at it looong > ago) they have a X server too... or at least they want to provide one. KGI provides a X server accelerated (PhoneiX) implementation not based on X. On the other hand GGI (http://www.ggi-project.org), the user library going with KGI does provide XFree86 (called XGGI) running) on top of the KGI driver framework without its own drivers. Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@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 Jan 22 0:19:27 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 127C937B401 for ; Wed, 22 Jan 2003 00:19:26 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1951643F43 for ; Wed, 22 Jan 2003 00:19:25 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0M8JFMW026863; Wed, 22 Jan 2003 00:19:15 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0M8JOgZ010997; Wed, 22 Jan 2003 00:19:24 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0M8JN27010996; Wed, 22 Jan 2003 00:19:23 -0800 (PST) Date: Wed, 22 Jan 2003 00:19:23 -0800 From: Marcel Moolenaar To: Nicolas Souchu Cc: Alexander@Leidinger.net, arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030122081923.GA10985@dhcp01.pn.xcllnt.net> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030120074638.A11055@armor.fastether> <20030120222027.GA597@athlon.pn.xcllnt.net> <3E2D173C.3040507@graphics.cs.uni-sb.de> <20030122091519.B6700@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122091519.B6700@armor.fastether> User-Agent: Mutt/1.5.3i 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, Jan 22, 2003 at 09:15:19AM +0100, Nicolas Souchu wrote: > On Tue, Jan 21, 2003 at 10:47:40AM +0100, Alexander Leidinger wrote: > > Marcel Moolenaar wrote: > > > > [KGI] > > > > > I took a quick look at it. I'm not opposed to having graphics support > > > in the kernel. The problem I think I see is that we probably have > > > enough interest to make standard VGA work, but never really have the > > > people or interest to keep up with the latest and greatest graphics > > > engine. So, I think this would be useful only in a model where the > > > graphics drivers are contributed and the X server makes use of it. > > > So, if XFree86 changes to this model, then I see potential... > > > > Chicken and egg problem... as far as I remember (I looked at it looong > > ago) they have a X server too... or at least they want to provide one. > > KGI provides a X server accelerated (PhoneiX) implementation not based on X. On > the other hand GGI (http://www.ggi-project.org), the user library going > with KGI does provide XFree86 (called XGGI) running) on top of the KGI > driver framework without its own drivers. Do I understand correctly that "without its own drivers" means that XFree86 doesn't have its own drivers and thus that the kernel driver is the hardware driver that's being used (though KGI)? -- 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 Wed Jan 22 3:48: 3 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A14A37B401 for ; Wed, 22 Jan 2003 03:48:01 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F69943ED8 for ; Wed, 22 Jan 2003 03:48:00 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0MBlpBs022642; Wed, 22 Jan 2003 11:47:51 GMT (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) by bluebottle.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0MBllt8025459; Wed, 22 Jan 2003 11:47:47 GMT (envelope-from dfr@nlsystems.com) Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) From: Doug Rabson To: "Pedro F. Giffuni" Cc: Marcel Moolenaar , arch@FreeBSD.ORG In-Reply-To: <20030122010246.52789.qmail@web13404.mail.yahoo.com> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> Content-Type: text/plain Organization: Message-Id: <1043236066.28124.6.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 22 Jan 2003 11:47:46 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 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, 2003-01-22 at 01:02, Pedro F. Giffuni wrote: > --- Marcel Moolenaar ha scritto: > > On Tue, Jan 21, 2003 at 05:47:13AM +0100, Pedro F. > > Giffuni wrote: > > > OK, I found it: > > > > > > > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=302402+322879+/usr/local/www/db/text/1998/freebsd-current/19980802.freebsd-current > > > > It makes perfect sense to me why this hasn't been > > implemented. Not > > because it's wrong, but because it's impractical. > > Ahem... the original document is from 1993. By those > years it was probably ahead of it's time :-). I think > there is one important thing that must be learned: > > What ever is done nowadays, must be based on an OO > design. > > In support to this, Newbus (which wasn't even a plan > in those years) is our friend. > I propose the following approach: > > 1) properly newbussify all the devices used by our > console. > 2) newbussify syscons (it doesn't use methods, does > it?) and clean the PC specifics as much as possible. > 3) port and newbussify wscons. > 4) find a way to run the both at the same time. The main sticking point for this stuff is that console is needed before the device tree is probed. I think the right approach will be to define a set of interfaces for the video console and then implement those interfaces using the lower-level kobj system. This allows you to put together a working console output system before the rest of the system is up and running. You can even use kobj before malloc is working if you are careful. I once had a prototype system on alpha which used kobj for all the busspace i/o primitives. It worked pretty well with kobj but I later changed it to use fixed arrays of function pointers because there was some interest in porting it over to 4.x which didn't have kobj at the time. I always preferred the kobj version since it had a nice stable ABI. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 4:18:52 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A7EC37B401; Wed, 22 Jan 2003 04:18:51 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78C7B43F18; Wed, 22 Jan 2003 04:18:50 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id h0MCIUP4025285; Wed, 22 Jan 2003 07:18:31 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 22 Jan 2003 07:18:30 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Dillon Cc: Peter Wemm , phk@FreeBSD.ORG, "Alan L. Cox" , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301220424.h0M4OdZn000391@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, 21 Jan 2003, Matthew Dillon wrote: > Hmm. Well, the opengroup manual page for fattach() basically says > that you fattach(filedes, path) to an existing file and operations on > the file are then operations on filedes, but the manual page is > specifically STREAM oriented. We could use it for other types of > file descriptors but I'm somewhat worried about how error conditions > would be detected... for a memory descriptor how do you know you are > mmap()ing the memory descriptor rather then the file? Yeah, I have to admit I'm not thrilled by these prospects -- there are lots of places in the kernel where we directly operate on the vnode w/o a struct file, or the supporting device, etc. Implementing consistent semantics would be daunting at best. One of the nice things about the current patch + rename to memfd system call was the pure simplicity of it. It introduces one new type of object created by a simple system call, and then a single operation on it, mmap(). I recognize the benefits of explicit namespaces in IPC, of course... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 7: 1:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3C6F37B401 for ; Wed, 22 Jan 2003 07:01:31 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E20643F5B for ; Wed, 22 Jan 2003 07:01:31 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0MF2r576494; Wed, 22 Jan 2003 10:02:53 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 22 Jan 2003 10:02:53 -0500 From: Bosko Milekic To: "M. Warner Losh" Cc: bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122100253.A76397@unixdaemons.com> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030121.222025.101592442.imp@bsdimp.com>; from imp@bsdimp.com on Tue, Jan 21, 2003 at 10:20: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 On Tue, Jan 21, 2003 at 10:20:25PM -0700, M. Warner Losh wrote: > In message: <20030121224148.A75236@unixdaemons.com> > Bosko Milekic writes: > : I think that defining M_TRYWAIT and M_WAITOK to 0 for KLD_MODULES is > : fine but I do not think that defining them to anything other than 0 is > : fine just so that we could add that KASSERT() that Warren suggested in > : the allocation code. As you point out, defining it to anything other > : than 0 would actually break ABI compatibility. Defining it to 0 for > : KLD_MODULES would preserve both API and ABI compatibility for those > : who actually care. Certainly, both M_TRYWAIT and M_WAITOK would have > : to be defined in order to maintain full backwards-API compatibility. > > Actually, I think that we shouldn't define them to be 0 for modules. > Instead, we should define them to the new values. However, we should > accpet '0' with the old meaning for a while (maybe with a printf). > There are going to be enough ABI changes between 5.0 and 5.branch that > worrying about this one is likely not worth the effort to do special > things for the modules. It isn't going to be too much longer before > it becomes impossible for 5.0-RELEASE compiled modules to not operate > with 5.0-CURRENT. Changing the value to something other than zero has the following problems: 1. Breaks ABI compatibility (but granted this is fine as long as it's done with good reason, and you have to prove that it's good reason beyond just 'this is the way I think it should be done') 2. Gives the impression that it's OK if just any code calls the allocators requesting either the wait behavior or the dont-wait behavior. This is the biggest point that you have to argue and if you can convince us here you can convince us that your change is worth breaking ABI compatibility for. Now, from what I gather, your argument for re-introducing the M_WAIT{,OK} flags and defining them to something other than zero is: 1. It allows us to error-check in the allocator code and make sure that the caller is passing in one or the other and be able to provide some sort of feedback to the programmer (either via a printf, or whatever) letting him know that he's made a mistake. 2. You think that the caller should always be allowed to specify whether or not he is willing to wait. This is basically the counter-part of (2) above. I'm going to argue why I think (1) is not worth it first. The claim that the added error reporting is worth it assumes that the caller is unknowingly making a mistake. How do you expect that this will happen? Your claim is that if the programmer calls the allocator without specifying either M_WAIT{,OK} or M_{NO,DONT}WAIT, that the allocator should spew out a warning, at the least. My claim is that unless the programmer passes in M_{NO,DONT}WAIT, the allocator should act according to default behavior. This really ties into (2) above. You're saying that any code needs to specify explicitly whether it wants the wait or dont-wait behavior. I'm saying that code should only explicitly request _not_ waiting. My argument is that only interrupt code and broken code should request the dontwait behavior. If you don't agree, then this is what you have to argue. I think that non-interrupt code should always be willing to try waiting merely because it can. Why would we take the trouble to design a system that allows concurrency in the kernel if we then proceed to write code that doesn't take advantage of it? The only exception is broken code which, possibly due to locking reasons, cannot wait (and we will be able to catch such code later on by grepping for the M_{NO,DONT}WAIT flags) and interrupt code which, due to our design, cannot sleep. So, basically what I'm saying is that the programmer is NEVER making a mistake unless he's calling the allocator code from an ISR without explicitly requesting the dontwait behavior. And if he makes that mistake, we'll leave things to blow right up once the ISR tries to msleep (we'll trap that problem in the scheduler code, not in the allocator code). The one exception, again, is if the programmer needs to specifically request the dontwait behavior because of locking problems he has in his code but in that case your idea of defining M_{,TRY}WAIT to something other than 0 isn't going to help him much either (he would spot the printf, and instead of taking the correct approach to fixing his problem, i.e. fixing the locking issue, he would just pass the flag that silences the printf()). Therefore, I believe that the default behavior in the system should be to always try to wait, at the very least, unless the programmer specifically requests that no waiting is performed. > I think we need to go fartehr than Alfred[*] is wanting to go, but > until I post a patch I'm going to be quiet. > > Warner Regards, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 22 8:30:29 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0488D37B401 for ; Wed, 22 Jan 2003 08:30:29 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 220CD43F18 for ; Wed, 22 Jan 2003 08:30:28 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.6/8.12.6) with ESMTP id h0MGUQwN007445; Wed, 22 Jan 2003 16:30:26 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.6/8.12.6/Submit) with UUCP id h0MGUQ7q007444; Wed, 22 Jan 2003 16:30:26 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.6/8.12.6) with ESMTP id h0MGTQaX091619; Wed, 22 Jan 2003 18:29:26 +0200 (SAST) (envelope-from mark@grondar.org) Message-Id: <200301221629.h0MGTQaX091619@grimreaper.grondar.org> To: Bosko Milekic Cc: arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step In-Reply-To: Your message of "Tue, 21 Jan 2003 20:18:45 EST." <20030121201845.A74822@unixdaemons.com> Date: Wed, 22 Jan 2003 16:29:26 +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 > I don't get it. What's the point of this "vote++" thing? Can you > people state what your technical arguments are, for a change? Mostly a fair point :-). I did it because I didn't want to repeat a previous argument, but I wanted to show support. However, Peter /et al/ has show that the argument that I was supporting is fallacious. So - let me take this opportunity to withdraw my support. Or, on other words "vote--;" ;-) I think that the direction the debate is taking is fine, and I see no further need for my participation (no offence intended). M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 9:21: 3 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F23ED37B401 for ; Wed, 22 Jan 2003 09:21:01 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59D4D43EB2 for ; Wed, 22 Jan 2003 09:21:01 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id h0MHKjdr000240; Wed, 22 Jan 2003 12:20:45 -0500 (EST) Date: Wed, 22 Jan 2003 12:20:45 -0500 (EST) From: Daniel Eischen To: Bosko Milekic Cc: "M. Warner Losh" , bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. In-Reply-To: <20030122100253.A76397@unixdaemons.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 Wed, 22 Jan 2003, Bosko Milekic wrote: > On Tue, Jan 21, 2003 at 10:20:25PM -0700, M. Warner Losh wrote: > > In message: <20030121224148.A75236@unixdaemons.com> > > Bosko Milekic writes: > > : I think that defining M_TRYWAIT and M_WAITOK to 0 for KLD_MODULES is > > : fine but I do not think that defining them to anything other than 0 is > > : fine just so that we could add that KASSERT() that Warren suggested in > > : the allocation code. As you point out, defining it to anything other > > : than 0 would actually break ABI compatibility. Defining it to 0 for > > : KLD_MODULES would preserve both API and ABI compatibility for those > > : who actually care. Certainly, both M_TRYWAIT and M_WAITOK would have > > : to be defined in order to maintain full backwards-API compatibility. > > > > Actually, I think that we shouldn't define them to be 0 for modules. > > Instead, we should define them to the new values. However, we should > > accpet '0' with the old meaning for a while (maybe with a printf). > > There are going to be enough ABI changes between 5.0 and 5.branch that > > worrying about this one is likely not worth the effort to do special > > things for the modules. It isn't going to be too much longer before > > it becomes impossible for 5.0-RELEASE compiled modules to not operate > > with 5.0-CURRENT. [ Good summary elided ] Bosko convinces me. One other thing. How about adding another version of malloc that _only_ acts as if M_NOWAIT was specified and disallow M_NOWAIT from the original malloc()? If flags confusion is a problem, then provide versions of malloc() that don't have flags as arguments, or perhaps don't allow M_WAITOK or M_NOWAIT. -- 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 Jan 22 9:30:12 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25AD737B401 for ; Wed, 22 Jan 2003 09:30:11 -0800 (PST) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ED1243F3F for ; Wed, 22 Jan 2003 09:30:10 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 1796 invoked from network); 22 Jan 2003 17:30:13 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Jan 2003 17:30:13 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h0MHU5UT038189; Wed, 22 Jan 2003 12:30:07 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 22 Jan 2003 12:30:08 -0500 (EST) From: John Baldwin To: Daniel Eischen Subject: Re: M_ flags summary. Cc: arch@FreeBSD.ORG, bright@mu.org, "M. Warner Losh" , Bosko Milekic 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 22-Jan-2003 Daniel Eischen wrote: > On Wed, 22 Jan 2003, Bosko Milekic wrote: >> On Tue, Jan 21, 2003 at 10:20:25PM -0700, M. Warner Losh wrote: >> > In message: <20030121224148.A75236@unixdaemons.com> >> > Bosko Milekic writes: >> > : I think that defining M_TRYWAIT and M_WAITOK to 0 for KLD_MODULES is >> > : fine but I do not think that defining them to anything other than 0 is >> > : fine just so that we could add that KASSERT() that Warren suggested in >> > : the allocation code. As you point out, defining it to anything other >> > : than 0 would actually break ABI compatibility. Defining it to 0 for >> > : KLD_MODULES would preserve both API and ABI compatibility for those >> > : who actually care. Certainly, both M_TRYWAIT and M_WAITOK would have >> > : to be defined in order to maintain full backwards-API compatibility. >> > >> > Actually, I think that we shouldn't define them to be 0 for modules. >> > Instead, we should define them to the new values. However, we should >> > accpet '0' with the old meaning for a while (maybe with a printf). >> > There are going to be enough ABI changes between 5.0 and 5.branch that >> > worrying about this one is likely not worth the effort to do special >> > things for the modules. It isn't going to be too much longer before >> > it becomes impossible for 5.0-RELEASE compiled modules to not operate >> > with 5.0-CURRENT. > > [ Good summary elided ] > > Bosko convinces me. One other thing. How about adding another > version of malloc that _only_ acts as if M_NOWAIT was specified > and disallow M_NOWAIT from the original malloc()? If flags > confusion is a problem, then provide versions of malloc() > that don't have flags as arguments, or perhaps don't allow > M_WAITOK or M_NOWAIT. I originally didn't like this change either because I viewed M_WAITOK and M_NOWAIT as different types rather than treating NOWAIT as a flag. Now that I've adopted the latter view (just as M_ZERO, etc. are flags) I'm probably in favor of just leaving things as they are. The manner in which such an API was proposed and swiftly implemented w/o review leaves much to be desired, but I prefer the new API to the old one now. -- 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 Wed Jan 22 9:38:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 682DE37B401 for ; Wed, 22 Jan 2003 09:38:25 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D74EC43EB2 for ; Wed, 22 Jan 2003 09:38:24 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id h0MHcLnN079733 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 22 Jan 2003 09:38:21 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <0aef01c2c23d$0f1ae690$52557f42@errno.com> From: "Sam Leffler" To: "Bosko Milekic" , "M. Warner Losh" Cc: , References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> Subject: Re: M_ flags summary. Date: Wed, 22 Jan 2003 09:38:21 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 <...long discussion about default behaviours and how callers should not require an M_* parameter when allocating an mbuf...> As one of the original authors of the mbuf code I must say that the intent was for every call to specify whether or not to block waiting for more memory. (I honestly can't recall if that is how the code worked, but that's my recollection of how it was supposed to work). In general I consider it very important that kernel code be as self-documenting as possible. As such implicit states, modes, or actions are a bad idea. In this particular case I want every call to clearly specify whether the caller is willing to block or not. No default values. No implicit meanings (e.g. 0 gives you the default behaviour). Separately I believe using a 0 value to mean "wait" was a mistake and one that should be fixed. As has been discussed, to enforce this change and catch old/broken code we need a mechanism to find instances. This is the reason for changing the "wait" flag to be a non-zero value. As to binary compatibility, I was under the impression that we'd already decided that 5.0 did not mark the start of an ABI freeze because there were too many issues still to be decided (e.g. Robert's MAC->m_tag changes). As such I considered the M_WAIT redefinition fair game and a good move. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 12:52:28 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 590D937B401 for ; Wed, 22 Jan 2003 12:52:27 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id A69E443EB2 for ; Wed, 22 Jan 2003 12:52:26 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0MKqPbs041428 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 15:52:25 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0MKqP4N041427; Wed, 22 Jan 2003 15:52:25 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 15:52:25 -0500 (EST) From: Garrett Wollman Message-Id: <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> To: peter@wemm.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <20030122041546.393AF2A8A5@canning.wemm.org> References: <200301220304.h0M34TMB099694@apollo.backplane.com> Organization: MIT Laboratory for Computer Science 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <20030122041546.393AF2A8A5@canning.wemm.org> you write: >I'd rather do that than add another arg to the memfd syscall. Otherwise >we're heading into shm_open() look and feel territory. Hmm. I wonder if >the POSIX folks would object to us calling the syscall shm_openfd() ? Can you please explain just what precisely your problem is with shm_open()? If we're going to reinvent the wheel, please, let's skip the square and hexagonal stages. - -GAWollman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+LwSHI+eG6b7tlG4RAj56AKCFhYoHdkXhvIX1sGPX9PgXB2dttwCgiR75 53DaDGocAf2aI5F7xR09398= =sswO -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 12:53:24 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 438B037B401 for ; Wed, 22 Jan 2003 12:53:23 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C10143F1E for ; Wed, 22 Jan 2003 12:53:22 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0MKswY77090; Wed, 22 Jan 2003 15:54:58 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 22 Jan 2003 15:54:57 -0500 From: Bosko Milekic To: Sam Leffler Cc: "M. Warner Losh" , bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122155457.A77036@unixdaemons.com> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0aef01c2c23d$0f1ae690$52557f42@errno.com>; from sam@errno.com on Wed, Jan 22, 2003 at 09:38:21AM -0800 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, Jan 22, 2003 at 09:38:21AM -0800, Sam Leffler wrote: > <...long discussion about default behaviours and how callers should not > require an M_* parameter when allocating an mbuf...> > > As one of the original authors of the mbuf code I must say that the intent > was for every call to specify whether or not to block waiting for more > memory. (I honestly can't recall if that is how the code worked, but that's > my recollection of how it was supposed to work). In general I consider it > very important that kernel code be as self-documenting as possible. As such > implicit states, modes, or actions are a bad idea. In this particular case > I want every call to clearly specify whether the caller is willing to block > or not. No default values. No implicit meanings (e.g. 0 gives you the > default behaviour). > > Separately I believe using a 0 value to mean "wait" was a mistake and one > that should be fixed. As has been discussed, to enforce this change and > catch old/broken code we need a mechanism to find instances. This is the > reason for changing the "wait" flag to be a non-zero value. I have a great amount of respect for your opinion on this matter and I am not religiously bound to doing it either way. However, I do think that leaving it as it is (with possibly defining M_WAIT{,OK} to 0 for KLD_MODULES) is the better thing to do. I realize that your idea of the interface is "it'll either block or not block," however when you think of the "new" approach don't think of it that way; rather, think of it as follows: "I am calling the allocator and it will do as much as it can to give me the resources I'm requesting (in the malloc() case, in fact, I'm sure it'll give me the resources I want or else block indefintely, in the mbuf allocator case it'll wait as long as I've configured it to wait - via a sysctl). I don't care what the allocator does. I am a thread executing in the kernel and let the allocator do whatever it takes to give me what I need." If you think of it that way you'll hopefully realize that it's no longer a question of whether or not to wait. Yes, we still provide a dontwait behavior, but in the new approach, that behavior is an _exception_, which is the way it should be. As I said, your thoughts are important to me (and I'm sure to anyone else involved in this discussion) but I have yet to read an argument as to why the dontwait case _shouldn't_ be treated like the exception that it is in SMPng. [...] > Sam Regards, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 22 13: 8: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 044B937B401; Wed, 22 Jan 2003 13:08:00 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E94DA43E4A; Wed, 22 Jan 2003 13:07:58 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0ML7w0i009590; Wed, 22 Jan 2003 13:07:58 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0ML7w7W009589; Wed, 22 Jan 2003 13:07:58 -0800 (PST) Date: Wed, 22 Jan 2003 13:07:58 -0800 (PST) From: Matthew Dillon Message-Id: <200301222107.h0ML7w7W009589@apollo.backplane.com> To: Robert Watson Cc: Peter Wemm , phk@FreeBSD.ORG, "Alan L. Cox" , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: 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 :Yeah, I have to admit I'm not thrilled by these prospects -- there are :lots of places in the kernel where we directly operate on the vnode w/o a :struct file, or the supporting device, etc. Implementing consistent :semantics would be daunting at best. : :One of the nice things about the current patch + rename to memfd system :call was the pure simplicity of it. It introduces one new type of object :created by a simple system call, and then a single operation on it, :mmap(). I recognize the benefits of explicit namespaces in IPC, of :course... : :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects :robert@fledge.watson.org Network Associates Laboratories If we assume that some future system call (fattach-like) will provide us with generic namespace operations for special file descriptors, then the current proposed patch becomes extremely simple and couild also trivially be MFC'd to -stable before the release cutoff. It would be in-line with other system calls such as pipe() and socketpair(). It's a question only of what we should call it. memfd() or getmemfd()? I'm a little worried about namespace pollution with memfd(), so I would put forth 'getmemfd()' as a better syscall name. But I am not rabid about it. int getmemfd(off_t size, int flags) Obtain a mmap()able descriptor representing a VM object of bytes (size will be rounded up to the nearest page). Flags should be 0 for now but may be used in the future to implement wired and/or physical backing store, etc. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 13: 9:31 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C265C37B401 for ; Wed, 22 Jan 2003 13:09:29 -0800 (PST) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 089FE43ED8 for ; Wed, 22 Jan 2003 13:09:29 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-8-62-147-157-185.dial.proxad.net [62.147.157.185]) by postfix3-2.free.fr (Postfix) with SMTP id 086FDC12D for ; Wed, 22 Jan 2003 22:09:27 +0100 (CET) Received: (qmail 8475 invoked by uid 1001); 22 Jan 2003 21:23:35 -0000 Date: Wed, 22 Jan 2003 22:23:35 +0100 From: Nicolas Souchu To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030122222335.A8449@armor.fastether> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030120074638.A11055@armor.fastether> <20030120222027.GA597@athlon.pn.xcllnt.net> <3E2D173C.3040507@graphics.cs.uni-sb.de> <20030122091519.B6700@armor.fastether> <20030122081923.GA10985@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030122081923.GA10985@dhcp01.pn.xcllnt.net>; from marcel@xcllnt.net on Wed, Jan 22, 2003 at 12:19:23AM -0800 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, Jan 22, 2003 at 12:19:23AM -0800, Marcel Moolenaar wrote: > On Wed, Jan 22, 2003 at 09:15:19AM +0100, Nicolas Souchu wrote: > > On Tue, Jan 21, 2003 at 10:47:40AM +0100, Alexander Leidinger wrote: > > > Marcel Moolenaar wrote: > > > > > > [KGI] > > > > > > > I took a quick look at it. I'm not opposed to having graphics support > > > > in the kernel. The problem I think I see is that we probably have > > > > enough interest to make standard VGA work, but never really have the > > > > people or interest to keep up with the latest and greatest graphics > > > > engine. So, I think this would be useful only in a model where the > > > > graphics drivers are contributed and the X server makes use of it. > > > > So, if XFree86 changes to this model, then I see potential... > > > > > > Chicken and egg problem... as far as I remember (I looked at it looong > > > ago) they have a X server too... or at least they want to provide one. > > > > KGI provides a X server accelerated (PhoneiX) implementation not based on X. On > > the other hand GGI (http://www.ggi-project.org), the user library going > > with KGI does provide XFree86 (called XGGI) running) on top of the KGI > > driver framework without its own drivers. > > Do I understand correctly that "without its own drivers" means that > XFree86 doesn't have its own drivers and thus that the kernel driver > is the hardware driver that's being used (though KGI)? You do. -- Nicholas Souchu - nsouch@free.fr - nsouch@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 Jan 22 13:19: 7 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6447837B401 for ; Wed, 22 Jan 2003 13:19:06 -0800 (PST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 134D643E4A for ; Wed, 22 Jan 2003 13:19:06 -0800 (PST) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H94005IXWJS1Z@mta5.snfc21.pbi.net> for arch@freebsd.org; Wed, 22 Jan 2003 13:19:05 -0800 (PST) Date: Wed, 22 Jan 2003 13:20:59 -0800 From: Jeffrey Hsu Subject: Re: Alfre's malloc changes: the next step In-reply-to: Message from Matthew Dillon "of Tue, 21 Jan 2003 20:48:57 PST." <200301220448.h0M4mvMh000621@apollo.backplane.com> To: arch@freebsd.org Message-id: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 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'm going to weigh in here on the side of the all the seasoned BSD veterans that we should preserve the M_WAIT flag. I like saying M_WAIT when I mean M_WAIT. I dislike saying 0 when I mean M_WAIT. The fundamental problem here is that M_WAIT looks like a bit flag. That problem should be directly solved by defining it to be a bit flag. There are no ABI issues with this in FreeBSD 5.x. Warner's proposal to automatically detect programming error is also a good idea. And, that relies on making M_WAIT a bit flag too. Let's solve the problem where it really lies by simply making M_WAIT a bit flag. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 13:22:22 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDC2037B401 for ; Wed, 22 Jan 2003 13:22:20 -0800 (PST) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B15543EB2 for ; Wed, 22 Jan 2003 13:22:20 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-8-62-147-157-185.dial.proxad.net [62.147.157.185]) by postfix4-2.free.fr (Postfix) with SMTP id 70F3CCC4E for ; Wed, 22 Jan 2003 22:22:18 +0100 (CET) Received: (qmail 8509 invoked by uid 1001); 22 Jan 2003 21:36:26 -0000 Date: Wed, 22 Jan 2003 22:36:26 +0100 From: Nicolas Souchu To: Doug Rabson Cc: "Pedro F. Giffuni" , Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030122223626.B8449@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1043236066.28124.6.camel@builder02.qubesoft.com>; from dfr@nlsystems.com on Wed, Jan 22, 2003 at 11:47:46AM +0000 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, Jan 22, 2003 at 11:47:46AM +0000, Doug Rabson wrote: > > 1) properly newbussify all the devices used by our > > console. > > 2) newbussify syscons (it doesn't use methods, does > > it?) and clean the PC specifics as much as possible. > > 3) port and newbussify wscons. > > 4) find a way to run the both at the same time. > > The main sticking point for this stuff is that console is needed before > the device tree is probed. The approach of KGI is to provide a very basic/minimal driver for console boot that can be overlaped later by fully probed graphic board drivers. This is somehow how VGA adapter is organized, with the video_switch used immediatly and later the vga_isa.c glue-code for newbus full attachement. Another way could be a memory virtual fb to allow rendering while booting before full graphic init. But I prefer the solution of the minimal driver with included text rendering if needed. > I think the right approach will be to define > a set of interfaces for the video console and then implement those > interfaces using the lower-level kobj system. This allows you to put > together a working console output system before the rest of the system > is up and running. What is called the kobj interface? Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@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 Jan 22 13:23:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B03AF37B401; Wed, 22 Jan 2003 13:23:48 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE99B43EB2; Wed, 22 Jan 2003 13:23:47 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0MLPVU77256; Wed, 22 Jan 2003 16:25:31 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 22 Jan 2003 16:25:31 -0500 From: Bosko Milekic To: Jeffrey Hsu Cc: arch@FreeBSD.org Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122162531.B77209@unixdaemons.com> References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0H94005IYWJT1Z@mta5.snfc21.pbi.net>; from hsu@FreeBSD.org on Wed, Jan 22, 2003 at 01:20:59PM -0800 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, Jan 22, 2003 at 01:20:59PM -0800, Jeffrey Hsu wrote: > I'm going to weigh in here on the side of the all the seasoned BSD veterans > that we should preserve the M_WAIT flag. I like saying M_WAIT when I mean > M_WAIT. I dislike saying 0 when I mean M_WAIT. > > The fundamental problem here is that M_WAIT looks like a bit flag. That > problem should be directly solved by defining it to be a bit flag. There > are no ABI issues with this in FreeBSD 5.x. > > Warner's proposal to automatically detect programming error is also > a good idea. And, that relies on making M_WAIT a bit flag too. > > Let's solve the problem where it really lies by simply making M_WAIT > a bit flag. > > Jeffrey Not one of you has said why you think that the wait behavior should not be the default behavior and why the dontwait behavior shouldn't be treated like an exception. -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 22 13:43:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CACA437B401 for ; Wed, 22 Jan 2003 13:43:23 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B36A43ED8 for ; Wed, 22 Jan 2003 13:43:23 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h0MLhHro018192 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 22 Jan 2003 16:43:17 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h0MLhCv90749; Wed, 22 Jan 2003 16:43:12 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15919.4208.394911.712558@grasshopper.cs.duke.edu> Date: Wed, 22 Jan 2003 16:43:12 -0500 (EST) To: arch@FreeBSD.ORG Subject: Re: M_ flags summary. In-Reply-To: <20030122155457.A77036@unixdaemons.com> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Speaking as the token 3rd party driver vendor, the removal of M_WAITOK/M_TRYWAIT is irritating, but not something that can't be solved with yet another ifdef in my driver. Breaking the 5.0 ABI prior to 5.1 is no big deal to me, as I don't plan to support 5.0-RELEASE anyway, so I don't care what the #defines end up as in the 5.0-STABLE branch. My thoughts are that whether we pronounce it po-ta-to, or po-tat-o, its still a potato and how its pronounced doesn't matter nearly as much as how it tastes. The taste "problem" here is that it always used to be safe to sleep in a process context. That's not true anymore. Now its safe to sleep in a process context if you're not holding any mutexes. So there are pleny of sleepable allocation bugs lurking. If we want to catch sleepable allocation bugs right up front, I suggest we put this: if (!(flags & M_NOWAIT)) { WITNESS_SLEEP(1, NULL); } at the top of malloc, and at the top of all entry points to the mbuf allocator. Eg, before the system has a chance to pull the allocation off of some cache which will succeed 99.5% of the time, except when the system is under memory pressure. Sorry for dragging this in another direction.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 13:44:43 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D755D37B401 for ; Wed, 22 Jan 2003 13:44:41 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72CDA43F13 for ; Wed, 22 Jan 2003 13:44:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0MLif0i009830; Wed, 22 Jan 2003 13:44:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0MLifiC009829; Wed, 22 Jan 2003 13:44:41 -0800 (PST) Date: Wed, 22 Jan 2003 13:44:41 -0800 (PST) From: Matthew Dillon Message-Id: <200301222144.h0MLifiC009829@apollo.backplane.com> To: Garrett Wollman Cc: peter@wemm.org, arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> 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 You guys are talking apples and oranges here. shm_open() is a libc call, not a system call. getmemfd() or equivalent is a system call and performs a function that no other system call can duplicate. Until we fix our VFS layering system to provide a call vector for file descriptors, the descriptors returned by the two APIs are not going to be compatible. e.g. you can call ftruncate() on an shm_open() descriptor (because it is essentially just a file descriptor), but you cannot call ftruncate() on a getmemfd() descriptor. The primary problem with using shm_open() in its current implementation is the fact that the anonymous memory associated with the descriptor is file-backed when what we really want is swap-backed anonymous memory. file-backed memory has serious repercussions that swap backed memory does not. The two most serious repercussions are (A) it will eat space in the filesystem and (B) if you do not pre-zero the space, any pageout activity will (due to its randomness) create an extremely inefficient, highly fragmented file. Additionally, the most important madvise() function, MADV_FREE, does not work on file-backed memory. -Matt Matthew Dillon :-----BEGIN PGP SIGNED MESSAGE----- :Hash: SHA1 : :In article <20030122041546.393AF2A8A5@canning.wemm.org> you write: : :>I'd rather do that than add another arg to the memfd syscall. Otherwise :>we're heading into shm_open() look and feel territory. Hmm. I wonder if :>the POSIX folks would object to us calling the syscall shm_openfd() ? : :Can you please explain just what precisely your problem is with :shm_open()? If we're going to reinvent the wheel, please, let's skip :the square and hexagonal stages. : :- -GAWollman : :-----BEGIN PGP SIGNATURE----- :Version: GnuPG v1.0.7 (FreeBSD) : :iD8DBQE+LwSHI+eG6b7tlG4RAj56AKCFhYoHdkXhvIX1sGPX9PgXB2dttwCgiR75 :53DaDGocAf2aI5F7xR09398= :=sswO :-----END PGP SIGNATURE----- : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 13:51:15 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF21037B405 for ; Wed, 22 Jan 2003 13:51:12 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB4843F7B for ; Wed, 22 Jan 2003 13:51:08 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0MLp7MW030320; Wed, 22 Jan 2003 13:51:07 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0MLpHEx007985; Wed, 22 Jan 2003 13:51:17 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0MLpGcq007984; Wed, 22 Jan 2003 13:51:16 -0800 (PST) Date: Wed, 22 Jan 2003 13:51:16 -0800 From: Marcel Moolenaar To: Doug Rabson Cc: "Pedro F. Giffuni" , arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030122215115.GC590@dhcp01.pn.xcllnt.net> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1043236066.28124.6.camel@builder02.qubesoft.com> User-Agent: Mutt/1.5.3i 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, Jan 22, 2003 at 11:47:46AM +0000, Doug Rabson wrote: > > The main sticking point for this stuff is that console is needed before > the device tree is probed. I think the right approach will be to define > a set of interfaces for the video console and then implement those > interfaces using the lower-level kobj system. This allows you to put > together a working console output system before the rest of the system > is up and running. This is what's been building in my head so far. It's graph-like and probably too early for public exposure, but what the hee. Related frameworks probably include netgraph and geom: 4 interfaces: top Your regular file I/O. It's the highest level interface known by the console framework. bottom A pseudo interface that denotes the lack of interface. Probably just a formality, but may have its use when implemented... con_out A procedural interface typically used by output devices. con_in A procedural interface typically used by input devices. A typical serial console is implemented by a sio node that has top and bottom interfaces. The top interface is directly "attached" to the UART. Consequently, you cannot attach a terminal emulator to it. A non-typical sio node may do so. Whether you want to have sio included like this is irrelevent. A VGA display driver is implemented by a vga node that implements the bottom and con_out interfaces. The con_out interface is directly tied to the VGA hardware. Non-VGA display drivers do the same. A keyboard driver implements bottom and con_in. An input terminal emulator (TE) implements con_in and top and an output TE implements con_out and top. A null-TE hooks up top with con_in or con_out without doing any emulation. Note that I split TEs in output and input here, but that's mostly from an interfacing point of view. You cannot split TEs, because state is shared between input and output. Hence, you can attach a vga node to a output TE and a keyboard to an input TE and have the basics of a console with terminal emulation. Other building blocks are multiplexers with which you can implement virtual consoles and demultiplexers with which you can allow multiple keyboards for the same terminal or multiple identical displays (not really the same as multi-head). These typically implement multiple con_in or multiple con_out interfaces. This asks for a top and bottom side of a node or an input/output side (consumer/producer). We'll see... Note that text-only VGA drivers themselves have the ability to multiplex by switching the display page. So, one could implement virtual consoles with the VGA driver only. Need to keep this in mind... One could envision top-top nodes, such as encoding translators or file multiplexers/demultiplexers, but they don't really add any value that's not already here (flexibility). The prime responsibility of the console driver is to hook up these interfaces in a meaningful fashion. Lot's can be hooked up dynamicly, but you need some directives. Probably compile-time defaults. I see it working roughly like: o Low-level console hooks up to the con_out and con_in interfaces of predetermined drivers. Maybe use a different interface for this (which is basicly a subset of con_in and con_out). o Console framework initialization, which involves getting all the TEs (either compiled-in or loaded as a module). o Bus enumeration causes low-level nodes to be added such as display and keyboard. Modules add to the dynamic nature or this process. o Everything gets hooked up. This is currently a magical process as it's not fleshed out. o sysctl or ioctl or whatever can be used to change the "graph" by swapping TEs or adding/removing an additional keyboard. Again, mostly magic... Anyway, you get the picture: building blocks. Objects if you like the OO paradigm. -- 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 Wed Jan 22 13:52:53 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC98337B401; Wed, 22 Jan 2003 13:52:51 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8095243F13; Wed, 22 Jan 2003 13:52:51 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 60759AE211; Wed, 22 Jan 2003 13:52:51 -0800 (PST) Date: Wed, 22 Jan 2003 13:52:51 -0800 From: Alfred Perlstein To: Bosko Milekic Cc: Jeffrey Hsu , arch@FreeBSD.org Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030122215251.GU42333@elvis.mu.org> References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122162531.B77209@unixdaemons.com> User-Agent: Mutt/1.4i 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 * Bosko Milekic [030122 13:23] wrote: > > On Wed, Jan 22, 2003 at 01:20:59PM -0800, Jeffrey Hsu wrote: > > I'm going to weigh in here on the side of the all the seasoned BSD veterans > > that we should preserve the M_WAIT flag. I like saying M_WAIT when I mean > > M_WAIT. I dislike saying 0 when I mean M_WAIT. > > > > The fundamental problem here is that M_WAIT looks like a bit flag. That > > problem should be directly solved by defining it to be a bit flag. There > > are no ABI issues with this in FreeBSD 5.x. > > > > Warner's proposal to automatically detect programming error is also > > a good idea. And, that relies on making M_WAIT a bit flag too. > > > > Let's solve the problem where it really lies by simply making M_WAIT > > a bit flag. > > > > Jeffrey > > Not one of you has said why you think that the wait behavior should > not be the default behavior and why the dontwait behavior shouldn't be > treated like an exception. Well it's easier to argue when you just voice an opinion/preference without any technical reason. Btw, under Darwin, even free(9) can block you. :) So saying developing an implementation that depends on non-blocking malloc isn't all that good. :) -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 13:54:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD4CD37B401 for ; Wed, 22 Jan 2003 13:54:24 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7667C43F13 for ; Wed, 22 Jan 2003 13:54:24 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 58013AE2B7; Wed, 22 Jan 2003 13:54:24 -0800 (PST) Date: Wed, 22 Jan 2003 13:54:24 -0800 From: Alfred Perlstein To: Andrew Gallatin Cc: arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122215424.GV42333@elvis.mu.org> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> <15919.4208.394911.712558@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15919.4208.394911.712558@grasshopper.cs.duke.edu> User-Agent: Mutt/1.4i 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 * Andrew Gallatin [030122 13:43] wrote: > > The taste "problem" here is that it always used to be safe to sleep > in a process context. That's not true anymore. Now its safe to > sleep in a process context if you're not holding any mutexes. So > there are pleny of sleepable allocation bugs lurking. > > If we want to catch sleepable allocation bugs right up front, I > suggest we put this: > > if (!(flags & M_NOWAIT)) { > WITNESS_SLEEP(1, NULL); > } > > at the top of malloc, and at the top of all entry points to the mbuf > allocator. Eg, before the system has a chance to pull the allocation > off of some cache which will succeed 99.5% of the time, except when > the system is under memory pressure. > > Sorry for dragging this in another direction.. This is actually a very good idea. It's too bad that one needs witness to catch this though. Can you add it, or shall i do it tonight? -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 13:58: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6158A37B401 for ; Wed, 22 Jan 2003 13:58:06 -0800 (PST) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98DE943F5F for ; Wed, 22 Jan 2003 13:58:05 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 19365 invoked from network); 22 Jan 2003 21:58:12 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Jan 2003 21:58:12 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h0MLw2UT039040; Wed, 22 Jan 2003 16:58:03 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15919.4208.394911.712558@grasshopper.cs.duke.edu> Date: Wed, 22 Jan 2003 16:58:05 -0500 (EST) From: John Baldwin To: Andrew Gallatin Subject: Re: M_ flags summary. 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 22-Jan-2003 Andrew Gallatin wrote: > > > Speaking as the token 3rd party driver vendor, the removal of > M_WAITOK/M_TRYWAIT is irritating, but not something that can't be > solved with yet another ifdef in my driver. Breaking the 5.0 ABI > prior to 5.1 is no big deal to me, as I don't plan to support > 5.0-RELEASE anyway, so I don't care what the #defines end up as in the > 5.0-STABLE branch. > > My thoughts are that whether we pronounce it po-ta-to, or po-tat-o, > its still a potato and how its pronounced doesn't matter nearly as > much as how it tastes. > > The taste "problem" here is that it always used to be safe to sleep > in a process context. That's not true anymore. Now its safe to > sleep in a process context if you're not holding any mutexes. So > there are pleny of sleepable allocation bugs lurking. > > If we want to catch sleepable allocation bugs right up front, I > suggest we put this: > > if (!(flags & M_NOWAIT)) { > WITNESS_SLEEP(1, NULL); > } > > at the top of malloc, and at the top of all entry points to the mbuf > allocator. Eg, before the system has a chance to pull the allocation > off of some cache which will succeed 99.5% of the time, except when > the system is under memory pressure. We already do this for malloc(), that is the source of most of the 'could sleep' messages these days. I have some patches I need to commit to make the actual message more informative so that it will say 'could malloc' etc. -- 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 Wed Jan 22 14: 0:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 532D437B405 for ; Wed, 22 Jan 2003 14:00:24 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E09043F3F for ; Wed, 22 Jan 2003 14:00:22 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0MM0JMW030369; Wed, 22 Jan 2003 14:00:19 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0MM0TEx008032; Wed, 22 Jan 2003 14:00:29 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0MM0TVR008031; Wed, 22 Jan 2003 14:00:29 -0800 (PST) Date: Wed, 22 Jan 2003 14:00:29 -0800 From: Marcel Moolenaar To: Nicolas Souchu Cc: Doug Rabson , "Pedro F. Giffuni" , arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030122220029.GD590@dhcp01.pn.xcllnt.net> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122223626.B8449@armor.fastether> User-Agent: Mutt/1.5.3i 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, Jan 22, 2003 at 10:36:26PM +0100, Nicolas Souchu wrote: > > > > The main sticking point for this stuff is that console is needed before > > the device tree is probed. > > The approach of KGI is to provide a very basic/minimal driver for console boot > that can be overlaped later by fully probed graphic board drivers. This is > somehow how VGA adapter is organized, with the video_switch used immediatly > and later the vga_isa.c glue-code for newbus full attachement. This is what makes it non-portable and why we have problems getting it to work in non-PC, non-ISA environments. > But I prefer the solution of the minimal driver with included text rendering > if needed. Booting a notebook in text mode looks ugly and I can imagine that early boot environments can be graphical as well. I prefer not to fixate on text-only video modes for the low-level console, even though we probably won't use it for anything but text. -- 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 Wed Jan 22 14: 2: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C94737B401 for ; Wed, 22 Jan 2003 14:02:01 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E46C43ED8 for ; Wed, 22 Jan 2003 14:02:00 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id h0MM1tnN080949 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 22 Jan 2003 14:01:56 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <0cdc01c2c261$e1589390$52557f42@errno.com> From: "Sam Leffler" To: "Bosko Milekic" Cc: "M. Warner Losh" , , References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> Subject: Re: M_ flags summary. Date: Wed, 22 Jan 2003 14:01:55 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Hey, I've got one vote. If the consensus it to go a different route I'm fine with that. I'd much prefer to spend my effort on important things like getting the system performance back up to where it belongs. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14: 3:45 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E8BF37B401 for ; Wed, 22 Jan 2003 14:03:44 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD3343EB2 for ; Wed, 22 Jan 2003 14:03:43 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0MM3Y1e095136; Wed, 22 Jan 2003 15:03:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 22 Jan 2003 15:03:05 -0700 (MST) Message-Id: <20030122.150305.79160884.imp@bsdimp.com> To: bmilekic@unixdaemons.com Cc: sam@errno.com, bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. From: "M. Warner Losh" In-Reply-To: <20030122155457.A77036@unixdaemons.com> References: <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030122155457.A77036@unixdaemons.com> Bosko Milekic writes: : am not religiously bound to doing it either way. However, I do think : that leaving it as it is (with possibly defining M_WAIT{,OK} to 0 for : KLD_MODULES) is the better thing to do. Actually, we wouldn't do that because it is stupid (kld and base kernel having a different ABI). What we'd likely do instead is to warn if sometimes if the old ABI was used. : I realize that your idea of : the interface is "it'll either block or not block," however when you : think of the "new" approach don't think of it that way; rather, think : of it as follows: "I am calling the allocator and it will do as much : as it can to give me the resources I'm requesting (in the malloc() : case, in fact, I'm sure it'll give me the resources I want or else : block indefintely, in the mbuf allocator case it'll wait as long as : I've configured it to wait - via a sysctl). I don't care what the : allocator does. I am a thread executing in the kernel and let the : allocator do whatever it takes to give me what I need." I think of it as "I'm calling the allocator, and I know it is safe to block" or "I'm calling the allocator and I know it isn't safe to block." : If you think of it that way you'll hopefully realize that it's no : longer a question of whether or not to wait. Yes, we still provide a : dontwait behavior, but in the new approach, that behavior is an : _exception_, which is the way it should be. In your opinion. I differ that dontwait is the exceptional case, and that it will always be the exceptional case in the future. : As I said, your thoughts are important to me (and I'm sure to anyone : else involved in this discussion) but I have yet to read an argument : as to why the dontwait case _shouldn't_ be treated like the exception : that it is in SMPng. The arguement against it is that you *SHOULD* be thinking about is it OK to block here or not. I personally think the default should be to no wait and return NULL because we don't want kernel threads blocking by default. The more kernel threads block, the higher the latency you introduce into those subsystems. We should only have them block when they know that the latency for blocking is OK. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14: 7:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69EA437B401 for ; Wed, 22 Jan 2003 14:07:29 -0800 (PST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18A5943EB2 for ; Wed, 22 Jan 2003 14:07:29 -0800 (PST) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H9400CZ7YSGMM@mta6.snfc21.pbi.net> for arch@FreeBSD.org; Wed, 22 Jan 2003 14:07:29 -0800 (PST) Date: Wed, 22 Jan 2003 14:09:24 -0800 From: Jeffrey Hsu Subject: Re: Alfre's malloc changes: the next step In-reply-to: Message from Bosko Milekic "of Wed, 22 Jan 2003 16:25:31 EST." <20030122162531.B77209@unixdaemons.com> To: Bosko Milekic Cc: arch@FreeBSD.org Message-id: <0H9400CZ8YSGMM@mta6.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 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 > Not one of you has said why you think that the wait behavior should > not be the default behavior and why the dontwait behavior shouldn't be > treated like an exception. Maybe because it's not relevant to my technical argument that we should specify what an argument means when we pass it in rather than giving it some magic value like 0? Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:10: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8823D37B401 for ; Wed, 22 Jan 2003 14:10:04 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF0F143F13 for ; Wed, 22 Jan 2003 14:10:03 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0MMA1bs042905 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 17:10:01 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0MMA0gB042902; Wed, 22 Jan 2003 17:10:00 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 17:10:00 -0500 (EST) From: Garrett Wollman Message-Id: <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301222144.h0MLifiC009829@apollo.backplane.com> References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.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 < said: > You guys are talking apples and oranges here. shm_open() is a libc > call, not a system call. Erm, no. It's an *interface*. Whether its implementation in the C library is complete or merely a syscall stub is irrelevant. > be compatible. e.g. you can call ftruncate() on an shm_open() > descriptor (because it is essentially just a file descriptor), but you > cannot call ftruncate() on a getmemfd() descriptor. Why not? We already have a round wheel, I see no need for additional square ones. > The primary problem with using shm_open() in its current implementation > is the fact that the anonymous memory associated with the descriptor > is file-backed when what we really want is swap-backed anonymous memory. Only in the current implementation. Nothing in the definition of shm_open() requires it to access the filesystem at all, although since a shared memory object has many attributes -- such as naming and access-control semantics -- that the filesystem already models well, it is probably preferable to continue to use it to manage those attributes. A simple implementation would add an additional field to `struct file'; perhaps call it `f_ipcobject'. Then you have the following model of operations: - open() operates on the file itself, with no special semantics - shm_open() performs all of the operations of open(), but also looks up the abstract name of the file[1] and creates or attaches an IPC object to the descriptor and changes the type to DTYPE_SHM. - ftruncate() when performed on a DTYPE_SHM descriptor changes the size of the IPC object rather than the rendezvous file. - shm_unlink() performs all of the operations of unlink(), but also looks up the abstract name of the file and marks the related IPC object, if any exists, for removal. - fstat() gets the IPC object's size and sets the SHM bit in the status buffer after getting other attributes from the vnode layer. - all other file operations pass through to the usual vnode operations. -GAWollman [1] E.g., a vnode pointer value or an NFS-style file handle. If the former is used, the IPC object would obviously have to keep a reference to the vnode so that it couldn't be recycled. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:16:39 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5389937B401 for ; Wed, 22 Jan 2003 14:16:37 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEA2043F1E for ; Wed, 22 Jan 2003 14:16:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0MMGa0i010111; Wed, 22 Jan 2003 14:16:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0MMGZMD010110; Wed, 22 Jan 2003 14:16:35 -0800 (PST) Date: Wed, 22 Jan 2003 14:16:35 -0800 (PST) From: Matthew Dillon Message-Id: <200301222216.h0MMGZMD010110@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.com> <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> 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 Garrett, I fail to see what you are argument is here. Are you arguing for the addition of a system call or against? shm_open() is irrelevant to the discussion, it is a libc function which has no capability whatsoever of implementing the features we need for a shared-memory descriptor, which have already been outlined in prior emails. Even if we were to add a more complete function vector to the struct file, it still would not in any way implement the shared memory features we need on a standard file. What I was saying was that a struct file function vector would allow a special memory descriptor to become compatible with the shm_open() API. But you still need the new system call to get that special memory descriptor... adding a function vector does not in any way allow you to avoid adding the system call. Apples and Oranges. -Matt : :< said: : :> You guys are talking apples and oranges here. shm_open() is a libc :> call, not a system call. : :Erm, no. It's an *interface*. Whether its implementation in the C :library is complete or merely a syscall stub is irrelevant. : :> be compatible. e.g. you can call ftruncate() on an shm_open() :> descriptor (because it is essentially just a file descriptor), but you :> cannot call ftruncate() on a getmemfd() descriptor. : :Why not? We already have a round wheel, I see no need for additional :square ones. : :> The primary problem with using shm_open() in its current implementation :> is the fact that the anonymous memory associated with the descriptor :> is file-backed when what we really want is swap-backed anonymous memory. : :Only in the current implementation. Nothing in the definition of :shm_open() requires it to access the filesystem at all, although since :a shared memory object has many attributes -- such as naming and :access-control semantics -- that the filesystem already models well, it :is probably preferable to continue to use it to manage those :attributes. : :A simple implementation would add an additional field to `struct :file'; perhaps call it `f_ipcobject'. Then you have the following :model of operations: : :- open() operates on the file itself, with no special semantics : :- shm_open() performs all of the operations of open(), but also looks :up the abstract name of the file[1] and creates or attaches an IPC :object to the descriptor and changes the type to DTYPE_SHM. : :- ftruncate() when performed on a DTYPE_SHM descriptor changes the :size of the IPC object rather than the rendezvous file. : :- shm_unlink() performs all of the operations of unlink(), but also :looks up the abstract name of the file and marks the related IPC :object, if any exists, for removal. : :- fstat() gets the IPC object's size and sets the SHM bit in the :status buffer after getting other attributes from the vnode layer. : :- all other file operations pass through to the usual vnode :operations. : :-GAWollman : :[1] E.g., a vnode pointer value or an NFS-style file handle. If the :former is used, the IPC object would obviously have to keep a :reference to the vnode so that it couldn't be recycled. : Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:19: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 153AD37B401 for ; Wed, 22 Jan 2003 14:19:00 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09C9E43E4A for ; Wed, 22 Jan 2003 14:18:59 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0MMIvbs042984 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 17:18:57 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0MMIvcF042981; Wed, 22 Jan 2003 17:18:57 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 17:18:57 -0500 (EST) From: Garrett Wollman Message-Id: <200301222218.h0MMIvcF042981@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301222216.h0MMGZMD010110@apollo.backplane.com> References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.com> <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> <200301222216.h0MMGZMD010110@apollo.backplane.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 < said: > Garrett, I fail to see what you are argument is here. Are you arguing > for the addition of a system call or against? shm_open() is irrelevant > to the discussion No, it is not irrelevant. It is an existing, standardized interface that will support precisely the behavior that people seem to be asking for. There is no need to invent another, proprietary interface; we have too many of those already. >, it is a libc function which has no capability whatsoever Bullshit. Go back and read what I wrote. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:21:58 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E48137B407 for ; Wed, 22 Jan 2003 14:21:57 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B8ED43F6B for ; Wed, 22 Jan 2003 14:21:56 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0MMLu0i014260; Wed, 22 Jan 2003 14:21:56 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0MMLubI014259; Wed, 22 Jan 2003 14:21:56 -0800 (PST) Date: Wed, 22 Jan 2003 14:21:56 -0800 (PST) From: Matthew Dillon Message-Id: <200301222221.h0MMLubI014259@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.com> <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> <200301222216.h0MMGZMD010110@apollo.backplane.com> <200301222218.h0MMIvcF042981@khavrinen.lcs.mit.edu> 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 :>, it is a libc function which has no capability whatsoever : :Bullshit. Go back and read what I wrote. : :-GAWollman Sigh. Look Garrett, I just don't understand what your argument is. shm_open() has NO CAPABILITY to do what we want, because there is no underlying system interface that does what we want. That is why the new system call is required. If you believe otherwise, then explain, exactly, how shm_open() can be adapted to give us what we want-- a mmap()able file descriptor that provides swap-backed shared memory. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:34:52 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B16337B401 for ; Wed, 22 Jan 2003 14:34:52 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54C7743F18 for ; Wed, 22 Jan 2003 14:34:51 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0MMYnbs043079 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 17:34:49 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0MMYnvD043076; Wed, 22 Jan 2003 17:34:49 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 17:34:49 -0500 (EST) From: Garrett Wollman Message-Id: <200301222234.h0MMYnvD043076@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301222221.h0MMLubI014259@apollo.backplane.com> References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.com> <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> <200301222216.h0MMGZMD010110@apollo.backplane.com> <200301222218.h0MMIvcF042981@khavrinen.lcs.mit.edu> <200301222221.h0MMLubI014259@apollo.backplane.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 < said: > If you believe otherwise, then explain, exactly, how shm_open() can be > adapted to give us what we want-- a mmap()able file descriptor that > provides swap-backed shared memory. I did just that in my previous message which you apparently still have not comprehended. I did not feel the need to describe the mmap() part since you have evidently already done that work. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:38: 5 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D64E37B401 for ; Wed, 22 Jan 2003 14:38:04 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CBDB43F18 for ; Wed, 22 Jan 2003 14:38:03 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0MMbvj25082; Wed, 22 Jan 2003 17:37:58 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 22 Jan 2003 17:37:57 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Garrett Wollman , , Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301222144.h0MLifiC009829@apollo.backplane.com> Message-ID: <20030122173229.D46974-100000@mail.chesapeake.net> 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, 22 Jan 2003, Matthew Dillon wrote: > You guys are talking apples and oranges here. shm_open() is a libc > call, not a system call. getmemfd() or equivalent is a system call > and performs a function that no other system call can duplicate. Until > we fix our VFS layering system to provide a call vector for file > descriptors, the descriptors returned by the two APIs are not going to > be compatible. e.g. you can call ftruncate() on an shm_open() > descriptor (because it is essentially just a file descriptor), but you > cannot call ftruncate() on a getmemfd() descriptor. I think the argument is for fixing the implementation of shm_open() such that it supports this feature and move it into kernel space. Such that if you use a key preceded by a '/' it will use the filesystem as the namespace and otherwise it will be local and swap backed. Is there something wrong with this approach? > > The primary problem with using shm_open() in its current implementation > is the fact that the anonymous memory associated with the descriptor > is file-backed when what we really want is swap-backed anonymous memory. > file-backed memory has serious repercussions that swap backed memory does > not. The two most serious repercussions are (A) it will eat space in > the filesystem and (B) if you do not pre-zero the space, any pageout > activity will (due to its randomness) create an extremely inefficient, > highly fragmented file. Additionally, the most important madvise() > function, MADV_FREE, does not work on file-backed memory. > A doesn't sound so serious to me, but ok. I think I have an idea of why B happens but can you be more specific? Why does MADV_FREE not work with file backed memory? I'm not arguing against the ability to mmap an object that lives in swap. I'd just like to see if there are improvements that we could make to the vm to handle the mmap file case. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:41:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3731E37B401 for ; Wed, 22 Jan 2003 14:41:25 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81B4843ED8 for ; Wed, 22 Jan 2003 14:41:24 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0MMfO0i016630; Wed, 22 Jan 2003 14:41:24 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0MMfOhv016629; Wed, 22 Jan 2003 14:41:24 -0800 (PST) Date: Wed, 22 Jan 2003 14:41:24 -0800 (PST) From: Matthew Dillon Message-Id: <200301222241.h0MMfOhv016629@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <200301220304.h0M34TMB099694@apollo.backplane.com> <200301222052.h0MKqP4N041427@khavrinen.lcs.mit.edu> <200301222144.h0MLifiC009829@apollo.backplane.com> <200301222210.h0MMA0gB042902@khavrinen.lcs.mit.edu> <200301222216.h0MMGZMD010110@apollo.backplane.com> <200301222218.h0MMIvcF042981@khavrinen.lcs.mit.edu> <200301222221.h0MMLubI014259@apollo.backplane.com> <200301222234.h0MMYnvD043076@khavrinen.lcs.mit.edu> 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: : :> If you believe otherwise, then explain, exactly, how shm_open() can be :> adapted to give us what we want-- a mmap()able file descriptor that :> provides swap-backed shared memory. : :I did just that in my previous message which you apparently still have :not comprehended. I did not feel the need to describe the mmap() part :since you have evidently already done that work. : :-GAWollman Garrett, you haven't explained anything. Try again. Stop refering to previous messages which you have not explained anything in. I am being very specific here, please be very specific in response. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:43:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AFE637B401 for ; Wed, 22 Jan 2003 14:43:25 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 452A043F1E for ; Wed, 22 Jan 2003 14:43:24 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0MMhJ6Z031535; Wed, 22 Jan 2003 23:43:20 +0100 (CET) (envelope-from phk@freebsd.org) To: Matthew Dillon Cc: Garrett Wollman , arch@freebsd.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) From: phk@freebsd.org In-Reply-To: Your message of "Wed, 22 Jan 2003 14:41:24 PST." <200301222241.h0MMfOhv016629@apollo.backplane.com> Date: Wed, 22 Jan 2003 23:43:19 +0100 Message-ID: <31534.1043275399@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 Could you please take this private, and post a summary when you have reached concensus ? Then the rest of us can judge your proposal before anybody spends time creating a patch. Thankyou -- 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 Jan 22 14:49:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C73937B401 for ; Wed, 22 Jan 2003 14:49:12 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEF4B43F18 for ; Wed, 22 Jan 2003 14:49:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0MMn90i016698; Wed, 22 Jan 2003 14:49:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0MMn9e5016697; Wed, 22 Jan 2003 14:49:09 -0800 (PST) Date: Wed, 22 Jan 2003 14:49:09 -0800 (PST) From: Matthew Dillon Message-Id: <200301222249.h0MMn9e5016697@apollo.backplane.com> To: Jeff Roberson Cc: Garrett Wollman , , Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030122173229.D46974-100000@mail.chesapeake.net> 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 think the argument is for fixing the implementation of shm_open() such :that it supports this feature and move it into kernel space. Such that if :you use a key preceded by a '/' it will use the filesystem as the :namespace and otherwise it will be local and swap backed. Is there :something wrong with this approach? Moving shm_open() to kernel space? That's a pretty tall order. I don't think anyone has proposed that until now. shm_open() in its full glory must manage both namespace private and namespace-filespace operations. I would argue that namespace private operations are far better handled in userspace then kernelspace (why waste kernel memory managing private namespaces?). I would say that we would almost certainly want to keep shm_open() in userspace and add a system call (aka getmemfd()) that can eventually be used to support shm_open() behind the scenes. Additionally, namespace-filespace operations are far better handled with an fattach()-like system call, and give us a far more general feature-set then we would get implementing shm_open() in kernel space. To do that requires a two-stage process of which my current proposed patch is only stage-1, since we have no current ability to call ftruncate() on a descriptor, only a vnode. In stage-2 we could revamp the struct file function vector support to support high-level syscalls like ftruncate() at a high level, leaving the VFS vector intact to support those same system calls at a lower level. But that's a lot of work and not really relevant to the discussion vis-a-vie adding a new system call (because the work would not impact the new syscall's prototype, it would simply add new capabilities to the returned descriptor). I'm not against idea, but I think it would be rather silly to try to implement the whole mess all at once. :A doesn't sound so serious to me, but ok. I think I have an idea of why B :happens but can you be more specific? Why does MADV_FREE not work with :file backed memory? : :I'm not arguing against the ability to mmap an object that lives in swap. :I'd just like to see if there are improvements that we could make to the :vm to handle the mmap file case. : :Cheers, :Jeff MADV_FREE does not work on vnode-backed VM objects. It never has. It could probably be made to work ala-solaris (revert to original contents of file) but this still leaves us with the swap-backing problem. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 14:50:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5DCD37B401 for ; Wed, 22 Jan 2003 14:50:23 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id E788243F13 for ; Wed, 22 Jan 2003 14:50:22 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0MMpwt77439; Wed, 22 Jan 2003 17:51:58 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 22 Jan 2003 17:51:58 -0500 From: Bosko Milekic To: "M. Warner Losh" Cc: sam@errno.com, bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122175158.A77397@unixdaemons.com> References: <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> <20030122.150305.79160884.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030122.150305.79160884.imp@bsdimp.com>; from imp@bsdimp.com on Wed, Jan 22, 2003 at 03:03:05PM -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 On Wed, Jan 22, 2003 at 03:03:05PM -0700, M. Warner Losh wrote: > In message: <20030122155457.A77036@unixdaemons.com> > Bosko Milekic writes: > : am not religiously bound to doing it either way. However, I do think > : that leaving it as it is (with possibly defining M_WAIT{,OK} to 0 for > : KLD_MODULES) is the better thing to do. > > Actually, we wouldn't do that because it is stupid (kld and base > kernel having a different ABI). What we'd likely do instead is to > warn if sometimes if the old ABI was used. What the heck are you talking about? It wouldn't change the ABI, the ABI hasn't been changed. > : I realize that your idea of > : the interface is "it'll either block or not block," however when you > : think of the "new" approach don't think of it that way; rather, think > : of it as follows: "I am calling the allocator and it will do as much > : as it can to give me the resources I'm requesting (in the malloc() > : case, in fact, I'm sure it'll give me the resources I want or else > : block indefintely, in the mbuf allocator case it'll wait as long as > : I've configured it to wait - via a sysctl). I don't care what the > : allocator does. I am a thread executing in the kernel and let the > : allocator do whatever it takes to give me what I need." > > I think of it as "I'm calling the allocator, and I know it is safe to > block" or "I'm calling the allocator and I know it isn't safe to > block." It should always be safe to block unless you're in an ISR or unless you have code that is pretty whacked and that absolutely needs to hold on to a lock across an allocation. I'd prefer if we didn't encourage the latter, every time that you can wait (e.g. you're not in an ISR) and you don't take advantage of it, you lose. > : If you think of it that way you'll hopefully realize that it's no > : longer a question of whether or not to wait. Yes, we still provide a > : dontwait behavior, but in the new approach, that behavior is an > : _exception_, which is the way it should be. > > In your opinion. I differ that dontwait is the exceptional case, and > that it will always be the exceptional case in the future. Because you're thinking of bad design. > : As I said, your thoughts are important to me (and I'm sure to anyone > : else involved in this discussion) but I have yet to read an argument > : as to why the dontwait case _shouldn't_ be treated like the exception > : that it is in SMPng. > > The arguement against it is that you *SHOULD* be thinking about is it > OK to block here or not. I personally think the default should be to > no wait and return NULL because we don't want kernel threads blocking > by default. The more kernel threads block, the higher the latency you > introduce into those subsystems. We should only have them block when > they know that the latency for blocking is OK. What on earth are you talking about? "The more kernel threads block the higher latency you introduce?" That's totally non-sensical; how about you make EVERYTHING non-blocking then and let's just ditch blocking for resources altogether because it "increases latency?!" You're NOT increasing latency when you're blocking when you have nothing available. I really wish you considered what you're saying before you say it. I'm pretty sure that even the people who agree with what you want to do don't agree with some of the stuff you bring up here. > Warner Finally, I'm sick of arguing this. Just do whatever pleases you. -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 22 14:54:22 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F9BC37B401 for ; Wed, 22 Jan 2003 14:54:21 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52BAB43F1E for ; Wed, 22 Jan 2003 14:54:20 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0MMu0g77489; Wed, 22 Jan 2003 17:56:00 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 22 Jan 2003 17:56:00 -0500 From: Bosko Milekic To: Alfred Perlstein Cc: Andrew Gallatin , arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122175600.A77460@unixdaemons.com> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> <15919.4208.394911.712558@grasshopper.cs.duke.edu> <20030122215424.GV42333@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030122215424.GV42333@elvis.mu.org>; from bright@mu.org on Wed, Jan 22, 2003 at 01:54:24PM -0800 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, Jan 22, 2003 at 01:54:24PM -0800, Alfred Perlstein wrote: > * Andrew Gallatin [030122 13:43] wrote: > > > > The taste "problem" here is that it always used to be safe to sleep > > in a process context. That's not true anymore. Now its safe to > > sleep in a process context if you're not holding any mutexes. So > > there are pleny of sleepable allocation bugs lurking. > > > > If we want to catch sleepable allocation bugs right up front, I > > suggest we put this: > > > > if (!(flags & M_NOWAIT)) { > > WITNESS_SLEEP(1, NULL); > > } > > > > at the top of malloc, and at the top of all entry points to the mbuf > > allocator. Eg, before the system has a chance to pull the allocation > > off of some cache which will succeed 99.5% of the time, except when > > the system is under memory pressure. > > > > Sorry for dragging this in another direction.. > > This is actually a very good idea. It's too bad that one needs witness > to catch this though. Can you add it, or shall i do it tonight? It would be great if you did this for the mbuf code (the malloc() code apparently, as John points out, already does it). If anything, I think this is the one valuable thing we got out of this discussion. > -- > -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.' -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@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 Jan 22 15: 1:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF70D37B401 for ; Wed, 22 Jan 2003 15:01:57 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3323A43EB2 for ; Wed, 22 Jan 2003 15:01:57 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0MN1obs043397 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 18:01:50 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0MN1nHg043396; Wed, 22 Jan 2003 18:01:49 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 18:01:49 -0500 (EST) From: Garrett Wollman Message-Id: <200301222301.h0MN1nHg043396@khavrinen.lcs.mit.edu> To: jroberson@chesapeake.net Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <20030122173229.D46974-100000@mail.chesapeake.net> References: <200301222144.h0MLifiC009829@apollo.backplane.com> Organization: MIT Laboratory for Computer Science 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <20030122173229.D46974-100000@mail.chesapeake.net> you write: >I think the argument is for fixing the implementation of shm_open() such >that it supports this feature and move it into kernel space. Such that if >you use a key preceded by a '/' it will use the filesystem as the >namespace and otherwise it will be local and swap backed. There is no reason to have more than one namespace. Indeed, doing so would only complicate matters. Just interpret the path name like a path name. As I mentioned before, you need to have reasonable access-control and naming semantics, and using the filesystem for that purpose is both natural and avoids unnecessary duplication. Want a unique name? We've got a whole pile of library functions which can do that. (If you do not need a name, then you don't need a shared-memory object, you need anonymous shared memory, which is already implemented.) The object in the filesystem is only a rendezvous point for the shared memory object; it is not the object itself. The only requirement on the part of the Standard is that two calls to shm_open("/foo", ...) must refer to the same shared memory object, provided of course that a call to shm_unlink("/foo") has not intervened. There is no, repeat NO requirement that the object have any sort of backing store, much less use the file system for that purpose. The current implementation of shm_open() does that, because it was easy to implement that way. A better implementation would probably not do so. What I am arguing against is the creation of yet another FreeBSD-only interface when the needs of applications can be met by a better implementation of a standard interface that we already have. - -GAWollman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+LyLcI+eG6b7tlG4RAkzwAKCM9YO9LKfSmwGxH5NIEyG77xgEiQCgpOmU Xf+Zt9yNwKUgGfA3BfTwFmg= =Keks -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 15: 6:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D11E37B401 for ; Wed, 22 Jan 2003 15:06:57 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37E6743ED8 for ; Wed, 22 Jan 2003 15:06:56 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0MN6n1e095680; Wed, 22 Jan 2003 16:06:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 22 Jan 2003 16:06:20 -0700 (MST) Message-Id: <20030122.160620.127772741.imp@bsdimp.com> To: bmilekic@unixdaemons.com Cc: sam@errno.com, bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. From: "M. Warner Losh" In-Reply-To: <20030122175158.A77397@unixdaemons.com> References: <20030122155457.A77036@unixdaemons.com> <20030122.150305.79160884.imp@bsdimp.com> <20030122175158.A77397@unixdaemons.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030122175158.A77397@unixdaemons.com> Bosko Milekic writes: : What on earth are you talking about? "The more kernel threads block : the higher latency you introduce?" That's totally non-sensical; how : about you make EVERYTHING non-blocking then and let's just ditch : blocking for resources altogether because it "increases latency?!" : You're NOT increasing latency when you're blocking when you have : nothing available. I made my point badly, and given your understanding of it, I can understand why you think I'm nuts. I was speaking with language that wasn't tight enough. Thread that can block will have a larger variance in latency than thread that don't block. Even though I made that point badly, the variance is likely a parameter that isn't of high enough importance to have it imfluance the API/ABI. I'm sorry if you find arguing with me frustrating. To be honest, I'm starting to agree with your point of view on this in many instances. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 15:23:13 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1998837B405 for ; Wed, 22 Jan 2003 15:23:11 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E3943F43 for ; Wed, 22 Jan 2003 15:23:09 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0MNN7bs043535 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 18:23:08 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0MNN7co043532; Wed, 22 Jan 2003 18:23:07 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 18:23:07 -0500 (EST) From: Garrett Wollman Message-Id: <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301222249.h0MMn9e5016697@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.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 < said: > Moving shm_open() to kernel space? That's a pretty tall order. I > don't think anyone has proposed that until now. It was always my expectation that this would happen at some point. > shm_open() in its full glory must manage both namespace private > and namespace-filespace operations. Huh? This doesn't make any sense. > I would argue that namespace private operations are far better handled > in userspace then kernelspace (why waste kernel memory managing > private namespaces?). Private namespaces are bad and unnecessary. We already have anonymous shared memory; I don't see any need for ``semi-anonymous'' shared memory. The garbage-collection problem is already bad enough. > I would say that we would almost certainly want > to keep shm_open() in userspace and add a system call (aka getmemfd()) > that can eventually be used to support shm_open() behind the scenes. You haven't provided any justification that I've seen for introducing a new interface when the one we've got can already do that. > Additionally, namespace-filespace operations are far better handled with Undefined external reference. I've never heard the term ``namespace-filespace'' before and do not understand the distinction you are trying to make. > To do that requires a two-stage process of which my current proposed > patch is only stage-1, since we have no current ability to call > ftruncate() on a descriptor, only a vnode. Trivial under my proposal... here's the conceptual patch: Index: vfs_syscalls.c =================================================================== RCS file: /home/cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.297 diff -u -r1.297 vfs_syscalls.c --- vfs_syscalls.c 27 Oct 2002 23:23:51 -0000 1.297 +++ vfs_syscalls.c 22 Jan 2003 23:19:31 -0000 @@ -2598,6 +2598,16 @@ fdrop(fp, td); return (EINVAL); } + if (fp->f_type == DTYPE_SHM) { + /* + * Don't touch the rendezvous file when changing the size + * on an SHM descriptor. There may be a need for a MAC + * check here or in shm_setsize(). + */ + error = shm_setsize(fp->f_ipcobj, uap->length); + goto out; + } + vp = (struct vnode *)fp->f_data; if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0) { fdrop(fp, td); @@ -2619,6 +2629,7 @@ } VOP_UNLOCK(vp, 0, td); vn_finished_write(mp); +out: fdrop(fp, td); return (error); } @@ -3414,7 +3425,9 @@ if ((u_int)fd >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[fd]) == NULL) error = EBADF; - else if (fp->f_type != DTYPE_VNODE && fp->f_type != DTYPE_FIFO) { + else if (fp->f_type != DTYPE_VNODE && + fp->f_type != DTYPE_FIFO && + fp->f_type != DTYPE_SHM) { fp = NULL; error = EINVAL; } else { This is one way to do it, assuming that we want the vnode layer to be completely oblivious to the shared-memory implementation (which I think is your intent and an approach I agree with). -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 15:55:11 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8411437B401; Wed, 22 Jan 2003 15:55:09 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 052F143E4A; Wed, 22 Jan 2003 15:55:09 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0182.cvx40-bradley.dialup.earthlink.net ([216.244.42.182] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18bUi0-0000gf-00; Wed, 22 Jan 2003 15:55:05 -0800 Message-ID: <3E2F2EFF.657921AD@mindspring.com> Date: Wed, 22 Jan 2003 15:53:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: Jeffrey Hsu , arch@FreeBSD.org Subject: Re: Alfre's malloc changes: the next step References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c8b98826c3311020065f1a66fef0ddc1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Bosko Milekic wrote: > On Wed, Jan 22, 2003 at 01:20:59PM -0800, Jeffrey Hsu wrote: > > I'm going to weigh in here on the side of the all the seasoned BSD veterans > > that we should preserve the M_WAIT flag. I like saying M_WAIT when I mean > > M_WAIT. I dislike saying 0 when I mean M_WAIT. [ ... ] > > Not one of you has said why you think that the wait behavior should > not be the default behavior and why the dontwait behavior shouldn't be > treated like an exception. I will: The need for the wait behaviour at all is an artifact of improper layering of state in legacy code. All code should be able to tolerate an allocation failure, and then back out the pending transaction if it happens. The "wait" behaviour exists only because some code has a hard time doing this, because it spreads it resource allocation (and concommitant locking of those resources) across different layers of functional abstraction. The "wait" therefore exists because Bad Old Code(tm) exists. It's a hell of a lot better, from a load-shedding and failure recovery perspective, if *all* code tolerated low resource conditions equally well, instead of some code tolerating it, and some code going to sleep, and telling the rest of the system "I'm not going to participate in voluntary resource release protocols, I'm going to sleep; wake me up when the crisis is over, thanks.". The problem comes down to people wanting to make the minimal hacks necessary to make things work, instead of doing things the right way, because the right way is the slower way. Toward that end, *I* suggest that M_WAIT *go away*, and that the code that needs it be rewritten, instead of haggling over this crap any more. The mbuf code was *already* rewritten this way, and FreeBSD is the better for it. What this comes down to is that people should quit rearranging the deck chairs on the Titanic, and *WHO CARES* about making warty code less error prone, when you can delete it, warts and all? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 15:55:28 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2430737B401; Wed, 22 Jan 2003 15:55:27 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 290CA43ED8; Wed, 22 Jan 2003 15:55:26 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h0MNtPro026938 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Jan 2003 18:55:25 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h0MNtKi90857; Wed, 22 Jan 2003 18:55:20 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15919.12136.371483.838009@grasshopper.cs.duke.edu> Date: Wed, 22 Jan 2003 18:55:20 -0500 (EST) To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: M_ flags summary. In-Reply-To: References: <15919.4208.394911.712558@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 John Baldwin writes: > > On 22-Jan-2003 Andrew Gallatin wrote: > > > > > > If we want to catch sleepable allocation bugs right up front, I > > suggest we put this: > > > > if (!(flags & M_NOWAIT)) { > > WITNESS_SLEEP(1, NULL); > > } > > > > at the top of malloc, and at the top of all entry points to the mbuf > > allocator. Eg, before the system has a chance to pull the allocation > > off of some cache which will succeed 99.5% of the time, except when > > the system is under memory pressure. > > We already do this for malloc(), that is the source of most of the > 'could sleep' messages these days. I have some patches I need to > commit to make the actual message more informative so that it will > say 'could malloc' etc. Actually, I think we do it only for small mallocs where we go through uma_zalloc{_arg}(). The case where size > KMEM_ZMAX does not (immediately) go through uma_zalloc(), so I was was worried things could sneek by. I'd feel more comfortable if the check happened in malloc() itself, so that both large and small cases got equal coverage. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 15:57:17 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 320F237B401 for ; Wed, 22 Jan 2003 15:57:16 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 785FF43F18 for ; Wed, 22 Jan 2003 15:57:15 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h0MNvEro027043 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Jan 2003 18:57:14 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h0MNv9C90860; Wed, 22 Jan 2003 18:57:09 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15919.12245.624926.495707@grasshopper.cs.duke.edu> Date: Wed, 22 Jan 2003 18:57:09 -0500 (EST) To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: M_ flags summary. In-Reply-To: <20030122215424.GV42333@elvis.mu.org> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> <15919.4208.394911.712558@grasshopper.cs.duke.edu> <20030122215424.GV42333@elvis.mu.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 writes: > > > > Sorry for dragging this in another direction.. > > This is actually a very good idea. It's too bad that one needs witness > to catch this though. Can you add it, or shall i do it tonight? Please go ahead and do it. Especially since Bosko approves. I'm bogged down in many other things ATM. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 18:22: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5939637B401 for ; Wed, 22 Jan 2003 18:21:59 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ADE943F5B for ; Wed, 22 Jan 2003 18:21:59 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id E5F5B2A7EA; Wed, 22 Jan 2003 18:21:58 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garrett Wollman Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> Date: Wed, 22 Jan 2003 18:21:58 -0800 From: Peter Wemm Message-Id: <20030123022158.E5F5B2A7EA@canning.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 Garrett Wollman wrote: > > I would argue that namespace private operations are far better handled > > in userspace then kernelspace (why waste kernel memory managing > > private namespaces?). > > Private namespaces are bad and unnecessary. We already have anonymous > shared memory; I don't see any need for ``semi-anonymous'' shared > memory. The garbage-collection problem is already bad enough. Meanwhile, in the real world, it is exactly what we need at work. Anonymous shared memory (MAP_ANON and /dev/zero) isn't good enough. Actually, we dont care for the shm_open() API too much at all since it conflicts with our application libraries. Fortunately it doesn't exist in 4.x yet, which is where we need the persistent object thing anyway. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Jan 22 18:59:58 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9242037B405 for ; Wed, 22 Jan 2003 18:59:56 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C45743E4A for ; Wed, 22 Jan 2003 18:59:56 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0N2xt0i017636; Wed, 22 Jan 2003 18:59:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0N2xt9R017635; Wed, 22 Jan 2003 18:59:55 -0800 (PST) Date: Wed, 22 Jan 2003 18:59:55 -0800 (PST) From: Matthew Dillon Message-Id: <200301230259.h0N2xt9R017635@apollo.backplane.com> To: Garrett Wollman Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> 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 :> Moving shm_open() to kernel space? That's a pretty tall order. I :> don't think anyone has proposed that until now. : :It was always my expectation that this would happen at some point. You are welcome to try, but I would consider it a big mistake. :> I would argue that namespace private operations are far better handled :> in userspace then kernelspace (why waste kernel memory managing :> private namespaces?). : :Private namespaces are bad and unnecessary. We already have anonymous :shared memory; I don't see any need for ``semi-anonymous'' shared :memory. The garbage-collection problem is already bad enough. I have no idea what you are talking about here. We can do swap-backed anonymous shared memory using SysV shared memory (non descriptor-based), and we can emulate anonymous shared memory using shared files (descriptor based), but we have no descriptor-based shared memory mechanism that uses swap backing store and that is primarily what most people need when they need shared memory. These are not minor differences. It is a huge problem to people who use shared memory regularly like Peter, and me as well. I had to go through loops to make shared memory work in the Diablo news system and I sure wish I had getmemfd() back then! :You haven't provided any justification that I've seen for introducing :a new interface when the one we've got can already do that. We have no interface that has any capability to do what we want. I've explained to you what the problem is several times now in exruciating detail and you have ignored me every time, disputing the conclusion without providing anything to back up your assertion. I am going to explain again in the next sentence: We have no descriptor-based shared memory mechanism which uses swap as backing store. It's that simple. If you believe that such a mechanism already exists then, by all means, tell us all what it is. :> To do that requires a two-stage process of which my current proposed :> patch is only stage-1, since we have no current ability to call :> ftruncate() on a descriptor, only a vnode. : :Trivial under my proposal... here's the conceptual patch: That's a terrible hack. I would never implement that. It's bad enough that mmap() has to be hacked. I would far prefer to implement a high-level operations vector on descriptors that covers both mmap() and ftruncate() (at a high level), not add more low level hacks. I believe it makes sense to hack mmap() in the proposed stage-1 patch, but that's about as far as I am willing to go. The next step would be a high level operations vector. Again, I have reiterated the technical details of the problem and the proposed solution. If you believe a solution is possible without adding another system call I'm all ears. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 19: 5:12 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A16F37B401 for ; Wed, 22 Jan 2003 19:05:12 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 573CA43ED8 for ; Wed, 22 Jan 2003 19:05:11 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h0N359oV081066; Wed, 22 Jan 2003 19:05:09 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h0N359f6081065; Wed, 22 Jan 2003 19:05:09 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 22 Jan 2003 19:05:09 -0800 From: David Schultz To: Peter Wemm Cc: Garrett Wollman , Matthew Dillon , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <20030123030509.GA52151@HAL9000.homeunix.com> Mail-Followup-To: Peter Wemm , Garrett Wollman , Matthew Dillon , arch@FreeBSD.ORG References: <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <20030123022158.E5F5B2A7EA@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123022158.E5F5B2A7EA@canning.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 Thus spake Peter Wemm : > Garrett Wollman wrote: > > > > I would argue that namespace private operations are far better handled > > > in userspace then kernelspace (why waste kernel memory managing > > > private namespaces?). > > > > Private namespaces are bad and unnecessary. We already have anonymous > > shared memory; I don't see any need for ``semi-anonymous'' shared > > memory. The garbage-collection problem is already bad enough. > > Meanwhile, in the real world, it is exactly what we need at work. > Anonymous shared memory (MAP_ANON and /dev/zero) isn't good enough. I suppose it's too late to argue that the L4 interface would be sufficient to solve all these problems... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 19:13:51 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9C8E37B401 for ; Wed, 22 Jan 2003 19:13:50 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B50243E4A for ; Wed, 22 Jan 2003 19:13:50 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0N3Dnbs044889 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 22:13:49 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0N3DmPP044886; Wed, 22 Jan 2003 22:13:48 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 22:13:48 -0500 (EST) From: Garrett Wollman Message-Id: <200301230313.h0N3DmPP044886@khavrinen.lcs.mit.edu> To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <20030123022158.E5F5B2A7EA@canning.wemm.org> References: <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <20030123022158.E5F5B2A7EA@canning.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 < said: > Meanwhile, in the real world, it is exactly what we need at work. > Anonymous shared memory (MAP_ANON and /dev/zero) isn't good enough. I haven't seen anyone explain or back up this assertion. Tell me what the semantics are that you want, or give me the Message-ID where you posted them. What, precisely, are you trying to accomplish? > Actually, we dont care for the shm_open() API too much at all since it > conflicts with our application libraries. Too bad. It's been in POSIX or SSWG-RT for practically as long as your company has existed. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 19:39:20 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 480CE37B401 for ; Wed, 22 Jan 2003 19:39:19 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 001C943EB2 for ; Wed, 22 Jan 2003 19:39:18 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id DE9372A7EA; Wed, 22 Jan 2003 19:39:18 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301230313.h0N3DmPP044886@khavrinen.lcs.mit.edu> Date: Wed, 22 Jan 2003 19:39:18 -0800 From: Peter Wemm Message-Id: <20030123033918.DE9372A7EA@canning.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 Garrett Wollman wrote: > < said: > > > Meanwhile, in the real world, it is exactly what we need at work. > > Anonymous shared memory (MAP_ANON and /dev/zero) isn't good enough. > > I haven't seen anyone explain or back up this assertion. Tell me what > the semantics are that you want, or give me the Message-ID where you > posted them. What, precisely, are you trying to accomplish? Sigh. It is in the beginning of this thread, before it changed name. Search for the subject containing "Virtual memory question" from around January 11th. The original subject lives on in brackets. The first message-id is <20030111224444.94D102A89E@canning.wemm.org>, and there is quite a bit of elaboration afterwards. > > Actually, we dont care for the shm_open() API too much at all since it > > conflicts with our application libraries. > > Too bad. It's been in POSIX or SSWG-RT for practically as long as > your company has existed. Doesn't change the fact that it hurts us and that we're glad it isn't in RELENG_4. And we'll probably remove it from RELENG_5 if we ever use it. Matt's stuff is relatively easy to backport. We wont be backporting the shm_open() API stuff ourselves. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Jan 22 19:43:46 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC58937B401 for ; Wed, 22 Jan 2003 19:43:44 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED59C43EB2 for ; Wed, 22 Jan 2003 19:43:43 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0N3hfbs044972 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 22:43:41 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0N3hfXt044969; Wed, 22 Jan 2003 22:43:41 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 22:43:41 -0500 (EST) From: Garrett Wollman Message-Id: <200301230343.h0N3hfXt044969@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301230259.h0N2xt9R017635@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <200301230259.h0N2xt9R017635@apollo.backplane.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 < said: > I have no idea what you are talking about here. We can do swap-backed > anonymous shared memory using SysV shared memory (non descriptor-based), No, SysV shared memory is emphatically not anonymous. It does not use the filesystem namespace, but it certainly does have a namespace, and every SysV shared memory segment has a name in that namespace. (A particularly badly thought-out one at that, which causes all sorts of resource leaks when programs terminate unexpectedly.) > We have no interface that has any capability to do what we want. > I've explained to you what the problem is several times now in > exruciating detail No, you haven't explained a damn thing. You haven't even stated the problem at all. Tell me, once and for all, WTF is wrong, technically, with the shm_open interface. Don't give me any NIH crap, I'm not interested in hearing your theories on technical elegance or what not. We have a standard interface. Given a lack of a clear problem statement, I can only conclude that the interface *can* do what you seem to be saying you want it to do (it was good enough for SSWG-RT), but that you are for some reason firmly attached to your pet interface instead. How the current implementation of shm_open() works is entirely irrelevant; my desire is to replace it. > We have no descriptor-based > shared memory mechanism which uses swap as backing store. It's that > simple. > If you believe that such a mechanism already exists then, by all means, > tell us all what it is. You claim to have already implemented it. I'm not interested in reinventing your work on the VM side of this. I just want to avoid public exposure of a proprietary interface when a standard interface would do the job just as well. > That's a terrible hack. I would never implement that. Why don't we make some more molehills into insurmountable obstacles? > I would far prefer to implement a > high-level operations vector on descriptors that covers both mmap() and > ftruncate() (at a high level), Great idea, you do that. I don't see it as a show-stopper; it is easy to recognize and undo the hacks later when a better implementation is ready. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 19:58:11 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B31AB37B401 for ; Wed, 22 Jan 2003 19:58:10 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E62643F13 for ; Wed, 22 Jan 2003 19:58:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0N3w90i017901; Wed, 22 Jan 2003 19:58:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0N3w98H017900; Wed, 22 Jan 2003 19:58:09 -0800 (PST) Date: Wed, 22 Jan 2003 19:58:09 -0800 (PST) From: Matthew Dillon Message-Id: <200301230358.h0N3w98H017900@apollo.backplane.com> To: David Schultz Cc: Peter Wemm , Garrett Wollman , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <20030123022158.E5F5B2A7EA@canning.wemm.org> <20030123030509.GA52151@HAL9000.homeunix.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 :> > shared memory; I don't see any need for ``semi-anonymous'' shared :> > memory. The garbage-collection problem is already bad enough. :> :> Meanwhile, in the real world, it is exactly what we need at work. :> Anonymous shared memory (MAP_ANON and /dev/zero) isn't good enough. : :I suppose it's too late to argue that the L4 interface would be :sufficient to solve all these problems... Hmm. It's probably a bit overkill for what we need. We would probably want to implement Mach IPC instead (since NetBSD is already working on Mach). But IPC interfaces aren't really the issue here anyway. You still need something to pass (aka a descriptor). While you can pass shared memory around with the Mach interface, it is more designed for the short term shared memory accompanying a message and not really designed for memory objects (which can be larger then a process's VM space). I don't know how L4 deals with passing memory around. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 20:12:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D36237B401 for ; Wed, 22 Jan 2003 20:12:24 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89B9F43ED8 for ; Wed, 22 Jan 2003 20:12:23 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0N4CHbs045126 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 23:12:17 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0N4CHFI045123; Wed, 22 Jan 2003 23:12:17 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 23:12:17 -0500 (EST) From: Garrett Wollman Message-Id: <200301230412.h0N4CHFI045123@khavrinen.lcs.mit.edu> To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <20030123033918.DE9372A7EA@canning.wemm.org> References: <200301230313.h0N3DmPP044886@khavrinen.lcs.mit.edu> <20030123033918.DE9372A7EA@canning.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 < said: > Sigh. It is in the beginning of this thread, before it changed name. > Search for the subject containing "Virtual memory question" from around > January 11th. The original subject lives on in brackets. > The first message-id is <20030111224444.94D102A89E@canning.wemm.org>, > and there is quite a bit of elaboration afterwards. OK, I found it in the archives. Assuming a swap-backed implementation of shm_open(), the way to get what you want would be very simple: fd = shm_open("/foo", O_RDWR | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR); shm_unlink("/foo"); ftruncate(fd, size_required); mmap(...); ...that's using only standard interfaces.[1] As an extension, we could dispense with the naming entirely: // cons up a unique unnamed shared memory object // it doesn't really matter what the permissions are since the only // reference to it is through `fd'; however, we have to at least // specify enough permission bits to allow ourself to open it fd = shm_open("", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); ftruncate(fd, size_required); mmap(...); "" is not really a valid pathname, but I think it's safer to use the empty string to invoke an extension like this than to use a null pointer. -GAWollman [1] The standard does not completely specify the semantics of the name of a shared memory object. The name is required to meet the syntax of a pathname. However, it neither requires nor prohibits the implementation interpreting the name as a pathname. In 1999, Stevens found that some implementations, such as DEC's, required that the name be a valid pathname (of an existing file or one that the user would have sufficient privilege to create); other implementations, like Sun's, required that the name contain exactly one slash (they would then create a rendezvous file of the form "/tmp/goop.foo" for the name "/foo" for all values of "foo" including ones containing slashes). The consensus seems to be that the former implementation is more useful, and certainly more secure. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 20:16:57 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5590537B401 for ; Wed, 22 Jan 2003 20:16:55 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA28D43ED8 for ; Wed, 22 Jan 2003 20:16:54 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0N4Gn0i017990; Wed, 22 Jan 2003 20:16:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0N4GnRv017989; Wed, 22 Jan 2003 20:16:49 -0800 (PST) Date: Wed, 22 Jan 2003 20:16:49 -0800 (PST) From: Matthew Dillon Message-Id: <200301230416.h0N4GnRv017989@apollo.backplane.com> To: Garrett Wollman Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <200301230259.h0N2xt9R017635@apollo.backplane.com> <200301230343.h0N3hfXt044969@khavrinen.lcs.mit.edu> 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 have no interface that has any capability to do what we want. :> I've explained to you what the problem is several times now in :> exruciating detail : :No, you haven't explained a damn thing. You haven't even stated the :problem at all. Tell me, once and for all, WTF is wrong, technically, :with the shm_open interface. Don't give me any NIH crap, I'm not :interested in hearing your theories on technical elegance or what not. :We have a standard interface. Given a lack of a clear problem :statement, I can only conclude that the interface *can* do what you :seem to be saying you want it to do (it was good enough for SSWG-RT), :but that you are for some reason firmly attached to your pet interface :instead. How the current implementation of shm_open() works is :entirely irrelevant; my desire is to replace it. Did you even bother reading any of my prior postings? Fine then, I'll explain it again, for the fourth time. We need a shared memory mechanism that is swap-backed. It's that simple. I'll repeat it. For the Fifth time: We need a shared memory mechanism that is swap-backed. Understand the problem now? shm_open() as it currently stands does not in any way give us the above. Now, I think I understand what you are getting at. You seem to believe that implementing shm_open() in the kernel is the solution. There's a serious problem with doing this, however. Actually, there are two problems with doing this: (1) We don't have the kernel infrastructure to support it without a lot of hacks. i.e. we need a file-descriptor based vector array for high level descriptor based system calls in order to implement shm_open() properly in the kernel if we want to have any hope of keeping it compatible, or growing its compatibility, with other implementations. (2) You are talking about a fairly complex API in its full glory. In its full glory shm_open() needs to deal with both private and public name spaces. Implementing this in the kernel makes very little sense to me when the same thing can be implemented in userland at a far lower cost and far lower complexity. Hence, the current proposal is to implement a far simpler system call, one that simply returns a memory descriptor. This far simpler system call can eventually be leveraged in the userland implementation of shm_open(), at a far lower development cost. For example, Peter brought up the idea of using the solaris fattach() and related system calls as a means to give a memory descriptor public namespace support, and private namespace support can just as obviously be implemented within libc. As has been already discussed, some of the aspects of shm_open() do not lend themselves well to kernel implementation -- namely the private namespace support. In a previous email you seem to reject the whole concept of a private namespace but you can't argue that and also argue that we should implement it in the kernel, because then we wind up with a non-standard implementation of a standard's based function name. Now if you, personally, are willing to put in the huge amount of work necessary to implement shm_open(), in its full glory, in the kernel, I think that's just dandy. But if you aren't (and in your previous emails you don't seem to be willing to follow the shm_open() API in its full glory in a kernel implementation), then I don't see any advantage to regressing our shm_open() interface and instead I would far rather implement the simpler interface in the kernel and then, once we get all the proper support in down the line, use it to back a fully implemented userland shm_open(). I am recommending a course of action that allows us to incrementally achieve the same goals at a far lower cost. You seem to be trying to force a course of action, which you are not willing to undertake yourself, which achieves the goals at far higher cost, complexity, and with more hacks to the kernel. I'm sorry if you don't agree with me but that is my take on the situation. I really dislike hacking random code in the kernel unless its absolutely necessary. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 20:31:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1022E37B405 for ; Wed, 22 Jan 2003 20:31:48 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB1D243ED8 for ; Wed, 22 Jan 2003 20:31:46 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0N4Vibs045187 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 23:31:44 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0N4ViJ6045184; Wed, 22 Jan 2003 23:31:44 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 23:31:44 -0500 (EST) From: Garrett Wollman Message-Id: <200301230431.h0N4ViJ6045184@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301230416.h0N4GnRv017989@apollo.backplane.com> References: <20030122173229.D46974-100000@mail.chesapeake.net> <200301222249.h0MMn9e5016697@apollo.backplane.com> <200301222323.h0MNN7co043532@khavrinen.lcs.mit.edu> <200301230259.h0N2xt9R017635@apollo.backplane.com> <200301230343.h0N3hfXt044969@khavrinen.lcs.mit.edu> <200301230416.h0N4GnRv017989@apollo.backplane.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 < said: > (1) We don't have the kernel infrastructure to support it without a lot > of hacks. i.e. we need a file-descriptor based vector array for > high level descriptor based system calls in order to implement > shm_open() properly in the kernel if we want to have any hope of > keeping it compatible, or growing its compatibility, with other > implementations. You'd need to do that for any implementation of shared memory attached to file descriptors; it's not a unique problem. > (2) You are talking about a fairly complex API in its full glory. In > its full glory shm_open() needs to deal with both private and public > name spaces. No, it doesn't. shm_open() knows nothing of `both private and public name spaces'. The interpretation of the name of a shared memory object is entirely left up to the implementation; the only requirement is that all opens of "/foo" without an intervening unlink("/foo") refer to the same object. *No other semantics are specified.* The implementation is free to do anything it wishes with the names -- including what the current file-backed implementation does (which, you will note, has no `private name space'). > As has been already discussed, some of the aspects of shm_open() do not > lend themselves well to kernel implementation -- namely the private > namespace support. Again, there is no such thing as `private namespace support' in shm_open() or any other POSIX IPC interface. You are reading something into the standard that is simply not there. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 20:35:16 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67FEA37B401 for ; Wed, 22 Jan 2003 20:35:15 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DF8643EB2 for ; Wed, 22 Jan 2003 20:35:15 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id EFB672A7EA; Wed, 22 Jan 2003 20:35:09 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garrett Wollman Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <200301230343.h0N3hfXt044969@khavrinen.lcs.mit.edu> Date: Wed, 22 Jan 2003 20:35:09 -0800 From: Peter Wemm Message-Id: <20030123043509.EFB672A7EA@canning.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 Garrett Wollman wrote: > < said: [..] > > I would far prefer to implement a > > high-level operations vector on descriptors that covers both mmap() and > > ftruncate() (at a high level), > > Great idea, you do that. I don't see it as a show-stopper; it is easy > to recognize and undo the hacks later when a better implementation is > ready. We already have the infrastructure. It's called 'struct fileops' and we've already added things to it, and need to add a couple more to fix some explicitly enumerated switches on file types. +++ sys/file.h 23 Jan 2003 04:31:56 -0000 @@ -82,2 +82,3 @@ typedef int fo_close_t(struct file *fp, struct thread *td); +typedef int fo_setsize_t(struct file *fp, struct thread *td, off_t size); @@ -91,2 +92,3 @@ fo_close_t *fo_close; + fo_setsize_t *fo_setsize; }; The core of the existing truncate stuff would then become vn_setsize (or vn_truncate if that suits better). Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Jan 22 20:49:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5A5A37B405 for ; Wed, 22 Jan 2003 20:49:41 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E93EF43E4A for ; Wed, 22 Jan 2003 20:49:40 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0N4ndbs045270 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 22 Jan 2003 23:49:40 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0N4nddP045267; Wed, 22 Jan 2003 23:49:39 -0500 (EST) (envelope-from wollman) Date: Wed, 22 Jan 2003 23:49:39 -0500 (EST) From: Garrett Wollman Message-Id: <200301230449.h0N4nddP045267@khavrinen.lcs.mit.edu> To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) In-Reply-To: <20030123043509.EFB672A7EA@canning.wemm.org> References: <200301230343.h0N3hfXt044969@khavrinen.lcs.mit.edu> <20030123043509.EFB672A7EA@canning.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 < said: > We already have the infrastructure. It's called 'struct fileops' and > we've already added things to it, and need to add a couple more to fix > some explicitly enumerated switches on file types. Cool. There's still a few things that would need to be hacked, though. Right now most of these system calls use getvnode(), and we might need to come up with a more generic interface that still did the right thing with locking. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 20:54:18 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E50537B401; Wed, 22 Jan 2003 20:54:18 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2659343F18; Wed, 22 Jan 2003 20:54:17 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0N4s91e097179; Wed, 22 Jan 2003 21:54:10 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 22 Jan 2003 21:53:36 -0700 (MST) Message-Id: <20030122.215336.55300145.imp@bsdimp.com> To: bmilekic@unixdaemons.com Cc: hsu@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step From: "M. Warner Losh" In-Reply-To: <20030122162531.B77209@unixdaemons.com> References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030122162531.B77209@unixdaemons.com> Bosko Milekic writes: : Not one of you has said why you think that the wait behavior should : not be the default behavior and why the dontwait behavior shouldn't be : treated like an exception. We are saying, but you aren't listening. We are concerned about the kernel programmer paying attention to the sleepability of the kernel calls they are making. We are concerned that making wait default will lead to a larger standard deviation in the cases where the thread has to wait. We are concerned about the use of locks and allocating memory with the locks held (juding from the could sleep messages we have a lot of this code). We are conerned about the interface being correct. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 20:57:19 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41CEF37B401 for ; Wed, 22 Jan 2003 20:57:18 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EFEE43F13 for ; Wed, 22 Jan 2003 20:57:17 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0N4v91e097199; Wed, 22 Jan 2003 21:57:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 22 Jan 2003 21:56:36 -0700 (MST) Message-Id: <20030122.215636.84354016.imp@bsdimp.com> To: gallatin@cs.duke.edu Cc: arch@FreeBSD.ORG Subject: Re: M_ flags summary. From: "M. Warner Losh" In-Reply-To: <15919.4208.394911.712558@grasshopper.cs.duke.edu> References: <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> <15919.4208.394911.712558@grasshopper.cs.duke.edu> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <15919.4208.394911.712558@grasshopper.cs.duke.edu> Andrew Gallatin writes: : if (!(flags & M_NOWAIT)) { : WITNESS_SLEEP(1, NULL); : } : : at the top of malloc, and at the top of all entry points to the mbuf : allocator. Eg, before the system has a chance to pull the allocation : off of some cache which will succeed 99.5% of the time, except when : the system is under memory pressure. : : Sorry for dragging this in another direction.. I think we should do this reguardless of what the outcome of M_ flags is. This is an excellent solution. It might even be good to do this NOW and use the results as evidence towards or against the change as it is in CVS and any proposed solution. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 21: 5:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5561037B401; Wed, 22 Jan 2003 21:05:46 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B4543F18; Wed, 22 Jan 2003 21:05:46 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 80A59AE1C6; Wed, 22 Jan 2003 21:05:42 -0800 (PST) Date: Wed, 22 Jan 2003 21:05:42 -0800 From: Alfred Perlstein To: "M. Warner Losh" Cc: bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030123050542.GX42333@elvis.mu.org> References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122.215336.55300145.imp@bsdimp.com> User-Agent: Mutt/1.4i 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 [030122 20:55] wrote: > In message: <20030122162531.B77209@unixdaemons.com> > Bosko Milekic writes: > : Not one of you has said why you think that the wait behavior should > : not be the default behavior and why the dontwait behavior shouldn't be > : treated like an exception. > > We are saying, but you aren't listening. We are concerned about the > kernel programmer paying attention to the sleepability of the kernel > calls they are making. We are concerned that making wait default will > lead to a larger standard deviation in the cases where the thread has > to wait. We are concerned about the use of locks and allocating > memory with the locks held (juding from the could sleep messages we > have a lot of this code). We are conerned about the interface being > correct. Encouraging the user to use M_NOWAIT to get around all these problems is not a solution. Either locks are being held too long, or allocations are being done in the wrong places. When we have proper priority inheritance and low memory callbacks then we will not have to worry about latency. M_NOWAIT should be the exception if even allowed at all. -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 21:22:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACAA237B401; Wed, 22 Jan 2003 21:22:34 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 271B743ED8; Wed, 22 Jan 2003 21:22:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0N5MV0i018335; Wed, 22 Jan 2003 21:22:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0N5MVwQ018334; Wed, 22 Jan 2003 21:22:31 -0800 (PST) Date: Wed, 22 Jan 2003 21:22:31 -0800 (PST) From: Matthew Dillon Message-Id: <200301230522.h0N5MVwQ018334@apollo.backplane.com> To: Alfred Perlstein Cc: "M. Warner Losh" , bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.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 :Encouraging the user to use M_NOWAIT to get around all these problems :is not a solution. : :Either locks are being held too long, or allocations are being done :in the wrong places. : :When we have proper priority inheritance and low memory callbacks :then we will not have to worry about latency. : :M_NOWAIT should be the exception if even allowed at all. : :-- :-Alfred Perlstein [alfred@freebsd.org] Well, we are going to have issues with memory allocated by an interrupt even after interrupts are totally unwound from Giant. Even using interrupt threads we cannot afford to block in an allocation because that would introduce unexpected and unbounded latencies. That's a pretty big reason for M_NOWAIT to stick around, especially considering the work being done to consolidate all the memory allocation code. Before we had zalloc(), zalloci(), and malloc() with or without M_NOWAIT. Now it is all being consolidated. I would argue that we will need M_NOWAIT for a long time to come. Thread or not, interrupts are still special. The M_WAIT issue is not one of interface correctness or historical compatibility. It has been amply shown that the malloc interface has been misused by kernel programmers over the years. What Warner is asking (and I think this is a good idea too), is to try to reduce such incidences by making developers more aware of the blocking nature of the interface. Making M_WAITOK and M_NOWAIT both explicit bits accomplishes this. We then clean up all the current code and add a warning printf() to catch any remaining cases where neither bit is set (we default to M_WAITOK for those cases after printing the warning). This would help solve one of the two most serious issues we have in the memory subsystem. The second issue is what to do when we run out of KVM. Right now even a normal allocation will return NULL and most of the kernel just assumes that *malloc() never returns NULL. The result is a random crash with an obscure panic (usually a trap on a low memory address). That has caused us no end of diagnostic trouble in -stable. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 21:25:16 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 346CA37B401; Wed, 22 Jan 2003 21:25:15 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 403A743ED8; Wed, 22 Jan 2003 21:25:14 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0N5PD1e097338; Wed, 22 Jan 2003 22:25:13 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 22 Jan 2003 22:24:40 -0700 (MST) Message-Id: <20030122.222440.14643762.imp@bsdimp.com> To: bright@mu.org Cc: bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step From: "M. Warner Losh" In-Reply-To: <20030123050542.GX42333@elvis.mu.org> References: <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20030123050542.GX42333@elvis.mu.org> Alfred Perlstein writes: : * M. Warner Losh [030122 20:55] wrote: : > In message: <20030122162531.B77209@unixdaemons.com> : > Bosko Milekic writes: : > : Not one of you has said why you think that the wait behavior should : > : not be the default behavior and why the dontwait behavior shouldn't be : > : treated like an exception. : > : > We are saying, but you aren't listening. We are concerned about the : > kernel programmer paying attention to the sleepability of the kernel : > calls they are making. We are concerned that making wait default will : > lead to a larger standard deviation in the cases where the thread has : > to wait. We are concerned about the use of locks and allocating : > memory with the locks held (juding from the could sleep messages we : > have a lot of this code). We are conerned about the interface being : > correct. : : Encouraging the user to use M_NOWAIT to get around all these problems : is not a solution. What is the solution then? Waiting? Why not dropping the request? I'm not necessarily encouraging M_NOWAIT in these cases. I am telling you that M_NOWAIT is absolutely required for some applications and you are picking nits with the examples I give. : Either locks are being held too long, or allocations are being done : in the wrong places. There's lots of code in the tree that's way wrong then. : When we have proper priority inheritance and low memory callbacks : then we will not have to worry about latency. I'm interest in this. Do you have references that explain what you'd have in mind? : M_NOWAIT should be the exception if even allowed at all. You have to do it in interrupt context, where if you can't get memory you drop the request to rate limit things coming in. There are other applications that need the "allocate and send or drop" semantics. We have several at work: If you don't do something on time, then you shouldn't do it at all. Not having the ability to get memory w/o waiting can be a big problem. Usually we prealloc, but we can't always prealloc everything since packets can come in any time... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 22:12:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADB3537B401; Wed, 22 Jan 2003 22:12:33 -0800 (PST) Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C7FE43E4A; Wed, 22 Jan 2003 22:12:33 -0800 (PST) (envelope-from billh@gnuppy.monkey.org) Received: from billh by gnuppy.monkey.org with local (Exim 3.36 #1 (Debian)) id 18baap-0001vA-00; Wed, 22 Jan 2003 22:12:03 -0800 Date: Wed, 22 Jan 2003 22:12:03 -0800 To: Alfred Perlstein Cc: "M. Warner Losh" , bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG, "Bill Huey (Hui)" Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030123061203.GA7305@gnuppy.monkey.org> References: <0H94005IYWJT1Z@mta5.snfc21.pbi.net> <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123050542.GX42333@elvis.mu.org> User-Agent: Mutt/1.5.3i From: Bill Huey (Hui) 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, Jan 22, 2003 at 09:05:42PM -0800, Alfred Perlstein wrote: > Either locks are being held too long, or allocations are being done > in the wrong places. > > When we have proper priority inheritance and low memory callbacks > then we will not have to worry about latency. Simple priority inheritence doesn't prevent deadlocking. It's only one of many techiques to find a kind of localized solution inside a task synchronization search space. For something to be be more complete, you'd have to do a pretty exhaustive analysis of this space, determine which priority inversion protocol you want to use, etc... and then implement it. I'm not a dedicated hard core RT person, but I do know this bit is true and an investigation of the theory behind this analysis will support this. It's just a simple solution for a relatively simple synchronization system. You can't just create an arbitrarily complicated lock scenario in a kernel, apply a kind of simple priority inheritence anu hope that stuff works without strange anomalies. If possible, simplifying a system is probably the best solution, remove funky waits, try to hold as few resources as possible, etc... That's all I have to say. :) bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 22:30:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F4E337B401 for ; Wed, 22 Jan 2003 22:30:48 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8E6F43EB2 for ; Wed, 22 Jan 2003 22:30:46 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.5/8.12.5) with ESMTP id h0N6UgLZ016296; Thu, 23 Jan 2003 17:30:42 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h0N6UeRo016295; Thu, 23 Jan 2003 17:30:40 +1100 (EST) Date: Thu, 23 Jan 2003 17:30:40 +1100 From: Peter Jeremy To: Nicolas Souchu Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123063040.GA16266@cirb503493.alcatel.com.au> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122223626.B8449@armor.fastether> User-Agent: Mutt/1.4i 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, Jan 22, 2003 at 10:36:26PM +0100, Nicolas Souchu wrote: >On Wed, Jan 22, 2003 at 11:47:46AM +0000, Doug Rabson wrote: >> The main sticking point for this stuff is that console is needed before >> the device tree is probed. > >The approach of KGI is to provide a very basic/minimal driver for console boot >that can be overlaped later by fully probed graphic board drivers. This is >somehow how VGA adapter is organized, with the video_switch used immediatly >and later the vga_isa.c glue-code for newbus full attachement. I think you've missed the point of Doug's quoted comment. During the system boot, the kernel determines all the attached devices by starting with a hardware-dependent list of known busses and then working through all the busses looking for devices and bridges to other busses. When all this is finished, each attached device is known by an address within a parent bus. All the newbus I/O functions require this logical descriptor - amongst other things, it specifies how to interpret the address and actually perform physical I/O to the hardware. The console devices represent a special case: The address(es) of the console are either implicitly hard-wired (eg a VGA device lives at specific I/O addresses on the [primary] ISA bus) or passed to the kernel by the firmware (eg Alpha SRM) as a physical address (eg bus, slot, address). The problem is that: 1) you can't portably perform I/O via the physical address 2) you can't translate the physical address into a logical descriptor until the device tree is probed 3) you need to be able to perform console writes (at least) before the device tree is probed. The existing console code gets around this by being excessively chummy with the hardware (and I gather KGI works the same way). The downside is that this is very non-portable - you need separate low-level console code for each architecture and for each different possible console device. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 22:38:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDD6637B401 for ; Wed, 22 Jan 2003 22:38:45 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DCA743EB2 for ; Wed, 22 Jan 2003 22:38:45 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0N6cij70706 for ; Thu, 23 Jan 2003 01:38:44 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 23 Jan 2003 01:38:44 -0500 (EST) From: Jeff Roberson To: arch@freebsd.org Subject: New scheduler Message-ID: <20030123012620.E46974-100000@mail.chesapeake.net> 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'm sure many of you have seen me discussing my new scheduler in relation to the scheduler framework. I'd like to show what I have so far and get opinions/feedback. First, let me describe the features and general design of this scheduler. It is a queue switching O(1) scheduler much like solaris/linux/many others. It has per cpu run queues. It supports some notion of affinity. It is designed as a general purpose replacement for the current scheduler. It is not complete by any means. What is currently lacking is a good cpu balancing algorithm. I've been working on that for a little while now. The version I'm going to post has some temporary code that just decides where to place a proc at fork time. It never moves them after that. Its interactivity is very good in the situations that I've put it in. I have written some code to prove its latency, priority computations, nice effectiveness, etc. that I will post along with results as compared to the old scheduler and linux. There are some aspects of priority computation that I am very happy with and some that need more work. The most notable problem I have right now is what I'd call priority drift. The scheduler uses voluntary sleep time to calculate priority. A process which sleeps exactly one tick longer than it runs will eventually accumulate enough sleep time to reach the highest priority. I need to fix this. Oh, also, the pctcpu calculations are still a little off. I need to look into that. I have just started doing performance tests. Prior to this I was focusing on interactive response and priority calculation with nice. Some interesting early results: make -j4 buildworld on a 2 way Athlon 1800MP with one ata disk. new sched: 1933.193u 1156.398s 56:31.33 91.1% 2628+2106k 18752+4863io 8538pf+0w old sched: 2153.557u 1803.705s 48:25.07 136.2% 2462+1925k 17250+4666io 7113pf+0w What you can see here is that the sys time and user time were greatly reduced. By approx. 35% and 10% respectively. But, since we're not evenly balancing the load across both cpus the real time suffered. I don't expect the speedup to be this good once both cpus are well utilized due to memory bus contention. Anyway, I'm still waiting on single cpu results. If you have some free compute resources I'd love to have reports from different loads comparing this to the old scheduler. I'd also like feedback on how people would like to see this added to the build. You just need one file. It's available at http://www.chesapeake.net/~jroberson/sched_smp.c Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 22:42: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13C4137B401 for ; Wed, 22 Jan 2003 22:41:59 -0800 (PST) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DFC943F3F for ; Wed, 22 Jan 2003 22:41:58 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-11-62-147-120-13.dial.proxad.net [62.147.120.13]) by postfix4-2.free.fr (Postfix) with SMTP id A470DC0BB for ; Thu, 23 Jan 2003 07:41:50 +0100 (CET) Received: (qmail 10400 invoked by uid 1001); 23 Jan 2003 06:55:56 -0000 Date: Thu, 23 Jan 2003 07:55:56 +0100 From: Nicolas Souchu To: Marcel Moolenaar Cc: arch@FreeBSD.ORG, Rodolphe Ortalo Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123075556.A10370@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030122220029.GD590@dhcp01.pn.xcllnt.net>; from marcel@xcllnt.net on Wed, Jan 22, 2003 at 02:00:29PM -0800 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, Jan 22, 2003 at 02:00:29PM -0800, Marcel Moolenaar wrote: > On Wed, Jan 22, 2003 at 10:36:26PM +0100, Nicolas Souchu wrote: > > > > > > The main sticking point for this stuff is that console is needed before > > > the device tree is probed. > > > > The approach of KGI is to provide a very basic/minimal driver for console boot > > that can be overlaped later by fully probed graphic board drivers. This is > > somehow how VGA adapter is organized, with the video_switch used immediatly > > and later the vga_isa.c glue-code for newbus full attachement. > > This is what makes it non-portable and why we have problems getting > it to work in non-PC, non-ISA environments. Not because of a minimal driver, but because syscons and even more pcvt make assumptions on the features provided by the driver (font, text modes...) As far as I could see this has be more or less resolved with the tga adapter driver for alpha arch for which a renderer has been introduced to tackle down framebuffer only video adapters. > > But I prefer the solution of the minimal driver with included text rendering > > if needed. > > Booting a notebook in text mode looks ugly and I can imagine that > early boot environments can be graphical as well. I prefer not to > fixate on text-only video modes for the low-level console, even > though we probably won't use it for anything but text. I agree. But booting a true PCI/AGP (and not ISA) graphic card without the bus stuff initialized seems very hard. KGI driver framework provides its own bus interface that can be either connected to the OS busses or directly drive the I/O registers. I have to consider it closely... -- Nicholas Souchu - nsouch@free.fr - nsouch@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 Jan 22 22:48:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EA6737B401; Wed, 22 Jan 2003 22:48:29 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC73443F1E; Wed, 22 Jan 2003 22:48:28 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 780BAAE2AB; Wed, 22 Jan 2003 22:48:28 -0800 (PST) Date: Wed, 22 Jan 2003 22:48:28 -0800 From: Alfred Perlstein To: "M. Warner Losh" Cc: bmilekic@unixdaemons.com, hsu@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Alfre's malloc changes: the next step Message-ID: <20030123064828.GY42333@elvis.mu.org> References: <20030122162531.B77209@unixdaemons.com> <20030122.215336.55300145.imp@bsdimp.com> <20030123050542.GX42333@elvis.mu.org> <20030122.222440.14643762.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122.222440.14643762.imp@bsdimp.com> User-Agent: Mutt/1.4i 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 [030122 21:25] wrote: > In message: <20030123050542.GX42333@elvis.mu.org> > Alfred Perlstein writes: > : Encouraging the user to use M_NOWAIT to get around all these problems > : is not a solution. > > What is the solution then? Waiting? Why not dropping the request? > I'm not necessarily encouraging M_NOWAIT in these cases. I am telling > you that M_NOWAIT is absolutely required for some applications and you > are picking nits with the examples I give. The only place where it really makes any sense is interrupts where pre-alloc is impossible, or code that runs in the low memory deadlock avoidance path. > : Either locks are being held too long, or allocations are being done > : in the wrong places. > > There's lots of code in the tree that's way wrong then. Yup. > : When we have proper priority inheritance and low memory callbacks > : then we will not have to worry about latency. > > I'm interest in this. Do you have references that explain what you'd > have in mind? It would take some work, but the idea being that any lock we have in the kernel needs an "owner" slot so that if a high priority thread blocks on it we loan its prio to the thread that holds the lock. The low memory callback is like what we have with mbufs, such that subsystems can register a callback that will be called when the system is low on resources so that it can toss out data it might not need. > > : M_NOWAIT should be the exception if even allowed at all. > > You have to do it in interrupt context, where if you can't get memory > you drop the request to rate limit things coming in. There are other > applications that need the "allocate and send or drop" semantics. We > have several at work: If you don't do something on time, then you > shouldn't do it at all. Not having the ability to get memory w/o > waiting can be a big problem. Usually we prealloc, but we can't > always prealloc everything since packets can come in any time... Which is one of the few the exceptions. I know that we need M_NOWAIT, but it's should not be considered in the toolbox we use to lock down the kernel. :) -- -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.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 22 23:12:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B89A37B401 for ; Wed, 22 Jan 2003 23:12:36 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5965143F75 for ; Wed, 22 Jan 2003 23:12:35 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0N7CWMW032446; Wed, 22 Jan 2003 23:12:32 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0N7CWKZ028098; Wed, 22 Jan 2003 23:12:32 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0N7CWr5028097; Wed, 22 Jan 2003 23:12:32 -0800 (PST) (envelope-from marcel) Date: Wed, 22 Jan 2003 23:12:32 -0800 From: Marcel Moolenaar To: Nicolas Souchu Cc: arch@FreeBSD.ORG, Rodolphe Ortalo Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123071232.GA80532@dhcp01.pn.xcllnt.net> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> <20030123075556.A10370@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123075556.A10370@armor.fastether> User-Agent: Mutt/1.5.3i 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 Thu, Jan 23, 2003 at 07:55:56AM +0100, Nicolas Souchu wrote: > > > The approach of KGI is to provide a very basic/minimal driver for console boot > > > that can be overlaped later by fully probed graphic board drivers. This is > > > somehow how VGA adapter is organized, with the video_switch used immediatly > > > and later the vga_isa.c glue-code for newbus full attachement. > > > > This is what makes it non-portable and why we have problems getting > > it to work in non-PC, non-ISA environments. > > Not because of a minimal driver, but because syscons and even more pcvt > make assumptions on the features provided by the driver (font, text modes...) Ok. I didn't look at that specific part of the problem space. I mostly worry about the use of memory addresses and I/O ports that are specific to a platform or configuration and thus non-portable. > > Booting a notebook in text mode looks ugly and I can imagine that > > early boot environments can be graphical as well. I prefer not to > > fixate on text-only video modes for the low-level console, even > > though we probably won't use it for anything but text. > > I agree. But booting a true PCI/AGP (and not ISA) graphic card without > the bus stuff initialized seems very hard. Yes and no. The PCI standard has defined the legacy memory address of the frame buffer and the legacy I/O port range for compatibility. I expect that we can safely probe that. I don't know how this works in non-PCI system though... The approach I took on the ia64 branch is to have a xxx_machdep.c in sys/$ARCH/$ARCH for every device xxx that can be a low level console. In the file xxx_machdep.c you do whatever MD specific thing you need to do to construct a tag and handle for use by the MI code for device xxx. When bus enumeration happens, you compare the tag and handle of the low-level console with the tag and handle of the device that's being probed if you want to know if the device that's being probed is the console or not (you don't want to reset the device if it's the console for example). Goto http://people.freebsd.org/~peter/ia64.diff and search for sio_machdep.c and vga_machdep.c. The low-level console code for sio(4) is in sio_cons.c in the diff. So far it works out well, but I don't yet have sparc64 specific feedback on the approach... -- 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 Thu Jan 23 1:13:27 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C003237B401; Thu, 23 Jan 2003 01:13:26 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEAD543EB2; Thu, 23 Jan 2003 01:13:25 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0N9DFO33883; Thu, 23 Jan 2003 04:13:15 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 23 Jan 2003 04:13:15 -0500 (EST) From: Jeff Roberson To: Alfred Perlstein Cc: "M. Warner Losh" , , , Subject: Re: Alfre's malloc changes: the next step In-Reply-To: <20030123064828.GY42333@elvis.mu.org> Message-ID: <20030123041209.L2966-100000@mail.chesapeake.net> 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, 22 Jan 2003, Alfred Perlstein wrote: > > : When we have proper priority inheritance and low memory callbacks > > : then we will not have to worry about latency. > > > > I'm interest in this. Do you have references that explain what you'd > > have in mind? > > It would take some work, but the idea being that any lock we have > in the kernel needs an "owner" slot so that if a high priority > thread blocks on it we loan its prio to the thread that holds > the lock. > > The low memory callback is like what we have with mbufs, such > that subsystems can register a callback that will be called when > the system is low on resources so that it can toss out data it > might not need. > We have an event now when we're running low on memory. We could probably use one more when we're running low on KVA. That might make more sense. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 1:21: 4 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C20137B405 for ; Thu, 23 Jan 2003 01:21:03 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E125043F18 for ; Thu, 23 Jan 2003 01:21:00 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id h0N9Ki3p018625; Thu, 23 Jan 2003 09:20:44 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Nicolas Souchu Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Date: Thu, 23 Jan 2003 09:20:43 +0000 User-Agent: KMail/1.4.3 Cc: "Pedro F. Giffuni" , Marcel Moolenaar , arch@FreeBSD.ORG References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> In-Reply-To: <20030122223626.B8449@armor.fastether> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200301230920.43976.dfr@nlsystems.com> X-Spam-Status: No, hits=-7.7 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_KMAIL version=2.41 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 Wednesday 22 January 2003 9:36 pm, Nicolas Souchu wrote: > On Wed, Jan 22, 2003 at 11:47:46AM +0000, Doug Rabson wrote: > > I think the right approach will be to define > > a set of interfaces for the video console and then implement those > > interfaces using the lower-level kobj system. This allows you to > > put together a working console output system before the rest of the > > system is up and running. > > What is called the kobj interface? Kobj is just the low-level method dispatch framework which newbus (at=20 least newbus in 5.x) uses to call the drivers. Look at the kobj(9)=20 manpage. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 4:17:43 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4114B37B401 for ; Thu, 23 Jan 2003 04:17:42 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEB9043EB2 for ; Thu, 23 Jan 2003 04:17:35 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NCHQBs036551; Thu, 23 Jan 2003 12:17:26 GMT (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) by bluebottle.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NCHPt8051097; Thu, 23 Jan 2003 12:17:25 GMT (envelope-from dfr@nlsystems.com) Subject: Re: Newbusifying kbd? From: Doug Rabson To: Nicolas Souchu Cc: Marcel Moolenaar , arch@FreeBSD.ORG In-Reply-To: <20030122222335.A8449@armor.fastether> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030120074638.A11055@armor.fastether> <20030120222027.GA597@athlon.pn.xcllnt.net> <3E2D173C.3040507@graphics.cs.uni-sb.de> <20030122091519.B6700@armor.fastether> <20030122081923.GA10985@dhcp01.pn.xcllnt.net> <20030122222335.A8449@armor.fastether> Content-Type: text/plain Organization: Message-Id: <1043324244.28124.34.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 23 Jan 2003 12:17:25 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.41 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, 2003-01-22 at 21:23, Nicolas Souchu wrote: > On Wed, Jan 22, 2003 at 12:19:23AM -0800, Marcel Moolenaar wrote: > > On Wed, Jan 22, 2003 at 09:15:19AM +0100, Nicolas Souchu wrote: > > > On Tue, Jan 21, 2003 at 10:47:40AM +0100, Alexander Leidinger wrote: > > > > Marcel Moolenaar wrote: > > > > > > > > [KGI] > > > > > > > > > I took a quick look at it. I'm not opposed to having graphics support > > > > > in the kernel. The problem I think I see is that we probably have > > > > > enough interest to make standard VGA work, but never really have the > > > > > people or interest to keep up with the latest and greatest graphics > > > > > engine. So, I think this would be useful only in a model where the > > > > > graphics drivers are contributed and the X server makes use of it. > > > > > So, if XFree86 changes to this model, then I see potential... > > > > > > > > Chicken and egg problem... as far as I remember (I looked at it looong > > > > ago) they have a X server too... or at least they want to provide one. > > > > > > KGI provides a X server accelerated (PhoneiX) implementation not based on X. On > > > the other hand GGI (http://www.ggi-project.org), the user library going > > > with KGI does provide XFree86 (called XGGI) running) on top of the KGI > > > driver framework without its own drivers. > > > > Do I understand correctly that "without its own drivers" means that > > XFree86 doesn't have its own drivers and thus that the kernel driver > > is the hardware driver that's being used (though KGI)? > > You do. This isn't terribly useful when you want to do something non-trivial with the video hardware like 3D rendering. Designing a lovely console output mechanism which prevents high-performance 2D and 3D drivers in userland is pretty pointless. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 4:27: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCDAC37B401; Thu, 23 Jan 2003 04:27:06 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A229E43EB2; Thu, 23 Jan 2003 04:27:05 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NCQlBs036638; Thu, 23 Jan 2003 12:26:47 GMT (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) by bluebottle.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NCQht8051348; Thu, 23 Jan 2003 12:26:43 GMT (envelope-from dfr@nlsystems.com) Subject: Re: M_ flags summary. From: Doug Rabson To: John Baldwin Cc: Andrew Gallatin , arch@FreeBSD.ORG In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1043324803.28337.40.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 23 Jan 2003 12:26:43 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.41 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, 2003-01-22 at 21:58, John Baldwin wrote: > On 22-Jan-2003 Andrew Gallatin wrote: > > > > > > Speaking as the token 3rd party driver vendor, the removal of > > M_WAITOK/M_TRYWAIT is irritating, but not something that can't be > > solved with yet another ifdef in my driver. Breaking the 5.0 ABI > > prior to 5.1 is no big deal to me, as I don't plan to support > > 5.0-RELEASE anyway, so I don't care what the #defines end up as in the > > 5.0-STABLE branch. > > > > My thoughts are that whether we pronounce it po-ta-to, or po-tat-o, > > its still a potato and how its pronounced doesn't matter nearly as > > much as how it tastes. > > > > The taste "problem" here is that it always used to be safe to sleep > > in a process context. That's not true anymore. Now its safe to > > sleep in a process context if you're not holding any mutexes. So > > there are pleny of sleepable allocation bugs lurking. > > > > If we want to catch sleepable allocation bugs right up front, I > > suggest we put this: > > > > if (!(flags & M_NOWAIT)) { > > WITNESS_SLEEP(1, NULL); > > } > > > > at the top of malloc, and at the top of all entry points to the mbuf > > allocator. Eg, before the system has a chance to pull the allocation > > off of some cache which will succeed 99.5% of the time, except when > > the system is under memory pressure. > > We already do this for malloc(), that is the source of most of the > 'could sleep' messages these days. I have some patches I need to > commit to make the actual message more informative so that it will > say 'could malloc' etc. I was thinking yesterday that perhaps it would be useful to have a new entry point to the allocator. This might be called mmalloc, with the idea that mmalloc is to malloc as msleep is to tsleep. The caller would call it with its currently held mutex as an argument and that mutex would filter all the way down to the place where malloc sleeps and be passed to msleep (or something). This makes it explicit for the caller what is happening, i.e. it is clear that as a side effect of calling the allocator, your mutex may be released and regained so you need to take care about any cached results depending on variables which might be modified by other threads. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 7:40: 5 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65A8837B40B for ; Thu, 23 Jan 2003 07:39:58 -0800 (PST) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id C67E543E4A for ; Thu, 23 Jan 2003 07:39:57 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 25401 invoked from network); 23 Jan 2003 15:40:00 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Jan 2003 15:40:00 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h0NFdtUT041493; Thu, 23 Jan 2003 10:39:56 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1043324803.28337.40.camel@builder02.qubesoft.com> Date: Thu, 23 Jan 2003 10:39:59 -0500 (EST) From: John Baldwin To: Doug Rabson Subject: Re: M_ flags summary. Cc: arch@FreeBSD.ORG, Andrew Gallatin 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 23-Jan-2003 Doug Rabson wrote: > On Wed, 2003-01-22 at 21:58, John Baldwin wrote: >> On 22-Jan-2003 Andrew Gallatin wrote: >> > >> > >> > Speaking as the token 3rd party driver vendor, the removal of >> > M_WAITOK/M_TRYWAIT is irritating, but not something that can't be >> > solved with yet another ifdef in my driver. Breaking the 5.0 ABI >> > prior to 5.1 is no big deal to me, as I don't plan to support >> > 5.0-RELEASE anyway, so I don't care what the #defines end up as in the >> > 5.0-STABLE branch. >> > >> > My thoughts are that whether we pronounce it po-ta-to, or po-tat-o, >> > its still a potato and how its pronounced doesn't matter nearly as >> > much as how it tastes. >> > >> > The taste "problem" here is that it always used to be safe to sleep >> > in a process context. That's not true anymore. Now its safe to >> > sleep in a process context if you're not holding any mutexes. So >> > there are pleny of sleepable allocation bugs lurking. >> > >> > If we want to catch sleepable allocation bugs right up front, I >> > suggest we put this: >> > >> > if (!(flags & M_NOWAIT)) { >> > WITNESS_SLEEP(1, NULL); >> > } >> > >> > at the top of malloc, and at the top of all entry points to the mbuf >> > allocator. Eg, before the system has a chance to pull the allocation >> > off of some cache which will succeed 99.5% of the time, except when >> > the system is under memory pressure. >> >> We already do this for malloc(), that is the source of most of the >> 'could sleep' messages these days. I have some patches I need to >> commit to make the actual message more informative so that it will >> say 'could malloc' etc. > > I was thinking yesterday that perhaps it would be useful to have a new > entry point to the allocator. This might be called mmalloc, with the > idea that mmalloc is to malloc as msleep is to tsleep. The caller would > call it with its currently held mutex as an argument and that mutex > would filter all the way down to the place where malloc sleeps and be > passed to msleep (or something). > > This makes it explicit for the caller what is happening, i.e. it is > clear that as a side effect of calling the allocator, your mutex may be > released and regained so you need to take care about any cached results > depending on variables which might be modified by other threads. This would prevent the malloc implementation from using internal mutexes that it msleep's or cv_wait's on. You only get to pass in one mutex to cv_wait* and msleep. In my experience, one can often "fix" problems with holding locks across malloc() by malloc()'ing things earlier in the function before you need locks. -- 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 Thu Jan 23 8:28:19 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFDC637B401 for ; Thu, 23 Jan 2003 08:28:17 -0800 (PST) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF5B243EB2 for ; Thu, 23 Jan 2003 08:28:16 -0800 (PST) (envelope-from ben@timing.com) Received: from piglet.timing.com (piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.11.3/8.11.3) with ESMTP id h0NGSGH98139 for ; Thu, 23 Jan 2003 09:28:16 -0700 (MST) (envelope-from ben@timing.com) Received: from piglet.timing.com (localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6/8.12.6) with ESMTP id h0NGSGvR035710 for ; Thu, 23 Jan 2003 09:28:16 -0700 (MST) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6/8.12.6/Submit) id h0NGSFgw035707; Thu, 23 Jan 2003 09:28:15 -0700 (MST) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15920.6175.737639.566519@piglet.timing.com> Date: Thu, 23 Jan 2003 09:28:15 -0700 To: freebsd-arch@freebsd.org Subject: _REENTRANT in math.h & libm oddities. X-Mailer: VM 7.00 under Emacs 21.2.93.1 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 Greetings, Recently while working on some threading issues I noticed an oddity in /usr/include/math.h : the definitions of two functions, gamma_r and lgamma_r, are protected with #ifdef _REENTRANT . I suspect this is a historical artifact, as the FreeBSD manpage for gcc indicates that -D_THREAD_SAFE is the proper way to indicate that you are compiling threaded code on FreeBSD. I think the correct fix for this is to remove the #ifdef _REENTRANT from math.h . But perhaps it is there for a reason I am not cognizant of. If that is the case, wouldn't we be better served by using _THREAD_SAFE in FreeBSD? Also note that there are reentrant API's available for gammaf & lgamma: gammaf_r and lgammaf_r, but there are no prototypes for these in math.h. Additionally, there is no mention of the four functions gamma_r, lgamma_r, gammaf_r, and lgammaf_r on the lgamma(3) man page. Is it worthwhile to work up a patch to: - remove _REENTRANT from math.h (and replace with _THREAD_SAFE if people think that is appropriate) - add prototypes for gammaf_r & lgammaf_r to math.h - update the lgamma(3) man page to mention gamma_r, lgamma_r, gammaf_r, and lgammaf_r ? Regards, Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 8:36: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2F9F37B401; Thu, 23 Jan 2003 08:36:03 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6643243F13; Thu, 23 Jan 2003 08:36:02 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NGZeBs039699; Thu, 23 Jan 2003 16:35:40 GMT (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) by bluebottle.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NGZct8056861; Thu, 23 Jan 2003 16:35:40 GMT (envelope-from dfr@nlsystems.com) Subject: Re: M_ flags summary. From: Doug Rabson To: John Baldwin Cc: arch@FreeBSD.org, Andrew Gallatin In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1043339738.29341.1.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 23 Jan 2003 16:35:38 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.41 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 Thu, 2003-01-23 at 15:39, John Baldwin wrote: > On 23-Jan-2003 Doug Rabson wrote: > > On Wed, 2003-01-22 at 21:58, John Baldwin wrote: > >> On 22-Jan-2003 Andrew Gallatin wrote: > >> > > >> > > >> > Speaking as the token 3rd party driver vendor, the removal of > >> > M_WAITOK/M_TRYWAIT is irritating, but not something that can't be > >> > solved with yet another ifdef in my driver. Breaking the 5.0 ABI > >> > prior to 5.1 is no big deal to me, as I don't plan to support > >> > 5.0-RELEASE anyway, so I don't care what the #defines end up as in the > >> > 5.0-STABLE branch. > >> > > >> > My thoughts are that whether we pronounce it po-ta-to, or po-tat-o, > >> > its still a potato and how its pronounced doesn't matter nearly as > >> > much as how it tastes. > >> > > >> > The taste "problem" here is that it always used to be safe to sleep > >> > in a process context. That's not true anymore. Now its safe to > >> > sleep in a process context if you're not holding any mutexes. So > >> > there are pleny of sleepable allocation bugs lurking. > >> > > >> > If we want to catch sleepable allocation bugs right up front, I > >> > suggest we put this: > >> > > >> > if (!(flags & M_NOWAIT)) { > >> > WITNESS_SLEEP(1, NULL); > >> > } > >> > > >> > at the top of malloc, and at the top of all entry points to the mbuf > >> > allocator. Eg, before the system has a chance to pull the allocation > >> > off of some cache which will succeed 99.5% of the time, except when > >> > the system is under memory pressure. > >> > >> We already do this for malloc(), that is the source of most of the > >> 'could sleep' messages these days. I have some patches I need to > >> commit to make the actual message more informative so that it will > >> say 'could malloc' etc. > > > > I was thinking yesterday that perhaps it would be useful to have a new > > entry point to the allocator. This might be called mmalloc, with the > > idea that mmalloc is to malloc as msleep is to tsleep. The caller would > > call it with its currently held mutex as an argument and that mutex > > would filter all the way down to the place where malloc sleeps and be > > passed to msleep (or something). > > > > This makes it explicit for the caller what is happening, i.e. it is > > clear that as a side effect of calling the allocator, your mutex may be > > released and regained so you need to take care about any cached results > > depending on variables which might be modified by other threads. > > This would prevent the malloc implementation from using internal mutexes > that it msleep's or cv_wait's on. You only get to pass in one mutex > to cv_wait* and msleep. That did occur to me too, which was why I wrote "or something". It looks hard to DTRT here without a version of msleep which took a list of mutexes to release. > In my experience, one can often "fix" problems > with holding locks across malloc() by malloc()'ing things earlier in the > function before you need locks. This is obviously preferable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 8:37:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1816737B401 for ; Thu, 23 Jan 2003 08:37:34 -0800 (PST) Received: from web13404.mail.yahoo.com (web13404.mail.yahoo.com [216.136.175.62]) by mx1.FreeBSD.org (Postfix) with SMTP id B244843EB2 for ; Thu, 23 Jan 2003 08:37:33 -0800 (PST) (envelope-from giffunip@yahoo.com) Message-ID: <20030123163733.86437.qmail@web13404.mail.yahoo.com> Received: from [200.24.79.163] by web13404.mail.yahoo.com via HTTP; Thu, 23 Jan 2003 17:37:33 CET Date: Thu, 23 Jan 2003 17:37:33 +0100 (CET) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) To: Doug Rabson Cc: arch@FreeBSD.ORG In-Reply-To: <200301230920.43976.dfr@nlsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 --- Doug Rabson ha scritto: > On Wednesday 22 January 2003 9:36 pm, Nicolas Souchu > wrote: ... > > > > What is called the kobj interface? > > Kobj is just the low-level method dispatch framework > which newbus (at > least newbus in 5.x) uses to call the drivers. Look > at the kobj(9) > manpage. > I understand the sound drivers already use it, and someday someone with lot's of spare time might start rewriting FreeBSD to make it more modular..something like SPIN OS where everything is an object. I wonder.. how far did your patches first set of patches for the Alpha go? ;). cheers, Pedro. ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 9:14:37 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B21537B401 for ; Thu, 23 Jan 2003 09:14:36 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 180E743E4A for ; Thu, 23 Jan 2003 09:14:35 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0NHEQ1e001069; Thu, 23 Jan 2003 10:14:26 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 23 Jan 2003 10:13:35 -0700 (MST) Message-Id: <20030123.101335.95024590.imp@bsdimp.com> To: ben@timing.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. From: "M. Warner Losh" In-Reply-To: <15920.6175.737639.566519@piglet.timing.com> References: <15920.6175.737639.566519@piglet.timing.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <15920.6175.737639.566519@piglet.timing.com> Ben Mesander writes: : Recently while working on some threading issues I noticed an oddity : in /usr/include/math.h : the definitions of two functions, gamma_r and : lgamma_r, are protected with #ifdef _REENTRANT . I suspect this is a : historical artifact, as the FreeBSD manpage for gcc indicates that : -D_THREAD_SAFE is the proper way to indicate that you are compiling : threaded code on FreeBSD. The #ifdef in math.h is way historical: 1.1 (jkh 19-Aug-94): #ifdef _REENTRANT 1.12 (obrien 21-Mar-02): double gamma_r(double, int *); 1.12 (obrien 21-Mar-02): double lgamma_r(double, int *); 1.1 (jkh 19-Aug-94): #endif /* _REENTRANT */ Since Sun donated this stuff to BSD back in 1993, I suspect that it comes from Solaris' -D_REENTRANT stuff that was/is done for threaded programs. : I think the correct fix for this is to remove the #ifdef _REENTRANT : from math.h . But perhaps it is there for a reason I am not cognizant : of. If that is the case, wouldn't we be better served by using : _THREAD_SAFE in FreeBSD? I can see no harm in just removing the ifdef. However, a quick survey of the header files shows that a number of the _r functions have ifdef protection for namespace pollution. One of the standard's wonks will have to tell us for sure which standard(s) these comply to. The functions generally don't have an ifdef _THREAD_SAFE around them. : Also note that there are reentrant API's available for gammaf & lgamma: : gammaf_r and lgammaf_r, but there are no prototypes for these in : math.h. Additionally, there is no mention of the four functions : gamma_r, lgamma_r, gammaf_r, and lgammaf_r on the lgamma(3) man page. This is likely also an issue. : Is it worthwhile to work up a patch to: : - remove _REENTRANT from math.h (and replace with _THREAD_SAFE if : people think that is appropriate) I'd remove it completely, unless the standard's wonks think some name space pollution avoiding typedef is necessary. : - add prototypes for gammaf_r & lgammaf_r to math.h I'd add it as above. : - update the lgamma(3) man page to mention gamma_r, lgamma_r, gammaf_r, : and lgammaf_r Safe. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 9:22:13 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76E2937B401 for ; Thu, 23 Jan 2003 09:22:11 -0800 (PST) Received: from straylight.ringlet.net (office.sbnd.net [217.75.140.130]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A60C43EB2 for ; Thu, 23 Jan 2003 09:22:06 -0800 (PST) (envelope-from roam@straylight.ringlet.net) Received: (qmail 20072 invoked by uid 1000); 23 Jan 2003 17:20:56 -0000 Date: Thu, 23 Jan 2003 19:20:55 +0200 From: Peter Pentchev To: "M. Warner Losh" Cc: ben@timing.com, freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. Message-ID: <20030123172055.GB19717@straylight.oblivion.bg> Mail-Followup-To: "M. Warner Losh" , ben@timing.com, freebsd-arch@FreeBSD.ORG References: <15920.6175.737639.566519@piglet.timing.com> <20030123.101335.95024590.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20030123.101335.95024590.imp@bsdimp.com> User-Agent: Mutt/1.5.3i 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 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 23, 2003 at 10:13:35AM -0700, M. Warner Losh wrote: [snip] > : Also note that there are reentrant API's available for gammaf & lgamm= a: > : gammaf_r and lgammaf_r, but there are no prototypes for these in > : math.h. Additionally, there is no mention of the four functions > : gamma_r, lgamma_r, gammaf_r, and lgammaf_r on the lgamma(3) man page. >=20 > This is likely also an issue. >=20 > : Is it worthwhile to work up a patch to: > : - remove _REENTRANT from math.h (and replace with _THREAD_SAFE if > : people think that is appropriate) >=20 > I'd remove it completely, unless the standard's wonks think some name > space pollution avoiding typedef is necessary. >=20 > : - add prototypes for gammaf_r & lgammaf_r to math.h >=20 > I'd add it as above. >=20 > : - update the lgamma(3) man page to mention gamma_r, lgamma_r, gammaf_= r, > : and lgammaf_r >=20 > Safe. With all this talk of removing / adding prototypes, and generally changing math.h, I hope that both you and the original poster are aware of the several math.h discussion threads on the -standards list :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. --17pEHd4RhPHOinZp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+MCR37Ri2jRYZRVMRAgLNAKDAce9Ya65srfbsEz9WgbM7fYdzjACgxDVX DiXIkdNwy9o4pLGLI5hztuk= =Bq1T -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 10: 3:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC7B937B401 for ; Thu, 23 Jan 2003 10:03:45 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC99243EB2 for ; Thu, 23 Jan 2003 10:03:43 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NI3UBs040780; Thu, 23 Jan 2003 18:03:30 GMT (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) by bluebottle.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NI3St8058819; Thu, 23 Jan 2003 18:03:28 GMT (envelope-from dfr@nlsystems.com) Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) From: Doug Rabson To: "Pedro F. Giffuni" Cc: arch@FreeBSD.ORG In-Reply-To: <20030123163733.86437.qmail@web13404.mail.yahoo.com> References: <20030123163733.86437.qmail@web13404.mail.yahoo.com> Content-Type: text/plain Organization: Message-Id: <1043345008.29340.7.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 23 Jan 2003 18:03:28 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 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 Thu, 2003-01-23 at 16:37, Pedro F. Giffuni wrote: > --- Doug Rabson ha scritto: > > On Wednesday 22 January 2003 9:36 pm, Nicolas Souchu > > wrote: > ... > > > > > > What is called the kobj interface? > > > > Kobj is just the low-level method dispatch framework > > which newbus (at > > least newbus in 5.x) uses to call the drivers. Look > > at the kobj(9) > > manpage. > > > I understand the sound drivers already use it, and > someday someone with lot's of spare time might start > rewriting FreeBSD to make it more modular..something > like SPIN OS where everything is an object. > > I wonder.. how far did your patches first set of > patches for the Alpha go? ;). The alpha stuff I did was solving a specific problem - implementing busspace properly on multi-hose alpha hardware. On such hardware, there isn't a single i/o port i/o memory address space. There is typically one of each per hose (a hose is approximately a host-pci bridge). The busspace implementation in 4.x was pretty lame and didn't scale to the really big machines so I re-wrote it to represent each space (i/o port or i/o memory) as an object with methods on that object to access the space. This was wrapped in a busspace-standard api. The kobj version was fully functional but it was never committed - we changed over to structures of function pointers to make it possible to back-port to 4.x. The back-porting never happened though :-(. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 11:43:20 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4706A37B401 for ; Thu, 23 Jan 2003 11:43:19 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73C4F43F18 for ; Thu, 23 Jan 2003 11:43:18 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NJhEMW035558; Thu, 23 Jan 2003 11:43:14 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NJhESx000864; Thu, 23 Jan 2003 11:43:14 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0NJhEUx000863; Thu, 23 Jan 2003 11:43:14 -0800 (PST) (envelope-from marcel) Date: Thu, 23 Jan 2003 11:43:14 -0800 From: Marcel Moolenaar To: Doug Rabson Cc: Nicolas Souchu , arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030123194314.GE579@dhcp01.pn.xcllnt.net> References: <20030119225129.A6948@armor.fastether> <20030119233031.GA24377@dhcp01.pn.xcllnt.net> <20030120074638.A11055@armor.fastether> <20030120222027.GA597@athlon.pn.xcllnt.net> <3E2D173C.3040507@graphics.cs.uni-sb.de> <20030122091519.B6700@armor.fastether> <20030122081923.GA10985@dhcp01.pn.xcllnt.net> <20030122222335.A8449@armor.fastether> <1043324244.28124.34.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1043324244.28124.34.camel@builder02.qubesoft.com> User-Agent: Mutt/1.5.3i 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 Thu, Jan 23, 2003 at 12:17:25PM +0000, Doug Rabson wrote: > > > > > > Do I understand correctly that "without its own drivers" means that > > > XFree86 doesn't have its own drivers and thus that the kernel driver > > > is the hardware driver that's being used (though KGI)? > > > > You do. > > This isn't terribly useful when you want to do something non-trivial > with the video hardware like 3D rendering. Designing a lovely console > output mechanism which prevents high-performance 2D and 3D drivers in > userland is pretty pointless. The precondition obviously is that the kernel driver has the same HP 2D/3D features as a userland driver. I find it interesting, but doubt that it will work in practice. It's hard to write and maintain a portable graphics driver that works with dozens of OSes. Especially since performance and portability are opposite forces. -- 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 Thu Jan 23 12:17: 5 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4593537B401 for ; Thu, 23 Jan 2003 12:17:04 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADACA43F18 for ; Thu, 23 Jan 2003 12:17:02 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id h0NKGo3p021813; Thu, 23 Jan 2003 20:16:50 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Marcel Moolenaar Subject: Re: Newbusifying kbd? Date: Thu, 23 Jan 2003 20:16:50 +0000 User-Agent: KMail/1.4.3 Cc: Nicolas Souchu , arch@FreeBSD.ORG References: <20030119225129.A6948@armor.fastether> <1043324244.28124.34.camel@builder02.qubesoft.com> <20030123194314.GE579@dhcp01.pn.xcllnt.net> In-Reply-To: <20030123194314.GE579@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200301232016.50139.dfr@nlsystems.com> X-Spam-Status: No, hits=-8.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_KMAIL version=2.41 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 Thursday 23 January 2003 7:43 pm, Marcel Moolenaar wrote: > On Thu, Jan 23, 2003 at 12:17:25PM +0000, Doug Rabson wrote: > > > > Do I understand correctly that "without its own drivers" means > > > > that XFree86 doesn't have its own drivers and thus that the > > > > kernel driver is the hardware driver that's being used (though > > > > KGI)? > > > > > > You do. > > > > This isn't terribly useful when you want to do something > > non-trivial with the video hardware like 3D rendering. Designing a > > lovely console output mechanism which prevents high-performance 2D > > and 3D drivers in userland is pretty pointless. > > The precondition obviously is that the kernel driver has the same > HP 2D/3D features as a userland driver. I find it interesting, but > doubt that it will work in practice. It's hard to write and > maintain a portable graphics driver that works with dozens of OSes. > Especially since performance and portability are opposite forces. All I'm trying to say is that the XFree86 project and the DRI projects=20 have already solved the problem of providing reasonable access to 2D=20 and 3D graphics hardware. There isn't much point in pursuing another=20 solution that doesn't leverage that work. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 12:58:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 955C937B401 for ; Thu, 23 Jan 2003 12:58:13 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86BB943EB2 for ; Thu, 23 Jan 2003 12:58:11 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.5/8.12.5) with ESMTP id h0NKw9LZ017317; Fri, 24 Jan 2003 07:58:09 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h0NKw8tH017316; Fri, 24 Jan 2003 07:58:08 +1100 (EST) Date: Fri, 24 Jan 2003 07:58:08 +1100 From: Peter Jeremy To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123205808.GA17281@cirb503493.alcatel.com.au> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> <20030123075556.A10370@armor.fastether> <20030123071232.GA80532@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123071232.GA80532@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4i 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, Jan 22, 2003 at 11:12:32PM -0800, Marcel Moolenaar wrote: >On Thu, Jan 23, 2003 at 07:55:56AM +0100, Nicolas Souchu wrote: >> I agree. But booting a true PCI/AGP (and not ISA) graphic card without >> the bus stuff initialized seems very hard. > >Yes and no. The PCI standard has defined the legacy memory address of >the frame buffer and the legacy I/O port range for compatibility. I >expect that we can safely probe that. I don't know how this works in >non-PCI system though... I think this is only true of VGA devices. Definitely the DEC TGA does not have any legacy address support - it has to be initialised as a generic PCI device and then written to using its proprietary command set. And based on other comments in this thread, I think that USB keyboards don't have legacy AT-keyboard support either. >The approach I took on the ia64 branch is to have a xxx_machdep.c in >sys/$ARCH/$ARCH for every device xxx that can be a low level console. Whilst I don't see any alternative, this is a fairly expensive approach since the number of MD files starts growing alarmingly as the number of architectures and console devices increases. (Though it's definitely better than having lots of MD code buried in supposedly MI files). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 13: 6:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 037AF37B407 for ; Thu, 23 Jan 2003 13:06:53 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5033343E4A for ; Thu, 23 Jan 2003 13:06:52 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id h0NL6e9n014606; Thu, 23 Jan 2003 16:06:41 -0500 (EST) Date: Thu, 23 Jan 2003 16:06:40 -0500 (EST) From: Daniel Eischen To: "M. Warner Losh" Cc: ben@timing.com, freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: <20030123.101335.95024590.imp@bsdimp.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 Thu, 23 Jan 2003, M. Warner Losh wrote: > In message: <15920.6175.737639.566519@piglet.timing.com> > Ben Mesander writes: > : Recently while working on some threading issues I noticed an oddity > : in /usr/include/math.h : the definitions of two functions, gamma_r and > : lgamma_r, are protected with #ifdef _REENTRANT . I suspect this is a > : historical artifact, as the FreeBSD manpage for gcc indicates that > : -D_THREAD_SAFE is the proper way to indicate that you are compiling > : threaded code on FreeBSD. > > The #ifdef in math.h is way historical: > > 1.1 (jkh 19-Aug-94): #ifdef _REENTRANT > 1.12 (obrien 21-Mar-02): double gamma_r(double, int *); > 1.12 (obrien 21-Mar-02): double lgamma_r(double, int *); > 1.1 (jkh 19-Aug-94): #endif /* _REENTRANT */ > > Since Sun donated this stuff to BSD back in 1993, I suspect that it > comes from Solaris' -D_REENTRANT stuff that was/is done for threaded > programs. The gcc manpage is wrong. It should state _REENTRANT instead of _THREAD_SAFE. POSIX specifies that _REENTRANT be defined to get these functions. I know that we always provide implementations of most of these _r functions so it might not make sense to #ifdef them in the header files, but I don't know that always making them visible would be against the spec or cause namespace pollution. > I can see no harm in just removing the ifdef. However, a quick survey > of the header files shows that a number of the _r functions have ifdef > protection for namespace pollution. One of the standard's wonks will > have to tell us for sure which standard(s) these comply to. The > functions generally don't have an ifdef _THREAD_SAFE around them. > > : Also note that there are reentrant API's available for gammaf & > lgamma: : gammaf_r and lgammaf_r, but there are no prototypes for > these in : math.h. Additionally, there is no mention of the four > functions : gamma_r, lgamma_r, gammaf_r, and lgammaf_r on the > lgamma(3) man page. > > This is likely also an issue. > : Is it worthwhile to work up a patch to: > : - remove _REENTRANT from math.h (and replace with _THREAD_SAFE if > : people think that is appropriate) > > I'd remove it completely, unless the standard's wonks think some name > space pollution avoiding typedef is necessary. I'd tend to leave them in. We're not violating the spec by leaving them in, but may be by removing them. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 13:22: 5 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8AD537B401 for ; Thu, 23 Jan 2003 13:22:04 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19F3843F1E for ; Thu, 23 Jan 2003 13:22:04 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0NLM31e003077; Thu, 23 Jan 2003 14:22:03 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200301232122.h0NLM31e003077@harmony.village.org> To: Daniel Eischen Subject: Re: _REENTRANT in math.h & libm oddities. Cc: ben@timing.com, freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 23 Jan 2003 16:06:40 EST." References: Date: Thu, 23 Jan 2003 14:22:03 -0700 From: Warner Losh 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 Daniel Eischen writes: : The gcc manpage is wrong. It should state _REENTRANT instead of : _THREAD_SAFE. POSIX specifies that _REENTRANT be defined to get : these functions. I know that we always provide implementations : of most of these _r functions so it might not make sense to : #ifdef them in the header files, but I don't know that always : making them visible would be against the spec or cause namespace : pollution. Then FreeBSD's source tree is basically wrong, since it uses _THREAD_SAFE for this in many places. But most of them appear to be just defining the macro for compiles and such. There's a little bit in libc's stdio still, but that's the only significant place that uses it in the tree. I'm not sure about out-of-tree software. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 13:30:41 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0C4437B401 for ; Thu, 23 Jan 2003 13:30:40 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABA7843EB2 for ; Thu, 23 Jan 2003 13:30:39 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.5/8.12.5) with ESMTP id h0NLUYLZ017353; Fri, 24 Jan 2003 08:30:34 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h0NLUXl3017352; Fri, 24 Jan 2003 08:30:33 +1100 (EST) Date: Fri, 24 Jan 2003 08:30:33 +1100 From: Peter Jeremy To: Nicolas Souchu Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123213033.GB17281@cirb503493.alcatel.com.au> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> <20030123075556.A10370@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123075556.A10370@armor.fastether> User-Agent: Mutt/1.4i 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 Thu, Jan 23, 2003 at 07:55:56AM +0100, Nicolas Souchu wrote: >Not because of a minimal driver, but because syscons and even more pcvt >make assumptions on the features provided by the driver (font, text modes...) AFAIK, these assumptions are all part of the VGA standard - if you have a VGA-compatible graphics card then it will provide standard font and text modes as used by syscons and pcvt. And the only non-VGA graphics adapter I'm aware of is the DEC TGA (though it seems likely that some or all of the Sun framebuffers don't support VGA. I don't see any reason to not use the VGA features if they're available and unless there's a lot of non-VGA adapters around, they can be treated on a case-by-case basis. >As far as I could see this has be more or less resolved with the tga adapter >driver for alpha arch for which a renderer has been introduced to tackle down >framebuffer only video adapters. It's not clear how much of the TGA renderer could be reused by another FB-only adapter. Whilst the renderer is mostly rendering into a raw framebuffer, there are a fair number of implicit assumptions about how the bits in the framebuffer RAM turn into pixels on the screen. Note that this driver explicitly uses VGA mode if it detects a TGA2 adapter. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 13:32:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA9FE37B401 for ; Thu, 23 Jan 2003 13:32:46 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E79AF43F18 for ; Thu, 23 Jan 2003 13:32:45 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id h0NLWjpQ017884; Thu, 23 Jan 2003 16:32:45 -0500 (EST) Date: Thu, 23 Jan 2003 16:32:44 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: ben@timing.com, freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: <200301232122.h0NLM31e003077@harmony.village.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 Thu, 23 Jan 2003, Warner Losh wrote: > In message Daniel Eischen writes: > : The gcc manpage is wrong. It should state _REENTRANT instead of > : _THREAD_SAFE. POSIX specifies that _REENTRANT be defined to get > : these functions. I know that we always provide implementations > : of most of these _r functions so it might not make sense to > : #ifdef them in the header files, but I don't know that always > : making them visible would be against the spec or cause namespace > : pollution. > > Then FreeBSD's source tree is basically wrong, since it uses > _THREAD_SAFE for this in many places. But most of them appear to be > just defining the macro for compiles and such. There's a little bit > in libc's stdio still, but that's the only significant place that uses > it in the tree. I'm not sure about out-of-tree software. I removed a lot of the _THREAD_SAFE stuff a couple of years ago, but it wasn't complete removed. -stable might be worse off. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 13:41:51 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A9C537B405 for ; Thu, 23 Jan 2003 13:41:49 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3061843EB2 for ; Thu, 23 Jan 2003 13:41:48 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NLflMW036139; Thu, 23 Jan 2003 13:41:47 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NLflSx001267; Thu, 23 Jan 2003 13:41:47 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0NLfljZ001266; Thu, 23 Jan 2003 13:41:47 -0800 (PST) (envelope-from marcel) Date: Thu, 23 Jan 2003 13:41:47 -0800 From: Marcel Moolenaar To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123214147.GA1218@dhcp01.pn.xcllnt.net> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> <20030123075556.A10370@armor.fastether> <20030123071232.GA80532@dhcp01.pn.xcllnt.net> <20030123205808.GA17281@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123205808.GA17281@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.3i 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 Fri, Jan 24, 2003 at 07:58:08AM +1100, Peter Jeremy wrote: > On Wed, Jan 22, 2003 at 11:12:32PM -0800, Marcel Moolenaar wrote: > >On Thu, Jan 23, 2003 at 07:55:56AM +0100, Nicolas Souchu wrote: > >> I agree. But booting a true PCI/AGP (and not ISA) graphic card without > >> the bus stuff initialized seems very hard. > > > >Yes and no. The PCI standard has defined the legacy memory address of > >the frame buffer and the legacy I/O port range for compatibility. I > >expect that we can safely probe that. I don't know how this works in > >non-PCI system though... > > I think this is only true of VGA devices. Yes, true. > Definitely the DEC TGA > does not have any legacy address support - it has to be initialised > as a generic PCI device and then written to using its proprietary > command set. If there's no firmware support for an early console, or even just firmware support for getting the console device addresses, this would mean that you need to have an early bus enumeration phase just to get output devices. I don't know how feasible this would be. See also below. > And based on other comments in this thread, I think > that USB keyboards don't have legacy AT-keyboard support either. Input devices have the advantage that we won't use them before we do bus enumeration, if we exclude the debugger for a moment. I think we can exclude the debugger because we don't have an obligation to support any and all kinds for input devices or necessarily need a "perfect" infrastructure to make it work... For input devices I think it would suffice if we could have zero or more of them attached during bus enumeration. Especially if the keyboard is attached to something non-trivial as USB... > >The approach I took on the ia64 branch is to have a xxx_machdep.c in > >sys/$ARCH/$ARCH for every device xxx that can be a low level console. > > Whilst I don't see any alternative, this is a fairly expensive approach > since the number of MD files starts growing alarmingly as the number of > architectures and console devices increases. (Though it's definitely > better than having lots of MD code buried in supposedly MI files). Agreed. I though about a single con_machdep.c in which you put the MD code for all possible console devices, but it doesn't really fit in well with the way we configure our kernel and the ease with which we can include/exclude source files. It's a possibility though and if we guarantee conditional compilation, a good alternative to avoid a large number of source files. -- 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 Thu Jan 23 13:44:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA1D037B401 for ; Thu, 23 Jan 2003 13:44:46 -0800 (PST) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA03D43ED8 for ; Thu, 23 Jan 2003 13:44:45 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-11-62-147-116-81.dial.proxad.net [62.147.116.81]) by postfix3-1.free.fr (Postfix) with SMTP id DEBB3C085 for ; Thu, 23 Jan 2003 22:44:38 +0100 (CET) Received: (qmail 12233 invoked by uid 1001); 23 Jan 2003 21:58:48 -0000 Date: Thu, 23 Jan 2003 22:58:48 +0100 From: Nicolas Souchu To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123225848.A12164@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030123063040.GA16266@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030123063040.GA16266@cirb503493.alcatel.com.au>; from peterjeremy@optushome.com.au on Thu, Jan 23, 2003 at 05:30:40PM +1100 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 Thu, Jan 23, 2003 at 05:30:40PM +1100, Peter Jeremy wrote: > On Wed, Jan 22, 2003 at 10:36:26PM +0100, Nicolas Souchu wrote: > >On Wed, Jan 22, 2003 at 11:47:46AM +0000, Doug Rabson wrote: > >> The main sticking point for this stuff is that console is needed before > >> the device tree is probed. > > > >The approach of KGI is to provide a very basic/minimal driver for console boot > >that can be overlaped later by fully probed graphic board drivers. This is > >somehow how VGA adapter is organized, with the video_switch used immediatly > >and later the vga_isa.c glue-code for newbus full attachement. [...] > > The existing console code gets around this by being excessively chummy > with the hardware (and I gather KGI works the same way). The downside > is that this is very non-portable - you need separate low-level console > code for each architecture and for each different possible console > device. Depends on what the console code is for you. syscons currently works on TGA Alpha adapters which is totally non ISA/VGA hardware. The hardwired code is part of dev/fb, not dev/syscons. We have to separate console implementation from rendering (fb, fonts) and even video drivers. I have some good understanding of Doug's newbus and newbus is more a driver than a console issue. The fact is that if you want to display the console output, you need some rendering and a graphic/text driver and yes the later makes assumption on the OS bus/io architecture. If you consider PCI, the bus standard is simple and detailed enough to allow any code to browse it, detect some hardware and perform basic I/O to setup a linear framebuffer and set a mode. This is what I would call a minimal/basic driver. Of course, when the OS boots the hardware has to be reprobed and this minimal driver has to be substituted by a soft one using the OS resources/methods. KGI has its own bus abstraction layer (far more simple than FreeBSD one's) that should allow to write simple I/O methods for PCI on different architectures. Extending this bus layer to accept other kind of busses is part of the TODOs... -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 13:50:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F18B37B401 for ; Thu, 23 Jan 2003 13:50:33 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77FFA43ED8 for ; Thu, 23 Jan 2003 13:50:32 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0NLoU1e003401; Thu, 23 Jan 2003 14:50:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 23 Jan 2003 14:49:33 -0700 (MST) Message-Id: <20030123.144933.13389746.imp@bsdimp.com> To: eischen@pcnet1.pcnet.com Cc: ben@timing.com, freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. From: "M. Warner Losh" In-Reply-To: References: <200301232122.h0NLM31e003077@harmony.village.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: Daniel Eischen writes: : On Thu, 23 Jan 2003, Warner Losh wrote: : : > In message Daniel Eischen writes: : > : The gcc manpage is wrong. It should state _REENTRANT instead of : > : _THREAD_SAFE. POSIX specifies that _REENTRANT be defined to get : > : these functions. I know that we always provide implementations : > : of most of these _r functions so it might not make sense to : > : #ifdef them in the header files, but I don't know that always : > : making them visible would be against the spec or cause namespace : > : pollution. : > : > Then FreeBSD's source tree is basically wrong, since it uses : > _THREAD_SAFE for this in many places. But most of them appear to be : > just defining the macro for compiles and such. There's a little bit : > in libc's stdio still, but that's the only significant place that uses : > it in the tree. I'm not sure about out-of-tree software. : : I removed a lot of the _THREAD_SAFE stuff a couple of years ago, : but it wasn't complete removed. -stable might be worse off. In a newish tree it looks like there are only 3 'real' places where we're wrong: find . -type f | xargs egrep _THREAD_SAFE code: ./contrib/ntp/ntpd/refclock_pcf.c:#if defined(_REENTRANT) || defined(_THREAD_SAFE) ./include/rpc/clnt.h:#ifdef _THREAD_SAFE ./include/rpc/clnt.h:#endif /* _THREAD_SAFE */ ./lib/libc_r/sys/uthread_error.c:#ifdef _THREAD_SAFE ./lib/libpthread/sys/thr_error.c:#ifdef _THREAD_SAFE docs or config or false positive: ./contrib/gcc/gcc.1:into user-threaded processes should be compiled with -D_THREAD_SAFE. ./contrib/gcc/gcc.1:-D_THREAD_SAFE. ./contrib/gcc/config/rs6000/aix41.h: %{pthread: -D_THREAD_SAFE}\ ./contrib/gcc/config/rs6000/aix43.h: %{pthread: -D_THREAD_SAFE}\ ./contrib/gcc/config/rs6000/aix43.h: %{pthread: -D_THREAD_SAFE}\ ./contrib/gcc/config/rs6000/aix51.h: %{pthread: -D_THREAD_SAFE}\ ./contrib/gcc/config/rs6000/aix51.h: %{pthread: -D_THREAD_SAFE}\ ./contrib/gcc/gthr-aix.h:#ifdef _THREAD_SAFE ./crypto/heimdal/configure: dpagaix_cflags="-D_THREAD_SAFE -D_AIX_PTHREADS_D7 -D_AIX32_THREADS=1 -D_AES_SOURCE -D_AIX41 -I/usr/include/dce" ./crypto/heimdal/configure.in: dpagaix_cflags="-D_THREAD_SAFE -D_AIX_PTHREADS_D7 -D_AIX32_THREADS=1 -D_AES_SOURCE -D_AIX41 -I/usr/include/dce" ./crypto/openssl/Configure:"FreeBSD-elf", "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall::-pthread -D_REENTRANT -D_THREAD_SAFE -D_THREADSAFE::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", ./crypto/openssl/crypto/rsa/rsa.h:#define RSA_FLAG_THREAD_SAFE 0x10 ./include/unistd.h:#define _POSIX_THREAD_SAFE_FUNCTIONS -1 ./include/unistd.h:#define _SC_THREAD_SAFE_FUNCTIONS 91 /* user */ ./lib/libc/gen/sysconf.c:#if _POSIX_THREAD_SAFE_FUNCTIONS > -1 ./lib/libc/gen/sysconf.c: case _SC_THREAD_SAFE_FUNCTIONS: ./lib/libc/gen/sysconf.c: return (_POSIX_THREAD_SAFE_FUNCTIONS); ./lib/libc_r/Makefile:CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE ./lib/libmilter/Makefile:CFLAGS+=-D_THREAD_SAFE ./lib/libpthread/Makefile:CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE ./usr.bin/getconf/sysconf.gperf:_POSIX_THREAD_SAFE_FUNCTIONS, _SC_THREAD_SAFE_FUNCTIONS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 13:50:37 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC25837B405 for ; Thu, 23 Jan 2003 13:50:33 -0800 (PST) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC26F43F43 for ; Thu, 23 Jan 2003 13:50:32 -0800 (PST) (envelope-from ben@timing.com) Received: from piglet.timing.com (piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.11.3/8.11.3) with ESMTP id h0NLoTH02045; Thu, 23 Jan 2003 14:50:29 -0700 (MST) (envelope-from ben@timing.com) Received: from piglet.timing.com (localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6/8.12.6) with ESMTP id h0NLoTvR038340; Thu, 23 Jan 2003 14:50:29 -0700 (MST) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6/8.12.6/Submit) id h0NLoSwb038337; Thu, 23 Jan 2003 14:50:28 -0700 (MST) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15920.25508.766136.494182@piglet.timing.com> Date: Thu, 23 Jan 2003 14:50:28 -0700 To: Warner Losh Cc: Daniel Eischen , ben@timing.com, freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: <200301232122.h0NLM31e003077@harmony.village.org> References: <200301232122.h0NLM31e003077@harmony.village.org> X-Mailer: VM 7.00 under Emacs 21.2.93.1 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 Warner Losh writes: > In message Daniel Eischen writes: > : The gcc manpage is wrong. It should state _REENTRANT instead of > : _THREAD_SAFE. POSIX specifies that _REENTRANT be defined to get > : these functions. I know that we always provide implementations > : of most of these _r functions so it might not make sense to > : #ifdef them in the header files, but I don't know that always > : making them visible would be against the spec or cause namespace > : pollution. > > Then FreeBSD's source tree is basically wrong, since it uses > _THREAD_SAFE for this in many places. But most of them appear to be > just defining the macro for compiles and such. There's a little bit > in libc's stdio still, but that's the only significant place that uses > it in the tree. I'm not sure about out-of-tree software. Lots of things for various UNIX flavors seem to use _REENTRANT (see contrib & ports for examples). But even so, I disagree that the _r function definitions should only appear in math.h if _REENTRANT is defined. That is, I disagree unless the POSIX specification says otherwise; I've been surprised by it before. I was unaware that POSIX mentioned _REENTRANT. You can call _r functions even if you are not a threaded application. Other _r functions in libc, etc. can be called even if you are not threaded; I don't see why the gamma functions in the math library would be different. Regards, Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 14: 0:46 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8CE337B401 for ; Thu, 23 Jan 2003 14:00:45 -0800 (PST) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FEC643ED8 for ; Thu, 23 Jan 2003 14:00:45 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-11-62-147-116-81.dial.proxad.net [62.147.116.81]) by postfix4-1.free.fr (Postfix) with SMTP id 44B82FB68 for ; Thu, 23 Jan 2003 23:00:43 +0100 (CET) Received: (qmail 12294 invoked by uid 1001); 23 Jan 2003 22:14:57 -0000 Date: Thu, 23 Jan 2003 23:14:57 +0100 From: Nicolas Souchu To: Doug Rabson Cc: Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: Newbusifying kbd? Message-ID: <20030123231457.C12164@armor.fastether> References: <20030119225129.A6948@armor.fastether> <1043324244.28124.34.camel@builder02.qubesoft.com> <20030123194314.GE579@dhcp01.pn.xcllnt.net> <200301232016.50139.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200301232016.50139.dfr@nlsystems.com>; from dfr@nlsystems.com on Thu, Jan 23, 2003 at 08:16:50PM +0000 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 Thu, Jan 23, 2003 at 08:16:50PM +0000, Doug Rabson wrote: [...] > > > > The precondition obviously is that the kernel driver has the same > > HP 2D/3D features as a userland driver. I find it interesting, but > > doubt that it will work in practice. It's hard to write and > > maintain a portable graphics driver that works with dozens of OSes. > > Especially since performance and portability are opposite forces. In that case, this is also the price of security. > > All I'm trying to say is that the XFree86 project and the DRI projects > have already solved the problem of providing reasonable access to 2D > and 3D graphics hardware. There isn't much point in pursuing another > solution that doesn't leverage that work. True, if you only think about using X. If you rather want Qt-embedded+KDE or GGI+Berlin , that's different. -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 14: 4:39 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6F0137B401 for ; Thu, 23 Jan 2003 14:04:37 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 848A343E4A for ; Thu, 23 Jan 2003 14:04:36 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0NM6BY79623; Thu, 23 Jan 2003 17:06:11 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 23 Jan 2003 17:06:11 -0500 From: Bosko Milekic To: Jeff Roberson Cc: arch@freebsd.org Subject: Re: New scheduler Message-ID: <20030123170611.A79549@unixdaemons.com> References: <20030123012620.E46974-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030123012620.E46974-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Thu, Jan 23, 2003 at 01:38:44AM -0500 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 Hey Jeff, First of all, let me say that I think the work you've undertook is superb, given that a re-write of the scheduler is not the easiest thing to do in the world, undertaking the task is pretty courageous. On Thu, Jan 23, 2003 at 01:38:44AM -0500, Jeff Roberson wrote: [...] > make -j4 buildworld on a 2 way Athlon 1800MP with one ata disk. > > new sched: > 1933.193u 1156.398s 56:31.33 91.1% 2628+2106k 18752+4863io 8538pf+0w > old sched: > 2153.557u 1803.705s 48:25.07 136.2% 2462+1925k 17250+4666io 7113pf+0w > > > What you can see here is that the sys time and user time were greatly > reduced. By approx. 35% and 10% respectively. But, since we're not > evenly balancing the load across both cpus the real time suffered. I > don't expect the speedup to be this good once both cpus are well utilized > due to memory bus contention. This is impressive. [...] > You just need one file. It's available at > http://www.chesapeake.net/~jroberson/sched_smp.c > > Cheers, > Jeff OK, after looking over the code, I'm curious: why does everything still seem to be protected by the sched_lock? Can you not now protect the per-CPU runqueues with their own spinlocks? I'm assuming that the primary reason for not switching to the finer grained model is complications related to the sched_lock protecting necessarily unpremptable sections of code elsewhere in the kernel... notably switching to a more finer grained model would involve changes in the context switching code and I think we would have to teach some MD code about the per-CPU runqueues, which would make this less "pluggable" than it was intended, correct? I think that one of the main advantages of this thing is the reduction of the contention on the sched lock. If that can be achieved than scheduling any thread, including interrupt threads, would already be cheaper than it currently is (assuming you could go through a context switch without the global sched_lock, and I don't see why with this code you could not). Finally, I have one question regarding your results. Obviously, 35% and 10% are noteworthy numbers. What do you attribute the speedup to, primarily, given that this is still all under a global sched_lock? Thanks again for all your work. Regards, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 14: 4:43 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1A7737B401 for ; Thu, 23 Jan 2003 14:04:42 -0800 (PST) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DE1943F1E for ; Thu, 23 Jan 2003 14:04:42 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-11-62-147-116-81.dial.proxad.net [62.147.116.81]) by postfix3-2.free.fr (Postfix) with SMTP id 88339C122 for ; Thu, 23 Jan 2003 23:04:40 +0100 (CET) Received: (qmail 12321 invoked by uid 1001); 23 Jan 2003 22:18:55 -0000 Date: Thu, 23 Jan 2003 23:18:55 +0100 From: Nicolas Souchu To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123231855.D12164@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> <20030123075556.A10370@armor.fastether> <20030123071232.GA80532@dhcp01.pn.xcllnt.net> <20030123205808.GA17281@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030123205808.GA17281@cirb503493.alcatel.com.au>; from peterjeremy@optushome.com.au on Fri, Jan 24, 2003 at 07:58:08AM +1100 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 Fri, Jan 24, 2003 at 07:58:08AM +1100, Peter Jeremy wrote: [...] > I think this is only true of VGA devices. Definitely the DEC TGA > does not have any legacy address support - it has to be initialised > as a generic PCI device and then written to using its proprietary > command set. And based on other comments in this thread, I think > that USB keyboards don't have legacy AT-keyboard support either. As far as I could see, ukbd has some compatibility code for AT emulation. -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 14: 5: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED22E37B401 for ; Thu, 23 Jan 2003 14:05:05 -0800 (PST) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40E3043ED8 for ; Thu, 23 Jan 2003 14:05:05 -0800 (PST) (envelope-from ben@timing.com) Received: from piglet.timing.com (piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.11.3/8.11.3) with ESMTP id h0NM53H02277; Thu, 23 Jan 2003 15:05:03 -0700 (MST) (envelope-from ben@timing.com) Received: from piglet.timing.com (localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6/8.12.6) with ESMTP id h0NM53vR040701; Thu, 23 Jan 2003 15:05:03 -0700 (MST) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6/8.12.6/Submit) id h0NM532l040698; Thu, 23 Jan 2003 15:05:03 -0700 (MST) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15920.26383.567651.566335@piglet.timing.com> Date: Thu, 23 Jan 2003 15:05:03 -0700 To: Ben Mesander Cc: Warner Losh , Daniel Eischen , freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: <15920.25508.766136.494182@piglet.timing.com> References: <200301232122.h0NLM31e003077@harmony.village.org> <15920.25508.766136.494182@piglet.timing.com> X-Mailer: VM 7.00 under Emacs 21.2.93.1 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 Ben Mesander writes: > But even so, I disagree that the _r function definitions should only > appear in math.h if _REENTRANT is defined. That is, I disagree unless > the POSIX specification says otherwise; I've been surprised by it > before. I was unaware that POSIX mentioned _REENTRANT. The folks on freebsd-standards said that the defns for the threadsafe gamma funcs should be in the BSD namespace (__BSD_VISIBLE). Regards, Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 14:15: 9 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 295E937B405 for ; Thu, 23 Jan 2003 14:15:06 -0800 (PST) Received: from espresso.q9media.com (espresso.q9media.com [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 624B943ED8 for ; Thu, 23 Jan 2003 14:15:05 -0800 (PST) (envelope-from mike@espresso.q9media.com) Received: by espresso.q9media.com (Postfix, from userid 1002) id 286759C4E; Thu, 23 Jan 2003 17:03:30 -0500 (EST) Date: Thu, 23 Jan 2003 17:03:30 -0500 From: Mike Barcroft To: Ben Mesander Cc: Warner Losh , Daniel Eischen , freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. Message-ID: <20030123170330.A32279@espresso.q9media.com> References: <200301232122.h0NLM31e003077@harmony.village.org> <15920.25508.766136.494182@piglet.timing.com> <15920.26383.567651.566335@piglet.timing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15920.26383.567651.566335@piglet.timing.com>; from ben@timing.com on Thu, Jan 23, 2003 at 03:05:03PM -0700 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 Ben Mesander writes: > Ben Mesander writes: > > But even so, I disagree that the _r function definitions should only > > appear in math.h if _REENTRANT is defined. That is, I disagree unless > > the POSIX specification says otherwise; I've been surprised by it > > before. I was unaware that POSIX mentioned _REENTRANT. > > The folks on freebsd-standards said that the defns for the threadsafe > gamma funcs should be in the BSD namespace (__BSD_VISIBLE). I've only been eyeballing this and the other thread, but I think the conditional we're looking for is: #if defined(__BSD_VISIBLE) || (defined(__POSIX_VISIBLE) && defined(_REENTRANT)) This provides the reentrant functions in the unencumbered (no standard specified) namespace and in the POSIX namespace when requested. 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 Thu Jan 23 14:15:12 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CDAA37B401 for ; Thu, 23 Jan 2003 14:15:11 -0800 (PST) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CF8D43F13 for ; Thu, 23 Jan 2003 14:15:10 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-11-62-147-116-81.dial.proxad.net [62.147.116.81]) by postfix4-2.free.fr (Postfix) with SMTP id 13F8FC0E0 for ; Thu, 23 Jan 2003 23:15:09 +0100 (CET) Received: (qmail 12355 invoked by uid 1001); 23 Jan 2003 22:29:23 -0000 Date: Thu, 23 Jan 2003 23:29:23 +0100 From: Nicolas Souchu To: Marcel Moolenaar Cc: arch@FreeBSD.ORG, Rodolphe Ortalo Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123232923.E12164@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> <20030123075556.A10370@armor.fastether> <20030123071232.GA80532@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030123071232.GA80532@dhcp01.pn.xcllnt.net>; from marcel@xcllnt.net on Wed, Jan 22, 2003 at 11:12:32PM -0800 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, Jan 22, 2003 at 11:12:32PM -0800, Marcel Moolenaar wrote: > > I agree. But booting a true PCI/AGP (and not ISA) graphic card without > > the bus stuff initialized seems very hard. > > Yes and no. The PCI standard has defined the legacy memory address of > the frame buffer and the legacy I/O port range for compatibility. I > expect that we can safely probe that. I don't know how this works in > non-PCI system though... But would you find the same HW on totally different bus architectures? The same graphic chipset that would work with ISA and PCI? No. Thus the bus has not to be too abstracted. I think one should abstract the graphic chipset from *its* bus (PCI in many cases) and that's all. As you say, PCI standard has defined... and I think this definition can be implemented much more simply than FreeBSD does, at least for booting a console. This simple code could be written for different architectures to init the same driver on any arch/OS before the rest of the OS bus abstraction. This is how the vga/tga adapter work (init prior to bus abstraction) but without any bus abstraction. On the other hand KGI provides this abstraction and thus is candidate for early init of complex graphic drivers. -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 14:36:45 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5FCA37B401 for ; Thu, 23 Jan 2003 14:36:43 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AF0943F18 for ; Thu, 23 Jan 2003 14:36:43 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id h0NMagTm025772; Thu, 23 Jan 2003 17:36:42 -0500 (EST) Date: Thu, 23 Jan 2003 17:36:42 -0500 (EST) From: Daniel Eischen To: Ben Mesander Cc: Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: <15920.25508.766136.494182@piglet.timing.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 Thu, 23 Jan 2003, Ben Mesander wrote: > Warner Losh writes: > > In message Daniel Eischen writes: > > : The gcc manpage is wrong. It should state _REENTRANT instead of > > : _THREAD_SAFE. POSIX specifies that _REENTRANT be defined to get > > : these functions. I know that we always provide implementations > > : of most of these _r functions so it might not make sense to > > : #ifdef them in the header files, but I don't know that always > > : making them visible would be against the spec or cause namespace > > : pollution. > > > > Then FreeBSD's source tree is basically wrong, since it uses > > _THREAD_SAFE for this in many places. But most of them appear to be > > just defining the macro for compiles and such. There's a little bit > > in libc's stdio still, but that's the only significant place that uses > > it in the tree. I'm not sure about out-of-tree software. > > Lots of things for various UNIX flavors seem to use _REENTRANT (see > contrib & ports for examples). > > But even so, I disagree that the _r function definitions should only > appear in math.h if _REENTRANT is defined. That is, I disagree unless > the POSIX specification says otherwise; I've been surprised by it > before. I was unaware that POSIX mentioned _REENTRANT. > > You can call _r functions even if you are not a threaded application. Compiling with -D_REENTRANT doesn't mean you have to be a threaded program, nor automatically linked to the threads library :-) > Other _r functions in libc, etc. can be called even if you are not > threaded; I don't see why the gamma functions in the math library would > be different. Here's an excerpt from Solaris 9 : #if defined(__EXTENSIONS__) || !defined(_XOPEN_SOURCE) ... /* * Reentrant version of gamma & lgamma; passes signgam back by reference * as the second argument; user must allocate space for signgam. */ #ifdef _REENTRANT extern double gamma_r __P((double, int *)); extern double lgamma_r __P((double, int *)); #if defined(__MATHERR_ERRNO_DONTCARE) #pragma does_not_read_global_data(gamma_r, lgamma_r) #endif #endif ... #endif /* defined(__EXTENSIONS__) || !defined(_XOPEN_SOURCE) */ -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 14:43: 3 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7F9A37B401 for ; Thu, 23 Jan 2003 14:43:02 -0800 (PST) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id F03F343F13 for ; Thu, 23 Jan 2003 14:43:01 -0800 (PST) (envelope-from ben@timing.com) Received: from piglet.timing.com (piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.11.3/8.11.3) with ESMTP id h0NMh0H02672; Thu, 23 Jan 2003 15:43:00 -0700 (MST) (envelope-from ben@timing.com) Received: from piglet.timing.com (localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6/8.12.6) with ESMTP id h0NMh0vR042158; Thu, 23 Jan 2003 15:43:00 -0700 (MST) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6/8.12.6/Submit) id h0NMgxGa042155; Thu, 23 Jan 2003 15:42:59 -0700 (MST) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15920.28659.884511.537371@piglet.timing.com> Date: Thu, 23 Jan 2003 15:42:59 -0700 To: Daniel Eischen Cc: Ben Mesander , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: References: <15920.25508.766136.494182@piglet.timing.com> X-Mailer: VM 7.00 under Emacs 21.2.93.1 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 writes: > Compiling with -D_REENTRANT doesn't mean you have to be a > threaded program, nor automatically linked to the threads > library :-) Well, fair enough. And you're right, solaris (which is where msun came from a long time ago) still has the _REENTRANT. I should have looked at some of the solaris machines I have accounts on. Does the conditional that Mike Barcroft suggested: #if defined(__BSD_VISIBLE) || (defined(__POSIX_VISIBLE) && defined(_REENTRANT)) Seem reasonable to you? Regards, Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 14:57:51 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FC9737B401 for ; Thu, 23 Jan 2003 14:57:49 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35CF643F3F for ; Thu, 23 Jan 2003 14:57:48 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NMvjMW036532; Thu, 23 Jan 2003 14:57:45 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NMvjSx034050; Thu, 23 Jan 2003 14:57:45 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0NMvjrZ034049; Thu, 23 Jan 2003 14:57:45 -0800 (PST) (envelope-from marcel) Date: Thu, 23 Jan 2003 14:57:45 -0800 From: Marcel Moolenaar To: Nicolas Souchu Cc: arch@FreeBSD.ORG, Rodolphe Ortalo Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123225745.GB5741@dhcp01.pn.xcllnt.net> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> <20030123075556.A10370@armor.fastether> <20030123071232.GA80532@dhcp01.pn.xcllnt.net> <20030123232923.E12164@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123232923.E12164@armor.fastether> User-Agent: Mutt/1.5.3i 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 Thu, Jan 23, 2003 at 11:29:23PM +0100, Nicolas Souchu wrote: > On Wed, Jan 22, 2003 at 11:12:32PM -0800, Marcel Moolenaar wrote: > > > I agree. But booting a true PCI/AGP (and not ISA) graphic card without > > > the bus stuff initialized seems very hard. > > > > Yes and no. The PCI standard has defined the legacy memory address of > > the frame buffer and the legacy I/O port range for compatibility. I > > expect that we can safely probe that. I don't know how this works in > > non-PCI system though... > > But would you find the same HW on totally different bus architectures? The > same graphic chipset that would work with ISA and PCI? No. Not necessarily in the same way. This makes early console probing a platform dependent operation. On PCs or PCI-based systems, you should be able to test for the presence of VGA that way. On non- PCI non-PC systems (that possibly also don't use VGA by default), other methods have to be found/implemented. > Thus the bus has not to be > too abstracted. I think one should abstract the graphic chipset from > *its* bus (PCI in many cases) and that's all. The MI code should have complete bus-abstraction by default. MD code should be used when platform-specific knowledge has to be used. > As you say, PCI standard has defined... and I think this definition can be > implemented much more simply than FreeBSD does, at least for booting a > console. On i386, yes. Note that even though i386 and ia64 have VGA by default now, already new (is it new?) graphics standards are being created. For example the Universal Graphics Adapter (UGA): http://www.microsoft.com/hwdev/tech/display/uga/default.asp I'm not saying that UGA is the light we've been searching for all these years, but the signal is clear: We should not assume a single graphics standard, like VGA, if we want to rework our console. > This simple code could be written for different architectures to > init the same driver on any arch/OS before the rest of the OS bus > abstraction. Roughly, yes. It may not be trivial in all cases, but this is what it boils down to. -- 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 Thu Jan 23 15:16:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A102037B401 for ; Thu, 23 Jan 2003 15:16:23 -0800 (PST) Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F7C843EB2 for ; Thu, 23 Jan 2003 15:16:22 -0800 (PST) (envelope-from ortalo@laas.fr) Received: by laas.laas.fr (8.12.7/8.12.7) with ESMTP id h0NNGE0j026837; Fri, 24 Jan 2003 00:16:15 +0100 (CET) Date: Thu, 23 Jan 2003 23:53:55 +0100 (CET) From: Rodolphe Ortalo To: Marcel Moolenaar Cc: Nicolas Souchu , arch@freebsd.org, Rodolphe Ortalo Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) In-Reply-To: <20030123071232.GA80532@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / 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 On Wed, 22 Jan 2003, Marcel Moolenaar wrote: > On Thu, Jan 23, 2003 at 07:55:56AM +0100, Nicolas Souchu wrote: > > > > The approach of KGI is to provide a very basic/minimal driver for console boot > > > > that can be overlaped later by fully probed graphic board drivers. This is > > > > somehow how VGA adapter is organized, with the video_switch used immediatly > > > > and later the vga_isa.c glue-code for newbus full attachement. > > > > > > This is what makes it non-portable and why we have problems getting > > > it to work in non-PC, non-ISA environments. > > > > Not because of a minimal driver, but because syscons and even more pcvt > > make assumptions on the features provided by the driver (font, text modes...) > > Ok. I didn't look at that specific part of the problem space. I mostly > worry about the use of memory addresses and I/O ports that are specific > to a platform or configuration and thus non-portable. Indeed, I think that the VGA boot driver of KGI is really VGA-specific (maybe i386-specific then in fact). On a Sun for example, I guess a boot driver using the open firmware should be needed. > > > Booting a notebook in text mode looks ugly and I can imagine that > > > early boot environments can be graphical as well. I prefer not to > > > fixate on text-only video modes for the low-level console, even > > > though we probably won't use it for anything but text. > > > > I agree. But booting a true PCI/AGP (and not ISA) graphic card without > > the bus stuff initialized seems very hard. > > Yes and no. The PCI standard has defined the legacy memory address of > the frame buffer and the legacy I/O port range for compatibility. I > expect that we can safely probe that. I don't know how this works in > non-PCI system though... > > The approach I took on the ia64 branch is to have a xxx_machdep.c in > sys/$ARCH/$ARCH for every device xxx that can be a low level console. > In the file xxx_machdep.c you do whatever MD specific thing you need > to do to construct a tag and handle for use by the MI code for device > xxx. When bus enumeration happens, you compare the tag and handle of > the low-level console with the tag and handle of the device that's > being probed if you want to know if the device that's being probed is > the console or not (you don't want to reset the device if it's the > console for example). Why do you want to take so much care wrt the initial boot device? If you want to preserve the console display across the switch to a new display driver isn't it possible to do this at a higher level? E.g.: save the console output somewhere, close() the boot driver, open the new driver(), set an adequate text (or text-on-graphic) mode, restore the console output, and then proceed. Are there other reasons that motivated a more careful approach? Rodolphe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 15:19:46 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0473237B405 for ; Thu, 23 Jan 2003 15:19:44 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4613E43ED8 for ; Thu, 23 Jan 2003 15:19:43 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0NNJd260537; Thu, 23 Jan 2003 18:19:39 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 23 Jan 2003 18:19:39 -0500 (EST) From: Jeff Roberson To: Bosko Milekic Cc: arch@FreeBSD.ORG Subject: Re: New scheduler In-Reply-To: <20030123170611.A79549@unixdaemons.com> Message-ID: <20030123181343.E2966-100000@mail.chesapeake.net> 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 Thu, 23 Jan 2003, Bosko Milekic wrote: B> > Hey Jeff, > > First of all, let me say that I think the work you've undertook is > superb, given that a re-write of the scheduler is not the easiest > thing to do in the world, undertaking the task is pretty courageous. > Thanks! :-) > On Thu, Jan 23, 2003 at 01:38:44AM -0500, Jeff Roberson wrote: > [...] > > make -j4 buildworld on a 2 way Athlon 1800MP with one ata disk. > > > > new sched: > > 1933.193u 1156.398s 56:31.33 91.1% 2628+2106k 18752+4863io 8538pf+0w > > old sched: > > 2153.557u 1803.705s 48:25.07 136.2% 2462+1925k 17250+4666io 7113pf+0w > > > > > > What you can see here is that the sys time and user time were greatly > > reduced. By approx. 35% and 10% respectively. But, since we're not > > evenly balancing the load across both cpus the real time suffered. I > > don't expect the speedup to be this good once both cpus are well utilized > > due to memory bus contention. > > This is impressive. Yeah, hopefully the speedup stays after the cpus are well balanced. > > [...] > > You just need one file. It's available at > > http://www.chesapeake.net/~jroberson/sched_smp.c > > > > Cheers, > > Jeff > > OK, after looking over the code, I'm curious: why does everything > still seem to be protected by the sched_lock? Can you not now protect > the per-CPU runqueues with their own spinlocks? I'm assuming that the > primary reason for not switching to the finer grained model is > complications related to the sched_lock protecting necessarily > unpremptable sections of code elsewhere in the kernel... notably > switching to a more finer grained model would involve changes in the > context switching code and I think we would have to teach some MD code > about the per-CPU runqueues, which would make this less "pluggable" than > it was intended, correct? stand -> walk -> run :-) I didn't want to make it any more invasive than it currently is as that would require either desupporting the current scheduler, or using it only on UP. Also, it's a lot of extra effort and a lot of extra bugs. I doubt there is much sched lock contention today. > > I think that one of the main advantages of this thing is the reduction > of the contention on the sched lock. If that can be achieved than > scheduling any thread, including interrupt threads, would already be > cheaper than it currently is (assuming you could go through a context > switch without the global sched_lock, and I don't see why with this > code you could not). I'd like to reeorg the mi_switch/cpu_switch path. I'd like do pick the new thread in mi_switch and hand it off to cpu_switch instead of calling back into sched_choose(). This will make all of this slightly cleaner. > > Finally, I have one question regarding your results. Obviously, 35% > and 10% are noteworthy numbers. What do you attribute the speedup to, > primarily, given that this is still all under a global sched_lock? > > Thanks again for all your work. > There are a few factors. Most notably the cpu affinity. The caches are trashing so much on SMP with the old scheduler that it's actually slower than UP in some cases. Also, since the balancing is currently pooched the memory bus is contended for less. So the 35% will probably get a bit smaller, but hopefully the real time will too. The new scheduler is also algorithmically cheaper. 10 times a second schedcpu() would run on the old scheduler and pollute your cache. With lots of processes this code could take a while too. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 15:31: 9 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C28F837B401 for ; Thu, 23 Jan 2003 15:31:08 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29FDC43EB2 for ; Thu, 23 Jan 2003 15:31:08 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id h0NNV7gn002213; Thu, 23 Jan 2003 18:31:07 -0500 (EST) Date: Thu, 23 Jan 2003 18:31:07 -0500 (EST) From: Daniel Eischen To: Ben Mesander Cc: Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: <15920.28659.884511.537371@piglet.timing.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 Thu, 23 Jan 2003, Ben Mesander wrote: > Daniel Eischen writes: > > Compiling with -D_REENTRANT doesn't mean you have to be a > > threaded program, nor automatically linked to the threads > > library :-) > > Well, fair enough. And you're right, solaris (which is where msun came > from a long time ago) still has the _REENTRANT. I should have looked at > some of the solaris machines I have accounts on. > > Does the conditional that Mike Barcroft suggested: > > #if defined(__BSD_VISIBLE) || (defined(__POSIX_VISIBLE) && defined(_REENTRANT)) > > Seem reasonable to you? I don't have a problem with it, but I'll leave it to the -standards guys to decide. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 15:44:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F99837B405 for ; Thu, 23 Jan 2003 15:44:35 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BE7843F13 for ; Thu, 23 Jan 2003 15:44:34 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NNiVMW036739; Thu, 23 Jan 2003 15:44:31 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NNiVwR000658; Thu, 23 Jan 2003 15:44:31 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0NNiVnT000657; Thu, 23 Jan 2003 15:44:31 -0800 (PST) Date: Thu, 23 Jan 2003 15:44:31 -0800 From: Marcel Moolenaar To: Rodolphe Ortalo Cc: Nicolas Souchu , arch@freebsd.org Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123234431.GB555@athlon.pn.xcllnt.net> References: <20030123071232.GA80532@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i 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 Thu, Jan 23, 2003 at 11:53:55PM +0100, Rodolphe Ortalo wrote: > > > The approach I took on the ia64 branch is to have a xxx_machdep.c in > > sys/$ARCH/$ARCH for every device xxx that can be a low level console. > > In the file xxx_machdep.c you do whatever MD specific thing you need > > to do to construct a tag and handle for use by the MI code for device > > xxx. When bus enumeration happens, you compare the tag and handle of > > the low-level console with the tag and handle of the device that's > > being probed if you want to know if the device that's being probed is > > the console or not (you don't want to reset the device if it's the > > console for example). > > Why do you want to take so much care wrt the initial boot device? > If you want to preserve the console display across the switch to a new > display driver isn't it possible to do this at a higher level? E.g.: save > the console output somewhere, close() the boot driver, open the new > driver(), set an adequate text (or text-on-graphic) mode, restore the > console output, and then proceed. > Are there other reasons that motivated a more careful approach? Not all low-level consoles are (graphical) display adapters. If the low-level console is a serial interface, you need to preserve the communication settings. In general though I like to take the approach that the low-level console has done some work, possibly non-trivial, to get the state/information it currently has and it seems wasteful to destroy that state simply because we run into that device during bus enumeration and we then have the resources available to use the device to its fullest potential, but end up not doing that. So, unless there's a good reason not to, preserving state can only proof beneficial. I realize it's mostly subjective. I think you should have the mechanism to allow preserving state, so that you have the freedom to make use of it or not... -- 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 Thu Jan 23 16: 5:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5BEB37B401 for ; Thu, 23 Jan 2003 16:05:35 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B77F43E4A for ; Thu, 23 Jan 2003 16:05:35 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0O076N79959; Thu, 23 Jan 2003 19:07:06 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 23 Jan 2003 19:07:06 -0500 From: Bosko Milekic To: Jeff Roberson Cc: arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030123190706.A79935@unixdaemons.com> References: <20030123170611.A79549@unixdaemons.com> <20030123181343.E2966-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030123181343.E2966-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Thu, Jan 23, 2003 at 06:19:39PM -0500 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 Thu, Jan 23, 2003 at 06:19:39PM -0500, Jeff Roberson wrote: [...] > > OK, after looking over the code, I'm curious: why does everything > > still seem to be protected by the sched_lock? Can you not now protect > > the per-CPU runqueues with their own spinlocks? I'm assuming that the > > primary reason for not switching to the finer grained model is > > complications related to the sched_lock protecting necessarily > > unpremptable sections of code elsewhere in the kernel... notably > > switching to a more finer grained model would involve changes in the > > context switching code and I think we would have to teach some MD code > > about the per-CPU runqueues, which would make this less "pluggable" than > > it was intended, correct? > > stand -> walk -> run :-) I didn't want to make it any more invasive than > it currently is as that would require either desupporting the current > scheduler, or using it only on UP. Also, it's a lot of extra effort and a > lot of extra bugs. I doubt there is much sched lock contention today. Oh, that makes sense. I just wanted to make sure that the possibility existed to move this way at some point in the time to come, assuming that the additional complexity (if any) is not too costly when compared to the [measured] performance gains (again, if they are measurable, and I am sure they will be - the same cache locality arguments you apply below undoubtedly also apply to splitting a global lock into per-CPU locks). > > I think that one of the main advantages of this thing is the reduction > > of the contention on the sched lock. If that can be achieved than > > scheduling any thread, including interrupt threads, would already be > > cheaper than it currently is (assuming you could go through a context > > switch without the global sched_lock, and I don't see why with this > > code you could not). > > I'd like to reeorg the mi_switch/cpu_switch path. I'd like do pick the > new thread in mi_switch and hand it off to cpu_switch instead of calling > back into sched_choose(). This will make all of this slightly cleaner. Good idea. This would make other things easier to implement, too (including lightweight interrupt threads, should we decide to persue that at some point again). > > Finally, I have one question regarding your results. Obviously, 35% > > and 10% are noteworthy numbers. What do you attribute the speedup to, > > primarily, given that this is still all under a global sched_lock? > > > > Thanks again for all your work. > > > > There are a few factors. Most notably the cpu affinity. The caches are > trashing so much on SMP with the old scheduler that it's actually slower > than UP in some cases. Also, since the balancing is currently pooched the > memory bus is contended for less. So the 35% will probably get a bit > smaller, but hopefully the real time will too. > > The new scheduler is also algorithmically cheaper. 10 times a second > schedcpu() would run on the old scheduler and pollute your cache. With > lots of processes this code could take a while too. Both of these are what I was looking for, thanks. I totally believe the cache locality argument, especially given that the slight performance improvements I've seen when doing mb_alloc were also attributed to that. > Cheers, > Jeff Regards, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 16:52:45 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E55CD37B401 for ; Thu, 23 Jan 2003 16:52:42 -0800 (PST) Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CAA443ED8 for ; Thu, 23 Jan 2003 16:52:40 -0800 (PST) (envelope-from fjoe@iclub.nsu.ru) Received: from drweb by mail.nsu.ru with drweb-scanned (Exim 3.20 #1) id 18bs4z-0006jn-00; Fri, 24 Jan 2003 06:52:21 +0600 Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 18bs4y-0006jO-00; Fri, 24 Jan 2003 06:52:20 +0600 Received: from iclub.nsu.ru (fjoe@localhost [127.0.0.1]) by iclub.nsu.ru (8.12.6/8.12.6) with ESMTP id h0O0qCRV044707; Fri, 24 Jan 2003 06:52:12 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.12.6/8.12.6/Submit) id h0O0qA3v044706; Fri, 24 Jan 2003 06:52:10 +0600 (NS) Date: Fri, 24 Jan 2003 06:52:10 +0600 From: Max Khon To: "M. Warner Losh" Cc: eischen@pcnet1.pcnet.com, ben@timing.com, freebsd-arch@freebsd.org Subject: Re: _REENTRANT in math.h & libm oddities. Message-ID: <20030124065210.B44070@iclub.nsu.ru> References: <200301232122.h0NLM31e003077@harmony.village.org> <20030123.144933.13389746.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030123.144933.13389746.imp@bsdimp.com>; from imp@bsdimp.com on Thu, Jan 23, 2003 at 02:49:33PM -0700 X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, SUPERLONG_LINE,UPPERCASE_25_50,USER_AGENT,USER_AGENT_MUTT version=2.43 X-Envelope-To: imp@bsdimp.com, eischen@pcnet1.pcnet.com, ben@timing.com, freebsd-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 hi, there! On Thu, Jan 23, 2003 at 02:49:33PM -0700, M. Warner Losh wrote: > : I removed a lot of the _THREAD_SAFE stuff a couple of years ago, > : but it wasn't complete removed. -stable might be worse off. > > In a newish tree it looks like there are only 3 'real' places where > we're wrong: > > find . -type f | xargs egrep _THREAD_SAFE > > code: > > ./contrib/ntp/ntpd/refclock_pcf.c:#if defined(_REENTRANT) || defined(_THREAD_SAFE) this is contrib > ./include/rpc/clnt.h:#ifdef _THREAD_SAFE > ./include/rpc/clnt.h:#endif /* _THREAD_SAFE */ this should be removed (only _THREAD_SAFE should be left) I'll take care if there will be no objections > ./lib/libc_r/sys/uthread_error.c:#ifdef _THREAD_SAFE > ./lib/libpthread/sys/thr_error.c:#ifdef _THREAD_SAFE > ./lib/libc_r/Makefile:CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE > ./lib/libmilter/Makefile:CFLAGS+=-D_THREAD_SAFE > ./lib/libpthread/Makefile:CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE this can be safely removed I'll take care if there will be no objections > docs or config or false positive: > > ./contrib/gcc/gcc.1:into user-threaded processes should be compiled with -D_THREAD_SAFE. > ./contrib/gcc/gcc.1:-D_THREAD_SAFE. not sure about this. also -kthread statement should be removed this is contrib anyway > ./contrib/gcc/config/rs6000/aix41.h: %{pthread: -D_THREAD_SAFE}\ > ./contrib/gcc/config/rs6000/aix43.h: %{pthread: -D_THREAD_SAFE}\ > ./contrib/gcc/config/rs6000/aix43.h: %{pthread: -D_THREAD_SAFE}\ > ./contrib/gcc/config/rs6000/aix51.h: %{pthread: -D_THREAD_SAFE}\ > ./contrib/gcc/config/rs6000/aix51.h: %{pthread: -D_THREAD_SAFE}\ > ./contrib/gcc/gthr-aix.h:#ifdef _THREAD_SAFE > ./crypto/heimdal/configure: dpagaix_cflags="-D_THREAD_SAFE -D_AIX_PTHREADS_D7 -D_AIX32_THREADS=1 -D_AES_SOURCE -D_AIX41 -I/usr/include/dce" > ./crypto/heimdal/configure.in: dpagaix_cflags="-D_THREAD_SAFE -D_AIX_PTHREADS_D7 -D_AIX32_THREADS=1 -D_AES_SOURCE -D_AIX41 -I/usr/include/dce" these are not related to FreeBSD > ./crypto/openssl/Configure:"FreeBSD-elf", "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall::-pthread -D_REENTRANT -D_THREAD_SAFE -D_THREADSAFE::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", this is contrib > ./crypto/openssl/crypto/rsa/rsa.h:#define RSA_FLAG_THREAD_SAFE 0x10 > ./include/unistd.h:#define _POSIX_THREAD_SAFE_FUNCTIONS -1 > ./include/unistd.h:#define _SC_THREAD_SAFE_FUNCTIONS 91 /* user */ > ./lib/libc/gen/sysconf.c:#if _POSIX_THREAD_SAFE_FUNCTIONS > -1 > ./lib/libc/gen/sysconf.c: case _SC_THREAD_SAFE_FUNCTIONS: > ./lib/libc/gen/sysconf.c: return (_POSIX_THREAD_SAFE_FUNCTIONS); > ./usr.bin/getconf/sysconf.gperf:_POSIX_THREAD_SAFE_FUNCTIONS, _SC_THREAD_SAFE_FUNCTIONS these are not "_THREAD_SAFE" (you could use '\<_THREAD_SAFE\>' pattern) /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 16:58:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 068C637B401 for ; Thu, 23 Jan 2003 16:58:34 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 548B543ED8 for ; Thu, 23 Jan 2003 16:58:33 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h0O0wVbs052923 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 23 Jan 2003 19:58:32 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.6/8.12.6/Submit) id h0O0wVt3052922; Thu, 23 Jan 2003 19:58:31 -0500 (EST) (envelope-from wollman) Date: Thu, 23 Jan 2003 19:58:31 -0500 (EST) From: Garrett Wollman Message-Id: <200301240058.h0O0wVt3052922@khavrinen.lcs.mit.edu> To: eischen@pcnet1.pcnet.com Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: References: <20030123.101335.95024590.imp@bsdimp.com> Organization: MIT Laboratory for Computer Science 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 In article you write: >The gcc manpage is wrong. It should state _REENTRANT instead of >_THREAD_SAFE. POSIX specifies that _REENTRANT be defined to get >these functions. Obsolete versions of POSIX might say that. The current version of POSIX says nothing of the kind: it says that functions of that sort *shall be declared*, unconditionally. As I noted elsewhere, the functions in question (lgamma_r() etc.) are not standard functions at all and POSIX doesn't give a whoop about when they are declared, provided that they are NOT declared when _POSIX_C_SOURCE == 200112L. -GAWollman -- Garrett A. Wollman | [G]enes make enzymes, and enzymes control the rates of wollman@lcs.mit.edu | chemical processes. Genes do not make ``novelty- Opinions not those of| seeking'' or any other complex and overt behavior. MIT, LCS, CRS, or NSA| - Stephen Jay Gould (1941-2002) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 17: 3:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A4E537B401 for ; Thu, 23 Jan 2003 17:03:48 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A15B143F13 for ; Thu, 23 Jan 2003 17:03:47 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id h0O13cxg012893; Thu, 23 Jan 2003 20:03:38 -0500 (EST) Date: Thu, 23 Jan 2003 20:03:37 -0500 (EST) From: Daniel Eischen To: Max Khon Cc: "M. Warner Losh" , ben@timing.com, freebsd-arch@freebsd.org Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: <20030124065210.B44070@iclub.nsu.ru> 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 Fri, 24 Jan 2003, Max Khon wrote: > hi, there! > > On Thu, Jan 23, 2003 at 02:49:33PM -0700, M. Warner Losh wrote: > > > : I removed a lot of the _THREAD_SAFE stuff a couple of years ago, > > : but it wasn't complete removed. -stable might be worse off. > > > > In a newish tree it looks like there are only 3 'real' places where > > we're wrong: > > > > find . -type f | xargs egrep _THREAD_SAFE > > > > code: > > > > ./contrib/ntp/ntpd/refclock_pcf.c:#if defined(_REENTRANT) || defined(_THREAD_SAFE) > > this is contrib > > > ./include/rpc/clnt.h:#ifdef _THREAD_SAFE > > ./include/rpc/clnt.h:#endif /* _THREAD_SAFE */ > > this should be removed (only _THREAD_SAFE should be left) > I'll take care if there will be no objections > > > ./lib/libc_r/sys/uthread_error.c:#ifdef _THREAD_SAFE > > ./lib/libpthread/sys/thr_error.c:#ifdef _THREAD_SAFE > > ./lib/libc_r/Makefile:CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE > > ./lib/libmilter/Makefile:CFLAGS+=-D_THREAD_SAFE > > ./lib/libpthread/Makefile:CFLAGS+=-DPTHREAD_KERNEL -D_THREAD_SAFE > > this can be safely removed > I'll take care if there will be no objections Knock yourself out (proceed) :-) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 18:10: 2 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACF1F37B401; Thu, 23 Jan 2003 18:10:00 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 296EA43EB2; Thu, 23 Jan 2003 18:10:00 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0463.cvx22-bradley.dialup.earthlink.net ([209.179.199.208] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18btHu-00046q-00; Thu, 23 Jan 2003 18:09:47 -0800 Message-ID: <3E309FE5.F74564DC@mindspring.com> Date: Thu, 23 Jan 2003 18:07:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Rabson Cc: John Baldwin , arch@FreeBSD.org, Andrew Gallatin Subject: Re: M_ flags summary. References: <1043339738.29341.1.camel@builder02.qubesoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ac06470c581d13d67968bfa9f4b6c0d5a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c 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 Doug Rabson wrote: > On Thu, 2003-01-23 at 15:39, John Baldwin wrote: > > This would prevent the malloc implementation from using internal mutexes > > that it msleep's or cv_wait's on. You only get to pass in one mutex > > to cv_wait* and msleep. > > That did occur to me too, which was why I wrote "or something". It looks > hard to DTRT here without a version of msleep which took a list of > mutexes to release. The hard part here is that this is almost entirely useless for most FS directory operations, which must hold both the mutex for the parent directory, and the mutex for the object being manipulated, plus potentially other mutexes (e.g. rename), etc.. There are other places where this is true, too. > > In my experience, one can often "fix" problems > > with holding locks across malloc() by malloc()'ing things earlier in the > > function before you need locks. > > This is obviously preferable. This is preferrable for *most* cases. For cases where a failure of an operation to complete immediately results in the operation being queued, which requires an allocation, then you are doing a preallocation for the failure code path. Doing a preallocation that way is incredibly expensive. If on the other hand, you are doing the allocation on the assumption of success, then it's "free". The real question is whether or not the allocation is in the common or uncommon code path. The easy way to mitigate the issue here is to maintain an object free list, and use that, instead of the allocator. Of course, if you do that, you can often avoid holding a mutex altogether. And if the code tolerates a failure to allocate reasonably well, you can signal a "need to refill free list", and not hold a mutex over an allocation at all. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 18:26:15 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1756B37B401; Thu, 23 Jan 2003 18:26:13 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40C5D43F18; Thu, 23 Jan 2003 18:26:12 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0O2RME80438; Thu, 23 Jan 2003 21:27:22 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 23 Jan 2003 21:27:22 -0500 From: Bosko Milekic To: Terry Lambert Cc: Doug Rabson , John Baldwin , arch@FreeBSD.org, Andrew Gallatin Subject: Re: M_ flags summary. Message-ID: <20030123212722.A80406@unixdaemons.com> References: <1043339738.29341.1.camel@builder02.qubesoft.com> <3E309FE5.F74564DC@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E309FE5.F74564DC@mindspring.com>; from tlambert2@mindspring.com on Thu, Jan 23, 2003 at 06:07:33PM -0800 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 Thu, Jan 23, 2003 at 06:07:33PM -0800, Terry Lambert wrote: > Doug Rabson wrote: > > On Thu, 2003-01-23 at 15:39, John Baldwin wrote: > > > This would prevent the malloc implementation from using internal mutexes > > > that it msleep's or cv_wait's on. You only get to pass in one mutex > > > to cv_wait* and msleep. > > > > That did occur to me too, which was why I wrote "or something". It looks > > hard to DTRT here without a version of msleep which took a list of > > mutexes to release. > > The hard part here is that this is almost entirely useless for > most FS directory operations, which must hold both the mutex for > the parent directory, and the mutex for the object being > manipulated, plus potentially other mutexes (e.g. rename), etc.. > There are other places where this is true, too. Exactly. > > > In my experience, one can often "fix" problems > > > with holding locks across malloc() by malloc()'ing things earlier in the > > > function before you need locks. > > > > This is obviously preferable. > > This is preferrable for *most* cases. For cases where a failure > of an operation to complete immediately results in the operation > being queued, which requires an allocation, then you are doing a > preallocation for the failure code path. Doing a preallocation > that way is incredibly expensive. If on the other hand, you are > doing the allocation on the assumption of success, then it's > "free". The real question is whether or not the allocation is in > the common or uncommon code path. In that case you shouldn't be holding the lock protecting the queue before actually detecting the failure. Once you detect the failure, then you allocate your resource, _then_ you grab the queue lock, _then_ you queue the operation. This works unless you left out some of the detail from your example. The point is that I'm sure that a reasonable solution exists for each scenario, unless the design is wrong to begin with... but I'm willing to accept that my intuition has misled me. > The easy way to mitigate the issue here is to maintain an object > free list, and use that, instead of the allocator. Of course, if > you do that, you can often avoid holding a mutex altogether. And > if the code tolerates a failure to allocate reasonably well, you > can signal a "need to refill free list", and not hold a mutex over > an allocation at all. Although clever, this is somewhat bogus behavior w.r.t. the allocator. Remember that the allocator already keeps a cache but if you instead start maintaining your own (lock-free) cache, yes, maybe you're improving local performance but, overall, you're doing what the allocator should be doing anyway and, in some cases, this hampers the allocator's ability to manage the resources it is responsible for. But I'm sure you know this because, yes, you are technically correct. > -- Terry In any case, it's good that we're discussing general solution possibilities for these sorts of problems but I think that we agree that they are rather special exception situations that, given good thought and MP-oriented design, can be avoided. And that's what I think the allocator API should encourage: good design. By specifying the wait-case as the default behavior, the allocator API is effectively encouraging all non-ISR code to be prepared to wait, for whatever amount of time (the actual amount of time is irrelevant in making my point). Regards, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 19:13:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06AAB37B401; Thu, 23 Jan 2003 19:13:32 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51C8843F43; Thu, 23 Jan 2003 19:13:31 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0463.cvx22-bradley.dialup.earthlink.net ([209.179.199.208] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18buHM-0004nK-00; Thu, 23 Jan 2003 19:13:17 -0800 Message-ID: <3E30AEF6.FD18CF37@mindspring.com> Date: Thu, 23 Jan 2003 19:11:50 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: Doug Rabson , John Baldwin , arch@FreeBSD.org, Andrew Gallatin Subject: Re: M_ flags summary. References: <1043339738.29341.1.camel@builder02.qubesoft.com> <3E309FE5.F74564DC@mindspring.com> <20030123212722.A80406@unixdaemons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a499b4237ee4ee977d4c2efb242358239593caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c 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 Bosko Milekic wrote: > On Thu, Jan 23, 2003 at 06:07:33PM -0800, Terry Lambert wrote: > > This is preferrable for *most* cases. For cases where a failure > > of an operation to complete immediately results in the operation > > being queued, which requires an allocation, then you are doing a > > preallocation for the failure code path. Doing a preallocation > > that way is incredibly expensive. If on the other hand, you are > > doing the allocation on the assumption of success, then it's > > "free". The real question is whether or not the allocation is in > > the common or uncommon code path. > > In that case you shouldn't be holding the lock protecting the queue > before actually detecting the failure. Once you detect the failure, > then you allocate your resource, _then_ you grab the queue lock, > _then_ you queue the operation. This works unless you left out some > of the detail from your example. The point is that I'm sure that a > reasonable solution exists for each scenario, unless the design is > wrong to begin with... but I'm willing to accept that my intuition has > misled me. Sorry, I thought the problem was obvious: by doing this, you invert the lock order that you would normally use for a free, if you are locking one or more other things, at the time. The most common case for this inversion would be "fork", or any other place that has to punch the scheduler. But it's also in pretty much every place you would do a kevent, as well as in the network stacks, where copies or pullups happen. Basically, you can't delay holding the lock, but you can accellerate it (ie. doing it early means an extra free in the failure case -- if it means it in the success case, you are pessimizing the heck out of something you shouldn't be). Otherwise, you would have to tolerate "LOCK MALLOC; LOCK XXX" on malloc and "LOCK XXX; LOCK MALLOC" on frees. > > The easy way to mitigate the issue here is to maintain an object > > free list, and use that, instead of the allocator. Of course, if > > you do that, you can often avoid holding a mutex altogether. And > > if the code tolerates a failure to allocate reasonably well, you > > can signal a "need to refill free list", and not hold a mutex over > > an allocation at all. > > Although clever, this is somewhat bogus behavior w.r.t. the allocator. > Remember that the allocator already keeps a cache but if you instead > start maintaining your own (lock-free) cache, yes, maybe you're > improving local performance but, overall, you're doing what the > allocator should be doing anyway and, in some cases, this hampers the > allocator's ability to manage the resources it is responsible for. > But I'm sure you know this because, yes, you are technically correct. IMO, the allocator should really do this on your behalf, under the covers. One of the things that UnixWare (SVR4.2) did internally was to preallocate a pool of buffers for use by network drivers, to avoid having to do allocations at interrupt time, and then refill the pool, as necessary, in the top en of the drivers. So while clever, I can't claim that it's original. 8-). > In any case, it's good that we're discussing general solution > possibilities for these sorts of problems but I think that we agree > that they are rather special exception situations that, given good > thought and MP-oriented design, can be avoided. And that's what I > think the allocator API should encourage: good design. By specifying > the wait-case as the default behavior, the allocator API is > effectively encouraging all non-ISR code to be prepared to wait, for > whatever amount of time (the actual amount of time is irrelevant in > making my point). This contradicts bot Jeffrey's and Warner's points, though, and I think their points were valid. The problem that Jeffrey wants addressed is the problem of magic numbers; I almost made this point myself, when we were talking about prototypes in scope for the math library functions, which were defines instead of prototypes in the x86 case, to use inline functions. The issue there was that the place the defines and/or prototypes belonged was actually in the machine dependent files. Thsi is because the functions took manifest constants as parameters which may very well be enum's or something else -- and the values of the bits could be different from platform to platform. Magic numbers really suck, even if they are "0". The problem Warner wants addressed is that in order to provide certain classes of scheduling service to applications, and in particular, to provide POSIX conformant scheduling for parts of the POSIX specifications, you have to be able to do deadlining. What this boils down to is that you have to be able to guarantee that particular operations will either succeed or fail in a bounded amount of time (e.g. 2ms or whatever the bound happens to be). For that to work, you prefer that something fails, rather than sleeping. Short of adding a parameter that gets passed down to all the functions in the chain to the target function which might sleep, telling it whether or not it's OK to do so, you really can't make the type of guaranteeds necessary to conform to the standards. I understand that malloc() has a parameter for this now -- or it defaults to that aparameter being there -- but basically this means that what *should* be the common case: bounded completion time, regardless of success or failure, ends up being unbounded by default. So to fix this problem, a programmer would have to go out of their way to add additional "nowait" parameters to all functions up the gall graph, until they got to the one they cared about. This, to me, means that there's a lot of unnecessary slogging that's going to have to happen to get to the point where this is all heading anyway, eventually, and along with that, a lot of additional future opportunities for error. -- At this point, I would almost suggest elminating both M_NOWAIT and M_WAIT (and M_TRYWAIT and M_WAITOK, or whatever the heck it is this week), and split the functionality, so that there are two different function calls for malloc. This is similar to the suggestion on the table here -- however, I would *NOT* pass a mutex that could be released and reacquired over the wait to the allocation function; I would, instead have an allocation function which blocks indefinitely until it gets memory, or the heat death of the universe, whichever comes first (the whole "TRYWAIT" thing was an incredible mistake, IMO). At least this way, you can look at it as clearly laying out a way of getting rid of blocking allocation requests *some time in the future*, and then call the entry point for blocking allocations "deprecated" from the start, so that people will at least try to avoid using it in new code. I guess I should say that, on general principles, barriers should be up front-loaded, if possible. What I mean by this is that if you make it hard to do initial work on a massive change, and easier to do later work, you are *MUCH* better off than if you make the work easy up front, and then have to write "And Then A Miracle Happens..." in your project plan, right at the end. 8-). Put another way: people will only do work they are passionate about, and passion wanes, so you have to put the hard stuff up front, or lots of things will be started, but nothing will ever be completed. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 23 20:34:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CACB337B405; Thu, 23 Jan 2003 20:34:46 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 199C343F1E; Thu, 23 Jan 2003 20:34:45 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA20585; Fri, 24 Jan 2003 15:34:40 +1100 Date: Fri, 24 Jan 2003 15:36:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mike Barcroft Cc: Ben Mesander , Warner Losh , Daniel Eischen , Subject: Re: _REENTRANT in math.h & libm oddities. In-Reply-To: <20030123170330.A32279@espresso.q9media.com> Message-ID: <20030124152541.U4363-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 Thu, 23 Jan 2003, Mike Barcroft wrote: > Ben Mesander writes: > > Ben Mesander writes: > > > But even so, I disagree that the _r function definitions should only > > > appear in math.h if _REENTRANT is defined. That is, I disagree unless > > > the POSIX specification says otherwise; I've been surprised by it > > > before. I was unaware that POSIX mentioned _REENTRANT. > > > > The folks on freebsd-standards said that the defns for the threadsafe > > gamma funcs should be in the BSD namespace (__BSD_VISIBLE). > > I've only been eyeballing this and the other thread, but I think the > conditional we're looking for is: > > #if defined(__BSD_VISIBLE) || (defined(__POSIX_VISIBLE) && defined(_REENTRANT)) > > This provides the reentrant functions in the unencumbered (no standard > specified) namespace and in the POSIX namespace when requested. The gamma_r functions are not in POSIX and neither is _REENTRANT, so the correct conditional is just: #if defined(__BSD_VISIBLE) (unless we add conditions to support Sun standards). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 0:20:29 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2589A37B4DF for ; Fri, 24 Jan 2003 00:20:26 -0800 (PST) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 799E143EB2 for ; Fri, 24 Jan 2003 00:20:25 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-7-62-147-153-115.dial.proxad.net [62.147.153.115]) by postfix4-2.free.fr (Postfix) with SMTP id C2C8DC0F9 for ; Fri, 24 Jan 2003 09:20:17 +0100 (CET) Received: (qmail 14156 invoked by uid 1001); 24 Jan 2003 08:34:30 -0000 Date: Fri, 24 Jan 2003 09:34:30 +0100 From: Nicolas Souchu To: Marcel Moolenaar Cc: "Pedro F. Giffuni" , arch@FreeBSD.ORG, Rodolphe Ortalo Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030124093430.A14066@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122215115.GC590@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030122215115.GC590@dhcp01.pn.xcllnt.net>; from marcel@xcllnt.net on Wed, Jan 22, 2003 at 01:51:16PM -0800 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, Jan 22, 2003 at 01:51:16PM -0800, Marcel Moolenaar wrote: > This is what's been building in my head so far. It's graph-like > and probably too early for public exposure, but what the hee. Hey! You'd love KGI. This Kernel Graphic Interface is actually broken down in two parts: - KGI with display/device abstraction - KII with input/device abstraction Both are running around "focuses". So called devices are "clients" of display/input drivers and all (drivers and devices) can be registered/unregistered independently. At least two kind of graphic devices exist currently: /dev/graph for userland interfacing with the drivers and the TEs (currently a text based one and an xterm). Also, two kind of input devices: /dev/event for input event acquisition from userspace (keys, mouse) and the TEs. The bottom interfaces are input and display drivers. The input driver delivers input events to the focus management system (the core of virtual term management). If special events are hooked, devices *and* drivers are switched depending on the focus organisation (allocation of devices to input/display drivers). For example, in a multihead config with only *one* keyboard, if you have your TE on one screen and X on another, you can switch between them. A display driver is organized in mode setting and resource (cursor, fb, accel engine, fonts) methods. KGI provides for complex display drivers a framework for separating chipset/ramdac/clock drivers and allow building of a complete display driver with basic chip objects. One resource of display is a "text". If a display is used for console, it provides its own method for printing text. [...] > Note that text-only VGA drivers themselves have the ability to > multiplex by switching the display page. So, one could implement > virtual consoles with the VGA driver only. Need to keep this in > mind... Currently, such optimization is not handled by KGI but should be I believe. -- Nicholas Souchu - nsouch@free.fr - nsouch@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 Jan 24 10:59:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BF6037B401 for ; Fri, 24 Jan 2003 10:59:27 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D11543F5F for ; Fri, 24 Jan 2003 10:59:26 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2003012418592500200mku13e>; Fri, 24 Jan 2003 18:59:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA78270; Fri, 24 Jan 2003 10:59:24 -0800 (PST) Date: Fri, 24 Jan 2003 10:59:22 -0800 (PST) From: Julian Elischer To: Bosko Milekic Cc: Jeff Roberson , arch@FreeBSD.ORG Subject: Re: New scheduler In-Reply-To: <20030123190706.A79935@unixdaemons.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 Thu, 23 Jan 2003, Bosko Milekic wrote: > > On Thu, Jan 23, 2003 at 06:19:39PM -0500, Jeff Roberson wrote: > [...] > > > OK, after looking over the code, I'm curious: why does everything > > > still seem to be protected by the sched_lock? Can you not now protect > > > the per-CPU runqueues with their own spinlocks? I'm assuming that the > > > primary reason for not switching to the finer grained model is > > > complications related to the sched_lock protecting necessarily > > > unpremptable sections of code elsewhere in the kernel... notably > > > switching to a more finer grained model would involve changes in the > > > context switching code and I think we would have to teach some MD code > > > about the per-CPU runqueues, which would make this less "pluggable" than > > > it was intended, correct? > > > > stand -> walk -> run :-) I didn't want to make it any more invasive than > > it currently is as that would require either desupporting the current > > scheduler, or using it only on UP. Also, it's a lot of extra effort and a > > lot of extra bugs. I doubt there is much sched lock contention today. KSE is relying to much on schedlock at the moment. If you remove schedlock then KSE will probabyl explode. We are plannign a "lock-a-thon" at some stage where we rationalise all teh locks that have organically grown. > > Oh, that makes sense. I just wanted to make sure that the possibility > existed to move this way at some point in the time to come, assuming > that the additional complexity (if any) is not too costly when > compared to the [measured] performance gains (again, if they are > measurable, and I am sure they will be - the same cache locality > arguments you apply below undoubtedly also apply to splitting a global > lock into per-CPU locks). > > > > I think that one of the main advantages of this thing is the reduction > > > of the contention on the sched lock. If that can be achieved than > > > scheduling any thread, including interrupt threads, would already be > > > cheaper than it currently is (assuming you could go through a context > > > switch without the global sched_lock, and I don't see why with this > > > code you could not). > > > > I'd like to reeorg the mi_switch/cpu_switch path. I'd like do pick the > > new thread in mi_switch and hand it off to cpu_switch instead of calling > > back into sched_choose(). This will make all of this slightly cleaner. > > Good idea. This would make other things easier to implement, too > (including lightweight interrupt threads, should we decide to persue > that at some point again). Be aware that KSE has its fingers in there too. > > > > Finally, I have one question regarding your results. Obviously, 35% > > > and 10% are noteworthy numbers. What do you attribute the speedup to, > > > primarily, given that this is still all under a global sched_lock? > > > > > > Thanks again for all your work. > > > > > > > There are a few factors. Most notably the cpu affinity. The caches are > > trashing so much on SMP with the old scheduler that it's actually slower > > than UP in some cases. Also, since the balancing is currently pooched the > > memory bus is contended for less. So the 35% will probably get a bit > > smaller, but hopefully the real time will too. > > > > The new scheduler is also algorithmically cheaper. 10 times a second > > schedcpu() would run on the old scheduler and pollute your cache. With > > lots of processes this code could take a while too. > > Both of these are what I was looking for, thanks. I totally believe > the cache locality argument, especially given that the slight > performance improvements I've seen when doing mb_alloc were also > attributed to that. > > > Cheers, > > Jeff > > Regards, > -- > Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org > > > 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 Fri Jan 24 11: 0:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8FB937B401; Fri, 24 Jan 2003 11:00:57 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id A175243F18; Fri, 24 Jan 2003 11:00:57 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 91A3B2A7EA; Fri, 24 Jan 2003 11:00:57 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: phk@freebsd.org Cc: Kris Kennaway , arch@freebsd.org Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. In-Reply-To: <16728.1043173644@critter.freebsd.dk> Date: Fri, 24 Jan 2003 11:00:57 -0800 From: Peter Wemm Message-Id: <20030124190057.91A3B2A7EA@canning.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 phk@freebsd.org wrote: > In message <20030121092851.A27172@citusc.usc.edu>, Kris Kennaway writes: > >On Tue, Jan 21, 2003 at 12:58:12PM +0100, phk@FreeBSD.ORG wrote: > >>=20 > >> I have uploaded two patchfiles: > >>=20 > >> http://phk.freebsd.dk/patch/small.patch > >> Removes just the options from sys/conf > >>=20 > >> http://phk.freebsd.dk/patch/big.patch > >> unifdef -UNODEVFS -UNO_GEOM > >> Removes roughly 2800 lines of code. > > > >To the best of your knowledge, there are no remaining serious bugs or > >missing functionality with GEOM (like the disklabel editing problems > >found before 5.0, etc)? > > There is one errata point (can't rewrite BSD boot code on a disk > which is in use) which I am testing a patch for. > > I know of no bugs at present. BTW; assuming these are taken care of, do we really gain anything by waiting so long? Personally, I'd rather get it over and done with sooner rather than later. What does waiting another month and a half buy us? The handful folks who dont like it now are not going to start liking it by March 1st :-(. Frankly I'd rather have an extra month focussed on this code to shake out any remaining quirks and make sure that we have all the bases covered and that we actually deal with any reasons why folks might be using NO_GEOM and not letting us know. It would give us an extra month to solve those before the next release/branch/whatever. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Fri Jan 24 11:22: 7 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A115837B401 for ; Fri, 24 Jan 2003 11:22:05 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBF2543EB2 for ; Fri, 24 Jan 2003 11:22:04 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0OJLv8k003128; Fri, 24 Jan 2003 20:21:58 +0100 (CET) (envelope-from phk@freebsd.org) To: Peter Wemm Cc: Kris Kennaway , arch@freebsd.org Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. From: phk@freebsd.org In-Reply-To: Your message of "Fri, 24 Jan 2003 11:00:57 PST." <20030124190057.91A3B2A7EA@canning.wemm.org> Date: Fri, 24 Jan 2003 20:21:57 +0100 Message-ID: <3127.1043436117@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 In message <20030124190057.91A3B2A7EA@canning.wemm.org>, Peter Wemm writes: >> There is one errata point (can't rewrite BSD boot code on a disk >> which is in use) which I am testing a patch for. >> >> I know of no bugs at present. > >BTW; assuming these are taken care of, do we really gain anything by >waiting so long? Some nights sleep before all hell breaks loose ? :-) >Frankly I'd rather have an extra month focussed on this >code to shake out any remaining quirks and make sure that we have all the >bases covered and that we actually deal with any reasons why folks might be >using NO_GEOM and not letting us know. It would give us an extra month to >solve those before the next release/branch/whatever. I personally wanted to give 5.0-R a chance in the wild, just to see if somebody came up and said "You've busted all PC's in Elbonia" or similar overlooked details. Considering that there has not been a any reports on GEOM/DEVFS which have filtered through to me yet means that I am open to a more aggresive timeline. Show of hands ? When should I remove NODEVFS and NO_GEOM from sys/conf ? When should I commit the consequent unifdef of 2865 lines ? -- 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 Fri Jan 24 11:35:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C07737B401; Fri, 24 Jan 2003 11:35:41 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47D3343F43; Fri, 24 Jan 2003 11:35:40 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.6/8.12.6) with ESMTP id h0OJZc4L035195; Fri, 24 Jan 2003 19:35:38 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.6/8.12.6/Submit) with UUCP id h0OJZcB5035194; Fri, 24 Jan 2003 19:35:38 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.6/8.12.6) with ESMTP id h0OJWdaX015667; Fri, 24 Jan 2003 21:32:39 +0200 (SAST) (envelope-from mark@grondar.org) Message-Id: <200301241932.h0OJWdaX015667@grimreaper.grondar.org> To: phk@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. In-Reply-To: Your message of "Fri, 24 Jan 2003 20:21:57 +0100." <3127.1043436117@critter.freebsd.dk> Date: Fri, 24 Jan 2003 19:32:38 +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 > Show of hands ? I have no objection. All my machines have been using DEVFS and GEOM for about as long as I was able to do so. > When should I remove NODEVFS and NO_GEOM from sys/conf ? > > When should I commit the consequent unifdef of 2865 lines ? Now? :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 11:36:20 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBB7337B401; Fri, 24 Jan 2003 11:36:18 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76D9543EB2; Fri, 24 Jan 2003 11:36:18 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 6693C2A8A5; Fri, 24 Jan 2003 11:36:18 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: phk@freebsd.org Cc: arch@freebsd.org Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. In-Reply-To: <3127.1043436117@critter.freebsd.dk> Date: Fri, 24 Jan 2003 11:36:18 -0800 From: Peter Wemm Message-Id: <20030124193618.6693C2A8A5@canning.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 phk@freebsd.org wrote: > In message <20030124190057.91A3B2A7EA@canning.wemm.org>, Peter Wemm writes: > > >> There is one errata point (can't rewrite BSD boot code on a disk > >> which is in use) which I am testing a patch for. > >> > >> I know of no bugs at present. > > > >BTW; assuming these are taken care of, do we really gain anything by > >waiting so long? > > Some nights sleep before all hell breaks loose ? :-) > > >Frankly I'd rather have an extra month focussed on this > >code to shake out any remaining quirks and make sure that we have all the > >bases covered and that we actually deal with any reasons why folks might be > >using NO_GEOM and not letting us know. It would give us an extra month to > >solve those before the next release/branch/whatever. > > I personally wanted to give 5.0-R a chance in the wild, just to see > if somebody came up and said "You've busted all PC's in Elbonia" > or similar overlooked details. > > Considering that there has not been a any reports on GEOM/DEVFS > which have filtered through to me yet means that I am open to a > more aggresive timeline. > > Show of hands ? > > When should I remove NODEVFS and NO_GEOM from sys/conf ? IMHO, some time over the next few days. This is easy to undo if there is a showstopper that turns up. > When should I commit the consequent unifdef of 2865 lines ? IMHO, some time early february. You may like to get the TRB to sign off on this as a CYA. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Fri Jan 24 12:51:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65D2837B401 for ; Fri, 24 Jan 2003 12:51:53 -0800 (PST) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FDE043ED8 for ; Fri, 24 Jan 2003 12:51:47 -0800 (PST) (envelope-from garyj@jennejohn.org) Received: from fwd03.sul.t-online.de by mailout09.sul.t-online.com with smtp id 18cAni-0002MP-04; Fri, 24 Jan 2003 21:51:46 +0100 Received: from peedub.jennejohn.org (520017439985-0001@[217.80.231.124]) by fmrl03.sul.t-online.com with esmtp id 18cAnc-1Td8QSC; Fri, 24 Jan 2003 21:51:40 +0100 Received: from peedub.jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.12.6/8.11.6) with ESMTP id h0OKpcOv029151 for ; Fri, 24 Jan 2003 21:51:39 +0100 (CET) (envelope-from garyj@peedub.jennejohn.org) Message-Id: <200301242051.h0OKpcOv029151@peedub.jennejohn.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.3 To: arch@FreeBSD.ORG Subject: Re: New scheduler From: Gary Jennejohn Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Jan 2003 21:51:38 +0100 X-Sender: 520017439985-0001@t-dialin.net 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 assume that this new scheduler is only for SMP? I tried it out on my UP machine - BTW on line 312 there's a missing ``);'' - and the results were, not to pull any blows, catastrophic. Running X I started a ``make buildworld'' in an aterm and immediately observerd: o the cursor lagged way behind mouse movements o switching desktops allowed me to observe in detail how various applications repaint themselves - it was that slow o mozilla was totally unusable With the current scheduler interactive applications are still quite snappy. I never observe any of the above mentioned problems with it. I know this is a WIP, but I thought I'd report my observations. This on an XP 1800+ with 768MB of memory and (fairly) fast SCSI disks. -------- Gary Jennejohn / garyj@jennejohn.org gj@freebsd.org gj@denx.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 13:20:18 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FA9F37B401 for ; Fri, 24 Jan 2003 13:20:15 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EE4643EB2 for ; Fri, 24 Jan 2003 13:20:14 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0OLKBMW041578; Fri, 24 Jan 2003 13:20:11 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0OLKA3X047121; Fri, 24 Jan 2003 13:20:10 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0OLKAJ1047120; Fri, 24 Jan 2003 13:20:10 -0800 (PST) (envelope-from marcel) Date: Fri, 24 Jan 2003 13:20:10 -0800 From: Marcel Moolenaar To: Nicolas Souchu Cc: arch@FreeBSD.ORG Subject: Console implementation: summary and personal conclusion Message-ID: <20030124212010.GA44543@dhcp01.pn.xcllnt.net> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122215115.GC590@dhcp01.pn.xcllnt.net> <20030124093430.A14066@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030124093430.A14066@armor.fastether> User-Agent: Mutt/1.5.3i 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 Fri, Jan 24, 2003 at 09:34:30AM +0100, Nicolas Souchu wrote: > On Wed, Jan 22, 2003 at 01:51:16PM -0800, Marcel Moolenaar wrote: > > This is what's been building in my head so far. It's graph-like > > and probably too early for public exposure, but what the hee. > > Hey! You'd love KGI. From your description it looks like there's a big overlap. The major difference being that I didn't worry too much about the graphical aspect beyond elementary graphical consoles. Ok, time to summarize: o Original topic was newbusification of kbd but it was clear from the email that the intend was broader. This opened up Pandora's box. See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2463+0+current/freebsd-arch o The new kids on the platform block already have issues with syscons and pvct as they are both PC and ISA oriented. This also hits pccard based docking stations. Importing wscons has been suggested, but I didn't get the impression that it was a superior alternative as there are definite downsides. See for example: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=12593+0+current/freebsd-arch o KGI has been pulled in and so far (superficially) looks like the framework I had building in my head but allows or moves accelerated graphics drivers in the kernel. After reading up on it a bit more I see definite potential in that direction. See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=18642+0+current/freebsd-arch http://docs.freebsd.org/cgi/getmsg.cgi?fetch=253924+0+current/freebsd-arch o This issue has been raised that we need to probe potential console hardware before the newbus infrastructure has been initialized and that this by itself causes the biggest non- portability. I get the impression that this point is the easiest to do wrong by making all sorts of assumptions. See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=405180+0+current/freebsd-arch Where to go from here: First of all, we already have 2 console implementations in the tree and whatever we do, I don't think we should make that 3 or more. So, if we're going to add a new console implementation, we need to axe at least one. My ordering would be pcvt first, syscons second. I think it's easier to create pcvt compatibility than syscons compatibility. Ideally we should only have one of course. The following thoughts are battling for recognition. It is highly graphics oriented in cases. I guess it shows my preference: 1. According to current standards FreeBSD is severely lacking in the looks department. We really depend on X with GNOME, KDE or any of the other selection of colors. With sysinstall still the application that many people see as they have their first encounter with FreeBSD, the first impression can really suck in cases. Whatever we did on the looks front is i386 specific. Someday i386 will not be the primary platform or syscons may simply stop working because we don't have VGA anymore and how do we get those nifty splash screens then? 2. The security revolution we had a couple of years ago has changed much and we're more and more aware of security issues. Having a userland application in control of hardware seems very odd in that light. We have put our faith in userland to not hose the hardware or to prevent one process to look at data that belongs to another process. Can we trust X to prevent reading/writing outside the area of the display that is assigned to us? 3. We have a bunch of network hardware drivers and a sound infra- structure that supports many controllers. Yet, when it comes to graphics adapters we seem to apply a different standard. What makes a graphics infrastructure so different from a sound infra- structure other than that it is designed to annoy the eyes and not the ears. 4. I really hate to have the kernel double in size because we have to have a bloody graphics engine in a headless machine or a machine that is shipped with a 3D graphics adapter because you get 3D graphics adapters with everything you buy and all you want to do is attach a monitor and keyboard once in a while because you don't have any other means for a console and all you want is text. 5. We are very likely not going to write high-performance graphics drivers by ourselves. A complex infrastructure that is not used in practice is rather pointless. A much simpler or limited approach has a higher chance of being successful and we may actually have it before we have our 10th anniversary. I think that if we focus on our immediate needs, but don't cut corners that can't be "uncut" we should go for something like KGI. We already have a vga and tga driver and those can be used to bootstrap something new. Even if we have to write a driver from scratch, we don't have to write a 2D/3D accelerator. Get a portable console implemetation first, even if it's text-only. If we make sure we can provide compatibility with pcvt, we can keep syscons for i386. After that, we can work on the future... Thoughts? -- 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 Fri Jan 24 13:23: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F2E237B401 for ; Fri, 24 Jan 2003 13:23:00 -0800 (PST) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 027BF43F1E for ; Fri, 24 Jan 2003 13:23:00 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch01.lj.gnf.org [172.25.10.19]) by ns1.gnf.org (8.12.3/8.12.3) with ESMTP id h0OLMwMf014879 for ; Fri, 24 Jan 2003 13:22:58 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 13:22:59 -0800 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.6/8.12.6) with ESMTP id h0OLMx6t080401 for ; Fri, 24 Jan 2003 13:22:59 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.6/8.12.6/Submit) id h0OLMxqp080400 for arch@FreeBSD.org; Fri, 24 Jan 2003 13:22:59 -0800 (PST) (envelope-from gtetlow) Date: Fri, 24 Jan 2003 13:22:59 -0800 From: Gordon Tetlow To: arch@FreeBSD.org Subject: CFR: Volume labels in FFS Message-ID: <20030124212259.GJ53114@roark.gnf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4wKa0rmtotUGtIt6" Content-Disposition: inline User-Agent: Mutt/1.4i X-OriginalArrivalTime: 24 Jan 2003 21:22:59.0742 (UTC) FILETIME=[C52BF3E0:01C2C3EE] 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 --4wKa0rmtotUGtIt6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'd like to get some review of my patch to add volume label support to FFS. I've already changed struct fs (sorry non-i386 users) to allocate some space for the label. I'm looking to commit this relatively soon unless there is some major problems with the review. http://people.freebsd.org/~gordon/patches/volume.diff The patch is basically a GEOM module (which allows you to use volume labels for your root partition is you so desire (my laptop's root slice is mounted from /dev/vol/rootfs)) and a couple modifications to add labels (newfs, tunefs). -gordon --4wKa0rmtotUGtIt6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+Ma6zRu2t9DV9ZfsRAi79AJ4uVKOVViZw67PaBpKR0bClYh4ZZACeMwzR eRBxqNfmk6LY1Q2kWphOWNg= =ZJNS -----END PGP SIGNATURE----- --4wKa0rmtotUGtIt6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 13:53: 3 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBE3D37B401 for ; Fri, 24 Jan 2003 13:53:01 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 332CF43F3F for ; Fri, 24 Jan 2003 13:53:01 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id h0OLqxIm130112; Fri, 24 Jan 2003 16:52:59 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030124212259.GJ53114@roark.gnf.org> References: <20030124212259.GJ53114@roark.gnf.org> Date: Fri, 24 Jan 2003 16:52:57 -0500 To: Gordon Tetlow , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: CFR: Volume labels in FFS 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 1:22 PM -0800 1/24/03, Gordon Tetlow wrote: >I'd like to get some review of my patch to add volume label >support to FFS. I've already changed struct fs (sorry non-i386 >users) to allocate some space for the label. I'm looking to >commit this relatively soon unless there is some major problems >with the review. > >http://people.freebsd.org/~gordon/patches/volume.diff > >The patch is basically a GEOM module (which allows you to use >volume labels for your root partition is you so desire (my >laptop's root slice is mounted from /dev/vol/rootfs)) and a >couple modifications to add labels (newfs, tunefs). This sounds interesting. The patch looks like it just adds support for setting and retrieving the label. How will this be usable at the /etc/fstab level? Will this let us do something similar to what linux allows for /etc/fstab, such as: LABEL=/blah /mnt/blah ufs rw 2 2 (if so, I'd also like something like: IFLABEL=/blah /mnt/blah ufs rw 2 2 which means *iff* the OS finds a partition labelled /blah, then it should mount it at /mnt/blah, and that it is *not* an error when no such labelled volume is found) -- Garance Alistair Drosehn = gad@gilead.netel.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 Fri Jan 24 13:57:58 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 326BB37B401 for ; Fri, 24 Jan 2003 13:57:56 -0800 (PST) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 789B943ED8 for ; Fri, 24 Jan 2003 13:57:55 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch01.lj.gnf.org [172.25.10.19]) by ns1.gnf.org (8.12.3/8.12.3) with ESMTP id h0OLvqMf015060 for ; Fri, 24 Jan 2003 13:57:52 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 13:57:54 -0800 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.6/8.12.6) with ESMTP id h0OLvs6t080789; Fri, 24 Jan 2003 13:57:54 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.6/8.12.6/Submit) id h0OLvrkk080788; Fri, 24 Jan 2003 13:57:53 -0800 (PST) (envelope-from gtetlow) Date: Fri, 24 Jan 2003 13:57:53 -0800 From: Gordon Tetlow To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS Message-ID: <20030124215753.GM53114@roark.gnf.org> References: <20030124212259.GJ53114@roark.gnf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IoCMmVDh1/K3iHvq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-OriginalArrivalTime: 24 Jan 2003 21:57:54.0249 (UTC) FILETIME=[A5985B90:01C2C3F3] 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 --IoCMmVDh1/K3iHvq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2003 at 04:52:57PM -0500, Garance A Drosihn wrote: > At 1:22 PM -0800 1/24/03, Gordon Tetlow wrote: > >I'd like to get some review of my patch to add volume label > >support to FFS. I've already changed struct fs (sorry non-i386 > >users) to allocate some space for the label. I'm looking to > >commit this relatively soon unless there is some major problems > >with the review. > > > >http://people.freebsd.org/~gordon/patches/volume.diff > > > >The patch is basically a GEOM module (which allows you to use > >volume labels for your root partition is you so desire (my > >laptop's root slice is mounted from /dev/vol/rootfs)) and a > >couple modifications to add labels (newfs, tunefs). >=20 > This sounds interesting. The patch looks like it just adds > support for setting and retrieving the label. How will this > be usable at the /etc/fstab level? Will this let us do something > similar to what linux allows for /etc/fstab, such as: > LABEL=3D/blah /mnt/blah ufs rw 2 2 >=20 > (if so, I'd also like something like: > IFLABEL=3D/blah /mnt/blah ufs rw 2 2 > which means *iff* the OS finds a partition labelled /blah, then > it should mount it at /mnt/blah, and that it is *not* an error > when no such labelled volume is found) No, it actually creates device nodes in /dev/vol/, so it be more like this: /dev/vol/rootfs / ufs rw 1 1 /dev/vol/usrfs /usr ufs rw 2 2 =2E..etc... I didn't go the Linux route and do LABEL=3D because there is alot of black magic in the loader that reads /etc/fstab looking for the root partition and I didn't want to mess with fstab.h and friends. -gordon -gordon --IoCMmVDh1/K3iHvq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+MbbhRu2t9DV9ZfsRAu0ZAJ4r/kTQHVJiO7u6bO8ehcsEb9tM5gCeL2RW xgM8ouEQQyXJug4kIjA0/fs= =wyoe -----END PGP SIGNATURE----- --IoCMmVDh1/K3iHvq-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 14:27:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9D4F37B401 for ; Fri, 24 Jan 2003 14:27:19 -0800 (PST) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC3343ED8 for ; Fri, 24 Jan 2003 14:27:19 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch01.lj.gnf.org [172.25.10.19]) by ns1.gnf.org (8.12.3/8.12.3) with ESMTP id h0OMRHMf015258 for ; Fri, 24 Jan 2003 14:27:17 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 14:27:18 -0800 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.6/8.12.6) with ESMTP id h0OMRI6t081154; Fri, 24 Jan 2003 14:27:18 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.6/8.12.6/Submit) id h0OMRIKs081153; Fri, 24 Jan 2003 14:27:18 -0800 (PST) (envelope-from gtetlow) Date: Fri, 24 Jan 2003 14:27:18 -0800 From: Gordon Tetlow To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS Message-ID: <20030124222718.GN53114@roark.gnf.org> References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KbRlJ7rsgYPVCYDX" Content-Disposition: inline In-Reply-To: <20030124215753.GM53114@roark.gnf.org> User-Agent: Mutt/1.4i X-OriginalArrivalTime: 24 Jan 2003 22:27:18.0841 (UTC) FILETIME=[C15FBA90:01C2C3F7] 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 --KbRlJ7rsgYPVCYDX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2003 at 01:57:53PM -0800, Gordon Tetlow wrote: > On Fri, Jan 24, 2003 at 04:52:57PM -0500, Garance A Drosihn wrote: > >=20 > > This sounds interesting. The patch looks like it just adds > > support for setting and retrieving the label. How will this > > be usable at the /etc/fstab level? Will this let us do something > > similar to what linux allows for /etc/fstab, such as: > > LABEL=3D/blah /mnt/blah ufs rw 2 2 > >=20 > > (if so, I'd also like something like: > > IFLABEL=3D/blah /mnt/blah ufs rw 2 2 > > which means *iff* the OS finds a partition labelled /blah, then > > it should mount it at /mnt/blah, and that it is *not* an error > > when no such labelled volume is found) >=20 > No, it actually creates device nodes in /dev/vol/, so it be more > like this: >=20 > /dev/vol/rootfs / ufs rw 1 1 > /dev/vol/usrfs /usr ufs rw 2 2 > ...etc... >=20 > I didn't go the Linux route and do LABEL=3D because there is alot of > black magic in the loader that reads /etc/fstab looking for the root > partition and I didn't want to mess with fstab.h and friends. I can also forsee being able to hook into devd to do some automounting magic for things like zip disks and cdroms (obviously not with FFS, but cd9660 support would be a good thing to have once GEOM recognizes cdroms). -gordon --KbRlJ7rsgYPVCYDX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+Mb3GRu2t9DV9ZfsRAjAhAJ0ZHF+Zs2k32/+oAEWqUmM0sZN0QQCggdHb 1BFAsP/6xxPnzWUAIORumYA= =kCew -----END PGP SIGNATURE----- --KbRlJ7rsgYPVCYDX-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 14:35:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E55B337B401 for ; Fri, 24 Jan 2003 14:35:51 -0800 (PST) Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD0C143F13 for ; Fri, 24 Jan 2003 14:35:50 -0800 (PST) (envelope-from ortalo@laas.fr) Received: by laas.laas.fr (8.12.7/8.12.7) with ESMTP id h0OMZh0j021762; Fri, 24 Jan 2003 23:35:44 +0100 (CET) Date: Fri, 24 Jan 2003 22:58:12 +0100 (CET) From: Rodolphe Ortalo To: Marcel Moolenaar Cc: Nicolas Souchu , arch@freebsd.org Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) In-Reply-To: <20030123234431.GB555@athlon.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / 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 On Thu, 23 Jan 2003, Marcel Moolenaar wrote: > Not all low-level consoles are (graphical) display adapters. If > the low-level console is a serial interface, you need to preserve > the communication settings. In general though I like to take the > approach that the low-level console has done some work, possibly > non-trivial, to get the state/information it currently has and it > seems wasteful to destroy that state simply because we run into > that device during bus enumeration and we then have the resources > available to use the device to its fullest potential, but end up > not doing that. So, unless there's a good reason not to, preserving > state can only proof beneficial. > > I realize it's mostly subjective. I think you should have the > mechanism to allow preserving state, so that you have the freedom > to make use of it or not... I understand clearly why doing so may be important for serial consoles (or possibly other non-display adapters), but wrt most (modern) VGA adapters, I have the feeling that discarding the state and switching to some advanced mode should be done as soon as possible! :-) Note that this does not necessarily mean discarding VGA-style display mode; but for example if the board allows to access all needed VGA registers via a MMIO area (instead of the usual fixed adresses regs around 0x3C0) and its framebuffer (including the VGA part) via another area, it is urgent to take advantage of it: even if the console layer simply re-sets an VGA mode identical to the one set by the boot driver; then, all potential conflicts due to the fixed (and non-shareable, or at least very difficult to share) VGA adresses in a multiple-boards configuration are cleared, and further initialisations of remaining boards can proceed more cleanly. This is still an experimental subject for me with KGI/Linux, but I'd really like to try this one of these days. (I have a computer with, say a G200 AGP board and a Matrox Mystique) Currently, I use one of the board as the boot board (primary in my own terminology) and starts a driver on the other one, then raise my initlevel to active some virtual consoles on this secondary head. (At boot, these consoles are directed on a "display-null" which is basically a /dev/null. My driver instance replaces one of these "display-null". [1]) What I have to experiment yet is to replace the primary head VGA-only boot driver with another instance of the Matrox driver (and get rid entirely of the boot drivers), and do this first in the rc scripts. (Of course, I wanted to have more confidence in the drivers themselves before doing this in such a permanent and possibly dangerous way.) In this case, it would be possible to add another PCI board (like my old S3 Trio) and use a simple (but generic) VGA driver to use it in text mode only (S3 does not have a driver in KGI currently, and probably won't until some more time). If I do not have the ability to replace the initial boot VGA driver (targetted at one of the Matrox boards) with a more complete driver (using MMIO accesses), to do that, I would be obliged to set the S3 board as the primary (BIOS initialized) board. Something most users will probably not want to do (even though it is not absurd at all): use the oldest graphic board in the computer as the primary boot display. (Plus the fact that it may compromise some nice boot logo. :-) Well, sorry for going into such futile remarks in the end... :-) Rodolphe [1] The total number of available displays is a compiled-in default (4). Nicholas, please correct me if I'm wrong. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 14:38:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 520F637B405 for ; Fri, 24 Jan 2003 14:38:34 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D89A43EB2 for ; Fri, 24 Jan 2003 14:38:33 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0OMcW8k004615 for ; Fri, 24 Jan 2003 23:38:32 +0100 (CET) (envelope-from phk@freebsd.org) To: arch@freebsd.org Subject: GEOM and CDROM media (was: CFR: Volume labels in FFS) From: phk@freebsd.org In-Reply-To: Your message of "Fri, 24 Jan 2003 14:27:18 PST." <20030124222718.GN53114@roark.gnf.org> Date: Fri, 24 Jan 2003 23:38:32 +0100 Message-ID: <4614.1043447912@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 In message <20030124222718.GN53114@roark.gnf.org>, Gordon Tetlow writes: >I can also forsee being able to hook into devd to do some automounting magic >for things like zip disks and cdroms (obviously not with FFS, but cd9660 >support would be a good thing to have once GEOM recognizes cdroms). I am currently experimenting with code for removable devices which will poll the drive if there is a media in it (too many drives/interfaces are too stupid to tell us) and this can and could be include CDROMS as well. The question in my mind is how to handle complex CDROM formats: Imagine a CD with this layout: 1: Data track 2: Data track 3: Music "You can build a mainframe from the things you find at home" 4: Music "I'm a mainframe baby" 5: Data track 6: Data track, multi-session with track 5. (I belive this layout is possible, but even if it isn't, assume that it is for the sake of this argument, the principle is what we are discussing here, not what's in the various coloured books) How and what appears where and why ? SCSI CD's won't do a thing, you get one device and a ton of ioctls to deal with. ATAPI CD's do neat tricks and present each track as a (cloned) device so you can do things like /dev/acd0t05 etc. Should CD drivers offer all data tracks to GEOM ? Or only the last ? How should music tracks be handled ? (GEOM can handle them and that would mean that you could build a GEOM_MP3 module which converted the format. I'd scream if you did, but you could :-) Suggestions welcome... Poul-Henning PS: No, I've not made those titles up :-) -- 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 Fri Jan 24 14:59:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66B1E37B401 for ; Fri, 24 Jan 2003 14:59:37 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id D37DC43F13 for ; Fri, 24 Jan 2003 14:59:36 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0189.cvx21-bradley.dialup.earthlink.net ([209.179.192.189] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18cCnI-0007FR-00; Fri, 24 Jan 2003 14:59:29 -0800 Message-ID: <3E31C4F5.972AA69C@mindspring.com> Date: Fri, 24 Jan 2003 14:57:57 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Tetlow Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a469a69ea338127b4338cf10a2a949511d548b785378294e88350badd9bab72f9c350badd9bab72f9c 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 Gordon Tetlow wrote: > > No, it actually creates device nodes in /dev/vol/, so it be more > > like this: > > > > /dev/vol/rootfs / ufs rw 1 1 > > /dev/vol/usrfs /usr ufs rw 2 2 > > ...etc... > > > > I didn't go the Linux route and do LABEL= because there is alot of > > black magic in the loader that reads /etc/fstab looking for the root > > partition and I didn't want to mess with fstab.h and friends. > > I can also forsee being able to hook into devd to do some automounting magic > for things like zip disks and cdroms (obviously not with FFS, but cd9660 > support would be a good thing to have once GEOM recognizes cdroms). That's what "Last mounted on" is for. Gotta wonder why we need volume devices, when we know where we are going to mount the thing... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 15:15:39 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B098637B405 for ; Fri, 24 Jan 2003 15:15:37 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6986C43EB2 for ; Fri, 24 Jan 2003 15:15:36 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0ONFYMW042045; Fri, 24 Jan 2003 15:15:34 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0ONFX3X047481; Fri, 24 Jan 2003 15:15:33 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0ONFXqP047480; Fri, 24 Jan 2003 15:15:33 -0800 (PST) (envelope-from marcel) Date: Fri, 24 Jan 2003 15:15:33 -0800 From: Marcel Moolenaar To: Rodolphe Ortalo Cc: Nicolas Souchu , arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030124231533.GA47190@dhcp01.pn.xcllnt.net> References: <20030123234431.GB555@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i 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 Fri, Jan 24, 2003 at 10:58:12PM +0100, Rodolphe Ortalo wrote: > > I understand clearly why doing so may be important for serial consoles (or > possibly other non-display adapters), but wrt most (modern) VGA adapters, > I have the feeling that discarding the state and switching to some > advanced mode should be done as soon as possible! :-) I cannot disagree. Preserving state may range from being crucial important to totally bollocks. If we switch to some hi-res graphics mode as part of the low-level console probing and selection, I don't immediately feel any pain by loosing the info that the loader has put on the screen. Doing it as part of bus-enumeration and loosing the output for half the device probes hurts... State also doesn't have to be visible. State could also mean some data passed to us through the loader by the firmware. In any case YMMV. For the hackery on the ia64 branch I reuse the softc that I initialize during low-level console probing when I find the device during bus-enumeration so that I can defer setting cn_dev to when I actually know the unit number instead of kludging around the phase ordering problem... > What I have to experiment yet is to replace the primary head VGA-only > boot driver with another instance of the Matrox driver (and get rid > entirely of the boot drivers), and do this first in the rc scripts. Yuck :-) I don't see a problem really. Maybe because I don't understand what you're trying to achieve, but I don't see how handling of graphics controllers is different from sound controllers. If there's no specific driver, but the hardware is VGA compatible, you use a generic VGA driver. In any case, you either compile-in the right drivers or you depend on module loading to achieve some dynamic behaviour. I categorize the replacement of active drivers during runtime without tearing down the "clients" of the driver first as... as... well, I don't even have a bucket for it. Trash comes closest :-) -- 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 Fri Jan 24 15:29:40 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5243A37B401; Fri, 24 Jan 2003 15:29:38 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E5FE43F18; Fri, 24 Jan 2003 15:29:37 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0ONTbMW042112; Fri, 24 Jan 2003 15:29:37 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0ONTb3X047512; Fri, 24 Jan 2003 15:29:37 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0ONTbXL047511; Fri, 24 Jan 2003 15:29:37 -0800 (PST) (envelope-from marcel) Date: Fri, 24 Jan 2003 15:29:36 -0800 From: Marcel Moolenaar To: phk@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: GEOM and CDROM media (was: CFR: Volume labels in FFS) Message-ID: <20030124232936.GB47190@dhcp01.pn.xcllnt.net> References: <20030124222718.GN53114@roark.gnf.org> <4614.1043447912@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4614.1043447912@critter.freebsd.dk> User-Agent: Mutt/1.5.3i 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 Fri, Jan 24, 2003 at 11:38:32PM +0100, phk@FreeBSD.ORG wrote: > In message <20030124222718.GN53114@roark.gnf.org>, Gordon Tetlow writes: > > >I can also forsee being able to hook into devd to do some automounting magic > >for things like zip disks and cdroms (obviously not with FFS, but cd9660 > >support would be a good thing to have once GEOM recognizes cdroms). > > I am currently experimenting with code for removable devices which > will poll the drive if there is a media in it (too many drives/interfaces > are too stupid to tell us) and this can and could be include CDROMS > as well. > > The question in my mind is how to handle complex CDROM formats: What about an intermediate layer that splits the physical media into logical media based on the format. Example given below (forgive me the unethical device naming -- it's for illustration purposes): > 1: Data track > 2: Data track > 3: Music "You can build a mainframe from the things you find at home" > 4: Music "I'm a mainframe baby" > 5: Data track > 6: Data track, multi-session with track 5. /dev/cd0/data/track1 /dev/cd0/data/track2 /dev/cd0/data/track3 /dev/cd0/data/track4, multi-session with track 3 /dev/cd0/audio/track1 /dev/cd0/audio/track2 The track numbers are logical so you can treat /dev/cd0/audio as a logical audio-only CD and /dev/cd0/data as a logical data-only CD. Whether you want to have GEOM deal with audio tracks or just present a logical audio CD depends on how loud you scream if someone would write GEOM_MP3 :-) You could treat the DVD VOBs in the same way I guess... I guess the point I'm getting at is that GEOM stacks objects to abstract the physical representation by presenting logical entities. An abstraction layer based on the format seems to fit in... Just some random thoughts... -- 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 Fri Jan 24 15:29:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D33A37B406 for ; Fri, 24 Jan 2003 15:29:43 -0800 (PST) Received: from ns2.gnf.org (ns2.gnf.org [63.196.132.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56CFD43E4A for ; Fri, 24 Jan 2003 15:29:42 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch01.lj.gnf.org [172.25.10.19]) by ns2.gnf.org (8.12.3/8.12.3) with ESMTP id h0ONTdtk073803 for ; Fri, 24 Jan 2003 15:29:39 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 15:29:41 -0800 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.6/8.12.6) with ESMTP id h0ONTf6t081758; Fri, 24 Jan 2003 15:29:41 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.6/8.12.6/Submit) id h0ONTfYK081757; Fri, 24 Jan 2003 15:29:41 -0800 (PST) (envelope-from gtetlow) Date: Fri, 24 Jan 2003 15:29:41 -0800 From: Gordon Tetlow To: Terry Lambert Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS Message-ID: <20030124232941.GQ53114@roark.gnf.org> References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> <3E31C4F5.972AA69C@mindspring.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kYEd1k/8P7wP4RaW" Content-Disposition: inline In-Reply-To: <3E31C4F5.972AA69C@mindspring.com> User-Agent: Mutt/1.4i X-OriginalArrivalTime: 24 Jan 2003 23:29:42.0046 (UTC) FILETIME=[787F7BE0:01C2C400] 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 --kYEd1k/8P7wP4RaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 24, 2003 at 02:57:57PM -0800, Terry Lambert wrote: > Gordon Tetlow wrote: > >=20 > > I can also forsee being able to hook into devd to do some automounting = magic > > for things like zip disks and cdroms (obviously not with FFS, but cd9660 > > support would be a good thing to have once GEOM recognizes cdroms). >=20 >=20 > That's what "Last mounted on" is for. >=20 > Gotta wonder why we need volume devices, when we know where we > are going to mount the thing... It's just a thought. No one said whether it was a good idea or not. -gordon --kYEd1k/8P7wP4RaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+McxlRu2t9DV9ZfsRAutBAKDIJzk0kBSWUE5LosJHKA0cyVSBOACgi8VJ +Dr8NNr2HlNttHX5e0JXP5k= =c/bo -----END PGP SIGNATURE----- --kYEd1k/8P7wP4RaW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 15:47:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB68737B401 for ; Fri, 24 Jan 2003 15:47:41 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 387D943E4A for ; Fri, 24 Jan 2003 15:47:41 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.6/8.12.6) id h0ONlenK032366; Fri, 24 Jan 2003 17:47:40 -0600 (CST) (envelope-from dan) Date: Fri, 24 Jan 2003 17:47:40 -0600 From: Dan Nelson To: Terry Lambert Cc: Gordon Tetlow , Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS Message-ID: <20030124234740.GA58038@dan.emsphone.com> References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> <3E31C4F5.972AA69C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E31C4F5.972AA69C@mindspring.com> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.3i 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 the last episode (Jan 24), Terry Lambert said: > Gordon Tetlow wrote: > > I can also forsee being able to hook into devd to do some > > automounting magic for things like zip disks and cdroms (obviously > > not with FFS, but cd9660 support would be a good thing to have once > > GEOM recognizes cdroms). > > That's what "Last mounted on" is for. > > Gotta wonder why we need volume devices, when we know where we are > going to mount the thing... So we can uniquely identify server1_usr and server2_usr when they're both on a SAN? That's what we use labels for here. Very useful if you accidentally mess up the SAN masks for a server. You don't need to use labels, but they have their uses. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 16:25:20 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C919037B401; Fri, 24 Jan 2003 16:25:18 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A37143EB2; Fri, 24 Jan 2003 16:25:17 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA12126; Sat, 25 Jan 2003 11:24:54 +1100 Date: Sat, 25 Jan 2003 11:26:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Wemm Cc: phk@FreeBSD.ORG, Kris Kennaway , Subject: Re: HEADSUP: DEVFS and GEOM mandatorification timeline. In-Reply-To: <20030124190057.91A3B2A7EA@canning.wemm.org> Message-ID: <20030125110722.C8080-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 Fri, 24 Jan 2003, Peter Wemm wrote: > phk@freebsd.org wrote: > > In message <20030121092851.A27172@citusc.usc.edu>, Kris Kennaway writes: > > >On Tue, Jan 21, 2003 at 12:58:12PM +0100, phk@FreeBSD.ORG wrote: > > >>=20 > > >> I have uploaded two patchfiles: > > >>=20 > > >> http://phk.freebsd.dk/patch/small.patch > > >> Removes just the options from sys/conf > > >>=20 > > >> http://phk.freebsd.dk/patch/big.patch > > >> unifdef -UNODEVFS -UNO_GEOM > > >> Removes roughly 2800 lines of code. > > > > > >To the best of your knowledge, there are no remaining serious bugs or > > >missing functionality with GEOM (like the disklabel editing problems > > >found before 5.0, etc)? > > > > There is one errata point (can't rewrite BSD boot code on a disk > > which is in use) which I am testing a patch for. > > > > I know of no bugs at present. Features like disklabel -r and disklabel -W not working are not bugs of course. > BTW; assuming these are taken care of, do we really gain anything by > waiting so long? Personally, I'd rather get it over and done with sooner > rather than later. What does waiting another month and a half buy us? The > handful folks who dont like it now are not going to start liking it by > March 1st :-(. Frankly I'd rather have an extra month focussed on this True. Some of us stopped working on FreeBSD already due to this. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 17: 8:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 955EE37B401 for ; Fri, 24 Jan 2003 17:08:12 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26B1943E4A for ; Fri, 24 Jan 2003 17:08:12 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.6/8.12.6) with ESMTP id h0P18BXv014225; Fri, 24 Jan 2003 17:08:11 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.6/8.12.6/Submit) id h0P18ABq014224; Fri, 24 Jan 2003 17:08:10 -0800 (PST) Date: Fri, 24 Jan 2003 17:08:10 -0800 From: Steve Kargl To: Gary Jennejohn Cc: arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030125010810.GA14191@troutmask.apl.washington.edu> References: <200301242051.h0OKpcOv029151@peedub.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301242051.h0OKpcOv029151@peedub.jennejohn.org> User-Agent: Mutt/1.4i 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 Fri, Jan 24, 2003 at 09:51:38PM +0100, Gary Jennejohn wrote: > I assume that this new scheduler is only for SMP? > > I tried it out on my UP machine - BTW on line 312 there's a missing > ``);'' - and the results were, not to pull any blows, catastrophic. > > Running X I started a ``make buildworld'' in an aterm and immediately > observerd: > o the cursor lagged way behind mouse movements > o switching desktops allowed me to observe in detail how various > applications repaint themselves - it was that slow > o mozilla was totally unusable > > With the current scheduler interactive applications are still quite > snappy. I never observe any of the above mentioned problems with it. > I know this is a WIP, but I thought I'd report my observations. > > This on an XP 1800+ with 768MB of memory and (fairly) fast SCSI disks. > I can (unfortunately) confirm Gary's observation. Building LAPACK, "make -j 2 buldworld" and running KDE brought my 1GHz athlon to its knees. Moving the mouse between windows/desktops was painfully slow/lagging. top(1) for a similar load on the current scheduler shows last pid: 4220; load averages: 2.51, 1.06, 0.43 up 0+00:22:02 17:06:20 81 processes: 4 running, 77 sleeping CPU states: 70.4% user, 0.0% nice, 29.6% system, 0.0% interrupt, 0.0% idle Mem: 84M Active, 93M Inact, 38M Wired, 1176K Cache, 48M Buf, 157M Free Swap: 356M Total, 356M Free With your new scheduler the load averages were (approximately) 7.5, 5.5, 5. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 18:14: 5 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBDEA37B401 for ; Fri, 24 Jan 2003 18:14:03 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BFE543ED8 for ; Fri, 24 Jan 2003 18:14:03 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0P2Dsw18046; Fri, 24 Jan 2003 21:13:54 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 24 Jan 2003 21:13:53 -0500 (EST) From: Jeff Roberson To: Steve Kargl Cc: Gary Jennejohn , Subject: Re: New scheduler In-Reply-To: <20030125010810.GA14191@troutmask.apl.washington.edu> Message-ID: <20030124211133.E2966-100000@mail.chesapeake.net> 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 Fri, 24 Jan 2003, Steve Kargl wrote: > On Fri, Jan 24, 2003 at 09:51:38PM +0100, Gary Jennejohn wrote: > > I assume that this new scheduler is only for SMP? > > > > I tried it out on my UP machine - BTW on line 312 there's a missing > > ``);'' - and the results were, not to pull any blows, catastrophic. > > > > Running X I started a ``make buildworld'' in an aterm and immediately > > observerd: > > o the cursor lagged way behind mouse movements > > o switching desktops allowed me to observe in detail how various > > applications repaint themselves - it was that slow > > o mozilla was totally unusable > > > > With the current scheduler interactive applications are still quite > > snappy. I never observe any of the above mentioned problems with it. > > I know this is a WIP, but I thought I'd report my observations. > > > > This on an XP 1800+ with 768MB of memory and (fairly) fast SCSI disks. > > > > I can (unfortunately) confirm Gary's observation. > Building LAPACK, "make -j 2 buldworld" and running > KDE brought my 1GHz athlon to its knees. Moving > the mouse between windows/desktops was painfully > slow/lagging. > > top(1) for a similar load on the current scheduler shows > > last pid: 4220; load averages: 2.51, 1.06, 0.43 up 0+00:22:02 17:06:20 > 81 processes: 4 running, 77 sleeping > CPU states: 70.4% user, 0.0% nice, 29.6% system, 0.0% interrupt, 0.0% idle > Mem: 84M Active, 93M Inact, 38M Wired, 1176K Cache, 48M Buf, 157M Free > Swap: 356M Total, 356M Free > > With your new scheduler the load averages were (approximately) > 7.5, 5.5, 5. > Ah, the interactivity has regressed. Can you try something like this: /* * This macro determines whether or not the kse belongs on the current or * next run queue. */ #define SCHED_CURR(kg) ((kg)->kg_slptime > (hz / 4) || \ (kg)->kg_pri_class != PRI_TIMESHARE) change the (hz / 4) to (hz / 10) Let me know how that goes? I'm not going to be able to work on this for a bit. I just had some minor surgery and the painkillers are making it hard to think clearly. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 20:47:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D7F737B401 for ; Fri, 24 Jan 2003 20:47:49 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF56943F43 for ; Fri, 24 Jan 2003 20:47:48 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.6/8.12.6) with ESMTP id h0P4lfXv015074; Fri, 24 Jan 2003 20:47:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.6/8.12.6/Submit) id h0P4lfcJ015073; Fri, 24 Jan 2003 20:47:41 -0800 (PST) Date: Fri, 24 Jan 2003 20:47:41 -0800 From: Steve Kargl To: Jeff Roberson Cc: Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030125044741.GA15046@troutmask.apl.washington.edu> References: <20030125010810.GA14191@troutmask.apl.washington.edu> <20030124211133.E2966-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030124211133.E2966-100000@mail.chesapeake.net> User-Agent: Mutt/1.4i 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 Fri, Jan 24, 2003 at 09:13:53PM -0500, Jeff Roberson wrote: > > Ah, the interactivity has regressed. Can you try something like this: > > /* > * This macro determines whether or not the kse belongs on the current or > * next run queue. > */ > #define SCHED_CURR(kg) ((kg)->kg_slptime > (hz / 4) || \ > (kg)->kg_pri_class != PRI_TIMESHARE) > > change the (hz / 4) to (hz / 10) > > Let me know how that goes? I'm not going to be able to work on this for a > bit. I just had some minor surgery and the painkillers are making it hard > to think clearly. > It did not help. The load averages reported be top(1) with the above change in palce are 7.86, 9.01, 8.72. I left the machine running for 45 minute and lost about 6 minutes on the system clock. Time is sync'd with ntp. When I came back to the machine there was no keyboard or mouse response. The reset button was the only recourse. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 20:52: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97DFF37B401 for ; Fri, 24 Jan 2003 20:52:07 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2547143F18 for ; Fri, 24 Jan 2003 20:52:07 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.6/8.12.6) with ESMTP id h0P4q5Xv015103; Fri, 24 Jan 2003 20:52:05 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.6/8.12.6/Submit) id h0P4q5PW015102; Fri, 24 Jan 2003 20:52:05 -0800 (PST) Date: Fri, 24 Jan 2003 20:52:05 -0800 From: Steve Kargl To: Jeff Roberson Cc: Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030125045205.GA15091@troutmask.apl.washington.edu> References: <20030125010810.GA14191@troutmask.apl.washington.edu> <20030124211133.E2966-100000@mail.chesapeake.net> <20030125044741.GA15046@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030125044741.GA15046@troutmask.apl.washington.edu> User-Agent: Mutt/1.4i 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 Fri, Jan 24, 2003 at 08:47:41PM -0800, Steve Kargl wrote: > On Fri, Jan 24, 2003 at 09:13:53PM -0500, Jeff Roberson wrote: > > > > It did not help. The load averages reported be top(1) > with the above change in palce are 7.86, 9.01, 8.72. Jeff, it isn't the painkillers. The 2nd sentence should read "The load averages, reported by top(1) with the above change in place, are 7.86, 9.01, 8.72" -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 24 22:28:31 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 199A037B405 for ; Fri, 24 Jan 2003 22:28:30 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46C5843ED8 for ; Fri, 24 Jan 2003 22:28:03 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id h0P6PsIm153614; Sat, 25 Jan 2003 01:25:56 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3E31C4F5.972AA69C@mindspring.com> References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> <3E31C4F5.972AA69C@mindspring.com> Date: Sat, 25 Jan 2003 01:25:53 -0500 To: Terry Lambert , Gordon Tetlow From: Garance A Drosihn Subject: Re: CFR: Volume labels in FFS Cc: 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 2:57 PM -0800 1/24/03, Terry Lambert wrote: >Gordon Tetlow wrote: > > > No, it actually creates device nodes in /dev/vol/, > > > so it be more like this: > > > >> > /dev/vol/rootfs / ufs rw 1 1 > > > /dev/vol/usrfs /usr ufs rw 2 2 > > > ...etc... >> > > > > I didn't go the Linux route and do LABEL= because there is > > > alot of black magic in the loader that reads /etc/fstab looking > > > for the root partition and I didn't want to mess with fstab.h > > > and friends. > > > > I can also forsee being able to hook into devd to do some > > automounting magic for things like zip disks and cdroms > > (obviously not with FFS, but cd9660 support would be a good > > thing to have once GEOM recognizes cdroms). > >That's what "Last mounted on" is for. > >Gotta wonder why we need volume devices, when we know where we >are going to mount the thing... Actually, now that I know how it's going to work, I like it. In my mind this is much better than "last mounted on". The problem I'd like to solve is when I've got my PC disks set up to multi-boot between several different freebsd systems (4.x, 5.x, 5.x-backup, etc). I've had up to eight different freebsd systems defined on a single PC, and when I switch from 4.x to 5.x, I sure as hell don't want to take /usr from 4.x and remount it as /usr when I reboot into 5.x just because it was last-mounted-as /usr on 4.x. If I understand this right, I will be able to label the partition "usr4x", and in /etc/fstab for 4.x I'd have: /dev/vol/usr4x /usr ufs rw 2 2 while the /etc/fstab on 5.x would have: /dev/vol/usr4x /x4x/usr ufs rw 3 3 If so, then I very much like this idea. -- Garance Alistair Drosehn = gad@gilead.netel.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 Fri Jan 24 23:36:32 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F35B37B401 for ; Fri, 24 Jan 2003 23:36:31 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25EF043F5B for ; Fri, 24 Jan 2003 23:36:31 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 049092A89E; Fri, 24 Jan 2003 23:36:24 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Terry Lambert Cc: Gordon Tetlow , Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS In-Reply-To: <3E31C4F5.972AA69C@mindspring.com> Date: Fri, 24 Jan 2003 23:36:23 -0800 From: Peter Wemm Message-Id: <20030125073624.049092A89E@canning.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 Terry Lambert wrote: > Gordon Tetlow wrote: > > > No, it actually creates device nodes in /dev/vol/, so it be more > > > like this: > > > > > > /dev/vol/rootfs / ufs rw 1 1 > > > /dev/vol/usrfs /usr ufs rw 2 2 > > > ...etc... > > > > > > I didn't go the Linux route and do LABEL= because there is alot of > > > black magic in the loader that reads /etc/fstab looking for the root > > > partition and I didn't want to mess with fstab.h and friends. > > > > I can also forsee being able to hook into devd to do some automounting magi c > > for things like zip disks and cdroms (obviously not with FFS, but cd9660 > > support would be a good thing to have once GEOM recognizes cdroms). > > > That's what "Last mounted on" is for. Umm, no thanks. > Gotta wonder why we need volume devices, when we know where we > are going to mount the thing... This is far too unreliable. Check what happens (for example) when you boot from floppy and mount your partitions as /mnt/foo. I dont want the system to helpfully remember that for me. I much prefer Gordon's approach. It's deterministic and isn't going to be messed with during the normal course of system administration. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "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 Sat Jan 25 1:46:58 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5D4B37B401 for ; Sat, 25 Jan 2003 01:46:56 -0800 (PST) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C5143ED8 for ; Sat, 25 Jan 2003 01:46:55 -0800 (PST) (envelope-from nsouch@free.fr) Received: from armor.fastether (nas-cbv-7-62-147-153-9.dial.proxad.net [62.147.153.9]) by postfix3-2.free.fr (Postfix) with SMTP id C4A53C076 for ; Sat, 25 Jan 2003 10:46:48 +0100 (CET) Received: (qmail 19542 invoked by uid 1001); 25 Jan 2003 09:34:26 -0000 Date: Sat, 25 Jan 2003 10:34:26 +0100 From: Nicolas Souchu To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Console implementation: summary and personal conclusion Message-ID: <20030125103426.G14066@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122215115.GC590@dhcp01.pn.xcllnt.net> <20030124093430.A14066@armor.fastether> <20030124212010.GA44543@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030124212010.GA44543@dhcp01.pn.xcllnt.net>; from marcel@xcllnt.net on Fri, Jan 24, 2003 at 01:20:10PM -0800 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 Fri, Jan 24, 2003 at 01:20:10PM -0800, Marcel Moolenaar wrote: [...] > I think that if we focus on our immediate needs, but don't cut > corners that can't be "uncut" we should go for something like KGI. > We already have a vga and tga driver and those can be used to > bootstrap something new. Even if we have to write a driver from > scratch, we don't have to write a 2D/3D accelerator. Get a portable > console implemetation first, even if it's text-only. If we make > sure we can provide compatibility with pcvt, we can keep syscons > for i386. After that, we can work on the future... > > Thoughts? Well summarized. For the compatibility I already have planned the following mechanisms (vidsw is the current console/video_driver API): -------- VGA -------- <- vidsw VESA -------- <- vidsw kgiy *new KGI display code* -------- KGI (ported KGI) -------- kgia *new KGI device code* -------- <- vidsw syscons -------- VGL -------- At least, all this is necessary for testing. Similar approach is used for keyboard: -------- atkbdc -------- atkbd (or ukbd) -------- <- kbd kiidrv *new KII input code* -------- KII (ported KGI) -------- kiikbd *new KII device code* -------- <- kbd syscons -------- VGL -------- But the one which won't be compatible with above scheme is certainly pcvt... Ok, all this is too much code, but for the moment it helps integrating and understanding KII/KGI. Once definitely accepted and trusted we'll rip the extra code. -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 3:59:16 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 317F437B401 for ; Sat, 25 Jan 2003 03:59:15 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59BF843F13 for ; Sat, 25 Jan 2003 03:55:13 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.5/8.12.5) with ESMTP id h0PBtBLZ021938 for ; Sat, 25 Jan 2003 22:55:11 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h0PBrp5o021926; Sat, 25 Jan 2003 22:53:51 +1100 (EST) Date: Sat, 25 Jan 2003 22:53:51 +1100 From: Peter Jeremy To: Rodolphe Ortalo Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030125115351.GA21347@cirb503493.alcatel.com.au> References: <20030123234431.GB555@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i 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 Fri, Jan 24, 2003 at 10:58:12PM +0100, Rodolphe Ortalo wrote: >I understand clearly why doing so may be important for serial consoles (or >possibly other non-display adapters), but wrt most (modern) VGA adapters, >I have the feeling that discarding the state and switching to some >advanced mode should be done as soon as possible! :-) I'd prefer to retain state if at all possible. It's very useful being able to look back through the kernel output - whilst working on the TGA driver, I found it quite annoying that the main TGA device probe would wipe all the state. (This is also something I find particularly irritating about sysinstall - the probe messages are all wiped by the sysinstall menu so you don't know if the hardware was found correctly). Personally, I don't see why it's at all important to switch out of text mode quickly. Kernel output messages are inherently text so switching to a graphics mode just makes more work for the kernel. I know Sun have had their logo in the boot screen for as long as I can recall - and it's getting fancier with time - but I fail to see that this is more than unnecessary frippery. > Note that this does not necessarily mean discarding VGA-style display >mode; but for example if the board allows to access all needed VGA >registers via a MMIO area (instead of the usual fixed adresses regs around >0x3C0) and its framebuffer (including the VGA part) via another area, Whilst I can't verify it, I believe Tru64 does something like this. It's quite obvious that the text font on a VGA card changes when the card is probed during the main device tree scan. Presumably the card is being switched to a graphics mode by the main device driver. >difficult to share) VGA adresses in a multiple-boards configuration are >cleared, and further initialisations of remaining boards can proceed more >cleanly. How common is this? And how important is it that both cards function during boot? I have two Matrox Millennium-II cards in one of my systems and I'm not at all fazed by one of them not being initialised until X starts. I suspect that very few people have more than one graphics adapter and even fewer want to be able to use both adapters outside X. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 4: 1:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A847237B401 for ; Sat, 25 Jan 2003 04:01:25 -0800 (PST) Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7849043F18 for ; Sat, 25 Jan 2003 04:01:24 -0800 (PST) (envelope-from danfe@regency.nsu.ru) Received: from drweb by mail.nsu.ru with drweb-scanned (Exim 3.20 #1) id 18cOzb-00044j-00; Sat, 25 Jan 2003 18:00:59 +0600 Received: from regency.nsu.ru ([193.124.210.26]) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 18cOzZ-00043Z-00; Sat, 25 Jan 2003 18:00:57 +0600 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.6/8.12.6) with ESMTP id h0PC4ZH7027244; Sat, 25 Jan 2003 18:04:35 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.6/8.12.6/Submit) id h0PC4XIW027213; Sat, 25 Jan 2003 18:04:33 +0600 (NOVT) Date: Sat, 25 Jan 2003 18:04:33 +0600 From: Alexey Dokuchaev To: Terry Lambert Cc: Gordon Tetlow , Garance A Drosihn , arch@freebsd.org Subject: Re: CFR: Volume labels in FFS Message-ID: <20030125120433.GA24687@regency.nsu.ru> References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> <3E31C4F5.972AA69C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E31C4F5.972AA69C@mindspring.com> User-Agent: Mutt/1.4i X-Envelope-To: tlambert2@mindspring.com, gordont@gnf.org, drosih@rpi.edu, 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 Fri, Jan 24, 2003 at 02:57:57PM -0800, Terry Lambert wrote: > Gordon Tetlow wrote: > > > No, it actually creates device nodes in /dev/vol/, so it be more > > > like this: > > > > > > /dev/vol/rootfs / ufs rw 1 1 > > > /dev/vol/usrfs /usr ufs rw 2 2 > > > ...etc... > > > > > > I didn't go the Linux route and do LABEL= because there is alot of > > > black magic in the loader that reads /etc/fstab looking for the root > > > partition and I didn't want to mess with fstab.h and friends. > > > > I can also forsee being able to hook into devd to do some automounting magic > > for things like zip disks and cdroms (obviously not with FFS, but cd9660 > > support would be a good thing to have once GEOM recognizes cdroms). > > That's what "Last mounted on" is for. > > Gotta wonder why we need volume devices, when we know where we > are going to mount the thing... I second Terry here; seeing little-to-none sense in volume lables as they are. ./danfe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 10:58:45 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE49437B401 for ; Sat, 25 Jan 2003 10:58:44 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17DAA43ED8 for ; Sat, 25 Jan 2003 10:58:44 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id h0PIwYP4007913; Sat, 25 Jan 2003 13:58:34 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 25 Jan 2003 13:58:33 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Steve Kargl Cc: Jeff Roberson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler In-Reply-To: <20030125045205.GA15091@troutmask.apl.washington.edu> 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 Fri, 24 Jan 2003, Steve Kargl wrote: > On Fri, Jan 24, 2003 at 08:47:41PM -0800, Steve Kargl wrote: > > On Fri, Jan 24, 2003 at 09:13:53PM -0500, Jeff Roberson wrote: > > > > > > > It did not help. The load averages reported be top(1) > > with the above change in palce are 7.86, 9.01, 8.72. > > Jeff, it isn't the painkillers. The 2nd sentence should read "The load > averages, reported by top(1) with the above change in place, are 7.86, > 9.01, 8.72" Part of the problem is that the load average is a poor measure of system utilization. Jeff's new scheduler may defer scheduling a process that's ready to run to improve throughput and wait for a "better" CPU to run a process on based on affinity. Potentially the result might be that the run queues are (on average) deeper, and what the load average does is measure the depth of the run queue over time. So for the moment, it's probably best to disregard load average as a measure of performance. On the other hand, actual interactivity regressions and performance changes are very relevant. Load average is intended to capture the degree of contention for CPU resources, but what exactly that means is always an interesting question. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 11:25:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11FBE37B401; Sat, 25 Jan 2003 11:25:24 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8962043F43; Sat, 25 Jan 2003 11:25:23 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.6/8.12.6) with ESMTP id h0PJPLXv018292; Sat, 25 Jan 2003 11:25:21 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.6/8.12.6/Submit) id h0PJPLaT018291; Sat, 25 Jan 2003 11:25:21 -0800 (PST) Date: Sat, 25 Jan 2003 11:25:21 -0800 From: Steve Kargl To: Robert Watson Cc: Jeff Roberson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030125192521.GA18048@troutmask.apl.washington.edu> References: <20030125045205.GA15091@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i 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, Jan 25, 2003 at 01:58:33PM -0500, Robert Watson wrote: > On Fri, 24 Jan 2003, Steve Kargl wrote: > > On Fri, Jan 24, 2003 at 08:47:41PM -0800, Steve Kargl wrote: > > > > > > It did not help. The load averages reported be top(1) > > > with the above change in palce are 7.86, 9.01, 8.72. > > > > Jeff, it isn't the painkillers. The 2nd sentence should read "The load > > averages, reported by top(1) with the above change in place, are 7.86, > > 9.01, 8.72" > > Part of the problem is that the load average is a poor measure of system > utilization. Jeff's new scheduler may defer scheduling a process that's > ready to run to improve throughput and wait for a "better" CPU to run a > process on based on affinity. Potentially the result might be that the > run queues are (on average) deeper, and what the load average does is > measure the depth of the run queue over time. So for the moment, it's > probably best to disregard load average as a measure of performance. On > the other hand, actual interactivity regressions and performance changes > are very relevant. Load average is intended to capture the degree of > contention for CPU resources, but what exactly that means is always an > interesting question. > Robert, I'm sure your analysis is correct. All I can say is that Jeff's experimental scheduler will bring a UP system to its knees. The system I tested on runs NTP to sync the clock, and the system clock lost 6 minutes of wall-clock time in 45 minutes. The two possible causes of the problem (that I can think of) are (1) deadlock in the scheduler or (2) processes are ping-ponging between run queues without actually getting a time slice. Unfortunately, I was running X window at the time and could not break into the debugger. I'll try again later today to what ddb says. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 11:57: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78BA237B401; Sat, 25 Jan 2003 11:57:07 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D7C143F13; Sat, 25 Jan 2003 11:57:06 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0PJv40i039705; Sat, 25 Jan 2003 11:57:04 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0PJv4Jd039704; Sat, 25 Jan 2003 11:57:04 -0800 (PST) Date: Sat, 25 Jan 2003 11:57:04 -0800 (PST) From: Matthew Dillon Message-Id: <200301251957.h0PJv4Jd039704@apollo.backplane.com> To: Steve Kargl Cc: Robert Watson , Jeff Roberson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler References: <20030125045205.GA15091@troutmask.apl.washington.edu> <20030125192521.GA18048@troutmask.apl.washington.edu> 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 From looking at the code I am fairly confident that the UP and possible ping-ponging problems can be fixed. This code looks like earlier versions of my fractional-fair scheduler. I'm going to play with it and offer up some suggestions. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 12:13:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E9C637B405 for ; Sat, 25 Jan 2003 12:13:49 -0800 (PST) Received: from newsguy.com (smtp.newsguy.com [129.250.170.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DABD43F1E for ; Sat, 25 Jan 2003 12:13:47 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (200-163-023-225.bsace7016.dsl.brasiltelecom.net.br [200.163.23.225]) by newsguy.com (8.9.1a/8.9.1) with ESMTP id MAA75133; Sat, 25 Jan 2003 12:12:26 -0800 (PST) Message-ID: <3E32EF99.C3E07015@newsguy.com> Date: Sat, 25 Jan 2003 18:12:09 -0200 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en,pt-BR,pt,en-GB,en-US,ja MIME-Version: 1.0 To: Alexey Dokuchaev Cc: Terry Lambert , Gordon Tetlow , Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> <3E31C4F5.972AA69C@mindspring.com> <20030125120433.GA24687@regency.nsu.ru> 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 Alexey Dokuchaev wrote: > > > That's what "Last mounted on" is for. > > > > Gotta wonder why we need volume devices, when we know where we > > are going to mount the thing... > > I second Terry here; seeing little-to-none sense in volume lables as > they are. Well, Terry's solution wouldn't work on my very trivial system. After all, I have two /usr, two /var, even two /. One of each is chosen when I boot current, and the other when I boot stable. If it can't handle even something that simple, what it can handle? Nothing. The only thing it can handle is mounting from the devices we already know, thus giving us absolutely nothing. I can't swap disks and install a new system, and them mount partitions of the old disk to grab the data. I can't put in a foreign hd to copy something. And I don't even want to think of shared disks. Terry is only interested in one thing: docking his notebook. Honestly, that could be solved with devd alone. _This_ really helps managing server enviroments. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@professional.bsdconspiracy.net Spellng is overated anywy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 13:55:57 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C394F37B401 for ; Sat, 25 Jan 2003 13:55:55 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C788543F18 for ; Sat, 25 Jan 2003 13:55:54 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0PLtrMW049322; Sat, 25 Jan 2003 13:55:53 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0PLtqgR000809; Sat, 25 Jan 2003 13:55:52 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0PLto7l000808; Sat, 25 Jan 2003 13:55:50 -0800 (PST) (envelope-from marcel) Date: Sat, 25 Jan 2003 13:55:50 -0800 From: Marcel Moolenaar To: Peter Jeremy Cc: Rodolphe Ortalo , arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030125215550.GA589@dhcp01.pn.xcllnt.net> References: <20030123234431.GB555@athlon.pn.xcllnt.net> <20030125115351.GA21347@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030125115351.GA21347@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.3i 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, Jan 25, 2003 at 10:53:51PM +1100, Peter Jeremy wrote: > > Personally, I don't see why it's at all important to switch out of > text mode quickly. Kernel output messages are inherently text so > switching to a graphics mode just makes more work for the kernel. There are two reasons why I like switching to graphics mode early: 1. The machine on which we're running may or may not support text mode. Support for text mode may be sub-optimal due to the focus on graphics support. In the latter case it probably works, but the quality of the output may be low (only using 3/4 or 2/3 of the LCD area in text mode is low quality). Note that this low quality is not limited to kernel output. One has to work with it until ones favorite GUI is up and running. This includes the whole sysinstall process on new machines, possibly run by a first-time FreeBSD user who is used to Windows. Ouch... 2. 64-bit architectures obviously need more space to print addresses and there tends to be more memory mapping. During device probing, when the display width is limited to 80 characters, this more frequently results in line wraps than on 32-bit architectures. Switching to graphics mode allows us to take advantage of a longer line and thereby improving the "neatness" of the output. -- 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 Sat Jan 25 14: 4:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E53AD37B401 for ; Sat, 25 Jan 2003 14:04:24 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F95743F65 for ; Sat, 25 Jan 2003 14:04:24 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0PM4J8k013889; Sat, 25 Jan 2003 23:04:20 +0100 (CET) (envelope-from phk@freebsd.org) To: Marcel Moolenaar Cc: Peter Jeremy , Rodolphe Ortalo , arch@freebsd.org Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) From: phk@freebsd.org In-Reply-To: Your message of "Sat, 25 Jan 2003 13:55:50 PST." <20030125215550.GA589@dhcp01.pn.xcllnt.net> Date: Sat, 25 Jan 2003 23:04:19 +0100 Message-ID: <13888.1043532259@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 In message <20030125215550.GA589@dhcp01.pn.xcllnt.net>, Marcel Moolenaar writes : >On Sat, Jan 25, 2003 at 10:53:51PM +1100, Peter Jeremy wrote: >> >> Personally, I don't see why it's at all important to switch out of >> text mode quickly. Kernel output messages are inherently text so >> switching to a graphics mode just makes more work for the kernel. > >There are two reasons why I like switching to graphics mode early: Will panic messages and DDB work in graphics mode ? (Any reservations on this point and I'm dead set against it.) Will the kernel be sufficiently aware of the mode the Xserver have put the screen in, to allow panic and DDB to work even when running X ? (If yes, then I'm all for it :-) -- 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 Sat Jan 25 14:23:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12C8737B401; Sat, 25 Jan 2003 14:23:42 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 323EE43EB2; Sat, 25 Jan 2003 14:23:41 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0PMNYq96481; Sat, 25 Jan 2003 17:23:34 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Jan 2003 17:23:34 -0500 (EST) From: Jeff Roberson To: Steve Kargl Cc: Robert Watson , Gary Jennejohn , Subject: Re: New scheduler In-Reply-To: <20030125192521.GA18048@troutmask.apl.washington.edu> Message-ID: <20030125171217.D18109-100000@mail.chesapeake.net> 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, 25 Jan 2003, Steve Kargl wrote: > On Sat, Jan 25, 2003 at 01:58:33PM -0500, Robert Watson wrote: > > > > Part of the problem is that the load average is a poor measure of system > > utilization. Jeff's new scheduler may defer scheduling a process that's > > ready to run to improve throughput and wait for a "better" CPU to run a > > process on based on affinity. Potentially the result might be that the > > run queues are (on average) deeper, and what the load average does is > > measure the depth of the run queue over time. So for the moment, it's > > probably best to disregard load average as a measure of performance. On > > the other hand, actual interactivity regressions and performance changes > > are very relevant. Load average is intended to capture the degree of > > contention for CPU resources, but what exactly that means is always an > > interesting question. > > > > Robert, I'm sure your analysis is correct. All I can > say is that Jeff's experimental scheduler will bring > a UP system to its knees. The system I tested on > runs NTP to sync the clock, and the system clock lost > 6 minutes of wall-clock time in 45 minutes. The two > possible causes of the problem (that I can think of) > are (1) deadlock in the scheduler or (2) processes are > ping-ponging between run queues without actually getting > a time slice. Unfortunately, I was running X window > at the time and could not break into the debugger. I'll > try again later today to what ddb says. > A process will not leave it's current run queue until it has exhausted its slice. If it does, it is a bug. You can see that this is the case by looking at sched_clock() which resets the runq to NULL when the slice is exhausted. Then in sched_add() we pick a new queue if it is NULL otherwise we use the queue that the kse is using. There are a few potential problems. One is that processes which are deemed interactive are ALWAYS put on the current queue. They will hold the current queue in place until they sleep which will starve any process which is on the alternate queue. The code that decides interactivity is far too simple. It could be that non interactive tasks are being marked as interactive and holding up the queues. There is another potential problem. I think that tasks which are interactive are not getting reassigned to the front queue when they wake up. I believe the runq should be reassigned in sched_wakeup(). This would cause horrible interactivity. I can come up with patches for the second problem but probably not for another day. If someone else wants to experiment you can look at the code in sched_add that reassigns the runq and do that in sched_wakeup() if we think the process is interactive. I appreciate the testing. I must admit that the interactivity testing that I had done was with parallel buildworlds and vi. I haven't done much with guis, other than run this on my laptop which is 2ghz. I think these problems should be relatively quick to address. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 14:40:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A504C37B401 for ; Sat, 25 Jan 2003 14:40:48 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1948F43EB2 for ; Sat, 25 Jan 2003 14:40:48 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0008.cvx40-bradley.dialup.earthlink.net ([216.244.42.8] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18cYxR-0003Iy-00; Sat, 25 Jan 2003 14:39:26 -0800 Message-ID: <3E3311CA.5646F3AA@mindspring.com> Date: Sat, 25 Jan 2003 14:38:02 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Eugene M. Kim" Cc: Alexey Dokuchaev , Gordon Tetlow , Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> <3E31C4F5.972AA69C@mindspring.com> <20030125120433.GA24687@regency.nsu.ru> <20030125185338.GA54691@purple.the-7.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4606d14a7b49ad307b848c15ed3013074a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c 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 "Eugene M. Kim" wrote: > > > > I can also forsee being able to hook into devd to do some > > > > automounting magic for things like zip disks and cdroms > > > > (obviously not with FFS, but cd9660 support would be a good > > > > thing to have once GEOM recognizes cdroms). > > > > > > That's what "Last mounted on" is for. > > > > > > Gotta wonder why we need volume devices, when we know where we > > > are going to mount the thing... > > > > I second Terry here; seeing little-to-none sense in volume lables as > > they are. > > `Last mounted on' is useful only when a disk is assumed to be used on > one computer. If you wanted to mount a removable data disk at /data on > computer A but at /mydata on computer B and so on, we do need some > volume label. You all misunderstand. I was asking why you were introducing another field in the superblock, rather than using the "last mounted on" field. Maybe I should point out that the "last mounted on" field is write-only, and no one uses it, particularly since it is not longer possible to open the block device and examine a live FS (given that there are no longer block devices). I'll also point out that the only reason an FS type has to be able to distinguish a root mount from a non-root mount boils down to two things: o Covering the moint point, which should be done in upper level code anyway, since it's an operation common to all FS's in the non-root mount case o Setting of the "last mounted on" data contents in the superblock Even if nothing else happens, and you decide to keep around this appendix of "last mounted on", at the very least, the code should be reorganized so that the setting/getting of it is a new VFSOP. Note that I first suggested doing this, and provided code that did this, in 1996. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 14:46: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 520A637B401 for ; Sat, 25 Jan 2003 14:46:05 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD1643EB2 for ; Sat, 25 Jan 2003 14:46:00 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0008.cvx40-bradley.dialup.earthlink.net ([216.244.42.8] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18cZ3b-0003ww-00; Sat, 25 Jan 2003 14:45:47 -0800 Message-ID: <3E331344.6A2A60BC@mindspring.com> Date: Sat, 25 Jan 2003 14:44:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Daniel C. Sobral" Cc: Alexey Dokuchaev , Gordon Tetlow , Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> <3E31C4F5.972AA69C@mindspring.com> <20030125120433.GA24687@regency.nsu.ru> <3E32EF99.C3E07015@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4606d14a7b49ad3073a110385c627888ca7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c 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 C. Sobral" wrote: > Well, Terry's solution wouldn't work on my very trivial system. After > all, I have two /usr, two /var, even two /. One of each is chosen when I > boot current, and the other when I boot stable. See other posting. > Terry is only interested in one thing: docking his notebook. Honestly, > that could be solved with devd alone. What are you smoking? I first suggested this use of the "last mounted on" field back in 1994, for the purpose of supporting auto-mounting on device "arrival" for removable media. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 14:51:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5739A37B401; Sat, 25 Jan 2003 14:51:33 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DCF643F18; Sat, 25 Jan 2003 14:51:32 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0PMpWMW049558; Sat, 25 Jan 2003 14:51:32 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0PMpVgR000966; Sat, 25 Jan 2003 14:51:31 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0PMpVnj000965; Sat, 25 Jan 2003 14:51:31 -0800 (PST) (envelope-from marcel) Date: Sat, 25 Jan 2003 14:51:31 -0800 From: Marcel Moolenaar To: phk@freebsd.org Cc: Peter Jeremy , Rodolphe Ortalo , arch@freebsd.org Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030125225131.GA897@dhcp01.pn.xcllnt.net> References: <20030125215550.GA589@dhcp01.pn.xcllnt.net> <13888.1043532259@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13888.1043532259@critter.freebsd.dk> User-Agent: Mutt/1.5.3i 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, Jan 25, 2003 at 11:04:19PM +0100, phk@freebsd.org wrote: > In message <20030125215550.GA589@dhcp01.pn.xcllnt.net>, Marcel Moolenaar writes > : > >On Sat, Jan 25, 2003 at 10:53:51PM +1100, Peter Jeremy wrote: > >> > >> Personally, I don't see why it's at all important to switch out of > >> text mode quickly. Kernel output messages are inherently text so > >> switching to a graphics mode just makes more work for the kernel. > > > >There are two reasons why I like switching to graphics mode early: > > Will panic messages and DDB work in graphics mode ? It has to and I don't see any reason why it can't. Instead of depending on the existence of fonts on the graphics controllers we depend on fonts one can compile-in or pre-load in the loader. Switching to graphics mode to me does not imply using it for non-text purposes right away, although it opens up that door... > Will the kernel be sufficiently aware of the mode the Xserver have > put the screen in, to allow panic and DDB to work even when running X ? I cannot really answer this other than that if you pull more knowledge about the graphics hardware from userland into the kernel you increase the possibility. We basicly don't know anything about the hardware other than the VGA compatibility it provides. I don't think we need to know the ins and outs of the controller to make it work. I think we "only" need to know how to write to the frame buffer so that we can use the current mode, whatever it is. I think this problem is more naturally solved if we have the infrastructure in place to have the controller operate in graphics mode from as soon as we can... -- 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 Sat Jan 25 15:20:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CEB537B401; Sat, 25 Jan 2003 15:20:33 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EEFB43F5F; Sat, 25 Jan 2003 15:20:33 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0PNKV0i090078; Sat, 25 Jan 2003 15:20:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0PNKVoq090077; Sat, 25 Jan 2003 15:20:31 -0800 (PST) Date: Sat, 25 Jan 2003 15:20:31 -0800 (PST) From: Matthew Dillon Message-Id: <200301252320.h0PNKVoq090077@apollo.backplane.com> To: Jeff Roberson Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler References: <20030125171217.D18109-100000@mail.chesapeake.net> 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 Jeff, while investigating your patch I found a couple of possible issues which I think are causing the time problems. The first problem is sched_choose() appears to be causing a lot of ping-ponging because the swap is made permanent. i.e. it swaps cpu queues but then the new queue (belonging to another cpu) becomes the current queue. For the current choose it doesn't matter, but for the NEXT time choose is called it does. The second issue has to do with the way kg_slptime is calculated. It just doesn't look right to me. I think a better solution is to add an additional field, kg_runtime, and rather then trying to decrement kg_slptime you instead increment kg_runtime, then use the ratio kg_runtime / kg_slptime to calculate the interactivity of the process. If either kg_runtime or kg_slptime exceed SCHED_SLP_MAX, simply scale both down (to deal with overflows). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 15:50: 9 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34E9637B401; Sat, 25 Jan 2003 15:50:08 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C933E43F43; Sat, 25 Jan 2003 15:50:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0PNo60i009490; Sat, 25 Jan 2003 15:50:06 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0PNo6xO009489; Sat, 25 Jan 2003 15:50:06 -0800 (PST) Date: Sat, 25 Jan 2003 15:50:06 -0800 (PST) From: Matthew Dillon Message-Id: <200301252350.h0PNo6xO009489@apollo.backplane.com> To: Jeff Roberson , Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler (#2) References: <20030125171217.D18109-100000@mail.chesapeake.net> <200301252320.h0PNKVoq090077@apollo.backplane.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 found another problem. In sched_exit() you are 'returning' part of the child's priority and interactivity to the parent, but you are not taking into account batch processes. A batch child which is exiting, such as the 'cc1' in a 'cc' or the 'cc' in a 'make' (you see where this is leading? Consider a 'make buildworld') must penalize the parent so the next fork/exec'd child retains the batch priority. The 4bsd code does this. The sched_smp code does not. The sched_smp code simply adds to kg_slptime and this can *never* penalize the parent. The result is that the parent retains its near-zero cpu utilization (because all it is doing is fork/exec/wait). This could be the primary cause of the interactive/buildworld latency reports. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 15:52:29 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A00737B401 for ; Sat, 25 Jan 2003 15:52:28 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFE0443F43 for ; Sat, 25 Jan 2003 15:52:27 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.6/8.12.6) id h0PNqMwD055701; Sat, 25 Jan 2003 17:52:22 -0600 (CST) (envelope-from dan) Date: Sat, 25 Jan 2003 17:52:22 -0600 From: Dan Nelson To: Terry Lambert Cc: "Daniel C. Sobral" , Alexey Dokuchaev , Gordon Tetlow , Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: CFR: Volume labels in FFS Message-ID: <20030125235221.GA23649@dan.emsphone.com> References: <20030124212259.GJ53114@roark.gnf.org> <20030124215753.GM53114@roark.gnf.org> <20030124222718.GN53114@roark.gnf.org> <3E31C4F5.972AA69C@mindspring.com> <20030125120433.GA24687@regency.nsu.ru> <3E32EF99.C3E07015@newsguy.com> <3E331344.6A2A60BC@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E331344.6A2A60BC@mindspring.com> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.3i 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 the last episode (Jan 25), Terry Lambert said: > "Daniel C. Sobral" wrote: > > Well, Terry's solution wouldn't work on my very trivial system. > > After all, I have two /usr, two /var, even two /. One of each is > > chosen when I boot current, and the other when I boot stable. > > See other posting. > > > Terry is only interested in one thing: docking his notebook. > > Honestly, that could be solved with devd alone. > > What are you smoking? > > I first suggested this use of the "last mounted on" field back in > 1994, for the purpose of supporting auto-mounting on device "arrival" > for removable media. You should probably refer to it as your suggestion to rename "last mounted on" to "volume label", since people seem to think you want it to keep its original behaviour. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 17:14:37 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16CF437B401; Sat, 25 Jan 2003 17:14:35 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D74A43ED8; Sat, 25 Jan 2003 17:14:35 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0Q1EY0i017547; Sat, 25 Jan 2003 17:14:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0Q1EXuu017546; Sat, 25 Jan 2003 17:14:33 -0800 (PST) Date: Sat, 25 Jan 2003 17:14:33 -0800 (PST) From: Matthew Dillon Message-Id: <200301260114.h0Q1EXuu017546@apollo.backplane.com> To: Jeff Roberson , Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler (#3) References: <20030125171217.D18109-100000@mail.chesapeake.net> <200301252320.h0PNKVoq090077@apollo.backplane.com> <200301252350.h0PNo6xO009489@apollo.backplane.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 Found another bug. In sched_sleep() you set td_slptime to ticks in order to calculate the time slept in sched_wakeup(). You have to do the same thing in sched_switchout() (or move it to sched_switchout()?), because not all kernel subsystems use msleep(). For example, select() does it manually and uses mi_switch(), which means that sched_sleep() is never called. (select() uses condvars which use mi_switch(). The wakeup portion in the condvar code will use sched_wakeup() so no additional changes are required on the wakeup side). This could be contributing to why people's X servers are blowing up... it's because your scheduler thinks the X server never sleeps so the priority remains artifically high even if the X server is mostly idle. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 17:32:39 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AB9C37B401; Sat, 25 Jan 2003 17:32:38 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2C6043E4A; Sat, 25 Jan 2003 17:32:37 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.6/8.12.6) with ESMTP id h0Q1WZXv019912; Sat, 25 Jan 2003 17:32:35 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.6/8.12.6/Submit) id h0Q1WYNE019911; Sat, 25 Jan 2003 17:32:34 -0800 (PST) Date: Sat, 25 Jan 2003 17:32:34 -0800 From: Steve Kargl To: Matthew Dillon Cc: Jeff Roberson , Robert Watson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler (#3) Message-ID: <20030126013234.GA19891@troutmask.apl.washington.edu> References: <20030125171217.D18109-100000@mail.chesapeake.net> <200301252320.h0PNKVoq090077@apollo.backplane.com> <200301252350.h0PNo6xO009489@apollo.backplane.com> <200301260114.h0Q1EXuu017546@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301260114.h0Q1EXuu017546@apollo.backplane.com> User-Agent: Mutt/1.4i 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, Jan 25, 2003 at 05:14:33PM -0800, Matthew Dillon wrote: > > This could be contributing to why people's X servers are blowing up... > it's because your scheduler thinks the X server never sleeps so the > priority remains artifically high even if the X server is mostly idle. > This would explain why my recent effort to force Jeff's scheduler to overload without X running didn't work. Matt, are you generating patches or simply analyzing Jeff's code? I don't mind panicking my machine if you need a guinea pig. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 18:18:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B467637B401; Sat, 25 Jan 2003 18:18:49 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E72543F1E; Sat, 25 Jan 2003 18:18:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0Q2Il0i024484; Sat, 25 Jan 2003 18:18:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0Q2IlkX024483; Sat, 25 Jan 2003 18:18:47 -0800 (PST) Date: Sat, 25 Jan 2003 18:18:47 -0800 (PST) From: Matthew Dillon Message-Id: <200301260218.h0Q2IlkX024483@apollo.backplane.com> To: Steve Kargl Cc: Jeff Roberson , Robert Watson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler (#3) References: <20030125171217.D18109-100000@mail.chesapeake.net> <200301252320.h0PNKVoq090077@apollo.backplane.com> <200301252350.h0PNo6xO009489@apollo.backplane.com> <200301260114.h0Q1EXuu017546@apollo.backplane.com> <20030126013234.GA19891@troutmask.apl.washington.edu> 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 :This would explain why my recent effort to force Jeff's :scheduler to overload without X running didn't work. : :Matt, are you generating patches or simply analyzing :Jeff's code? I don't mind panicking my machine if you :need a guinea pig. : :-- :Steve I'm just analyzing Jeff's code and doing simple rip-up tests. I haven't been saving the bug fixes. Mainly I am getting up to speed on the scheduler API so I can implement my fractional fair share cpu and I/O scheduler down the line. I expect Jeff can fix the more obvious bugs in a few seconds. Dealing with the cpu-thread-stealing issue is a much harder problem. I saw the flip-flop and reported it, but did not try to fix it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 19: 5:29 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E5C737B401; Sat, 25 Jan 2003 19:05:28 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A1E243E4A; Sat, 25 Jan 2003 19:05:27 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q35IV91485; Sat, 25 Jan 2003 22:05:18 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Jan 2003 22:05:18 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler In-Reply-To: <200301252320.h0PNKVoq090077@apollo.backplane.com> Message-ID: <20030125220155.E18109-100000@mail.chesapeake.net> 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, 25 Jan 2003, Matthew Dillon wrote: > Jeff, while investigating your patch I found a couple of possible > issues which I think are causing the time problems. Thanks for the feedback. > > The first problem is sched_choose() appears to be causing a lot > of ping-ponging because the swap is made permanent. i.e. it > swaps cpu queues but then the new queue (belonging to another cpu) > becomes the current queue. For the current choose it doesn't matter, > but for the NEXT time choose is called it does. Eh? There are two queues per cpu. sched_choose() does not effect the run queues of cpus other than the current one. I'm not sure I understand where you're going with this. > > The second issue has to do with the way kg_slptime is calculated. > It just doesn't look right to me. I think a better solution is > to add an additional field, kg_runtime, and rather then trying to > decrement kg_slptime you instead increment kg_runtime, then use > the ratio kg_runtime / kg_slptime to calculate the interactivity > of the process. If either kg_runtime or kg_slptime exceed > SCHED_SLP_MAX, simply scale both down (to deal with overflows). > > -Matt > Yeah, I had intended to do something similar to this to fix the slptime. This helps deal with a priority drift that is possible with the current design. I think I'll make this change soon. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 19: 6:52 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12E3037B401; Sat, 25 Jan 2003 19:06:51 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FCD743E4A; Sat, 25 Jan 2003 19:06:50 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q36mX91957; Sat, 25 Jan 2003 22:06:48 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Jan 2003 22:06:48 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler (#2) In-Reply-To: <200301252350.h0PNo6xO009489@apollo.backplane.com> Message-ID: <20030125220607.Y18109-100000@mail.chesapeake.net> 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, 25 Jan 2003, Matthew Dillon wrote: > I found another problem. In sched_exit() you are 'returning' > part of the child's priority and interactivity to the parent, but > you are not taking into account batch processes. > > A batch child which is exiting, such as the 'cc1' in a 'cc' or the 'cc' > in a 'make' (you see where this is leading? Consider a 'make buildworld') > must penalize the parent so the next fork/exec'd child retains the batch > priority. > > The 4bsd code does this. The sched_smp code does not. The sched_smp > code simply adds to kg_slptime and this can *never* penalize the parent. > The result is that the parent retains its near-zero cpu utilization > (because all it is doing is fork/exec/wait). > > This could be the primary cause of the interactive/buildworld latency > reports. > Ah, yeah, very good. I hadn't considered the fork/exit priority adjustments in this light. I did have a big XXX there to look at this later though. I'll see if I cant do something more similar to the 4bsd code here. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 19: 9: 3 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D798A37B401; Sat, 25 Jan 2003 19:09:01 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC7843F18; Sat, 25 Jan 2003 19:09:01 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q38wN92814; Sat, 25 Jan 2003 22:08:58 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Jan 2003 22:08:58 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler (#3) In-Reply-To: <200301260114.h0Q1EXuu017546@apollo.backplane.com> Message-ID: <20030125220657.N18109-100000@mail.chesapeake.net> 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, 25 Jan 2003, Matthew Dillon wrote: > Found another bug. In sched_sleep() you set td_slptime to ticks > in order to calculate the time slept in sched_wakeup(). > > You have to do the same thing in sched_switchout() (or move it to > sched_switchout()?), because not all kernel subsystems use msleep(). > For example, select() does it manually and uses mi_switch(), which > means that sched_sleep() is never called. (select() uses condvars which > use mi_switch(). The wakeup portion in the condvar code will use > sched_wakeup() so no additional changes are required on the wakeup side). > I want the sleep time to ONLY reflect voluntary sleep time. Thats why it was only done in sched_sleep(). It looks like I might have to add it to either select or the condvar code. I think that perhaps adding it to condvar would be correct since that is a voluntary sleep. Good catch. thanks. > This could be contributing to why people's X servers are blowing up... > it's because your scheduler thinks the X server never sleeps so the > priority remains artifically high even if the X server is mostly idle. > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 19:13:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC44337B401; Sat, 25 Jan 2003 19:13:42 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB54243EB2; Sat, 25 Jan 2003 19:13:41 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q3DdH94067; Sat, 25 Jan 2003 22:13:39 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Jan 2003 22:13:39 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler (#3) In-Reply-To: <200301260218.h0Q2IlkX024483@apollo.backplane.com> Message-ID: <20030125220945.L18109-100000@mail.chesapeake.net> 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, 25 Jan 2003, Matthew Dillon wrote: > > :This would explain why my recent effort to force Jeff's > :scheduler to overload without X running didn't work. > : > :Matt, are you generating patches or simply analyzing > :Jeff's code? I don't mind panicking my machine if you > :need a guinea pig. > : > :-- > :Steve > > I'm just analyzing Jeff's code and doing simple rip-up tests. I haven't > been saving the bug fixes. Mainly I am getting up to speed on the > scheduler API so I can implement my fractional fair share cpu and I/O > scheduler down the line. > I'd be very interested in hearing a critique of the API. There are a few things that I think are missing now. For example, a sched_exec(). Also, I think sched_fork() should be a finer grained thing like: sched_fork_kse() sched_fork_kseg() sched_fork_td() sched_fork_proc() So that they could be used when new structures are created from fork or as part of adding a new thread/kse/kseg to an existing proc. > I expect Jeff can fix the more obvious bugs in a few seconds. Dealing > with the cpu-thread-stealing issue is a much harder problem. I saw > the flip-flop and reported it, but did not try to fix it. > I'm still not sure about the flip-flop that you're talking about. The others should be very quick to fix. I'll get a patched version going pretty quickly here. Thank you very much for the review matt. This is the most thorough feedback I've received yet. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 19:37:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66FDB37B401; Sat, 25 Jan 2003 19:37:32 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5D4243E4A; Sat, 25 Jan 2003 19:37:31 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc02.attbi.com (sccrmhc02) with ESMTP id <2003012603373000200bi70le>; Sun, 26 Jan 2003 03:37:30 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA90751; Sat, 25 Jan 2003 19:37:28 -0800 (PST) Date: Sat, 25 Jan 2003 19:37:27 -0800 (PST) From: Julian Elischer To: Jeff Roberson Cc: Matthew Dillon , Steve Kargl , Robert Watson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler (#3) In-Reply-To: <20030125220657.N18109-100000@mail.chesapeake.net> 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, 25 Jan 2003, Jeff Roberson wrote: > On Sat, 25 Jan 2003, Matthew Dillon wrote: > > > Found another bug. In sched_sleep() you set td_slptime to ticks > > in order to calculate the time slept in sched_wakeup(). > > > > You have to do the same thing in sched_switchout() (or move it to > > sched_switchout()?), because not all kernel subsystems use msleep(). > > For example, select() does it manually and uses mi_switch(), which > > means that sched_sleep() is never called. (select() uses condvars which > > use mi_switch(). The wakeup portion in the condvar code will use > > sched_wakeup() so no additional changes are required on the wakeup side). > > > I want the sleep time to ONLY reflect voluntary sleep time. Thats why it > was only done in sched_sleep(). It looks like I might have to add it to > either select or the condvar code. I think that perhaps adding it to > condvar would be correct since that is a voluntary sleep. > > Good catch. thanks. Select uses cv_wait() Both jhb and I have been considering passing a parameter to mi_switch() that indicates if the switch was voluntary or not.. in the meanwhile you can do: if (TD_IS_ON_SLEEPQ(td)) in mi_switch (sched_switchout()) to catch both cases.. or just call sched_sleep() from the cv code as it's almost identical to the sleep code.. > > > This could be contributing to why people's X servers are blowing up... > > it's because your scheduler thinks the X server never sleeps so the > > priority remains artifically high even if the X server is mostly idle. > > > > -Matt > > > > > 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 Jan 25 19:42:58 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4F0137B401; Sat, 25 Jan 2003 19:42:56 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 317D143ED8; Sat, 25 Jan 2003 19:42:56 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <2003012603425505100pmtuge>; Sun, 26 Jan 2003 03:42:55 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA90799; Sat, 25 Jan 2003 19:42:54 -0800 (PST) Date: Sat, 25 Jan 2003 19:42:53 -0800 (PST) From: Julian Elischer To: Jeff Roberson Cc: Matthew Dillon , Steve Kargl , Robert Watson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler (#3) In-Reply-To: <20030125220945.L18109-100000@mail.chesapeake.net> 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, 25 Jan 2003, Jeff Roberson wrote: > On Sat, 25 Jan 2003, Matthew Dillon wrote: > > > > > :This would explain why my recent effort to force Jeff's > > :scheduler to overload without X running didn't work. > > : > > :Matt, are you generating patches or simply analyzing > > :Jeff's code? I don't mind panicking my machine if you > > :need a guinea pig. > > : > > :-- > > :Steve > > > > I'm just analyzing Jeff's code and doing simple rip-up tests. I haven't > > been saving the bug fixes. Mainly I am getting up to speed on the > > scheduler API so I can implement my fractional fair share cpu and I/O > > scheduler down the line. > > > I'd be very interested in hearing a critique of the API. There are a few > things that I think are missing now. For example, a sched_exec(). Also, > I think sched_fork() should be a finer grained thing like: > > sched_fork_kse() > sched_fork_kseg() > sched_fork_td() > sched_fork_proc() > > So that they could be used when new structures are created from fork or as > part of adding a new thread/kse/kseg to an existing proc. hhmmmmmmmm.. :-) > > > I expect Jeff can fix the more obvious bugs in a few seconds. Dealing > > with the cpu-thread-stealing issue is a much harder problem. I saw > > the flip-flop and reported it, but did not try to fix it. > > > > I'm still not sure about the flip-flop that you're talking about. The > others should be very quick to fix. I'll get a patched version going > pretty quickly here. > > Thank you very much for the review matt. This is the most thorough > feedback I've received yet. I read it but only briefly.. We're in the middle of "paradigm shift" in KSE land.. David Xu had a "moment of clarity" (the kind that one has in the shower, though I have no idea where he was when he had it) and figured out that we could make things much simpler by doing something differently so we're testing that.. So so haven't had time to give your scheduler the scrutiny it deserves. > > Cheers, > Jeff > > > 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 Jan 25 19:48: 9 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7148137B401; Sat, 25 Jan 2003 19:48:08 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F87943EB2; Sat, 25 Jan 2003 19:48:08 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0Q3m60i024914; Sat, 25 Jan 2003 19:48:06 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0Q3m65F024913; Sat, 25 Jan 2003 19:48:06 -0800 (PST) Date: Sat, 25 Jan 2003 19:48:06 -0800 (PST) From: Matthew Dillon Message-Id: <200301260348.h0Q3m65F024913@apollo.backplane.com> To: Jeff Roberson Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler (#3) References: <20030125220945.L18109-100000@mail.chesapeake.net> 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'd be very interested in hearing a critique of the API. There are a few :things that I think are missing now. For example, a sched_exec(). Also, :I think sched_fork() should be a finer grained thing like: : :sched_fork_kse() :sched_fork_kseg() :sched_fork_td() :sched_fork_proc() So far the API is sufficient for the fractional-fair-share I intend to implement later on. One thing I noticed was that the runq_*() procedures are in kern_switch.c when, in fact, they are only used by sched_*() functions (and in the workup I did of my own scheduler I didn't use them at all). That *might* argue for moving them into sched_*() or into their own file. I only hesitate because they are rather involved despite being sched_*() specific. :I'm still not sure about the flip-flop that you're talking about. The :others should be very quick to fix. I'll get a patched version going :pretty quickly here. : :Thank you very much for the review matt. This is the most thorough :feedback I've received yet. : :Cheers, :Jeff I think I misread that part of the code. Ah, I see what happened. I misread the sched_setup() code. I thought it was indexing into another cpu's kseq. This implies that either process ping-ponging is not a problem relative to the other issues, or that it is more subtle... perhaps an unstable ping pong occurs in the rescheduling code (since you reschedule every time the slice runs out). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 20: 2:31 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 423E037B401; Sat, 25 Jan 2003 20:02:30 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7E543F5F; Sat, 25 Jan 2003 20:02:29 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q42O409706; Sat, 25 Jan 2003 23:02:24 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Jan 2003 23:02:24 -0500 (EST) From: Jeff Roberson To: Julian Elischer Cc: Matthew Dillon , Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler (#3) In-Reply-To: Message-ID: <20030125230123.W7994-100000@mail.chesapeake.net> 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 want the sleep time to ONLY reflect voluntary sleep time. Thats why it > > was only done in sched_sleep(). It looks like I might have to add it to > > either select or the condvar code. I think that perhaps adding it to > > condvar would be correct since that is a voluntary sleep. > > > > Good catch. thanks. > > Select uses cv_wait() > > Both jhb and I have been considering passing a parameter to mi_switch() > that indicates if the switch was voluntary or not.. > in the meanwhile you can do: > if (TD_IS_ON_SLEEPQ(td)) > in mi_switch (sched_switchout()) > to catch both cases.. or just call sched_sleep() from the cv code > as it's almost identical to the sleep code.. I added sched_sleep() to the cv code since it was doing the old way manually. Now it is correct for both schedulers. I do like the idea of vol/invol parameter to mi_switch(). Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 20: 8:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7BFF37B401; Sat, 25 Jan 2003 20:08:35 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 029A743EB2; Sat, 25 Jan 2003 20:08:35 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q48Wa11392; Sat, 25 Jan 2003 23:08:32 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 25 Jan 2003 23:08:32 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler - Interactivity fixes In-Reply-To: <200301260348.h0Q3m65F024913@apollo.backplane.com> Message-ID: <20030125230350.O7994-100000@mail.chesapeake.net> 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 If you just want the interactivity fixes see the bottom of this email. Thanks for the help everyone! On Sat, 25 Jan 2003, Matthew Dillon wrote: > :I'd be very interested in hearing a critique of the API. There are a few > :things that I think are missing now. For example, a sched_exec(). Also, > :I think sched_fork() should be a finer grained thing like: > : > :sched_fork_kse() > :sched_fork_kseg() > :sched_fork_td() > :sched_fork_proc() > > So far the API is sufficient for the fractional-fair-share I intend > to implement later on. Groovy. I firmly believe the only way to get a good abstraction here is to see what a few consumers would look like and generalize to meet their needs. So far the abstraction seems to work well for 2 schedulers. :-) > > One thing I noticed was that the runq_*() procedures are in kern_switch.c > when, in fact, they are only used by sched_*() functions (and in the > workup I did of my own scheduler I didn't use them at all). That *might* > argue for moving them into sched_*() or into their own file. I only > hesitate because they are rather involved despite being sched_*() specific. At some point it would be nice for the per cpu runqs to be completely scheduler independant instead of existing as scheduler support code. This way we could switch schedulers on the fly and they could just take over the common run queues. Anyway, they aren't in a sched_ file because both schedulers use them. Although they could be inlined since each function is used only once in each scheduler. > > :I'm still not sure about the flip-flop that you're talking about. The > :others should be very quick to fix. I'll get a patched version going > :pretty quickly here. > : > :Thank you very much for the review matt. This is the most thorough > :feedback I've received yet. > : > :Cheers, > :Jeff > > I think I misread that part of the code. Ah, I see what happened. > I misread the sched_setup() code. I thought it was indexing into > another cpu's kseq. > > This implies that either process ping-ponging is not a problem > relative to the other issues, or that it is more subtle... perhaps > an unstable ping pong occurs in the rescheduling code (since you > reschedule every time the slice runs out). I think the issue was related to not adjusting the queue for interactive processes after they slept and woke up. Also, the missing sched_sleep() in the cv code really hosed things. The other problems you pointed out were very correct though. I have updated the file. It's available at http://www.chesapeake.net/~jroberson/sched_smp.c You'll need to update your kern_condvar.c to fix the select problem. This implements fixes for most things that we discussed other than the td_slptime adjustment. That's going to come later. With this patch I'm listening to mp3s, doing a make -j4 buildworld, running mozilla, and typing this email all at once without any latency. :-) Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 21: 9:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35DE437B401; Sat, 25 Jan 2003 21:09:54 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4CFC43E4A; Sat, 25 Jan 2003 21:09:53 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0Q59q0i025353; Sat, 25 Jan 2003 21:09:52 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0Q59pO0025352; Sat, 25 Jan 2003 21:09:51 -0800 (PST) Date: Sat, 25 Jan 2003 21:09:51 -0800 (PST) From: Matthew Dillon Message-Id: <200301260509.h0Q59pO0025352@apollo.backplane.com> To: Jeff Roberson Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler - Interactivity fixes References: <20030125230350.O7994-100000@mail.chesapeake.net> 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 Jeff, how are you loading your scheduler in? In my tests I just #if 0'd out sched_4bsd.c and added sched_smp.c to conf/files, but I think I'm missing something. Is there some way to set the scheduler at boot time (e.g. sched_4bsd.c vs sched_smp.c)? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 21:20:55 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8890837B401; Sat, 25 Jan 2003 21:20:54 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6AB243E4A; Sat, 25 Jan 2003 21:20:53 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q5Kp033124; Sun, 26 Jan 2003 00:20:51 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 26 Jan 2003 00:20:51 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler - Interactivity fixes In-Reply-To: <200301260509.h0Q59pO0025352@apollo.backplane.com> Message-ID: <20030126001955.I7994-100000@mail.chesapeake.net> 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 In a moment I'm adding some config options to handle this. I sent some mail out to current@ and I'm adding a line to updating. This has all gone through re. You will be required to specify one of SCHED_4BSD or SCHED_ULE (new name for sched_smp) in your config file. I went away from sched_smp because it should be a very effective up scheduler as well. Cheers, Jeff On Sat, 25 Jan 2003, Matthew Dillon wrote: > Jeff, how are you loading your scheduler in? In my tests I just > #if 0'd out sched_4bsd.c and added sched_smp.c to conf/files, but > I think I'm missing something. Is there some way to set the scheduler > at boot time (e.g. sched_4bsd.c vs sched_smp.c)? > > -Matt > > > 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 Jan 25 22:15:16 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 610FF37B401; Sat, 25 Jan 2003 22:15:15 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8965343EB2; Sat, 25 Jan 2003 22:15:14 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <20030126061512003000614je>; Sun, 26 Jan 2003 06:15: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 WAA91825; Sat, 25 Jan 2003 22:15:10 -0800 (PST) Date: Sat, 25 Jan 2003 22:15:08 -0800 (PST) From: Julian Elischer To: Jeff Roberson Cc: Matthew Dillon , Steve Kargl , Robert Watson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler - Interactivity fixes In-Reply-To: <20030126001955.I7994-100000@mail.chesapeake.net> 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 I think that the option should be set up so that no option gives the current scheduler. On Sun, 26 Jan 2003, Jeff Roberson wrote: > In a moment I'm adding some config options to handle this. I sent some > mail out to current@ and I'm adding a line to updating. This has all gone > through re. You will be required to specify one of SCHED_4BSD or > SCHED_ULE (new name for sched_smp) in your config file. I went away from > sched_smp because it should be a very effective up scheduler as well. > > Cheers, > Jeff > > On Sat, 25 Jan 2003, Matthew Dillon wrote: > > > Jeff, how are you loading your scheduler in? In my tests I just > > #if 0'd out sched_4bsd.c and added sched_smp.c to conf/files, but > > I think I'm missing something. Is there some way to set the scheduler > > at boot time (e.g. sched_4bsd.c vs sched_smp.c)? > > > > -Matt > > > > > > 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 Sat Jan 25 22:25: 9 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F105F37B401; Sat, 25 Jan 2003 22:25:07 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BA7043ED8; Sat, 25 Jan 2003 22:25:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0Q6Ox0i025785; Sat, 25 Jan 2003 22:24:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0Q6OxSl025784; Sat, 25 Jan 2003 22:24:59 -0800 (PST) Date: Sat, 25 Jan 2003 22:24:59 -0800 (PST) From: Matthew Dillon Message-Id: <200301260624.h0Q6OxSl025784@apollo.backplane.com> To: Julian Elischer Cc: Jeff Roberson , Steve Kargl , Robert Watson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler - Interactivity fixes References: 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 Although... it might be even better if we could specify no schedulers in the kernel build and then load one as a boot-time module. Or if we could load several schedulers at compile-time (i.e. all their functions and globals would be static and they would register via a SYS entry) and allow the scheduler to be selected with a boot-time variable. That might dovetail into a methodology to allow schedulers to be switched on the fly. I've thought about that a bit and it occurs to me that run-time switching a scheduler does not require that a common runq methodology be used. Instead we simply have an API call that allows the kernel to 'collect' all the queued KSEs into a single queue and then reallocate their sub-structures and re-add them to the new scheduler. /* * Ask the scheduler to pull off all the KSEs on its runq or runqs * (for all cpu's) and place them in colq. The kernel will call this * function prior to switching to a new scheduler. The scheduler * is also expected to cleanup any other auxillary management it * had initialized. */ void sched_collect(struct rqhead *colq) { } /* * Ask the scheduler to emplace all the KSEs on colq back onto the * appropriate scheduler-specific run queue. This function is called * after the kernel initializes the new scheduler and assigns new * empty substructures to the KSE,KSEGs,etc... as per the new scheduler. */ void sched_restore(struct rqhead *colq) { } -Matt :(Julian) :I think that the option should be set up so that no option gives the :current scheduler. : :On Sun, 26 Jan 2003, Jeff Roberson wrote: : :> In a moment I'm adding some config options to handle this. I sent some :> mail out to current@ and I'm adding a line to updating. This has all gone :> through re. You will be required to specify one of SCHED_4BSD or :> SCHED_ULE (new name for sched_smp) in your config file. I went away from :> sched_smp because it should be a very effective up scheduler as well. :> :> Cheers, :> Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 22:39:20 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B19F37B401; Sat, 25 Jan 2003 22:39:19 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2530943F13; Sat, 25 Jan 2003 22:39:18 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0Q6dCv55085; Sun, 26 Jan 2003 01:39:12 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 26 Jan 2003 01:39:12 -0500 (EST) From: Jeff Roberson To: Julian Elischer Cc: Matthew Dillon , Steve Kargl , Robert Watson , Gary Jennejohn , Subject: Re: New scheduler - Interactivity fixes In-Reply-To: Message-ID: <20030126013746.C7994-100000@mail.chesapeake.net> 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, 25 Jan 2003, Julian Elischer wrote: > I think that the option should be set up so that no option gives the > current scheduler. We discussed that but that would require adding a #ifndef each time a scheduler was added. It's less appealing long term. Sorry we didn't include you on this discussion. I sent requests for feedback on this with my first arch@ post and eventually ended up directly discussing it with re. Cheers, Jeff > > > On Sun, 26 Jan 2003, Jeff Roberson wrote: > > > In a moment I'm adding some config options to handle this. I sent some > > mail out to current@ and I'm adding a line to updating. This has all gone > > through re. You will be required to specify one of SCHED_4BSD or > > SCHED_ULE (new name for sched_smp) in your config file. I went away from > > sched_smp because it should be a very effective up scheduler as well. > > > > Cheers, > > Jeff > > > > On Sat, 25 Jan 2003, Matthew Dillon wrote: > > > > > Jeff, how are you loading your scheduler in? In my tests I just > > > #if 0'd out sched_4bsd.c and added sched_smp.c to conf/files, but > > > I think I'm missing something. Is there some way to set the scheduler > > > at boot time (e.g. sched_4bsd.c vs sched_smp.c)? > > > > > > -Matt > > > > > > > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 23:20:19 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC65A37B401; Sat, 25 Jan 2003 23:20:16 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DC1E43E4A; Sat, 25 Jan 2003 23:20:16 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003012607201400100hoq0le>; Sun, 26 Jan 2003 07:20:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA92238; Sat, 25 Jan 2003 23:20:13 -0800 (PST) Date: Sat, 25 Jan 2003 23:20:11 -0800 (PST) From: Julian Elischer To: Jeff Roberson Cc: Matthew Dillon , Steve Kargl , Robert Watson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler - Interactivity fixes In-Reply-To: <20030126013746.C7994-100000@mail.chesapeake.net> 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 Sun, 26 Jan 2003, Jeff Roberson wrote: > > On Sat, 25 Jan 2003, Julian Elischer wrote: > > > I think that the option should be set up so that no option gives the > > current scheduler. > > We discussed that but that would require adding a #ifndef each time a > scheduler was added. It's less appealing long term. Sorry we didn't > include you on this discussion. I sent requests for feedback on this with > my first arch@ post and eventually ended up directly discussing it with > re. Huh? Did I not indicate an interest? if you mean the post earluer today, then it needs abit more than one day.... I happen to think that what you are doing is good because we need the ability to abstract the scheduler, but 're@' doesn't have any say in this.. it's not an 're' issue. Making thousands of people go and edit their config files is just 'unfriendly'. This is an "arch@" issue and I think that you need to revert this change until it's been discussed in the correct forum. Maybe it's come to the decision that what you have done is corrrect but I suspect that having a default scheduler is more in line with POLA than suddenly having to specify one. The standard proceedure for adding a new "to be standard" feature is: Make the new feature an option, leaving the original as default. Make the old one as a feature as well. Change the default > > Cheers, > Jeff > > > > > > On Sun, 26 Jan 2003, Jeff Roberson wrote: > > > > > In a moment I'm adding some config options to handle this. I sent some > > > mail out to current@ and I'm adding a line to updating. This has all gone > > > through re. You will be required to specify one of SCHED_4BSD or > > > SCHED_ULE (new name for sched_smp) in your config file. I went away from > > > sched_smp because it should be a very effective up scheduler as well. > > > > > > Cheers, > > > Jeff > > > > > > On Sat, 25 Jan 2003, Matthew Dillon wrote: > > > > > > > Jeff, how are you loading your scheduler in? In my tests I just > > > > #if 0'd out sched_4bsd.c and added sched_smp.c to conf/files, but > > > > I think I'm missing something. Is there some way to set the scheduler > > > > at boot time (e.g. sched_4bsd.c vs sched_smp.c)? > > > > > > > > -Matt > > > > > > > > > > > > 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 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 25 23:25:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A781C37B401; Sat, 25 Jan 2003 23:25:12 -0800 (PST) Received: from endless.iteration.net (endless.iteration.net [198.92.249.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B2A243E4A; Sat, 25 Jan 2003 23:25:12 -0800 (PST) (envelope-from keichii@endless.iteration.net) Received: by endless.iteration.net (Postfix, from userid 1001) id 7F1396CB836; Sun, 26 Jan 2003 01:25:11 -0600 (CST) Date: Sun, 26 Jan 2003 01:25:11 -0600 From: "Michael C. Wu" To: Robert Watson Cc: Steve Kargl , Jeff Roberson , Gary Jennejohn , arch@FreeBSD.ORG Subject: Re: New scheduler Message-ID: <20030126072511.GB97105@endless.iteration.net> Reply-To: "Michael C. Wu" References: <20030125045205.GA15091@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 User-Agent: Mutt/1.5.1i 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, Jan 25, 2003 at 01:58:33PM -0500, Robert Watson scribbled: | > > It did not help. The load averages reported be top(1) | > > with the above change in palce are 7.86, 9.01, 8.72. Perhaps a better benchmark would be running simulataneous processes and timing them with a physical stopwatch. | > Jeff, it isn't the painkillers. The 2nd sentence should read "The load | > averages, reported by top(1) with the above change in place, are 7.86, | > 9.01, 8.72" | | Part of the problem is that the load average is a poor measure of system | utilization. Jeff's new scheduler may defer scheduling a process that's | ready to run to improve throughput and wait for a "better" CPU to run a | process on based on affinity. Potentially the result might be that the | run queues are (on average) deeper, and what the load average does is | measure the depth of the run queue over time. So for the moment, it's | probably best to disregard load average as a measure of performance. On | the other hand, actual interactivity regressions and performance changes | are very relevant. Load average is intended to capture the degree of | contention for CPU resources, but what exactly that means is always an | interesting question. After looking at the code somewhat (did not have enough time to read into the details), here are my humble suggestions. 1. Processor affinity is a two-edged sword, and optimizing a MP scheduler for a UP machine is almost a lost cause. Perhaps you can consider treating UP as a special case and look at the MP case without holding back. 2. Keep in mind that the Athlon MP you are using has a medium sized cache compared to large ones in Xeons and Alphas, and the P4 has trace caches built-in. Assuming that you have plans for future SMT architectures like p4-hyperthreads, your optimizations may fail. My suggestion is that you create a scoring matrix of sorts and dynamically test out run queue depth and affinity scores. (From experience, linear systems work the best.) After a period of time, a system will have "learned" to deal with the job that it is supposed to. Intel designed the P4 caches to be small so we can trash them, so to say. 3. In the scoring matrix, you may wish to give prioritizing affinity for certain processes like controlling the ata bus, mouse movements etc. Since you are creating a general purpose structure, remember that a lot of us use FreeBSD for scientific computing, with little disk I/O and lots of memory/cpu usage. Others like Yahoo! webfarms will want preference for disk I/O and network interface controlling priorities. If you are interested in the dynamic testing system, we can discuss this on IRC or in the follow-up emails. Regards, Michael -- Michael C. Wu keichii@{ iteration.net | FreeBSD.org | ece.utexas.edu | iis.sinica.edu.tw | ntugene.ibs.ntu.edu.tw } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message