From owner-freebsd-arch Sun Nov 12 4:58:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id DD0EB37B479 for ; Sun, 12 Nov 2000 04:58:14 -0800 (PST) Received: from daemon.chronias.ninth-circle.org (root@daemon.ninth-circle.org [195.38.210.81]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id eACCwA049020 for ; Sun, 12 Nov 2000 13:58:10 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.0/8.11.0) id eACCw1V05071 for arch@freebsd.org; Sun, 12 Nov 2000 13:58:01 +0100 (CET) (envelope-from asmodai) Date: Sun, 12 Nov 2000 13:58:01 +0100 From: Jeroen Ruigrok/Asmodai To: arch@freebsd.org Subject: Re: updating rdist Message-ID: <20001112135800.K67634@daemon.ninth-circle.org> References: <20001111035905.A82574@dragon.nuxi.com> <14862.9298.59870.209107@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14862.9298.59870.209107@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Sun, Nov 12, 2000 at 12:03:09AM -0500 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20001112 07:00], Andrew Gallatin (gallatin@cs.duke.edu) wrote: >David O'Brien writes: > > I have just committed a `44bsd-rdist' port. > > So the question is, do we totally remove `rdist' from the base system, > > or update it to rdist 6.1.5? > >I'd vote for removal. I see more logic in it moving to the ports. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Only the good die young, all the evil seems to live forever... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 12 11: 0:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id 26DC137B479 for ; Sun, 12 Nov 2000 11:00:47 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id 5034B18DB; Sun, 12 Nov 2000 14:00:45 -0500 (EST) Date: Sun, 12 Nov 2000 14:00:45 -0500 From: Will Andrews To: arch@FreeBSD.ORG Subject: Re: updating rdist Message-ID: <20001112140045.K555@puck.firepipe.net> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , arch@FreeBSD.ORG References: <20001111035905.A82574@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001111035905.A82574@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sat, Nov 11, 2000 at 03:59:05AM -0800 X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 11, 2000 at 03:59:05AM -0800, David O'Brien wrote: > I have just committed a `44bsd-rdist' port. > So the question is, do we totally remove `rdist' from the base system, > or update it to rdist 6.1.5? I personally think it's better to remove it and update in ports. Cy Schubert makes a good point (if it is valid; I didn't check and don't know myself) that 44bsd-rdist and rdist6 are interoperable on mutally exclusive systems. Hence, it makes sense that a system administrator should need to look in ports for what they need. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 12 13:18:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 7C50C37B479 for ; Sun, 12 Nov 2000 13:18:51 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id NAA65350; Sun, 12 Nov 2000 13:17:42 -0800 (PST) (envelope-from obrien) Date: Sun, 12 Nov 2000 13:17:42 -0800 From: "David O'Brien" To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: updating rdist Message-ID: <20001112131741.A65293@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20001111211254.B75129@vger.bsdhome.com> <200011120246.eAC2ksC39398@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011120246.eAC2ksC39398@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Sat, Nov 11, 2000 at 06:46:01PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 11, 2000 at 06:46:01PM -0800, Cy Schubert - ITSD Open Systems Group wrote: > If you want to use something truly modern: Use rsync. I'd love to, but I've decided it is a POS. I constantly hangs for me (and has for serval rsync releases now) when I try to copy an Alpha release to ftp.freebsd.org (or any other FreeBSD box). I guess I should spend the time to put tons of printf()s in the code as "-vvvvv" hasn't given my anything to go on. > why not install rsync instead. It's eaiser to use and doesn't require > a distfile. That's why I think rdist is bloat. It doesn't anymore. :-) rdist6's rdist -P -DFn -c name ... [login@]host[:dest] works very well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 13 7:18:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id BF07937B4C5 for ; Mon, 13 Nov 2000 07:18:19 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA18233; Mon, 13 Nov 2000 07:17:38 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda18231; Mon Nov 13 07:17:36 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eADFHV309931; Mon, 13 Nov 2000 07:17:31 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdMJ9929; Mon Nov 13 07:17:30 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eADFHTM01095; Mon, 13 Nov 2000 07:17:29 -0800 (PST) Message-Id: <200011131517.eADFHTM01095@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdwA1089; Mon Nov 13 07:16:49 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: Will Andrews Cc: arch@FreeBSD.ORG Subject: Re: updating rdist In-reply-to: Your message of "Sun, 12 Nov 2000 14:00:45 EST." <20001112140045.K555@puck.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 2000 07:16:49 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001112140045.K555@puck.firepipe.net>, Will Andrews writes: > On Sat, Nov 11, 2000 at 03:59:05AM -0800, David O'Brien wrote: > > I have just committed a `44bsd-rdist' port. > > So the question is, do we totally remove `rdist' from the base system, > > or update it to rdist 6.1.5? > > I personally think it's better to remove it and update in ports. Cy > Schubert makes a good point (if it is valid; I didn't check and don't > know myself) that 44bsd-rdist and rdist6 are interoperable on mutally > exclusive systems. Hence, it makes sense that a system administrator > should need to look in ports for what they need. The description file from the rdist6 ports states: This version of rdist is not directly compatible with rdist distributed with 4.3BSD and subsequent vendor releases, but does indirectly provide full backward compatibility. From the rdist6(1) man page: The -Server option is recognized to provide partial back- ward compatible support for older versions of rdist which used this option to put rdist into server mode. If rdist is started with the -Server command line option, it will attempt to exec (run) the old version of rdist. This option will only work if rdist was compiled with the loca- tion of the old rdist (usually either /usr/ucb/oldrdist or /usr/old/rdist) and that program is available at run time. To support both the classic rdist and rdist6 protocols, both need to be installed. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 13 16:53: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 49E6A37B4E5 for ; Mon, 13 Nov 2000 16:52:53 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id QAA20163 for ; Mon, 13 Nov 2000 16:52:53 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda20161; Mon Nov 13 16:52:35 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAE0qUu18513 for ; Mon, 13 Nov 2000 16:52:30 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpda18511; Mon Nov 13 16:52:07 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAE0q6213485 for ; Mon, 13 Nov 2000 16:52:06 -0800 (PST) Message-Id: <200011140052.eAE0q6213485@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdq13478; Mon Nov 13 16:51:49 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: arch@FreeBSD.ORG Subject: Re: updating rdist In-reply-to: Your message of "Sun, 12 Nov 2000 13:17:42 PST." <20001112131741.A65293@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 2000 16:51:49 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001112131741.A65293@dragon.nuxi.com>, "David O'Brien" writes: > On Sat, Nov 11, 2000 at 06:46:01PM -0800, Cy Schubert - ITSD Open Systems Gro > up wrote: > > If you want to use something truly modern: Use rsync. > > I'd love to, but I've decided it is a POS. I constantly hangs for me > (and has for serval rsync releases now) when I try to copy an Alpha > release to ftp.freebsd.org (or any other FreeBSD box). I guess I should > spend the time to put tons of printf()s in the code as "-vvvvv" hasn't > given my anything to go on. Various versions of rsync have had hang problems. 2.4.6 doesn't appear to have any hang problems. All of my recent (since this spring) rsync hangs have been related to IP Filter's RCMD proxy. For some reason, at around FreeBSD 4.1 and IPF 3.4.6 I was experiencing more rsync hangs, about the same time that rcp & krcp, and tar | rsh tar would hang. Switching to ssh (kind of a waste because of the encryption over an encrypted channel because I use IPSec between home and my desktop system at work) solved the problem because I no longer needed IPF's RCMD proxy. If you use a statefull firewall between rsync peers, try opening the firewall between the two nodes. > > > why not install rsync instead. It's eaiser to use and doesn't require > > a distfile. That's why I think rdist is bloat. > > It doesn't anymore. :-) > rdist6's rdist -P -DFn -c name ... [login@]host[:dest] > works very well. This is cool! I also use rsync to synchronise data between a SCSI disk and a SCSI Zip drive on the same machine. It beats copying files by hand or some other means which would copy everything. I suppose one could rdist to localhost to obtain the same effect. Hopefully your rsync problems will be as easy to solve as mine were. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 13 17: 2:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 8897A37B4C5 for ; Mon, 13 Nov 2000 17:02:53 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id RAA20193 for ; Mon, 13 Nov 2000 17:02:53 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda20189; Mon Nov 13 17:02:43 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAE12c319100 for ; Mon, 13 Nov 2000 17:02:38 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdK19097; Mon Nov 13 17:02:07 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAE126313557 for ; Mon, 13 Nov 2000 17:02:06 -0800 (PST) Message-Id: <200011140102.eAE126313557@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdy13547; Mon Nov 13 17:01:31 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: arch@FreeBSD.ORG Subject: Re: updating rdist In-reply-to: Your message of "Mon, 13 Nov 2000 16:51:49 PST." <200011140052.eAE0q6213485@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 2000 17:01:30 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oops this should have been sent to David directly, not to -arch. I assumed that reply-to-sender did the right thing without checking. Sorry. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC In message <200011140052.eAE0q6213485@cwsys.cwsent.com>, Cy Schubert - ITSD Ope n Systems Group writes: > In message <20001112131741.A65293@dragon.nuxi.com>, "David O'Brien" > writes: > > On Sat, Nov 11, 2000 at 06:46:01PM -0800, Cy Schubert - ITSD Open Systems G > ro > > up wrote: > > > If you want to use something truly modern: Use rsync. > > > > I'd love to, but I've decided it is a POS. I constantly hangs for me > > (and has for serval rsync releases now) when I try to copy an Alpha > > release to ftp.freebsd.org (or any other FreeBSD box). I guess I should > > spend the time to put tons of printf()s in the code as "-vvvvv" hasn't > > given my anything to go on. > > Various versions of rsync have had hang problems. 2.4.6 doesn't appear > to have any hang problems. > > All of my recent (since this spring) rsync hangs have been related to > IP Filter's RCMD proxy. For some reason, at around FreeBSD 4.1 and IPF > 3.4.6 I was experiencing more rsync hangs, about the same time that rcp > & krcp, and tar | rsh tar would hang. Switching to ssh (kind of a > waste because of the encryption over an encrypted channel because I use > IPSec between home and my desktop system at work) solved the problem > because I no longer needed IPF's RCMD proxy. > > If you use a statefull firewall between rsync peers, try opening the > firewall between the two nodes. > > > > > > why not install rsync instead. It's eaiser to use and doesn't require > > > a distfile. That's why I think rdist is bloat. > > > > It doesn't anymore. :-) > > rdist6's rdist -P -DFn -c name ... [login@]host[:dest] > > works very well. > > This is cool! > > I also use rsync to synchronise data between a SCSI disk and a SCSI Zip > drive on the same machine. It beats copying files by hand or some > other means which would copy everything. I suppose one could rdist to > localhost to obtain the same effect. > > Hopefully your rsync problems will be as easy to solve as mine were. > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca > Open Systems Group, ITSD, ISTA > Province of BC > > > > > > 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 Mon Nov 13 17:19:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 648B537B4C5 for ; Mon, 13 Nov 2000 17:19:13 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp245.osd.bsdi.com [204.216.28.245]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAE1JBB71269 for ; Mon, 13 Nov 2000 17:19:11 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 13 Nov 2000 17:19:38 -0800 (PST) From: John Baldwin To: arch@FreeBSD.org Subject: Turning on debugging in GENERIC Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, I've seen several cases of this being talked about, but unless there are major objections (and there shouldn't be), I plan to turn on the following options in GENERIC in -current in 2-3 days: options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTICS options WITNESS Currently a kernel will not boot with WITNESS turned on (it will die during the SCSI/ATA probes), but I have patches to fix this that have been tested on UP and SMP x86 and work fine and I am in the process of testing on my Alpha. If anyone has any other debugging options that they would like to see turned on in addition, feel free to add to this list. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Mon Nov 13 22:35: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 9214737B479; Mon, 13 Nov 2000 22:34:55 -0800 (PST) Received: from grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.1/8.11.1) with ESMTP id eAE6Ymw05170; Tue, 14 Nov 2000 08:34:48 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011140634.eAE6Ymw05170@grimreaper.grondar.za> To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC References: In-Reply-To: ; from John Baldwin "Mon, 13 Nov 2000 17:19:38 PST." Date: Tue, 14 Nov 2000 08:34:48 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well, I've seen several cases of this being talked about, but unless > there are major objections (and there shouldn't be), I plan to turn on > the following options in GENERIC in -current in 2-3 days: > > options INVARIANTS > options INVARIANT_SUPPORT > options DIAGNOSTICS > options WITNESS Cool! Hoping that it works, of course! :-) > Currently a kernel will not boot with WITNESS turned on (it will die > during the SCSI/ATA probes), but I have patches to fix this that have > been tested on UP and SMP x86 and work fine and I am in the process of > testing on my Alpha. If anyone has any other debugging options that > they would like to see turned onin addition, feel free to add to this > list. Aren't there some speed issues, or have these been worked out? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 2:59: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9E6D237B479; Tue, 14 Nov 2000 02:58:58 -0800 (PST) Received: from newsguy.com (p25-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.90]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id TAA09522; Tue, 14 Nov 2000 19:58:57 +0900 (JST) Message-ID: <3A111A29.F7A67799@newsguy.com> Date: Tue, 14 Nov 2000 19:55:37 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > Well, I've seen several cases of this being talked about, but unless there are > major objections (and there shouldn't be), I plan to turn on the following > options in GENERIC in -current in 2-3 days: > > options INVARIANTS > options INVARIANT_SUPPORT > options DIAGNOSTICS > options WITNESS > > Currently a kernel will not boot with WITNESS turned on (it will die during the > SCSI/ATA probes), but I have patches to fix this that have been tested on UP > and SMP x86 and work fine and I am in the process of testing on my Alpha. If > anyone has any other debugging options that they would like to see turned on in > addition, feel free to add to this list. Please forgive me if I'm making a Terrycism and talking about old issues, but isn't one of DIAGNOSTICS problem that it isn't "passive" code and, thus, can actually hide bugs? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@world.wide.bsdconspiracy.net He has been convicted of criminal possession of a clue with intent to distribute. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 3:22:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from bsdone.bsdwins.com (www.bsdwins.com [192.58.184.33]) by hub.freebsd.org (Postfix) with ESMTP id 1B07437B479; Tue, 14 Nov 2000 03:22:37 -0800 (PST) Received: (from jwd@localhost) by bsdone.bsdwins.com (8.11.0/8.11.0) id eAEBMag90356; Tue, 14 Nov 2000 06:22:36 -0500 (EST) (envelope-from jwd) Date: Tue, 14 Nov 2000 06:22:36 -0500 From: "John W. De Boskey" To: John Baldwin , arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC Message-ID: <20001114062236.A90313@bsdwins.com> References: <200011140634.eAE6Ymw05170@grimreaper.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011140634.eAE6Ymw05170@grimreaper.grondar.za>; from mark@grondar.za on Tue, Nov 14, 2000 at 08:34:48AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please strip these options from the GENERIC kernel during make release if you decide to to this. Thanks, John ----- Mark Murray's Original Message ----- > > Well, I've seen several cases of this being talked about, but unless > > there are major objections (and there shouldn't be), I plan to turn on > > the following options in GENERIC in -current in 2-3 days: > > > > options INVARIANTS > > options INVARIANT_SUPPORT > > options DIAGNOSTICS > > options WITNESS > > Cool! Hoping that it works, of course! :-) > > > Currently a kernel will not boot with WITNESS turned on (it will die > > during the SCSI/ATA probes), but I have patches to fix this that have > > been tested on UP and SMP x86 and work fine and I am in the process of > > testing on my Alpha. If anyone has any other debugging options that > > they would like to see turned onin addition, feel free to add to this > > list. > > Aren't there some speed issues, or have these been worked out? > > M > -- > Mark Murray > Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 6: 8:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id A1AEA37B4C5 for ; Tue, 14 Nov 2000 06:08:08 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAEE86v11487 for ; Tue, 14 Nov 2000 15:08:07 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: RANDOMDEV inspired realitycheck regarding i386/i486... From: Poul-Henning Kamp Date: Tue, 14 Nov 2000 15:08:06 +0100 Message-ID: <11485.974210886@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If no /entropy is found it takes a full minute to do the randomdev seeding during boot on a P5/133. Has anybody run a 486 or 386 under current recently ? Have we defacto discontinued them from current ? I can see the advantage for the SMPng people in dropping the 386/486 and I'm approaching the level where I would be willing to say: "Sorry, stick with 4.x for i386/i486". What is the consensus ? -- 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 Nov 14 10: 6:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 84C4F37B4E5; Tue, 14 Nov 2000 10:06:47 -0800 (PST) Received: from platinum.scientia.demon.co.uk ([192.168.91.37] ident=root) by scientia.demon.co.uk with esmtp (Exim 3.169 #1) id 13vhLh-000G9Y-00; Tue, 14 Nov 2000 14:46:13 +0000 Received: (from ben@localhost) by platinum.scientia.demon.co.uk (8.11.1/8.11.1) id eAEEkDx24561; Tue, 14 Nov 2000 14:46:13 GMT (envelope-from ben) Date: Tue, 14 Nov 2000 14:46:13 +0000 From: Ben Smithurst To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Message-ID: <20001114144613.B88888@platinum.scientia.demon.co.uk> References: <11485.974210886@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <11485.974210886@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > If no /entropy is found it takes a full minute to do the randomdev > seeding during boot on a P5/133. > > Has anybody run a 486 or 386 under current recently ? Yes, my only -current machine is a 486. I gave up waiting for the randomdev seeding to complete. It's lucky I'm only a docs committer and therefore not terribly important I run -current I suppose. :-) I'm not going to get involved in the argument about whether to say "stick with 4.x on old machines" though, I don't have any strong feelings either way. -- Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 10: 9: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id D46C037B4C5; Tue, 14 Nov 2000 10:09:03 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp245.osd.bsdi.com [204.216.28.245]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAEI8xB92906; Tue, 14 Nov 2000 10:08:59 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <11485.974210886@critter> Date: Tue, 14 Nov 2000 10:09:29 -0800 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: RE: RANDOMDEV inspired realitycheck regarding i386/i486... Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14-Nov-00 Poul-Henning Kamp wrote: > > If no /entropy is found it takes a full minute to do the randomdev > seeding during boot on a P5/133. > > Has anybody run a 486 or 386 under current recently ? > > Have we defacto discontinued them from current ? > > I can see the advantage for the SMPng people in dropping the 386/486 > and I'm approaching the level where I would be willing to say: "Sorry, > stick with 4.x for i386/i486". Actually, the only pessimisms for SMPng are on the 386. The 486 has the 'cmpxchg' instruction that makes SMPng go. :) > What is the consensus ? What is the current processor of choice for embedded stuff? Is x86 even a good architecture for embedded work? That is the only place that I would see the 386 still being alive... -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 10:52:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 68C6837B65E; Tue, 14 Nov 2000 10:52:50 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id LAA16115; Tue, 14 Nov 2000 11:50:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAK2aiCF; Tue Nov 14 11:50:48 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA24877; Tue, 14 Nov 2000 11:52:43 -0700 (MST) From: Terry Lambert Message-Id: <200011141852.LAA24877@usr08.primenet.com> Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... To: ben@FreeBSD.ORG (Ben Smithurst) Date: Tue, 14 Nov 2000 18:52:40 +0000 (GMT) Cc: phk@FreeBSD.ORG (Poul-Henning Kamp), arch@FreeBSD.ORG In-Reply-To: <20001114144613.B88888@platinum.scientia.demon.co.uk> from "Ben Smithurst" at Nov 14, 2000 02:46:13 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If no /entropy is found it takes a full minute to do the randomdev > > seeding during boot on a P5/133. > > > > Has anybody run a 486 or 386 under current recently ? > > Yes, my only -current machine is a 486. I gave up waiting for the > randomdev seeding to complete. It's lucky I'm only a docs committer and > therefore not terribly important I run -current I suppose. :-) I can only risk -current on old hardware that I don't have anything important stored on, and that means 386 or 486 class hardware. I think that dropping support for 386/486 would be a retreat up-market. Is FreeBSD so marginalized that it needs to do what hard disk vendors and others have done, when their market share is failing? There's a good reason that most of the proprietary hardware vendors are retreating into large scale parallel systems... but it's not like FreeBSD is trying to support 40% margins on sales, like they are. My two cents says this is a problem with the design of randomdev, and not a problem with 386/486 hardware. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 10:54:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 75FB237B4C5; Tue, 14 Nov 2000 10:53:54 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 13vlDM-0006lI-00; Tue, 14 Nov 2000 18:53:52 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.0) id eAE6vTt01225; Tue, 14 Nov 2000 07:57:29 +0100 (CET) (envelope-from wkb) Date: Tue, 14 Nov 2000 07:57:29 +0100 From: Wilko Bulte To: John Baldwin Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Message-ID: <20001114075729.G333@freebie.demon.nl> References: <11485.974210886@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jhb@freebsd.org on Tue, Nov 14, 2000 at 10:09:29AM -0800 X-OS: FreeBSD 4.2-BETA X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 14, 2000 at 10:09:29AM -0800, John Baldwin wrote: > On 14-Nov-00 Poul-Henning Kamp wrote: > > > > If no /entropy is found it takes a full minute to do the randomdev > > seeding during boot on a P5/133. > > > > Has anybody run a 486 or 386 under current recently ? > > > > Have we defacto discontinued them from current ? > > > > I can see the advantage for the SMPng people in dropping the 386/486 > > and I'm approaching the level where I would be willing to say: "Sorry, > > stick with 4.x for i386/i486". > > Actually, the only pessimisms for SMPng are on the 386. The 486 has the > 'cmpxchg' instruction that makes SMPng go. :) Dropping 386 seems sound to me. 486 probably has quite some users left. DNS/NTP/whatever servers in dark corners come to mind. > > What is the consensus ? > > What is the current processor of choice for embedded stuff? Is x86 even a > good architecture for embedded work? That is the only place that I would see > the 386 still being alive... x86 has never been a good CPU for embedded. [eyes his trusty books collection for Motorola's 680x0 ;) ] -- Wilko Bulte Arnhem, the Netherlands wilko@freebsd.org http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 11:36:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CC40B37B479; Tue, 14 Nov 2000 11:36:07 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAEJa1R13054; Tue, 14 Nov 2000 12:36:02 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA49406; Tue, 14 Nov 2000 12:36:01 -0700 (MST) Message-Id: <200011141936.MAA49406@harmony.village.org> To: John Baldwin Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Cc: Poul-Henning Kamp , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 14 Nov 2000 10:09:29 PST." References: Date: Tue, 14 Nov 2000 12:36:01 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : What is the current processor of choice for embedded stuff? Is x86 even a : good architecture for embedded work? That is the only place that I would see : the 386 still being alive... Timing Solutions has several 486 based machines. There are very few 386 machines out there still in the SBC arena, but I understand that the 386EX is still alive and kicking in the "put a cpu on the board" market. The random device seeding issue is still a problem. It must complete in << 10 s on slow hardware and << 1s on fast hardware. Mark Murray and I talked about this at BSDcon and he indicated to me that he'll be fixing the speed aspect of it soon, or at least in the fullness of time. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 11:38:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 14A2B37B479; Tue, 14 Nov 2000 11:38:24 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAEJcMR13066; Tue, 14 Nov 2000 12:38:23 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA49433; Tue, 14 Nov 2000 12:38:22 -0700 (MST) Message-Id: <200011141938.MAA49433@harmony.village.org> To: Wilko Bulte Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Cc: John Baldwin , Poul-Henning Kamp , arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 14 Nov 2000 07:57:29 +0100." <20001114075729.G333@freebie.demon.nl> References: <20001114075729.G333@freebie.demon.nl> <11485.974210886@critter> Date: Tue, 14 Nov 2000 12:38:22 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001114075729.G333@freebie.demon.nl> Wilko Bulte writes: : Dropping 386 seems sound to me. 486 probably has quite some users left. : DNS/NTP/whatever servers in dark corners come to mind. The dropping 386 from the i386 port seems odd to my mind :-) Seriously, I think that dropping support for 386 will do more harm in the marketing arena than good tht the similified code base will give us. Just my two cents. The 486 *MUST* remain supported through at least 5.x. There lots of good, cheap 486 single board computers being built and deployed today. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 11:42: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id A816337B4C5; Tue, 14 Nov 2000 11:42:05 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp245.osd.bsdi.com [204.216.28.245]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAEJflB96057; Tue, 14 Nov 2000 11:41:47 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011141936.MAA49406@harmony.village.org> Date: Tue, 14 Nov 2000 11:42:17 -0800 (PST) From: John Baldwin To: Warner Losh Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Cc: arch@FreeBSD.org, Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14-Nov-00 Warner Losh wrote: > In message John Baldwin writes: >: What is the current processor of choice for embedded stuff? Is x86 even a >: good architecture for embedded work? That is the only place that I would >: see >: the 386 still being alive... > > Timing Solutions has several 486 based machines. There are very few > 386 machines out there still in the SBC arena, but I understand that > the 386EX is still alive and kicking in the "put a cpu on the board" > market. > > The random device seeding issue is still a problem. It must complete > in << 10 s on slow hardware and << 1s on fast hardware. Mark Murray > and I talked about this at BSDcon and he indicated to me that he'll be > fixing the speed aspect of it soon, or at least in the fullness of time. > > Warner Would anyone have a heart attack if we removed I386_CPU from GENERIC but did not remove the 386 code? -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 12:32: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 9BB1A37B479; Tue, 14 Nov 2000 12:32:02 -0800 (PST) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id PAA68332; Tue, 14 Nov 2000 15:32:01 -0500 (EST) Date: Tue, 14 Nov 2000 15:32:01 -0500 (EST) From: "Matthew N. Dodd" To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-Reply-To: <11485.974210886@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 14 Nov 2000, Poul-Henning Kamp wrote: > Has anybody run a 486 or 386 under current recently ? Yea, it sucks. > Have we defacto discontinued them from current ? > > I can see the advantage for the SMPng people in dropping the 386/486 > and I'm approaching the level where I would be willing to say: "Sorry, > stick with 4.x for i386/i486". > > What is the consensus ? Hell no. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 12:41:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.salientsystems.com (pokey.salientsystems.com [204.210.234.253]) by hub.freebsd.org (Postfix) with ESMTP id BCB8E37B479; Tue, 14 Nov 2000 12:41:18 -0800 (PST) Received: from salientsystems.com (rusty [192.168.0.90]) by zippy.salientsystems.com (8.9.3/8.9.3) with ESMTP id PAA34997; Tue, 14 Nov 2000 15:49:21 -0500 (EST) (envelope-from nludban@salientsystems.com) Message-ID: <3A11A451.3C8A92B7@salientsystems.com> Date: Tue, 14 Nov 2000 15:45:05 -0500 From: Neil Ludban Reply-To: nludban@pokey.salientsystems.com X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd really miss support for the older processors. I'm spending considerable time and effort trying to get 4.x to boot on a 386ex based SBC. I'm never going to use all the latest features of FreeBSD, but it is a requirement that I be able to load a laptop computer with a full development and testing environment, then drive an hour or more from civilization to the installation site to get some work done. The 486 SBCs are quite a price jump, especially when all I need is a couple serial ports. Just my two cents worth- --Neil > > What is the current processor of choice for embedded stuff? Is x86 even a > good architecture for embedded work? That is the only place that I would see > the 386 still being alive... > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 13:27:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1FF4037B479; Tue, 14 Nov 2000 13:27:20 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA78999; Tue, 14 Nov 2000 14:27:18 -0700 (MST) (envelope-from ken) Date: Tue, 14 Nov 2000 14:27:18 -0700 From: "Kenneth D. Merry" To: net@FreeBSD.ORG Subject: new zero copy sockets and NFS snapshot Message-ID: <20001114142718.A78985@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early November 14th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Questions, comments and feedback are welcome. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - The "localhost panic" problem has hopefully been fixed. The fix was to avoid page-flipping pages with a wire count greater than 0. I believe this is the right fix, but I would welcome feedback from someone more familiar with the VM system. - The new external mbuf code has been integrated. As of this release, there are no known problems with the code. If anyone wants to challenge that, I'll gladly accept bug reports, code comments, etc. :) For those of you who missed the previous messages about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Zero copy send and receive code, written by Drew Gallatin . - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. The Alteon header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which kindly agreed to let me release the code. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 14 13:46: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 5CFE437B479 for ; Tue, 14 Nov 2000 13:45:59 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id eAELjp504253 for arch@freebsd.org; Tue, 14 Nov 2000 22:45:51 +0100 (CET) (envelope-from adrian) Date: Tue, 14 Nov 2000 22:45:05 +0100 From: Adrian Chadd To: arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Message-ID: <20001114224505.A4195@roaming.cacheboy.net> References: <11485.974210886@critter> <20001114144613.B88888@platinum.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20001114144613.B88888@platinum.scientia.demon.co.uk>; from ben@FreeBSD.ORG on Tue, Nov 14, 2000 at 02:46:13PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 14, 2000, Ben Smithurst wrote: > Poul-Henning Kamp wrote: > > > If no /entropy is found it takes a full minute to do the randomdev > > seeding during boot on a P5/133. > > > > Has anybody run a 486 or 386 under current recently ? > 386'en might still have a place for small embedded products but I'm proabably going to be flamed when I say I think FreeBSD-current isn't very suited to "embedded 386 with tiny everything" applications. 2c, Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 0:56:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id B060537B4C5; Wed, 15 Nov 2000 00:56:56 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id JAA20918; Wed, 15 Nov 2000 09:56:54 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id JAA69311; Wed, 15 Nov 2000 09:56:54 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 15 Nov 2000 09:56:54 +0100 (CET) From: Marius Bendiksen To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-Reply-To: <11485.974210886@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If no /entropy is found it takes a full minute to do the randomdev > seeding during boot on a P5/133. > Has anybody run a 486 or 386 under current recently ? > Have we defacto discontinued them from current ? > I can see the advantage for the SMPng people in dropping the 386/486 > and I'm approaching the level where I would be willing to say: "Sorry, > stick with 4.x for i386/i486". I would be strongly opposed to this. In fact, I'd go as far as to say that people should take the time to make the 486 cpu option switch to a faster random device. The ability to run on commodity hardware is, in my view, an important feature. Already, I am seeing FreeBSD suitable for installation on a decreasing number of commodity boxes I have lying about. I would not like for this trend to continue. If we decide to abandon the old x86en, we should certainly take it all the way and put more resources into Sparc, Cray et al, rather than sticking with a middle ground. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 1: 0:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 523D237B479; Wed, 15 Nov 2000 01:00:46 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id KAA22723; Wed, 15 Nov 2000 10:00:44 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id KAA69358; Wed, 15 Nov 2000 10:00:44 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 15 Nov 2000 10:00:44 +0100 (CET) From: Marius Bendiksen To: John Baldwin Cc: Warner Losh , arch@FreeBSD.org, Poul-Henning Kamp Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Would anyone have a heart attack if we removed I386_CPU from GENERIC but > did not remove the 386 code? Not really; a 386 will usually require custom installation options anyway. However, I'd appreciate if an installation floppy with just 386/486 could be shipped on the side, stripped of those things not needed for those people. That would resolve the problem nicely. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 4:43:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from warning.follo.net (warning.follo.net [195.204.136.30]) by hub.freebsd.org (Postfix) with ESMTP id AB18137B479; Wed, 15 Nov 2000 04:43:13 -0800 (PST) Received: (from eivind@localhost) by warning.follo.net (8.9.3/8.9.3) id NAA11146; Wed, 15 Nov 2000 13:43:12 +0100 (CET) Date: Wed, 15 Nov 2000 13:43:12 +0100 From: Eivind Eklund To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC Message-ID: <20001115134312.C7752@warning.follo.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from jhb@FreeBSD.ORG on Mon, Nov 13, 2000 at 05:19:38PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 13, 2000 at 05:19:38PM -0800, John Baldwin wrote: > Well, I've seen several cases of this being talked about, but unless there are > major objections (and there shouldn't be), I plan to turn on the following > options in GENERIC in -current in 2-3 days: > > options INVARIANTS > options INVARIANT_SUPPORT > options DIAGNOSTICS > options WITNESS > > Currently a kernel will not boot with WITNESS turned on (it will die during the > SCSI/ATA probes), but I have patches to fix this that have been tested on UP > and SMP x86 and work fine and I am in the process of testing on my Alpha. If > anyone has any other debugging options that they would like to see turned on in > addition, feel free to add to this list. I'm not sure I'm happy about DIAGNOSTIC; unless changed, it significantly change some codepaths, and it produce output about system state, not just extra checks. Any plain checks that are under DIAGNOSTIC is there through a miscommunication or not finished conversion, anyway; it should only be causing extra debug output. Adding the rest of them are in my opinion a good thing. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 9:23:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id F06C937B479; Wed, 15 Nov 2000 09:23:37 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id KAA28922; Wed, 15 Nov 2000 10:24:12 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp05.primenet.com, id smtpdAAAsmaaA4; Wed Nov 15 10:24:05 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA12325; Wed, 15 Nov 2000 10:23:27 -0700 (MST) From: Terry Lambert Message-Id: <200011151723.KAA12325@usr01.primenet.com> Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... To: wkb@freebie.demon.nl (Wilko Bulte) Date: Wed, 15 Nov 2000 17:23:26 +0000 (GMT) Cc: jhb@FreeBSD.ORG (John Baldwin), phk@FreeBSD.ORG (Poul-Henning Kamp), arch@FreeBSD.ORG In-Reply-To: <20001114075729.G333@freebie.demon.nl> from "Wilko Bulte" at Nov 14, 2000 07:57:29 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > What is the consensus ? > > > > What is the current processor of choice for embedded stuff? Is > > x86 even a good architecture for embedded work? That is the > > only place that I would see the 386 still being alive... > > x86 has never been a good CPU for embedded. [eyes his trusty books > collection for Motorola's 680x0 ;) ] The Motorola strategy is broken; the processor they are selling for Palm Pilots has no MMU. It's no good for most embedded work (and is barely good enough for making Palm Pilots unstable with one single bad program). Cyrix, AMD, and various Card PCs are all 386-class CPUs. The IBM "Blue Lightning" core is a 386 class core, which is used to implement macrocell based embedded ASICs. Intel has two 386 macrocells that are used for embedded work. I'd have to say that not even the 80186 was dead yet... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 9:40:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id ABC1F37B4CF; Wed, 15 Nov 2000 09:40:08 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA07105; Wed, 15 Nov 2000 10:36:03 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpdAAA76aa7m; Wed Nov 15 10:35:03 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA13021; Wed, 15 Nov 2000 10:39:00 -0700 (MST) From: Terry Lambert Message-Id: <200011151739.KAA13021@usr01.primenet.com> Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... To: adrian@FreeBSD.ORG (Adrian Chadd) Date: Wed, 15 Nov 2000 17:38:59 +0000 (GMT) Cc: arch@FreeBSD.ORG In-Reply-To: <20001114224505.A4195@roaming.cacheboy.net> from "Adrian Chadd" at Nov 14, 2000 10:45:05 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > If no /entropy is found it takes a full minute to do the randomdev > > > seeding during boot on a P5/133. > > > > > > Has anybody run a 486 or 386 under current recently ? > > 386'en might still have a place for small embedded products but I'm > proabably going to be flamed when I say I think FreeBSD-current isn't > very suited to "embedded 386 with tiny everything" applications. That's a problem with FreeBSD-current, not a problem with "embedded 386 with tiny everything". I'm reminded when SVR4s footprint first went to 8M of RAM. I also find it amusing that I can get an old SVR4.0.2 ES/MP, and load it on both SMP boxes, and on 6M 386 boxes, when I am quickly becoming unable to do the same for FreeBSD-current. I guess this is inevitable, as security is increased, since the most secure computer is one which doesn't run... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 9:56: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id C54B637B4CF; Wed, 15 Nov 2000 09:56:05 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id KAA08574; Wed, 15 Nov 2000 10:54:07 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpdAAAkyaOTq; Wed Nov 15 10:53:59 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA13742; Wed, 15 Nov 2000 10:55:54 -0700 (MST) From: Terry Lambert Message-Id: <200011151755.KAA13742@usr01.primenet.com> Subject: Re: Turning on debugging in GENERIC To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Wed, 15 Nov 2000 17:55:54 +0000 (GMT) Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG In-Reply-To: <20001115134312.C7752@warning.follo.net> from "Eivind Eklund" at Nov 15, 2000 01:43:12 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not sure I'm happy about DIAGNOSTIC; unless changed, it > significantly change some codepaths, and it produce output about system > state, not just extra checks. Any plain checks that are under DIAGNOSTIC is > there through a miscommunication or not finished conversion, anyway; it > should only be causing extra debug output. I am not happy about the code path changes it engenders. However, I see the need for turning it on, during a period where extreme instability of snapshots is anticipated/likely, and I think that's the reason it is being proposed. Many people "try" -current on small scratch disks that they install from snapshots, rather than polluting their local trees with -current bits, particularly since the answer to their bug reports is pretty much to ignore them and tell the reporter to "resup" or ask "have you tried the snapshot?". I think that having the DIAGNOSTIC option is OK; on the other hand, I somewhat wish that this would move from a GENERIC file into a SNAPSHOT file, and that snapshots be configured from there instead of GENERIC, since reverting this back and forth every six months, instead of changing a cron script, seems like a real waste of repository commits. All that said, let's not downplay the code path changes: I have worked in places where I had to be "the grumpy old man of the source tree", when the code would not build due to "DEBUG" _not_ being asserted during the build, or other such diagnostic manifest constants. I really dislike manifest constants in all forms, because of this, and prefer link or run time tuning. I really see no _good_ reason a source repository should not be at least buildable at all times, other than laziness, but that's an argument for another day. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 10: 0:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id EB5FA37B479; Wed, 15 Nov 2000 10:00:47 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAFI0eB25710; Wed, 15 Nov 2000 10:00:40 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001115134312.C7752@warning.follo.net> Date: Wed, 15 Nov 2000 10:01:19 -0800 (PST) From: John Baldwin To: Eivind Eklund Subject: Re: Turning on debugging in GENERIC Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15-Nov-00 Eivind Eklund wrote: > On Mon, Nov 13, 2000 at 05:19:38PM -0800, John Baldwin wrote: >> Well, I've seen several cases of this being talked about, but unless there >> are >> major objections (and there shouldn't be), I plan to turn on the following >> options in GENERIC in -current in 2-3 days: >> >> options INVARIANTS >> options INVARIANT_SUPPORT >> options DIAGNOSTICS >> options WITNESS >> >> Currently a kernel will not boot with WITNESS turned on (it will die during >> the >> SCSI/ATA probes), but I have patches to fix this that have been tested on UP >> and SMP x86 and work fine and I am in the process of testing on my Alpha. >> If >> anyone has any other debugging options that they would like to see turned on >> in >> addition, feel free to add to this list. > > I'm not sure I'm happy about DIAGNOSTIC; unless changed, it > significantly change some codepaths, and it produce output about system > state, not just extra checks. Any plain checks that are under DIAGNOSTIC is > there through a miscommunication or not finished conversion, anyway; it > should only be causing extra debug output. Ok. So converting any cases of DIAGNOSTIC that are extra checks to use INVARIANTS instead would be a preferable solution? > Adding the rest of them are in my opinion a good thing. > > Eivind. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Nov 15 10: 8:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from bsdone.bsdwins.com (www.bsdwins.com [192.58.184.33]) by hub.freebsd.org (Postfix) with ESMTP id 1BEF337B479; Wed, 15 Nov 2000 10:08:30 -0800 (PST) Received: (from jwd@localhost) by bsdone.bsdwins.com (8.11.0/8.11.0) id eAFI8RF01795; Wed, 15 Nov 2000 13:08:27 -0500 (EST) (envelope-from jwd) Date: Wed, 15 Nov 2000 13:08:27 -0500 From: "John W. De Boskey" To: Terry Lambert Cc: Eivind Eklund , John Baldwin , arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC Message-ID: <20001115130827.A1762@bsdwins.com> References: <20001115134312.C7752@warning.follo.net> <200011151755.KAA13742@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011151755.KAA13742@usr01.primenet.com>; from tlambert@primenet.com on Wed, Nov 15, 2000 at 05:55:54PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Terry Lambert's Original Message ----- > > I'm not sure I'm happy about DIAGNOSTIC; unless changed, it > > significantly change some codepaths, and it produce output about system > > state, not just extra checks. Any plain checks that are under DIAGNOSTIC is > > there through a miscommunication or not finished conversion, anyway; it > > should only be causing extra debug output. > > I am not happy about the code path changes it engenders. > > However, I see the need for turning it on, during a period > where extreme instability of snapshots is anticipated/likely, > and I think that's the reason it is being proposed. > > Many people "try" -current on small scratch disks that they > install from snapshots, rather than polluting their local > trees with -current bits, particularly since the answer to > their bug reports is pretty much to ignore them and tell the > reporter to "resup" or ask "have you tried the snapshot?". > > I think that having the DIAGNOSTIC option is OK; on the other > hand, I somewhat wish that this would move from a GENERIC > file into a SNAPSHOT file, and that snapshots be configured > from there instead of GENERIC, since reverting this back and > forth every six months, instead of changing a cron script, > seems like a real waste of repository commits. I tend to disagree here... Please don't build snapshots with this code turned on. Yes, run with these options turned on by default in GENERIC. I think building snapshots with a SNAPSHOT kernel is an interesting idea, but it leads to dual maint issues where GENERIC gets updated, but SNAPSHOT does not. > > All that said, let's not downplay the code path changes: I > have worked in places where I had to be "the grumpy old man > of the source tree", when the code would not build due to > "DEBUG" _not_ being asserted during the build, or other such > diagnostic manifest constants. I really dislike manifest > constants in all forms, because of this, and prefer link or > run time tuning. Can we turn some of these options into sysctl variables and remove them as kernel config options? sysctl -w kern.diagnostics=1 with the appropriate code changes? (Yes, minor perf loss)... just .02 cents worth of rambling, -John > > I really see no _good_ reason a source repository should not > be at least buildable at all times, other than laziness, but > that's an argument for another day. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > > 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 Wed Nov 15 10:15:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A7FA37B4CF; Wed, 15 Nov 2000 10:15:16 -0800 (PST) Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id A478F6E2E3C; Wed, 15 Nov 2000 10:15:15 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA27643; Wed, 15 Nov 2000 10:15:02 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda27637; Wed Nov 15 10:14:44 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAFIEdw55545; Wed, 15 Nov 2000 10:14:39 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdk55096; Wed Nov 15 10:14:26 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAFIEPu56217; Wed, 15 Nov 2000 10:14:25 -0800 (PST) Message-Id: <200011151814.eAFIEPu56217@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdN55772; Wed Nov 15 10:13:36 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: Terry Lambert Cc: adrian@FreeBSD.ORG (Adrian Chadd), arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-reply-to: Your message of "Wed, 15 Nov 2000 17:38:59 GMT." <200011151739.KAA13021@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 10:13:35 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011151739.KAA13021@usr01.primenet.com>, Terry Lambert writes: > > > > If no /entropy is found it takes a full minute to do the randomdev > > > > seeding during boot on a P5/133. > > > > > > > > Has anybody run a 486 or 386 under current recently ? > > > > 386'en might still have a place for small embedded products but I'm > > proabably going to be flamed when I say I think FreeBSD-current isn't > > very suited to "embedded 386 with tiny everything" applications. > > That's a problem with FreeBSD-current, not a problem with > "embedded 386 with tiny everything". > > I'm reminded when SVR4s footprint first went to 8M of RAM. > > I also find it amusing that I can get an old SVR4.0.2 ES/MP, > and load it on both SMP boxes, and on 6M 386 boxes, when I > am quickly becoming unable to do the same for FreeBSD-current. > > I guess this is inevitable, as security is increased, since > the most secure computer is one which doesn't run... Garfinkel and Spafford write in their book Practical UNIX and Internet Security that the most secure system is one berried under six feet of dirt. Even then tye didn't think it was 100% secure. :) If may comment about the 386/486 issue. I think it would be nice to continue to support 386/486. I and and ISP I do work for don't have an 386's in production but we do have a handful of 486's in use -- they make great firewalls. I even use a 486DX33 with 20 MB RAM as an X server. If we cannot 386/486, however, that would be unfortunate, as IMO the options for various reasons are inferior. It all depends on what our focus should be. What would really be nice would be some kind of charter or 3 year plan from CORE that outlines their vision of what they think FreeBSD should look at that time. This strawman could be use as a basis of debate to define what we really want. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 10:21: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 3A65A37B4C5; Wed, 15 Nov 2000 10:21:02 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 13w7B6-000HT9-00; Wed, 15 Nov 2000 18:21:01 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.0) id eAF6OZO01961; Wed, 15 Nov 2000 07:24:35 +0100 (CET) (envelope-from wkb) Date: Wed, 15 Nov 2000 07:24:35 +0100 From: Wilko Bulte To: Terry Lambert Cc: John Baldwin , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Message-ID: <20001115072435.E1321@freebie.demon.nl> References: <20001114075729.G333@freebie.demon.nl> <200011151723.KAA12325@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200011151723.KAA12325@usr01.primenet.com>; from tlambert@primenet.com on Wed, Nov 15, 2000 at 05:23:26PM +0000 X-OS: FreeBSD 4.2-BETA X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000 at 05:23:26PM +0000, Terry Lambert wrote: > > > > What is the consensus ? > > > > > > What is the current processor of choice for embedded stuff? Is > > > x86 even a good architecture for embedded work? That is the > > > only place that I would see the 386 still being alive... > > > > x86 has never been a good CPU for embedded. [eyes his trusty books > > collection for Motorola's 680x0 ;) ] > > The Motorola strategy is broken; the processor they are selling > for Palm Pilots has no MMU. It's no good for most embedded work > (and is barely good enough for making Palm Pilots unstable with > one single bad program). I could not care less about Palmpilots to be honest. Not an embedded application by my standards btw. > Cyrix, AMD, and various Card PCs are all 386-class CPUs. The > IBM "Blue Lightning" core is a 386 class core, which is used > to implement macrocell based embedded ASICs. Intel has two > 386 macrocells that are used for embedded work. I'd have to > say that not even the 80186 was dead yet... Sure, macrocells are used quite often. -- Wilko Bulte Arnhem, the Netherlands wilko@freebsd.org http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 10:37: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 7B5D737B4CF for ; Wed, 15 Nov 2000 10:37:01 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id eAFIb0t06833 for arch@freebsd.org; Wed, 15 Nov 2000 19:37:00 +0100 (CET) (envelope-from adrian) Date: Wed, 15 Nov 2000 19:37:00 +0100 From: Adrian Chadd To: arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Message-ID: <20001115193700.A6799@roaming.cacheboy.net> References: <200011151739.KAA13021@usr01.primenet.com> <200011151814.eAFIEPu56217@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200011151814.eAFIEPu56217@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Wed, Nov 15, 2000 at 10:13:35AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000, Cy Schubert - ITSD Open Systems Group wrote: > What would really be nice would be some kind of charter or 3 year plan > from CORE that outlines their vision of what they think FreeBSD should > look at that time. This strawman could be use as a basis of debate to > define what we really want. improve freebsd. IMHO a 3 year vision really isn't that useful - who knows where computers will be in three years? :-) Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 10:45: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29DF837B479; Wed, 15 Nov 2000 10:45:03 -0800 (PST) Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1DD86E2EE9; Wed, 15 Nov 2000 10:43:45 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA27719; Wed, 15 Nov 2000 10:38:23 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda27717; Wed Nov 15 10:38:03 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAFIbsn91737; Wed, 15 Nov 2000 10:37:54 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdG90432; Wed Nov 15 10:37:25 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAFIbPn69154; Wed, 15 Nov 2000 10:37:25 -0800 (PST) Message-Id: <200011151837.eAFIbPn69154@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdS68834; Wed Nov 15 10:36:43 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: "John W. De Boskey" Cc: Terry Lambert , Eivind Eklund , John Baldwin , arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC In-reply-to: Your message of "Wed, 15 Nov 2000 13:08:27 EST." <20001115130827.A1762@bsdwins.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 10:36:43 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001115130827.A1762@bsdwins.com>, "John W. De Boskey" writes: > ----- Terry Lambert's Original Message ----- > > > I'm not sure I'm happy about DIAGNOSTIC; unless changed, it > > > significantly change some codepaths, and it produce output about system > > > state, not just extra checks. Any plain checks that are under DIAGNOSTIC > is > > > there through a miscommunication or not finished conversion, anyway; it > > > should only be causing extra debug output. > > > > I am not happy about the code path changes it engenders. > > > > However, I see the need for turning it on, during a period > > where extreme instability of snapshots is anticipated/likely, > > and I think that's the reason it is being proposed. > > > > Many people "try" -current on small scratch disks that they > > install from snapshots, rather than polluting their local > > trees with -current bits, particularly since the answer to > > their bug reports is pretty much to ignore them and tell the > > reporter to "resup" or ask "have you tried the snapshot?". > > > > I think that having the DIAGNOSTIC option is OK; on the other > > hand, I somewhat wish that this would move from a GENERIC > > file into a SNAPSHOT file, and that snapshots be configured > > from there instead of GENERIC, since reverting this back and > > forth every six months, instead of changing a cron script, > > seems like a real waste of repository commits. > > I tend to disagree here... Please don't build snapshots with > this code turned on. > > Yes, run with these options turned on by default in GENERIC. > > I think building snapshots with a SNAPSHOT kernel is an > interesting idea, but it leads to dual maint issues where > GENERIC gets updated, but SNAPSHOT does not. How about a sed script that generates SNAPSHOT from GENERIC. Then there are no dual maint issues. When buildkernel KERNEL=SNAPSHOT is performed, the script is run to generate SNAPSHOT from GENERIC. > > > > > All that said, let's not downplay the code path changes: I > > have worked in places where I had to be "the grumpy old man > > of the source tree", when the code would not build due to > > "DEBUG" _not_ being asserted during the build, or other such > > diagnostic manifest constants. I really dislike manifest > > constants in all forms, because of this, and prefer link or > > run time tuning. > > Can we turn some of these options into sysctl variables and > remove them as kernel config options? > > sysctl -w kern.diagnostics=1 > > with the appropriate code changes? (Yes, minor perf loss)... Could even be a major perf loss. My vote is no. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 11: 8:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 6DEFD37B4C5; Wed, 15 Nov 2000 11:08:47 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA27834; Wed, 15 Nov 2000 11:08:44 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda27830; Wed Nov 15 11:08:30 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAFJ8On21295; Wed, 15 Nov 2000 11:08:24 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdK19127; Wed Nov 15 11:07:30 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAFJ7Rb87207; Wed, 15 Nov 2000 11:07:27 -0800 (PST) Message-Id: <200011151907.eAFJ7Rb87207@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdZ86735; Wed Nov 15 11:06:33 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: Adrian Chadd Cc: arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-reply-to: Your message of "Wed, 15 Nov 2000 19:37:00 +0100." <20001115193700.A6799@roaming.cacheboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 11:06:33 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001115193700.A6799@roaming.cacheboy.net>, Adrian Chadd writes: > On Wed, Nov 15, 2000, Cy Schubert - ITSD Open Systems Group wrote: > > > What would really be nice would be some kind of charter or 3 year plan > > from CORE that outlines their vision of what they think FreeBSD should > > look at that time. This strawman could be use as a basis of debate to > > define what we really want. > > improve freebsd. > > IMHO a 3 year vision really isn't that useful - who knows where > computers will be in three years? :-) OK, 1 year plan. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 11:11:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id B4EF237B4CF; Wed, 15 Nov 2000 11:11:08 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 13w7xZ-000IXp-00; Wed, 15 Nov 2000 19:11:06 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.0) id eAF7Ejx03164; Wed, 15 Nov 2000 08:14:45 +0100 (CET) (envelope-from wkb) Date: Wed, 15 Nov 2000 08:14:45 +0100 From: Wilko Bulte To: Cy Schubert - ITSD Open Systems Group Cc: Adrian Chadd , arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Message-ID: <20001115081445.A3059@freebie.demon.nl> References: <20001115193700.A6799@roaming.cacheboy.net> <200011151907.eAFJ7Rb87207@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200011151907.eAFJ7Rb87207@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Wed, Nov 15, 2000 at 11:06:33AM -0800 X-OS: FreeBSD 4.2-BETA X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000 at 11:06:33AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > In message <20001115193700.A6799@roaming.cacheboy.net>, Adrian Chadd > writes: > > On Wed, Nov 15, 2000, Cy Schubert - ITSD Open Systems Group wrote: > > > > > What would really be nice would be some kind of charter or 3 year plan > > > from CORE that outlines their vision of what they think FreeBSD should > > > look at that time. This strawman could be use as a basis of debate to > > > define what we really want. > > > > improve freebsd. > > > > IMHO a 3 year vision really isn't that useful - who knows where > > computers will be in three years? :-) > > OK, 1 year plan. Depends on what the DoJ does to M$ ? :-P -- Wilko Bulte Arnhem, the Netherlands wilko@freebsd.org http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 11:25:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 3FC7837B479; Wed, 15 Nov 2000 11:25:22 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA27888; Wed, 15 Nov 2000 11:24:44 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda27886; Wed Nov 15 11:24:40 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAFJOYn40295; Wed, 15 Nov 2000 11:24:34 -0800 (PST) Message-Id: <200011151924.eAFJOYn40295@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdu40109; Wed Nov 15 11:24:23 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cschuber To: Wilko Bulte Cc: Cy Schubert - ITSD Open Systems Group , Adrian Chadd , arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-reply-to: Your message of "Wed, 15 Nov 2000 08:14:45 +0100." <20001115081445.A3059@freebie.demon.nl> Date: Wed, 15 Nov 2000 11:24:22 -0800 From: Cy Schubert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001115081445.A3059@freebie.demon.nl>, Wilko Bulte writes: > On Wed, Nov 15, 2000 at 11:06:33AM -0800, Cy Schubert - ITSD Open Systems Gro > up wrote: > > In message <20001115193700.A6799@roaming.cacheboy.net>, Adrian Chadd > > writes: > > > On Wed, Nov 15, 2000, Cy Schubert - ITSD Open Systems Group wrote: > > > > > > > What would really be nice would be some kind of charter or 3 year plan > > > > from CORE that outlines their vision of what they think FreeBSD should > > > > look at that time. This strawman could be use as a basis of debate to > > > > define what we really want. > > > > > > improve freebsd. > > > > > > IMHO a 3 year vision really isn't that useful - who knows where > > > computers will be in three years? :-) > > > > OK, 1 year plan. > > Depends on what the DoJ does to M$ ? :-P And that depends on who wins the presidential election. :) Either way, it's still good to have some kind of plan in writing, even if it's a one page plan outlining what we'd like to accomplish over the next 12 months. Circumstances may change that plan, at which point we alter our plan. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 11:31:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 8624437B4C5 for ; Wed, 15 Nov 2000 11:31:42 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13w8HK-0007CK-00 for arch@freebsd.org; Wed, 15 Nov 2000 21:31:30 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id VAA13553 for ; Wed, 15 Nov 2000 21:31:36 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 13450; Wed Nov 15 21:30:44 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13w8Ga-0000es-00 for arch@FreeBSD.ORG; Wed, 15 Nov 2000 21:30:44 +0200 From: Sheldon Hearn To: arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-reply-to: Your message of "Wed, 15 Nov 2000 11:06:33 PST." <200011151907.eAFJ7Rb87207@cwsys.cwsent.com> Date: Wed, 15 Nov 2000 21:30:44 +0200 Message-ID: <2533.974316644@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can I just say that I think we've strayed _way_ off track here. This whole thing started with someone saying that the CPU required to seed the random device is prohibitive for the 386. Unless there are other undisclosed issues, I think we may be putting the cart before the horse here. Mark Murray has at least two different avenues down which performance improvements for the random device lie: * counter jitter instead of getnanotime(2) * rijndael instead of blowfish Perhaps it would be wise to hold off on reminiscing about the good old days, when FreeBSD's ancestors would operate with less memory than FreeBSD uses to wipe its bottom, until we're actually sure that the only issue raised is a real issue. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 11:42:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 3C5EC37B4C5; Wed, 15 Nov 2000 11:42:29 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 13w8Rv-000J8c-00; Wed, 15 Nov 2000 19:42:27 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.0) id eAF7k6Z04044; Wed, 15 Nov 2000 08:46:06 +0100 (CET) (envelope-from wkb) Date: Wed, 15 Nov 2000 08:46:06 +0100 From: Wilko Bulte To: Cy Schubert - ITSD Open Systems Group Cc: Adrian Chadd , arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Message-ID: <20001115084606.A3972@freebie.demon.nl> References: <20001115081445.A3059@freebie.demon.nl> <200011151924.eAFJOYn40295@passer.osg.gov.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200011151924.eAFJOYn40295@passer.osg.gov.bc.ca>; from cschuber@uumail.gov.bc.ca on Wed, Nov 15, 2000 at 11:24:22AM -0800 X-OS: FreeBSD 4.2-BETA X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000 at 11:24:22AM -0800, Cy Schubert wrote: > In message <20001115081445.A3059@freebie.demon.nl>, Wilko Bulte writes: > > On Wed, Nov 15, 2000 at 11:06:33AM -0800, Cy Schubert - ITSD Open Systems Gro ... > > > > computers will be in three years? :-) > > > > > > OK, 1 year plan. > > > > Depends on what the DoJ does to M$ ? :-P > > And that depends on who wins the presidential election. :) Europeans love to see this on CNN. It's better than Monty Python ;-) > Either way, it's still good to have some kind of plan in writing, even > if it's a one page plan outlining what we'd like to accomplish over the > next 12 months. Circumstances may change that plan, at which point we > alter our plan. Absolutely. -- Wilko Bulte Arnhem, the Netherlands wilko@freebsd.org http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 12:19:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id C7AEC37B479; Wed, 15 Nov 2000 12:19:26 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WVAKCDJJ; Wed, 15 Nov 2000 15:19:52 -0500 Reply-To: Randell Jesup To: Terry Lambert Cc: wkb@freebie.demon.nl (Wilko Bulte), jhb@FreeBSD.ORG (John Baldwin), phk@FreeBSD.ORG (Poul-Henning Kamp), arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... References: <200011151723.KAA12325@usr01.primenet.com> From: Randell Jesup Date: 15 Nov 2000 15:24:29 -0500 In-Reply-To: Terry Lambert's message of "Wed, 15 Nov 2000 17:23:26 +0000 (GMT)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: >> > What is the current processor of choice for embedded stuff? Is >> > x86 even a good architecture for embedded work? That is the >> > only place that I would see the 386 still being alive... >> >> x86 has never been a good CPU for embedded. [eyes his trusty books >> collection for Motorola's 680x0 ;) ] > >The Motorola strategy is broken; the processor they are selling >for Palm Pilots has no MMU. It's no good for most embedded work >(and is barely good enough for making Palm Pilots unstable with >one single bad program). You don't need an MMU in that situation; you merely need good memory-debugging tools for application writers. We did it on the Amiga; my average uptime on my development machine (often running buggy/alpha programs or parts of the OS) was measured in months. In fact, the color Palms are VERY similar in many ways to Amigas. The trick is just to develop with a strong epmhasis on failure paths and cleanup. However, we're getting off-topic; please follow-up my email if you want to continue. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 14:41:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id CE63D37B479 for ; Wed, 15 Nov 2000 14:41:15 -0800 (PST) Received: (qmail 56820 invoked from network); 15 Nov 2000 22:39:33 -0000 Received: from unknown (HELO telehouse.ch) ([213.210.21.177]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 15 Nov 2000 22:39:33 -0000 Message-ID: <3A09B0B0.6661E143@telehouse.ch> Date: Wed, 08 Nov 2000 20:59:44 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bosko Milekic Cc: arch@FreeBSD.ORG Subject: Re: Green/Yellow/Red state for the VM system. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bosko Milekic wrote: > > On Wed, 8 Nov 2000, Andre Oppermann wrote: > > > Let's have an example: There is a DoS attack being launched with > > thousands of TCP connections to some port. Now let's assume this > > would use up all available KVM resources. The thousand-and-first > > TCP connection cannot be handled anymore because there is no free > > KVM any more. Now the INET Networking subsystem has two options: > > 1) make some resources available, eg. drop all fin_wait connections, > > 2) refuse to accept this connection. > > You forget about something. > > (2) has serious implications which are not favorable. The system is > not only going to refuse to accept the connection, but it's going to get > so wedged that it's going to start dropping packets. The idea with the > "yellow" flag would be to stop accepting new connections, and rather just > deal with the presently established connections. This is way better than > just dropping random packets. That is more or less precisely an other way to say "refuse to accept this [new] connection" == "stop accepting new connections". All I argue about is that we don't need a global flag but subsystem local flags as you mention yourself in a later email. Strengthen (or bugfix) the subsystems in a way that they survive a malloc() returning zero either by stopping acceptance of new work, by cleaning up in it's own garden or a combination of both. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 15: 2:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id 53AC137B479 for ; Wed, 15 Nov 2000 15:02:58 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id 74C6F18C5; Wed, 15 Nov 2000 18:02:57 -0500 (EST) Date: Wed, 15 Nov 2000 18:02:57 -0500 From: Will Andrews To: Terry Lambert Cc: arch@FreeBSD.org Subject: Re: Turning on debugging in GENERIC Message-ID: <20001115180257.B26516@puck.firepipe.net> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , Terry Lambert , arch@FreeBSD.org References: <20001115134312.C7752@warning.follo.net> <200011151755.KAA13742@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011151755.KAA13742@usr01.primenet.com>; from tlambert@primenet.com on Wed, Nov 15, 2000 at 05:55:54PM +0000 X-Operating-System: FreeBSD 4.1-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000 at 05:55:54PM +0000, Terry Lambert wrote: > Many people "try" -current on small scratch disks that they > install from snapshots, rather than polluting their local > trees with -current bits, particularly since the answer to > their bug reports is pretty much to ignore them and tell the > reporter to "resup" or ask "have you tried the snapshot?". Um, Terry, are you even on bugs@ ? The fact of life is, many folks who "try" -current that report bugs do not give enough details, so they in return get vague suggestions like these. Besides, people are told to resup when the newer -current has fixed the problem, and using a snapshot is an easy way to determine points of infection. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 22:31:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.18]) by hub.freebsd.org (Postfix) with ESMTP id 1267137B4CF for ; Wed, 15 Nov 2000 22:31:31 -0800 (PST) Received: from grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.1/8.11.1) with ESMTP id eAG6VLD68299; Thu, 16 Nov 2000 08:31:21 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011160631.eAG6VLD68299@grimreaper.grondar.za> To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... References: <2533.974316644@axl.fw.uunet.co.za> In-Reply-To: <2533.974316644@axl.fw.uunet.co.za> ; from Sheldon Hearn "Wed, 15 Nov 2000 21:30:44 +0200." Date: Thu, 16 Nov 2000 08:31:21 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Unless there are other undisclosed issues, I think we may be putting > the cart before the horse here. Mark Murray has at least two different > avenues down which performance improvements for the random device lie: "three". > * counter jitter instead of getnanotime(2) > * rijndael instead of blowfish * Use a circular buffer instad if a TAILQ-fifo to store the entropy harvesting; this removes expensive malloc(9)s from the harvesting procedure. > Perhaps it would be wise to hold off on reminiscing about the good old > days, when FreeBSD's ancestors would operate with less memory than > FreeBSD uses to wipe its bottom, until we're actually sure that the only > issue raised is a real issue. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 15 23:57:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id DDE3B37B4E5 for ; Wed, 15 Nov 2000 23:57:09 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13wJuf-0005Jp-00; Thu, 16 Nov 2000 09:56:53 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id JAA28614; Thu, 16 Nov 2000 09:57:01 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 28445; Thu Nov 16 09:55:56 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13wJtj-0000Ho-00; Thu, 16 Nov 2000 09:55:55 +0200 From: Sheldon Hearn To: Will Andrews Cc: Terry Lambert , arch@freebsd.org Subject: Re: Turning on debugging in GENERIC In-reply-to: Your message of "Wed, 15 Nov 2000 18:02:57 EST." <20001115180257.B26516@puck.firepipe.net> Date: Thu, 16 Nov 2000 09:55:55 +0200 Message-ID: <1103.974361355@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 15 Nov 2000 18:02:57 EST, Will Andrews wrote: > Um, Terry, are you even on bugs@ ? The fact of life is, many folks who > "try" -current that report bugs do not give enough details, so they in > return get vague suggestions like these. I'd like to clarify what Will said before we get led down astray by the people who're just mailing for the sake of mailing. The problem I often had with freebsd-bugs when I was very active there was that folks would catch a panic, send a backtrace with absolutely no debugging symbols and then move on. Often, these people were not prepared to try to reproduce the panic. If we had CURRENT's kernel default to including full debugging support, I think we'd get better results out of many of our bug reports. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 1:23:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id A5C4B37B4D7 for ; Thu, 16 Nov 2000 01:23:24 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id CAA11014; Thu, 16 Nov 2000 02:19:51 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAkYaWqv; Thu Nov 16 02:19:39 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id CAA01986; Thu, 16 Nov 2000 02:23:09 -0700 (MST) From: Terry Lambert Message-Id: <200011160923.CAA01986@usr02.primenet.com> Subject: Re: Turning on debugging in GENERIC To: will@physics.purdue.edu Date: Thu, 16 Nov 2000 09:23:08 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.org In-Reply-To: <20001115180257.B26516@puck.firepipe.net> from "Will Andrews" at Nov 15, 2000 06:02:57 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The real point of this thread should be that a 386 taking forever to start up because it's not fast at generating pseudo-randomness is not an acceptable state of affairs. There are plenty of laptop and other so-called "green" processors today which will downgrade CPU power to the level of an old 386, merely to extend battery life or to be considered "eco-friendly", so throwing out the old systems will not solve the problem. The answer to this slow-start "dilemma" is _not_ to throw out the slow processors which can't run the hulking, slow-running new "improved" code, just for the sake of not making that code run efficiently. It's obvious to me that this has the same fix as if someone had put a big "for" loop in the idle proc: tolerate it for a while, if it does something useful, and if it doesn't get fixed after a while, take it out and shoot it, like PHK did to Julian's slice code, even if it _does_ something useful. --- I will answer your points after the ^L below, even though they are now wildly off-subject, as build engineering _is_ at least on topic for the -arch list; those not interested can stop the remainder of the message in their mail client now: If you are reply to this, please change the Subject: line. > > Many people "try" -current on small scratch disks that they > > install from snapshots, rather than polluting their local > > trees with -current bits, particularly since the answer to > > their bug reports is pretty much to ignore them and tell the > > reporter to "resup" or ask "have you tried the snapshot?". > > Um, Terry, are you even on bugs@ ? The fact of life is, many folks who > "try" -current that report bugs do not give enough details, so they in > return get vague suggestions like these. No, I'm not. But I run -current on scratch disks from snapshots because I can't afford the bandwidth to cvsup all the time, and because when you use cvsup, the lack of an interlock means that the result is often unbuildable, particularly when it comes to -current. If I can't afford one, then I can't afford the second one that would be necessary, were I to have a failure. Unfortunately, the cvsup date is not useful information for use in a bug report, either. I would have to change my strategy to doing a cvsup, and then backing off by date in GMT, until I got something that compiled (not a winning strategy on a 386, in any case). That would give me a baseline from which I (or others) could then report bugs that would be repeatable, even if not bleeding-edge -current. It takes a prohibitive amount of disk cycles to do something like this, and hosted cross-builds are still not that easy, unless you want to dirty your main source tree and the /sys link, or unless your scratch disks are really massive suckers. Using snapshots avoids the CPU cycles problem and the cvsup data synchronization problem: a snapshot is not made available until it can at least successfully compile. So you could ammend my statement, I suppose, to ``clued people "try" snapshots to reduce the number of useless answers to their bug reports''. So in summary, I don't need to be on "bugs@" today, since I'm already well aware of the dynamics involved, and nothing has changed from the past about them that would change the dynamics; and it's the dynamics which lead to the lack of details and the vague responses. > Besides, people are told to resup when the newer -current has > fixed the problem, and using a snapshot is an easy way to > determine points of infection. Agreed; I think all reports should be made against snapshots, to have a clear demarcation between developement and testing, if nothing else. But even though I advocate using them, in my post, which you quoted above, they are still succeptible to the problems I noted. Snapshots have a relatively short archival life expectancy, and so they aren't really useful for developers for repeating a user reported problem. Even with an exact date, a developer is probably not going to be able to rebuild a system against which they can run gdb with a user supplied crash dump. So where are we left? With a bunch of developers who would like help testing their code against a lot of different hardware, and a much larger group of users who would like to help them out, but have huge impediments in the communications channel between them and the developers. How can we resolve this impasse? There are a couple of simple procedural fixes, actually: 1) The snapshot was rebuildable from sources, such that a kernel debugging session would work. This could be done by build-tagging the repository sources (the tags could be removed as the snapshots were removed), or by using explicit dates to check out the snapshot trees for the build. 2) Snapshots could be trusted to hang around for long enough for a developer and a bug reported to be able to rendesvous on one, and fix a problem. 3) Kernels for snapshots were built with full debugging symbols (-g), and only stripped for the snapshot, and the unstripped version kept around with the snapshot for use by a developer wanting to debug a crash (this would mostly eliminate the ned for #1 for debugging -- but not for bug fixing, since you would want to rebuild with more error diagnostics and retry the failure, etc., until the fault was isolated). Even Whistle, which was about as ad-hoc about using the local source repository to communicate between developers in adjacent cubicles (a practice which can result in frequently unbuildable source trees) knew enough, institutionally, about build engineering to at least make all successful builds (not just releases) rebuildable. A seperate build engineer role, and a willingness to tag builds in the repository after reverting changes which prevented builds, was helpful in making this a nightly (or more frequent) occurrance, but FreeBSD doesn't have that strong an "it works" requirement, nor as formal testing vs. requirements and a regression of closed but not verified resolved bugs, that it could not afford some delay between snapshot instances. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 1:36: 4 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 1625037B479 for ; Thu, 16 Nov 2000 01:36:01 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13wLSL-0006hq-00; Thu, 16 Nov 2000 11:35:45 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id LAA19226; Thu, 16 Nov 2000 11:35:54 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 19104; Thu Nov 16 11:35:30 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13wLS6-0000Wf-00; Thu, 16 Nov 2000 11:35:30 +0200 From: Sheldon Hearn To: Terry Lambert Cc: will@physics.purdue.edu, arch@freebsd.org Subject: Re: Turning on debugging in GENERIC In-reply-to: Your message of "Thu, 16 Nov 2000 09:23:08 GMT." <200011160923.CAA01986@usr02.primenet.com> Date: Thu, 16 Nov 2000 11:35:30 +0200 Message-ID: <2024.974367330@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 16 Nov 2000 09:23:08 GMT, Terry Lambert wrote: > The real point of this thread should be that a 386 taking forever > to start up because it's not fast at generating pseudo-randomness > is not an acceptable state of affairs. Terry, please think about what you're trying to achieve by posting to his list. You're now arguing a point of view that relates to a completely different thread, and one which I've already suggested has dubious value in the here and now. Nobody else has come up with any issues that indicate that my suggestion was flawed. This thread (the one you're responding on) is about the value of making various debugging support options default in CURRENT, during the development cycle leading up to 5.0-RELEASE. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 1:58:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 65A5437B4D7 for ; Thu, 16 Nov 2000 01:58:37 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id CAA25595; Thu, 16 Nov 2000 02:57:35 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpdAAALvaG5X; Thu Nov 16 02:57:22 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id CAA02498; Thu, 16 Nov 2000 02:58:17 -0700 (MST) From: Terry Lambert Message-Id: <200011160958.CAA02498@usr02.primenet.com> Subject: Re: Turning on debugging in GENERIC To: sheldonh@uunet.co.za (Sheldon Hearn) Date: Thu, 16 Nov 2000 09:58:17 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), will@physics.purdue.edu, arch@freebsd.org In-Reply-To: <2024.974367330@axl.fw.uunet.co.za> from "Sheldon Hearn" at Nov 16, 2000 11:35:30 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The real point of this thread should be that a 386 taking forever > > to start up because it's not fast at generating pseudo-randomness > > is not an acceptable state of affairs. > > Terry, please think about what you're trying to achieve by posting to > his list. > > You're now arguing a point of view that relates to a completely > different thread, and one which I've already suggested has dubious value > in the here and now. Nobody else has come up with any issues that > indicate that my suggestion was flawed. > > This thread (the one you're responding on) is about the value of making > various debugging support options default in CURRENT, during the > development cycle leading up to 5.0-RELEASE. Sorry; I had an editor crash-and-burn, and was recovring via a vi -r, which lost my subject in a related posting. Please ignore the preamble section; I read one, and replied to another, based on two recovered edits. I think the build process issues are relevent to whether or not you need increased debugging, or whther you can get the information from a covert channel, like a bug report. I still think that increasing kernel spew to the DIAGNOSTIC level, at a cost of potentially very different code paths, is much less useful, in terms of getting good bug reports, than fixing the communcatons channel between the reporters and the developers would be. I would say: 1) Turn on everything but DIAGNOSTIC, since it _really_ changes the code and timings away from normal. 2) Do this in a copy of GENERIC that's used to build snapshots, not the real GENERIC, so it can be kept around and up to date (I liked the postprocessing of GENERIC suggestion, for keeping this in sync). 3) If the code path issues can be resolved, then any other options, including DIAGNOSTIC, should be heaped in, too. If they can't, though, then I think going after the bug report communcations is a better way to achieve the results I think are trying to be achieved by turning all this stuff on by default. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 2: 4: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id DFFAD37B4C5; Thu, 16 Nov 2000 02:04:01 -0800 (PST) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13wLtV-00073S-00; Thu, 16 Nov 2000 12:03:49 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id MAA23995; Thu, 16 Nov 2000 12:03:57 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 23902; Thu Nov 16 12:03:36 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13wLtI-0000bo-00; Thu, 16 Nov 2000 12:03:36 +0200 From: Sheldon Hearn To: Terry Lambert Cc: jhb@freebsd.org, arch@freebsd.org Subject: Re: Turning on debugging in GENERIC In-reply-to: Your message of "Thu, 16 Nov 2000 09:58:17 GMT." <200011160958.CAA02498@usr02.primenet.com> Date: Thu, 16 Nov 2000 12:03:36 +0200 Message-ID: <2343.974369016@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 16 Nov 2000 09:58:17 GMT, Terry Lambert wrote: > I still think that increasing kernel spew to the DIAGNOSTIC level, > at a cost of potentially very different code paths, is much less > useful [...] I haven't noticed any interesting disagreement on that score. Unless someone has new issues to bring to light, it looks like we have agreement on this one. Go, John, go! :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 8:30:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 20D0E37B479 for ; Thu, 16 Nov 2000 08:30:17 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id JAA17980; Thu, 16 Nov 2000 09:30:09 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id JAA04560; Thu, 16 Nov 2000 09:29:58 -0700 (MST) (envelope-from nate) Date: Thu, 16 Nov 2000 09:29:58 -0700 (MST) Message-Id: <200011161629.JAA04560@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: will@physics.purdue.edu, arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC In-Reply-To: <200011160923.CAA01986@usr02.primenet.com> References: <20001115180257.B26516@puck.firepipe.net> <200011160923.CAA01986@usr02.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Um, Terry, are you even on bugs@ ? The fact of life is, many folks who > > "try" -current that report bugs do not give enough details, so they in > > return get vague suggestions like these. > > No, I'm not. But I run -current on scratch disks from snapshots > because I can't afford the bandwidth to cvsup all the time Umm, Terry the amount of bandwidth you consume with email is close to the amount of bandwidth it would require for you to stay up-to-date with CVSup. I use it on a daily basis, and it takes literally minutes (not tens of minutes) to keep the tree up-to-date, except when tags are put down. >, and > because when you use cvsup, the lack of an interlock means that > the result is often unbuildable, particularly when it comes to > -current. If I can't afford one, then I can't afford the second > one that would be necessary, were I to have a failure. It doesn't build because the developers haven't taken the time to make sure it builds. This has little to do with lack of interlock. I can think of less than 2 dozen times in the 8+ years of FreeBSD where an interlock would have helped. Again, you speak w/out any experience, making you look like a fool. > Unfortunately, the cvsup date is not useful information for use > in a bug report, either. I would have to change my strategy to > doing a cvsup, and then backing off by date in GMT, until I got > something that compiled (not a winning strategy on a 386, in any > case). True, but it's the cost of doing bleeding edge development on a large project. Even monster projects have these sorts of problem, unless that have boatloads of people and hardware dedicately solely to the task of making sure the system builds. You aren't willing to help, why should you expect others to help? > It takes a prohibitive amount of disk cycles to do something like > this, and hosted cross-builds are still not that easy, unless you want > to dirty your main source tree and the /sys link, or unless your > scratch disks are really massive suckers. Cross-builds are trivial is you stick them in /chroot partition. (Julian did this initially with 'ref.tfs.com', and I've followed it since with great results in almost all cases.) Also, 'disk cycles' are free if this host in indeed a 'scratch' host, or did your computer start charging you more for being busy instead of being idle? (Or more to the point, do you have alot of other processes that your proverbial 386 must be busy doing instead of builds?) > Using snapshots avoids the CPU cycles problem and the cvsup data > synchronization problem: a snapshot is not made available until > it can at least successfully compile. Sure, and it's out-of-date as well. > So you could ammend my statement, I suppose, to ``clued people > "try" snapshots to reduce the number of useless answers to their > bug reports''. If it doesn't build, it's pretty tough to give out 'bug reports' of the type the developers are asking for (back-traces, etc..), simply because the system can't build. 'It doesn't work' bug reports come in often, and those in themselves are decent as long as the submitter gives enough error information on where it's broken. > So in summary, I don't need to be on "bugs@" today, since I'm Let me rephrase that again, for the Terry-impaired: "Because I'm a know-it-all and everyone ignores me anyway, because I often complain about non-existant bugs that only exist in my brain. Plus, I send out some much email that any bits of useful knowledge are lost in the incredible amount of noise I generate." Honestly Terry, you're a bright guy. But, you aren't nearly as bright as you think you are. People might take you seriously if you stuck to topics that you *do* know something about, and try to tone down both the length of your email as well the amount of politics your portray. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 14: 5:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5586E37B479 for ; Thu, 16 Nov 2000 14:05:08 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAGM58w16060 for arch@freebsd.org; Thu, 16 Nov 2000 14:05:08 -0800 (PST) Date: Thu, 16 Nov 2000 14:05:07 -0800 From: Alfred Perlstein To: arch@freebsd.org Subject: potentially simpler approach than scheduler activations. Message-ID: <20001116140506.Q830@fw.wintelcom.net> 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 X-Loop: FreeBSD.ORG This is an idea that I hope doesn't generate any major bikesheds, I just wanted to toss it out as something that someone might want to research further and possibly complete it. It's an idea to make the uthreads library safe against disk IO blocking the entire process. ====== We could have a pretty good threading system with some minor tweaks instead of rewriting the proc/scheduler mechanism. Afaik we still have problems with: a) sysV IPC b) disk I/O c) page not preset faults making the entire thread library block Solutions: a) implement kevent filters for messsage queues and semphore sets relatively easy. b) make uthreads use aio for disk files, relatively easy c) use a syscall that requests that on a page not present but valid pagefault we generate a signal such as SIGPNP (?) and have the kernel async page it in handing the process a kevent with the void * pointer referencing the page that was faulted in async. Or, have an aio call that the scheduler will call to have the page filled in. I know it's not exactly what you want, but it seems that it would be a lot easier to implement and at the same time a lot safer for the kernel. I know that by applying these band-aids we aren't completely solving every problem and as new interfaces pop-up we might have to apply more band-aids to libc_r, but I think this might get us past the point of system that breaks down on disk IO. We could then later use rfork threads and a "big giant" over the uthread schedule to take advantage of multiple processors. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 14: 8:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 1308A37B479 for ; Thu, 16 Nov 2000 14:08:50 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id OAA73277; Thu, 16 Nov 2000 14:07:37 -0800 (PST) (envelope-from obrien) Date: Thu, 16 Nov 2000 14:07:37 -0800 From: "David O'Brien" To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Message-ID: <20001116140737.B72650@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200011151739.KAA13021@usr01.primenet.com> <200011151814.eAFIEPu56217@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011151814.eAFIEPu56217@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Wed, Nov 15, 2000 at 10:13:35AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000 at 10:13:35AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > What would really be nice would be some kind of charter or 3 year plan > from CORE that outlines their vision of what they think FreeBSD should > look at that time. This strawman could be use as a basis of debate to > define what we really want. Why do you look to Core for this?? Look to the committers (and arch@freebsd.org) as they are the ones doing the work and pushing the technology forward. Today's Core is not an architectural board. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 14:25:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 1461337B479; Thu, 16 Nov 2000 14:25:22 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id OAA00232; Thu, 16 Nov 2000 14:25:10 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda00226; Thu Nov 16 14:24:55 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAGMOnL41055; Thu, 16 Nov 2000 14:24:49 -0800 (PST) Message-Id: <200011162224.eAGMOnL41055@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdG41048; Thu Nov 16 14:24:31 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cschuber To: obrien@FreeBSD.ORG Cc: Cy Schubert - ITSD Open Systems Group , arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-reply-to: Your message of "Thu, 16 Nov 2000 14:07:37 PST." <20001116140737.B72650@dragon.nuxi.com> Date: Thu, 16 Nov 2000 14:24:31 -0800 From: Cy Schubert Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001116140737.B72650@dragon.nuxi.com>, "David O'Brien" writes: > On Wed, Nov 15, 2000 at 10:13:35AM -0800, Cy Schubert - ITSD Open Systems Gro > up wrote: > > What would really be nice would be some kind of charter or 3 year plan > > from CORE that outlines their vision of what they think FreeBSD should > > look at that time. This strawman could be use as a basis of debate to > > define what we really want. > > Why do you look to Core for this?? Look to the committers (and > arch@freebsd.org) as they are the ones doing the work and pushing the > technology forward. Today's Core is not an architectural board. What is the purpose of Core then? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 14:32:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 877FE37B479; Thu, 16 Nov 2000 14:32:42 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAGMWfQ02345; Thu, 16 Nov 2000 15:32:41 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA69400; Thu, 16 Nov 2000 15:32:40 -0700 (MST) Message-Id: <200011162232.PAA69400@harmony.village.org> To: obrien@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Cc: Cy Schubert - ITSD Open Systems Group , arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Nov 2000 14:07:37 PST." <20001116140737.B72650@dragon.nuxi.com> References: <20001116140737.B72650@dragon.nuxi.com> <200011151739.KAA13021@usr01.primenet.com> <200011151814.eAFIEPu56217@cwsys.cwsent.com> Date: Thu, 16 Nov 2000 15:32:40 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001116140737.B72650@dragon.nuxi.com> "David O'Brien" writes: : On Wed, Nov 15, 2000 at 10:13:35AM -0800, Cy Schubert - ITSD Open Systems Group wrote: : > What would really be nice would be some kind of charter or 3 year plan : > from CORE that outlines their vision of what they think FreeBSD should : > look at that time. This strawman could be use as a basis of debate to : > define what we really want. : : Why do you look to Core for this?? Look to the committers (and : arch@freebsd.org) as they are the ones doing the work and pushing the : technology forward. Today's Core is not an architectural board. I'm not speaking for core. It is my sense that core won't produce such a document. I don't think I'd violate any confidences if I were to disclose that core has no formal request from anybody to produce anything at the moment. No such requests have been turned away. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 14:33:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E1BC037B479; Thu, 16 Nov 2000 14:33:08 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAGMX6Q02353; Thu, 16 Nov 2000 15:33:06 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA69420; Thu, 16 Nov 2000 15:33:06 -0700 (MST) Message-Id: <200011162233.PAA69420@harmony.village.org> To: Cy Schubert - ITSD Open Systems Group Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Cc: obrien@FreeBSD.ORG, arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Nov 2000 14:24:31 PST." <200011162224.eAGMOnL41055@passer.osg.gov.bc.ca> References: <200011162224.eAGMOnL41055@passer.osg.gov.bc.ca> Date: Thu, 16 Nov 2000 15:33:06 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Not speaking for core. In message <200011162224.eAGMOnL41055@passer.osg.gov.bc.ca> Cy Schubert writes: : What is the purpose of Core then? Core is the governing body of FreeBSD. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 14:37:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3528D37B4C5; Thu, 16 Nov 2000 14:37:42 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA12043; Thu, 16 Nov 2000 14:36:47 -0800 Date: Thu, 16 Nov 2000 14:36:44 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Warner Losh Cc: Cy Schubert - ITSD Open Systems Group , obrien@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-Reply-To: <200011162233.PAA69420@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200011162224.eAGMOnL41055@passer.osg.gov.bc.ca> Cy Schubert writes: > : What is the purpose of Core then? > > Core is the governing body of FreeBSD. Which, if I may say, seems to run under the rubric of "That which governs least, governs best". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 14:38:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9304737B4D7; Thu, 16 Nov 2000 14:38:41 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAGMcdQ02401; Thu, 16 Nov 2000 15:38:40 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA69515; Thu, 16 Nov 2000 15:38:39 -0700 (MST) Message-Id: <200011162238.PAA69515@harmony.village.org> To: mjacob@feral.com Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Cc: Cy Schubert - ITSD Open Systems Group , obrien@FreeBSD.ORG, arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Nov 2000 14:36:44 PST." References: Date: Thu, 16 Nov 2000 15:38:39 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : : > In message <200011162224.eAGMOnL41055@passer.osg.gov.bc.ca> Cy Schubert writes: : > : What is the purpose of Core then? : > : > Core is the governing body of FreeBSD. : : Which, if I may say, seems to run under the rubric of "That which governs : least, governs best". That's certainly how I, personally, view things. Others may differ. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 15:24:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 95BE537B4C5 for ; Thu, 16 Nov 2000 15:24:12 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA13319; Thu, 16 Nov 2000 16:24:46 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAAgoaajv; Thu Nov 16 16:18:24 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA04273; Thu, 16 Nov 2000 16:17:44 -0700 (MST) From: Terry Lambert Message-Id: <200011162317.QAA04273@usr08.primenet.com> Subject: Re: Turning on debugging in GENERIC To: nate@yogotech.com Date: Thu, 16 Nov 2000 23:17:43 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), will@physics.purdue.edu, arch@FreeBSD.ORG In-Reply-To: <200011161629.JAA04560@nomad.yogotech.com> from "Nate Williams" at Nov 16, 2000 09:29:58 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams writes: [ ... ] OK, Mr. "holier than thou": Q: What is the root cause of the desire for increased default diagnostics in GENERIC? I say it's to make it easier to debug things: it's a soloution to the "debugability problem". Your answer? Q: Is there more than one way to solve the "debugability problem", without adding a bunch of cruft to GENERIC? I say "yes", but it's probably not worth the effort, except for DIAGNOSTIC, which I think will preturb the results into unusabilty. Your answer? Q: Would making bug reports more repeatable by developers reduce the need for a bunch of debugging information? I say "yes", and it can be accomplished with some simple process changes that will cost nearly nothing. I'm willing to help with the script changes on the machines where these would have to be implemented to be effective. Your answer? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 15:28: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4220C37B4C5; Thu, 16 Nov 2000 15:28:03 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA24829; Thu, 16 Nov 2000 16:28:00 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id QAA17347; Thu, 16 Nov 2000 16:27:58 -0700 (MST) (envelope-from nate) Date: Thu, 16 Nov 2000 16:27:58 -0700 (MST) Message-Id: <200011162327.QAA17347@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Lambert Cc: nate@yogotech.com, chat@freebsd.org Subject: Re: Turning on debugging in GENERIC In-Reply-To: <200011162317.QAA04273@usr08.primenet.com> References: <200011161629.JAA04560@nomad.yogotech.com> <200011162317.QAA04273@usr08.primenet.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Moving replies to -chat ] > Q: What is the root cause of the desire for increased default > diagnostics in GENERIC? [ SNIP ] What does this have to do with you not having the resources to dedicate to CVSup or build -current? Are you going off changing the question, so you can be 'right' again? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 17:14:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id 8B56137B479; Thu, 16 Nov 2000 17:14:50 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13wa8j-0000AR-00; Thu, 16 Nov 2000 18:16:29 -0700 Message-ID: <3A1486ED.2568B51@softweyr.com> Date: Thu, 16 Nov 2000 18:16:29 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Chadd Cc: arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... References: <11485.974210886@critter> <20001114144613.B88888@platinum.scientia.demon.co.uk> <20001114224505.A4195@roaming.cacheboy.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Adrian Chadd wrote: > > On Tue, Nov 14, 2000, Ben Smithurst wrote: > > Poul-Henning Kamp wrote: > > > > > If no /entropy is found it takes a full minute to do the randomdev > > > seeding during boot on a P5/133. > > > > > > Has anybody run a 486 or 386 under current recently ? > > > > 386'en might still have a place for small embedded products but I'm > proabably going to be flamed when I say I think FreeBSD-current isn't > very suited to "embedded 386 with tiny everything" applications. Of course it is. You'd be astonished the tiny amounts of cpu power applied to a lot of ordinary tasks like small routers and such. FreeBSD on 386-class devices is entirely appropriate for any number of such devices, especially with companies like GE making actual appliances (washers, dryers, microwave ovens) that have HPNA or powerline IP networking built in. OK, so it was a candle rather than a flamethrower. It should be made simple to compile in a much less random randomdev for applications that do not need high-quality entropy, like the IP stack on your dishwasher. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 18:20:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (f277.pav1.hotmail.com [64.4.30.152]) by hub.freebsd.org (Postfix) with ESMTP id C8DE237B479 for ; Thu, 16 Nov 2000 18:20:19 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Nov 2000 18:20:17 -0800 Received: from 202.101.165.61 by pv1fd.pav1.hotmail.msn.com with HTTP; Fri, 17 Nov 2000 02:20:17 GMT X-Originating-IP: [202.101.165.61] From: "frank xu" To: arch@freebsd.org Subject: Re: potentially simpler approach than scheduler activations. Date: Fri, 17 Nov 2000 10:20:17 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Nov 2000 02:20:17.0516 (UTC) FILETIME=[ED4202C0:01C0503C] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have readed an article about KSE from jasone, it's cool, can complete resolve much headache, but you method has same problems as LinuxThread, jasone already talked about it, in new FreeBSD 5.0, why can't we have a new way to go? ----- Original Message ----- From: Alfred Perlstein To: Sent: Friday, November 17, 2000 6:05 AM Subject: potentially simpler approach than scheduler activations. >This is an idea that I hope doesn't generate any major bikesheds, >I just wanted to toss it out as something that someone might >want to research further and possibly complete it. > >It's an idea to make the uthreads library safe against disk IO >blocking the entire process. > >====== > >We could have a pretty good threading system with some minor >tweaks instead of rewriting the proc/scheduler mechanism. > >Afaik we still have problems with: > >a) sysV IPC >b) disk I/O >c) page not preset faults making the entire thread library block > >Solutions: > >a) implement kevent filters for messsage queues and semphore sets > relatively easy. >b) make uthreads use aio for disk files, relatively easy >c) use a syscall that requests that on a page not present but valid > pagefault we generate a signal such as SIGPNP (?) and have the > kernel async page it in handing the process a kevent with the > void * pointer referencing the page that was faulted in async. > Or, have an aio call that the scheduler will call to have the > page filled in. > >I know it's not exactly what you want, but it seems that it would >be a lot easier to implement and at the same time a lot safer >for the kernel. > >I know that by applying these band-aids we aren't completely >solving every problem and as new interfaces pop-up we might >have to apply more band-aids to libc_r, but I think this >might get us past the point of system that breaks down on >disk IO. > >We could then later use rfork threads and a "big giant" over >the uthread schedule to take advantage of multiple processors. > >-- >-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] >"I have the heart of a child; I keep it in a jar on my desk." > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-arch" in the body of the message _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 18:24:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (f99.pav1.hotmail.com [64.4.31.99]) by hub.freebsd.org (Postfix) with ESMTP id 22BDE37B479 for ; Thu, 16 Nov 2000 18:24:28 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Nov 2000 18:24:28 -0800 Received: from 202.101.165.61 by pv1fd.pav1.hotmail.msn.com with HTTP; Fri, 17 Nov 2000 02:24:27 GMT X-Originating-IP: [202.101.165.61] From: "frank xu" To: arch@freebsd.org Subject: Re: potentially simpler approach than scheduler activations. Date: Fri, 17 Nov 2000 10:24:27 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Nov 2000 02:24:28.0028 (UTC) FILETIME=[82931BC0:01C0503D] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have readed an article about KSE from jasone, it's cool, can complete resolve much headache, but you method has same problems as LinuxThread, jasone already talked about it, in new FreeBSD 5.0, why can't we have a new way to go? ----- Original Message ----- From: Alfred Perlstein To: Sent: Friday, November 17, 2000 6:05 AM Subject: potentially simpler approach than scheduler activations. >This is an idea that I hope doesn't generate any major bikesheds, >I just wanted to toss it out as something that someone might >want to research further and possibly complete it. > >It's an idea to make the uthreads library safe against disk IO >blocking the entire process. > >====== > >We could have a pretty good threading system with some minor >tweaks instead of rewriting the proc/scheduler mechanism. > >Afaik we still have problems with: > >a) sysV IPC >b) disk I/O >c) page not preset faults making the entire thread library block > >Solutions: > >a) implement kevent filters for messsage queues and semphore sets > relatively easy. >b) make uthreads use aio for disk files, relatively easy >c) use a syscall that requests that on a page not present but valid > pagefault we generate a signal such as SIGPNP (?) and have the > kernel async page it in handing the process a kevent with the > void * pointer referencing the page that was faulted in async. > Or, have an aio call that the scheduler will call to have the > page filled in. > >I know it's not exactly what you want, but it seems that it would >be a lot easier to implement and at the same time a lot safer >for the kernel. > >I know that by applying these band-aids we aren't completely >solving every problem and as new interfaces pop-up we might >have to apply more band-aids to libc_r, but I think this >might get us past the point of system that breaks down on >disk IO. > >We could then later use rfork threads and a "big giant" over >the uthread schedule to take advantage of multiple processors. > >-- >-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] >"I have the heart of a child; I keep it in a jar on my desk." > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-arch" in the body of the message _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 18:42: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4CD4D37B4C5 for ; Thu, 16 Nov 2000 18:42:04 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAH2g1J24568; Thu, 16 Nov 2000 18:42:01 -0800 (PST) Date: Thu, 16 Nov 2000 18:42:01 -0800 From: Alfred Perlstein To: frank xu Cc: arch@FreeBSD.ORG Subject: Re: potentially simpler approach than scheduler activations. Message-ID: <20001116184200.L18037@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bsdman@hotmail.com on Fri, Nov 17, 2000 at 10:24:27AM +0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * frank xu [001116 18:25] wrote: > I have readed an article about KSE from jasone, it's cool, can complete > resolve much headache, but you method has same problems as LinuxThread, > jasone already > talked about it, in new FreeBSD 5.0, why can't we have a new way to go? Actually KSE is closer to Linuxthreads than my suggestion from my point of view. Can you elaborate a bit? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 20:24: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id BC35037B4C5 for ; Thu, 16 Nov 2000 20:23:59 -0800 (PST) Received: (qmail 26501 invoked by uid 3130); 17 Nov 2000 04:23:58 -0000 Message-ID: <20001116232358.A25846@electricjellyfish.net> Date: Thu, 16 Nov 2000 23:23:58 -0500 From: Garrett Rooney To: Alfred Perlstein , frank xu , arch@freebsd.org Cc: arch@FreeBSD.ORG Subject: Re: potentially simpler approach than scheduler activations. References: <20001116184200.L18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <20001116184200.L18037@fw.wintelcom.net>; from Alfred Perlstein on Thu, Nov 16, 2000 at 06:42:01PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 16, 2000 at 06:42:01PM -0800, Alfred Perlstein wrote: > * frank xu [001116 18:25] wrote: > > I have readed an article about KSE from jasone, it's cool, can complete > > resolve much headache, but you method has same problems as LinuxThread, > > jasone already > > talked about it, in new FreeBSD 5.0, why can't we have a new way to go? > > Actually KSE is closer to Linuxthreads than my suggestion from my > point of view. Can you elaborate a bit? well, i don't know if you've come up with a way around this, but in the KSE paper (avail. from http://www.freebsd.org/~jasone/kse) the problems with using rfork() based threads for spreading threads across processors runs into the following issues: 1) each thread is a separate process, and such has a unique pid. POSIX requires each thread to appear to have the same pid, so substantial modifications to the kernel data structures would be required. 2) thread priority semantics specified by POSIX cannot be implimented because each thread is a a process. thread contention at the application level is therefor not possible, all threads are scheduled as processes. this lets multithreaded applications compete unfairly with single threaded applications. 3) Thread switching becomes expensive, because it is a full context switch, requiring dropping into the kernel, switching one proc out, and the other in. the only way to fix this is to optimize process switching, which gets hard past a certain point. 4) each thread has all the kernel resources associated with a process, so applications with many threads require a lot of kernel resources. all of these problems are basically cribbed right out of the paper, all the mistakes are mine, not his. -- garrett rooney my pid is inigo montoya. rooneg@electricjellyfish.net you kill -9 my parent process. http://electricjellyfish.net/ prepare to vi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 20:24: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id C930437B4CF for ; Thu, 16 Nov 2000 20:24:02 -0800 (PST) Received: (qmail 26501 invoked by uid 3130); 17 Nov 2000 04:23:58 -0000 Message-ID: <20001116232358.A25846@electricjellyfish.net> Date: Thu, 16 Nov 2000 23:23:58 -0500 From: Garrett Rooney To: Alfred Perlstein , frank xu , arch@freebsd.org Cc: arch@FreeBSD.ORG Subject: Re: potentially simpler approach than scheduler activations. References: <20001116184200.L18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <20001116184200.L18037@fw.wintelcom.net>; from Alfred Perlstein on Thu, Nov 16, 2000 at 06:42:01PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 16, 2000 at 06:42:01PM -0800, Alfred Perlstein wrote: > * frank xu [001116 18:25] wrote: > > I have readed an article about KSE from jasone, it's cool, can complete > > resolve much headache, but you method has same problems as LinuxThread, > > jasone already > > talked about it, in new FreeBSD 5.0, why can't we have a new way to go? > > Actually KSE is closer to Linuxthreads than my suggestion from my > point of view. Can you elaborate a bit? well, i don't know if you've come up with a way around this, but in the KSE paper (avail. from http://www.freebsd.org/~jasone/kse) the problems with using rfork() based threads for spreading threads across processors runs into the following issues: 1) each thread is a separate process, and such has a unique pid. POSIX requires each thread to appear to have the same pid, so substantial modifications to the kernel data structures would be required. 2) thread priority semantics specified by POSIX cannot be implimented because each thread is a a process. thread contention at the application level is therefor not possible, all threads are scheduled as processes. this lets multithreaded applications compete unfairly with single threaded applications. 3) Thread switching becomes expensive, because it is a full context switch, requiring dropping into the kernel, switching one proc out, and the other in. the only way to fix this is to optimize process switching, which gets hard past a certain point. 4) each thread has all the kernel resources associated with a process, so applications with many threads require a lot of kernel resources. all of these problems are basically cribbed right out of the paper, all the mistakes are mine, not his. -- garrett rooney my pid is inigo montoya. rooneg@electricjellyfish.net you kill -9 my parent process. http://electricjellyfish.net/ prepare to vi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 20:34:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A2D5F37B4CF for ; Thu, 16 Nov 2000 20:34:32 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAH4YTl27184; Thu, 16 Nov 2000 20:34:29 -0800 (PST) Date: Thu, 16 Nov 2000 20:34:28 -0800 From: Alfred Perlstein To: Garrett Rooney Cc: frank xu , arch@freebsd.org Subject: Re: potentially simpler approach than scheduler activations. Message-ID: <20001116203428.M18037@fw.wintelcom.net> References: <20001116184200.L18037@fw.wintelcom.net> <20001116232358.A25846@electricjellyfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001116232358.A25846@electricjellyfish.net>; from rooneg@electricjellyfish.net on Thu, Nov 16, 2000 at 11:23:58PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Garrett Rooney [001116 20:23] wrote: > On Thu, Nov 16, 2000 at 06:42:01PM -0800, Alfred Perlstein wrote: > > * frank xu [001116 18:25] wrote: > > > I have readed an article about KSE from jasone, it's cool, can complete > > > resolve much headache, but you method has same problems as LinuxThread, > > > jasone already > > > talked about it, in new FreeBSD 5.0, why can't we have a new way to go? > > > > Actually KSE is closer to Linuxthreads than my suggestion from my > > point of view. Can you elaborate a bit? > > well, i don't know if you've come up with a way around this, but in the > KSE paper (avail. from http://www.freebsd.org/~jasone/kse) the problems > with using rfork() based threads for spreading threads across processors > runs into the following issues: > > 1) each thread is a separate process, and such has a unique pid. POSIX > requires each thread to appear to have the same pid, so substantial > modifications to the kernel data structures would be required. > > 2) thread priority semantics specified by POSIX cannot be implimented > because each thread is a a process. thread contention at the > application level is therefor not possible, all threads are scheduled as > processes. this lets multithreaded applications compete unfairly with > single threaded applications. > > 3) Thread switching becomes expensive, because it is a full context > switch, requiring dropping into the kernel, switching one proc out, and > the other in. the only way to fix this is to optimize process > switching, which gets hard past a certain point. > > 4) each thread has all the kernel resources associated with a process, > so applications with many threads require a lot of kernel resources. > > all of these problems are basically cribbed right out of the paper, all > the mistakes are mine, not his. Yes, there are all problems in Linuxthreads, but not KSE nor my idea. Honestly my idea has more than several flaws, including things like blocking during open() and close()* (*over NFS) when accessing files. It's just that things like mysql and most threaded applications might benifit over the near trivial implementation of aio_/SIGPNP/sysVpoll almost as much as KSE. I really don't want to get into a big discussion about this. I had no intention of discrediting KSE project, the idea was that someone with some kernel programming skill and a couple of free weekends could improve on the uthread system while Jason continued on his quest for KSE. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 21:13: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id CD73B37B479 for ; Thu, 16 Nov 2000 21:12:58 -0800 (PST) Received: (qmail 4717 invoked by uid 3130); 17 Nov 2000 05:12:57 -0000 Message-ID: <20001117001257.B25846@electricjellyfish.net> Date: Fri, 17 Nov 2000 00:12:57 -0500 From: Garrett Rooney To: Alfred Perlstein Cc: frank xu , arch@freebsd.org Subject: Re: potentially simpler approach than scheduler activations. References: <20001116184200.L18037@fw.wintelcom.net> <20001116232358.A25846@electricjellyfish.net> <20001116203428.M18037@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <20001116203428.M18037@fw.wintelcom.net>; from Alfred Perlstein on Thu, Nov 16, 2000 at 08:34:28PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 16, 2000 at 08:34:28PM -0800, Alfred Perlstein wrote: > Yes, there are all problems in Linuxthreads, but not KSE nor my > idea. i see how the aio/kqueue ideas can get around some of this, but if you're using rfork() based threads to span multiple processors, don't you still run into all the problems that come with using a process as a thread? or at least the overhead problems with switching processes and the overhead within the kernel data structures? it just seems like KSE's solve these problems in a more palatable way. -- garrett rooney my pid is inigo montoya. rooneg@electricjellyfish.net you kill -9 my parent process. http://electricjellyfish.net/ prepare to vi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 22:55:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 61D9537B4C5 for ; Thu, 16 Nov 2000 22:55:17 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAH6tCJ05746 for ; Fri, 17 Nov 2000 08:55:12 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011170655.eAH6tCJ05746@gratis.grondar.za> To: arch@freebsd.org Subject: new monotime() call for all architectures. Date: Fri, 17 Nov 2000 08:55:04 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all I need a fast-as-possible "time" inside the kernel to help speed up the /dev/random device. I say "time", because although it needs to be a function of time (preferably accurate and linear), it has no need whatsoever to be "real time", so a simple counter is quite OK. Pentiums, Alphas and IA64's all have a suitable register on chip, while I have to make do with nanotime(9) on i386 and i486. I have prepared a monotime(9) call for the i386, alpha and ia64 architectures (patch enclosed). I have been running this for a week or two now with promising results (on a Pentium). With the exception of the minimum of "glue" (and nanotime on older architectures), these functions reduce to one instruction. Comments? Suggestions? Nobel Prize nominations? I'd like to commit this soonish if possible. M Index: alpha/include/clock.h =================================================================== RCS file: /home/ncvs/src/sys/alpha/include/clock.h,v retrieving revision 1.6 diff -u -d -r1.6 clock.h --- alpha/include/clock.h 2000/10/15 09:51:44 1.6 +++ alpha/include/clock.h 2000/11/08 06:02:24 @@ -19,6 +19,18 @@ int acquire_timer2 __P((int mode)); int release_timer2 __P((void)); +/* + * Standardised monotonic counter interface + */ +static __inline u_int64_t +monotime(void) +{ + u_int64_t retval; + + __asm__ __volatile__ ("rpcc %0" : "=r" (retval)); + return retval; +} + #endif #endif /* !_MACHINE_CLOCK_H_ */ Index: i386/include/clock.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/clock.h,v retrieving revision 1.39 diff -u -d -r1.39 clock.h --- i386/include/clock.h 2000/10/15 09:51:48 1.39 +++ i386/include/clock.h 2000/11/08 06:47:24 @@ -45,6 +45,23 @@ int sysbeep __P((int pitch, int period)); void i8254_restore __P((void)); +/* + * Standardised monotonic counter interface + */ +static __inline u_int64_t +monotime(void) +{ + u_int64_t retval; + +#if defined(I386_CPU) || defined(I486_CPU) + if (!tsc_present) + retval = nanotime(); + else +#endif + __asm __volatile("rdtsc" : "=A" (retval)); + return retval; +} + #endif /* _KERNEL */ #endif /* !_MACHINE_CLOCK_H_ */ Index: ia64/include/clock.h =================================================================== RCS file: /home/ncvs/src/sys/ia64/include/clock.h,v retrieving revision 1.2 diff -u -d -r1.2 clock.h --- ia64/include/clock.h 2000/10/15 09:51:48 1.2 +++ ia64/include/clock.h 2000/11/08 06:02:47 @@ -19,6 +19,18 @@ int acquire_timer2 __P((int mode)); int release_timer2 __P((void)); +/* + * Standardised monotonic counter interface + */ +static __inline u_int64_t +monotime(void) +{ + u_int64_t retval; + + __asm __volatile("mov %0=ar.itc" : "=r" (retval)); + return retval; +} + #endif #endif /* !_MACHINE_CLOCK_H_ */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 16 23:33:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (hades.cybercity.dk [212.242.42.118]) by hub.freebsd.org (Postfix) with ESMTP id 2C15637B479 for ; Thu, 16 Nov 2000 23:33:10 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAGHOe722616; Thu, 16 Nov 2000 18:24:40 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. In-Reply-To: Your message of "Fri, 17 Nov 2000 08:55:04 +0200." <200011170655.eAH6tCJ05746@gratis.grondar.za> Date: Thu, 16 Nov 2000 18:24:40 +0100 Message-ID: <22614.974395480@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011170655.eAH6tCJ05746@gratis.grondar.za>, Mark Murray writes: >Hi all > >I need a fast-as-possible "time" inside the kernel to help >speed up the /dev/random device. I say "time", because although >it needs to be a function of time (preferably accurate and linear), >it has no need whatsoever to be "real time", so a simple counter >is quite OK. Please don't call it *time() when it isn't returning that. monoticks(), monojiffies(), monocycles(), monomumble(), anything but monotime(). -- 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 Nov 17 0: 6: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4]) by hub.freebsd.org (Postfix) with ESMTP id 9872637B479 for ; Fri, 17 Nov 2000 00:05:58 -0800 (PST) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id RAA47240; Fri, 17 Nov 2000 17:05:41 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id RAA29883; Fri, 17 Nov 2000 17:05:41 +0900 (JST) To: mark@grondar.za Cc: arch@freebsd.org Subject: Re: new monotime() call for all architectures. In-Reply-To: <200011170655.eAH6tCJ05746@gratis.grondar.za> References: <200011170655.eAH6tCJ05746@gratis.grondar.za> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001117170541F.kjc@csl.sony.co.jp> Date: Fri, 17 Nov 2000 17:05:41 +0900 From: Kenjiro Cho X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > I need a fast-as-possible "time" inside the kernel to help > speed up the /dev/random device. I say "time", because although > it needs to be a function of time (preferably accurate and linear), > it has no need whatsoever to be "real time", so a simple counter > is quite OK. > > Pentiums, Alphas and IA64's all have a suitable register on chip, > while I have to make do with nanotime(9) on i386 and i486. > > I have prepared a monotime(9) call for the i386, alpha and ia64 > architectures (patch enclosed). I have been running this for a > week or two now with promising results (on a Pentium). With > the exception of the minimum of "glue" (and nanotime on older > architectures), these functions reduce to one instruction. > > Comments? Suggestions? Nobel Prize nominations? I'd like to > commit this soonish if possible. The PCC (Processor Cycle Counter) register on alpha is 64 bits but only the lower 32 bits is a counter. -Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 2:56:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id BF1C637B479 for ; Fri, 17 Nov 2000 02:55:50 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id eAHArq488675; Fri, 17 Nov 2000 12:53:52 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200011171053.eAHArq488675@zibbi.icomtek.csir.co.za> Subject: Re: new monotime() call for all architectures. In-Reply-To: <200011170655.eAH6tCJ05746@gratis.grondar.za> from Mark Murray at "Nov 17, 2000 08:55:04 am" To: mark@grondar.za (Mark Murray) Date: Fri, 17 Nov 2000 12:53:52 +0200 (SAT) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I need a fast-as-possible "time" inside the kernel to help > speed up the /dev/random device. I say "time", because although > it needs to be a function of time (preferably accurate and linear), > it has no need whatsoever to be "real time", so a simple counter > is quite OK. > > Pentiums, Alphas and IA64's all have a suitable register on chip, > while I have to make do with nanotime(9) on i386 and i486. > > I have prepared a monotime(9) call for the i386, alpha and ia64 > architectures (patch enclosed). I have been running this for a > week or two now with promising results (on a Pentium). With > the exception of the minimum of "glue" (and nanotime on older > architectures), these functions reduce to one instruction. > Are you sure it will work on SMP machines? There is nothing that synchronizes the onboard counters. Or will your code stay on one cpu? John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 4:48:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from warning.follo.net (warning.follo.net [195.204.136.30]) by hub.freebsd.org (Postfix) with ESMTP id B346D37B479; Fri, 17 Nov 2000 04:48:41 -0800 (PST) Received: (from eivind@localhost) by warning.follo.net (8.9.3/8.9.3) id NAA53657; Fri, 17 Nov 2000 13:48:34 +0100 (CET) Date: Fri, 17 Nov 2000 13:48:34 +0100 From: Eivind Eklund To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC Message-ID: <20001117134834.A53319@warning.follo.net> References: <20001115134312.C7752@warning.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from jhb@FreeBSD.ORG on Wed, Nov 15, 2000 at 10:01:19AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 15, 2000 at 10:01:19AM -0800, John Baldwin wrote: > On 15-Nov-00 Eivind Eklund wrote: > > I'm not sure I'm happy about DIAGNOSTIC; unless changed, it > > significantly change some codepaths, and it produce output about system > > state, not just extra checks. Any plain checks that are under DIAGNOSTIC is > > there through a miscommunication or not finished conversion, anyway; it > > should only be causing extra debug output. > > Ok. So converting any cases of DIAGNOSTIC that are extra checks to use > INVARIANTS instead would be a preferable solution? Yes. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 5:41:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C52C437B4C5 for ; Fri, 17 Nov 2000 05:41:34 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id IAA06390 for ; Fri, 17 Nov 2000 08:41:34 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id eAHDfXB41846; Fri, 17 Nov 2000 08:41:33 -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 Date: Fri, 17 Nov 2000 08:41:33 -0500 (EST) To: arch@freebsd.org Subject: Re: potentially simpler approach than scheduler activations. In-Reply-To: <20001116140506.Q830@fw.wintelcom.net> References: <20001116140506.Q830@fw.wintelcom.net> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14868.39578.928654.157924@grasshopper.cs.duke.edu> Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: <...> > > I know that by applying these band-aids we aren't completely > solving every problem and as new interfaces pop-up we might > have to apply more band-aids to libc_r, but I think this > might get us past the point of system that breaks down on > disk IO. <...> This sounds like a really good idea to me, as long as it is qualified as an interum solution until KSE is ready and not a competitor to it. Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 6:25:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 83C4837B479; Fri, 17 Nov 2000 06:25:54 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA09360; Fri, 17 Nov 2000 15:25:04 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Cy Schubert - ITSD Open Systems Group Cc: Adrian Chadd , arch@freebsd.org Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... References: <200011151907.eAFJ7Rb87207@cwsys.cwsent.com> From: Dag-Erling Smorgrav Date: 17 Nov 2000 15:25:03 +0100 In-Reply-To: Cy Schubert - ITSD Open Systems Group's message of "Wed, 15 Nov 2000 11:06:33 -0800" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group writes: > OK, 1 year plan. Forget about the N-year plans, I'd settle for a quick note saying "hi, we're the new core, we've taken office, you guys keep up the good work". The closest thing I've seen so far was the press release that Jordan forwarded to -announce. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 6:33:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id ADCBF37B479; Fri, 17 Nov 2000 06:33:11 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAGNpl724290; Fri, 17 Nov 2000 00:51:47 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Dag-Erling Smorgrav Cc: Cy Schubert - ITSD Open Systems Group , Adrian Chadd , arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... In-Reply-To: Your message of "17 Nov 2000 15:25:03 +0100." Date: Fri, 17 Nov 2000 00:51:47 +0100 Message-ID: <24288.974418707@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >Cy Schubert - ITSD Open Systems Group writes: >> OK, 1 year plan. > >Forget about the N-year plans, I'd settle for a quick note saying "hi, >we're the new core, we've taken office, you guys keep up the good >work". The closest thing I've seen so far was the press release that >Jordan forwarded to -announce. Yeah, I've had a number of people send me emails saying things like "clearly you didn't paralyze the core team, because the new one havn't even said ``hello'' yet" and I told this to various core members. I guess it's a bit silly to expect them to send a "Hello World" message now. I wonder if I should tick Matt Dillon of with some VM commit just to see if they're still alive ? :-) -- 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 Nov 17 9:12:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from bsdhome.dyndns.org (unknown [24.25.2.13]) by hub.freebsd.org (Postfix) with ESMTP id 4448337B479 for ; Fri, 17 Nov 2000 09:12:47 -0800 (PST) Received: from vger.bsdhome.com (vger [192.168.220.2]) by bsdhome.dyndns.org (8.11.1/8.11.1) with ESMTP id eAHHCjS05821 for ; Fri, 17 Nov 2000 12:12:45 -0500 (EST) (envelope-from bsd@bsdhome.com) Received: (from bsd@localhost) by vger.bsdhome.com (8.11.1/8.11.1) id eAHHCfC87302 for arch@FreeBSD.ORG; Fri, 17 Nov 2000 12:12:41 -0500 (EST) (envelope-from bsd) Date: Fri, 17 Nov 2000 12:12:41 -0500 From: Brian Dean To: arch@FreeBSD.ORG Subject: Re: updating rdist Message-ID: <20001117121241.A87182@vger.bsdhome.com> References: <20001111035905.A82574@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001111035905.A82574@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sat, Nov 11, 2000 at 03:59:05AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 11, 2000 at 03:59:05AM -0800, David O'Brien wrote: > I have just committed a `44bsd-rdist' port. > So the question is, do we totally remove `rdist' from the base system, > or update it to rdist 6.1.5? The consensus seems to be to get rid of this. Some folks (including me) may need this tool soon after install, but don't necessarily have immediate external net connectivity from which to get the port. To this end, why not leave this in base, but make a seperate collection for sysinstall (default to _not_ install) and put it there along with the other 'r' tools, and enable the building of these with a make.conf variable for source upgrades? If this is acceptable, I'm volunteering to do the patches. -Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 9:45:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id E50E237B479 for ; Fri, 17 Nov 2000 09:45:50 -0800 (PST) Received: from dragon.nuxi.com (root@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id JAA00604 for ; Fri, 17 Nov 2000 09:45:45 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id eAHHjiG24116 for arch@freebsd.org; Fri, 17 Nov 2000 09:45:44 -0800 (PST) (envelope-from obrien) Date: Fri, 17 Nov 2000 09:45:43 -0800 From: "David O'Brien" To: arch@freebsd.org Subject: Re: potentially simpler approach than scheduler activations. Message-ID: <20001117094543.A76006@dragon.nuxi.com> Reply-To: arch@freebsd.org References: <20001116140506.Q830@fw.wintelcom.net> <14868.39578.928654.157924@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14868.39578.928654.157924@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Nov 17, 2000 at 08:41:33AM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I know that by applying these band-aids we aren't completely > > solving every problem and as new interfaces pop-up we might > > have to apply more band-aids to libc_r, but I think this > > might get us past the point of system that breaks down on > > disk IO. > > This sounds like a really good idea to me, as long as it is qualified > as an interum solution until KSE is ready and not a competitor to it. Also KSE's will never be back ported to RELENG_4. Maybe some of these ideas can be. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 10:29:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id E275E37B479 for ; Fri, 17 Nov 2000 10:29:53 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHITWB96222; Fri, 17 Nov 2000 10:29:32 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001117121241.A87182@vger.bsdhome.com> Date: Fri, 17 Nov 2000 10:30:13 -0800 (PST) From: John Baldwin To: Brian Dean Subject: Re: updating rdist Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Nov-00 Brian Dean wrote: > > On Sat, Nov 11, 2000 at 03:59:05AM -0800, David O'Brien wrote: >> I have just committed a `44bsd-rdist' port. >> So the question is, do we totally remove `rdist' from the base system, >> or update it to rdist 6.1.5? > > The consensus seems to be to get rid of this. Some folks (including > me) may need this tool soon after install, but don't necessarily have > immediate external net connectivity from which to get the port. To > this end, why not leave this in base, but make a seperate collection > for sysinstall (default to _not_ install) and put it there along with > the other 'r' tools, and enable the building of these with a make.conf > variable for source upgrades? > > If this is acceptable, I'm volunteering to do the patches. Umm, if it becomes a port, you can just install the package during installation from sysinstall. So, what you have asked for is already done. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Fri Nov 17 10:30: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id A18D537B479 for ; Fri, 17 Nov 2000 10:30:02 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHITMB96213; Fri, 17 Nov 2000 10:29:24 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011171053.eAHArq488675@zibbi.icomtek.csir.co.za> Date: Fri, 17 Nov 2000 10:30:03 -0800 (PST) From: John Baldwin To: John Hay Subject: Re: new monotime() call for all architectures. Cc: arch@FreeBSD.org, (Mark Murray) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Nov-00 John Hay wrote: >> >> I need a fast-as-possible "time" inside the kernel to help >> speed up the /dev/random device. I say "time", because although >> it needs to be a function of time (preferably accurate and linear), >> it has no need whatsoever to be "real time", so a simple counter >> is quite OK. >> >> Pentiums, Alphas and IA64's all have a suitable register on chip, >> while I have to make do with nanotime(9) on i386 and i486. >> >> I have prepared a monotime(9) call for the i386, alpha and ia64 >> architectures (patch enclosed). I have been running this for a >> week or two now with promising results (on a Pentium). With >> the exception of the minimum of "glue" (and nanotime on older >> architectures), these functions reduce to one instruction. >> > > Are you sure it will work on SMP machines? There is nothing that > synchronizes the onboard counters. Or will your code stay on one > cpu? It doesn't matter. He just needs a psuedo-timestamp for entropy gathering purposes. It dosen't need to be entirely precise, so if different CPU's counters are not 100% in sync it won't hurt anything. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Fri Nov 17 10:30:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id A615137B479 for ; Fri, 17 Nov 2000 10:30:14 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHITVB96218; Fri, 17 Nov 2000 10:29:31 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011170655.eAH6tCJ05746@gratis.grondar.za> Date: Fri, 17 Nov 2000 10:30:13 -0800 (PST) From: John Baldwin To: Mark Murray Subject: RE: new monotime() call for all architectures. Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Nov-00 Mark Murray wrote: > Hi all > > I need a fast-as-possible "time" inside the kernel to help > speed up the /dev/random device. I say "time", because although > it needs to be a function of time (preferably accurate and linear), > it has no need whatsoever to be "real time", so a simple counter > is quite OK. > > Pentiums, Alphas and IA64's all have a suitable register on chip, > while I have to make do with nanotime(9) on i386 and i486. > > I have prepared a monotime(9) call for the i386, alpha and ia64 > architectures (patch enclosed). I have been running this for a > week or two now with promising results (on a Pentium). With > the exception of the minimum of "glue" (and nanotime on older > architectures), these functions reduce to one instruction. > > Comments? Suggestions? Nobel Prize nominations? I'd like to > commit this soonish if possible. Please use existing functions like rdtsc() instead of duplicating the inline assembly. This will help reduce maintenance down the road. In fact, you might want to move this to machine/cpufunc.h instead of machine/clock.h. Then use the rdtsc() function for x86, alpha_rpcc() for the alpha, and ia64_get_itc() for ia64. Note that for ia64, machine/cpufunc.h needs to be fixed to #include machine/ia64_cpu.h as it does on the alpha. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Fri Nov 17 10:36:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 56A3037B479 for ; Fri, 17 Nov 2000 10:36:31 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA15378; Fri, 17 Nov 2000 10:36:17 -0800 Date: Fri, 17 Nov 2000 10:36:15 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mark Murray Cc: arch@FreeBSD.ORG Subject: RE: new monotime() call for all architectures. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In case there's ever a sparc port, all of the worthwhile sparc machines have register onchip too. I like what you're doing with this- it would allow me to get rid of the nanotime calls I use to time some loops for the Qlogic driver. > > On 17-Nov-00 Mark Murray wrote: > > Hi all > > > > I need a fast-as-possible "time" inside the kernel to help > > speed up the /dev/random device. I say "time", because although > > it needs to be a function of time (preferably accurate and linear), > > it has no need whatsoever to be "real time", so a simple counter > > is quite OK. > > > > Pentiums, Alphas and IA64's all have a suitable register on chip, > > while I have to make do with nanotime(9) on i386 and i486. > > > > I have prepared a monotime(9) call for the i386, alpha and ia64 > > architectures (patch enclosed). I have been running this for a > > week or two now with promising results (on a Pentium). With > > the exception of the minimum of "glue" (and nanotime on older > > architectures), these functions reduce to one instruction. > > > > Comments? Suggestions? Nobel Prize nominations? I'd like to > > commit this soonish if possible. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 11: 9:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 71E5737B479; Fri, 17 Nov 2000 11:09:44 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id eAHJ9et99988; Fri, 17 Nov 2000 21:09:40 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200011171909.eAHJ9et99988@zibbi.icomtek.csir.co.za> Subject: Re: new monotime() call for all architectures. In-Reply-To: from John Baldwin at "Nov 17, 2000 10:30:03 am" To: jhb@FreeBSD.ORG (John Baldwin) Date: Fri, 17 Nov 2000 21:09:40 +0200 (SAT) Cc: arch@FreeBSD.ORG, mark@grondar.za X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> I need a fast-as-possible "time" inside the kernel to help > >> speed up the /dev/random device. I say "time", because although > >> it needs to be a function of time (preferably accurate and linear), > >> it has no need whatsoever to be "real time", so a simple counter > >> is quite OK. > >> > >> Pentiums, Alphas and IA64's all have a suitable register on chip, > >> while I have to make do with nanotime(9) on i386 and i486. > >> > >> I have prepared a monotime(9) call for the i386, alpha and ia64 > >> architectures (patch enclosed). I have been running this for a > >> week or two now with promising results (on a Pentium). With > >> the exception of the minimum of "glue" (and nanotime on older > >> architectures), these functions reduce to one instruction. > >> > > > > Are you sure it will work on SMP machines? There is nothing that > > synchronizes the onboard counters. Or will your code stay on one > > cpu? > > It doesn't matter. He just needs a psuedo-timestamp for entropy gathering > purposes. It dosen't need to be entirely precise, so if different CPU's > counters are not 100% in sync it won't hurt anything. Ok, I just thought the "mono" in his function name is for monotonic. If you are staying on one processor it will work, but if the timestamps have scheduling inbetween the timestamps and you land on a different processor it won't be monotonic anymore. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 11:24: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 16B7037B4C5 for ; Fri, 17 Nov 2000 11:24:03 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHJNIB98795; Fri, 17 Nov 2000 11:23:18 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011171909.eAHJ9et99988@zibbi.icomtek.csir.co.za> Date: Fri, 17 Nov 2000 11:24:00 -0800 (PST) From: John Baldwin To: John Hay Subject: Re: new monotime() call for all architectures. Cc: mark@grondar.za, arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Nov-00 John Hay wrote: >> >> I need a fast-as-possible "time" inside the kernel to help >> >> speed up the /dev/random device. I say "time", because although >> >> it needs to be a function of time (preferably accurate and linear), >> >> it has no need whatsoever to be "real time", so a simple counter >> >> is quite OK. >> >> >> >> Pentiums, Alphas and IA64's all have a suitable register on chip, >> >> while I have to make do with nanotime(9) on i386 and i486. >> >> >> >> I have prepared a monotime(9) call for the i386, alpha and ia64 >> >> architectures (patch enclosed). I have been running this for a >> >> week or two now with promising results (on a Pentium). With >> >> the exception of the minimum of "glue" (and nanotime on older >> >> architectures), these functions reduce to one instruction. >> >> >> > >> > Are you sure it will work on SMP machines? There is nothing that >> > synchronizes the onboard counters. Or will your code stay on one >> > cpu? >> >> It doesn't matter. He just needs a psuedo-timestamp for entropy gathering >> purposes. It dosen't need to be entirely precise, so if different CPU's >> counters are not 100% in sync it won't hurt anything. > > Ok, I just thought the "mono" in his function name is for monotonic. If > you are staying on one processor it will work, but if the timestamps > have scheduling inbetween the timestamps and you land on a different > processor it won't be monotonic anymore. It's close enough. :) > John -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Fri Nov 17 11:28:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 084EF37B479; Fri, 17 Nov 2000 11:28:30 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id MAA28028; Fri, 17 Nov 2000 12:26:29 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAA3JaWH2; Fri Nov 17 12:26:12 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA28994; Fri, 17 Nov 2000 12:28:07 -0700 (MST) From: Terry Lambert Message-Id: <200011171928.MAA28994@usr08.primenet.com> Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... To: wes@softweyr.com (Wes Peters) Date: Fri, 17 Nov 2000 19:28:06 +0000 (GMT) Cc: adrian@FreeBSD.ORG (Adrian Chadd), arch@FreeBSD.ORG In-Reply-To: <3A1486ED.2568B51@softweyr.com> from "Wes Peters" at Nov 16, 2000 06:16:29 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > OK, so it was a candle rather than a flamethrower. It should be made > simple to compile in a much less random randomdev for applications that > do not need high-quality entropy, like the IP stack on your dishwasher. Aren't you afraid of Eastern European crackers breaking into your washing machine via its IP connectivity, and stealing your "wears"? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 11:31:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 0BD1637B479; Fri, 17 Nov 2000 11:31:11 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAHJr9726016; Fri, 17 Nov 2000 20:53:09 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: John Hay , mark@grondar.za, arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. In-Reply-To: Your message of "Fri, 17 Nov 2000 11:24:00 PST." Date: Fri, 17 Nov 2000 20:53:09 +0100 Message-ID: <26014.974490789@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Ok, I just thought the "mono" in his function name is for monotonic. If >> you are staying on one processor it will work, but if the timestamps >> have scheduling inbetween the timestamps and you land on a different >> processor it won't be monotonic anymore. > >It's close enough. :) If it isn't dealing properly with async PCC/TSC counters on SMP machines it shouldn't be called "monoanyting". I guess I totally object to the name now :-) -- 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 Nov 17 11:53:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 98DBA37B479; Fri, 17 Nov 2000 11:53:24 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHJr9B99792; Fri, 17 Nov 2000 11:53:09 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011171928.MAA28994@usr08.primenet.com> Date: Fri, 17 Nov 2000 11:53:51 -0800 (PST) From: John Baldwin To: Terry Lambert Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... Cc: arch@FreeBSD.org, (Adrian Chadd) , (Wes Peters) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Nov-00 Terry Lambert wrote: >> OK, so it was a candle rather than a flamethrower. It should be made >> simple to compile in a much less random randomdev for applications that >> do not need high-quality entropy, like the IP stack on your dishwasher. > > Aren't you afraid of Eastern European crackers breaking into > your washing machine via its IP connectivity, and stealing > your "wears"? *groan* :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Fri Nov 17 11:55:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 8EA7437B479 for ; Fri, 17 Nov 2000 11:55:24 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHJr9B99788; Fri, 17 Nov 2000 11:53:09 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <26014.974490789@critter> Date: Fri, 17 Nov 2000 11:53:50 -0800 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: Re: new monotime() call for all architectures. Cc: arch@FreeBSD.org, mark@grondar.za, John Hay Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Nov-00 Poul-Henning Kamp wrote: > >>> Ok, I just thought the "mono" in his function name is for monotonic. If >>> you are staying on one processor it will work, but if the timestamps >>> have scheduling inbetween the timestamps and you land on a different >>> processor it won't be monotonic anymore. >> >>It's close enough. :) > > If it isn't dealing properly with async PCC/TSC counters on SMP machines > it shouldn't be called "monoanyting". > > I guess I totally object to the name now :-) It will be increasing at least. :) (except for occasional cases when you get events close together on 2 CPU's that are within the drift between teh CPU's and in the right order to result in the later event coming "earlier"). -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Fri Nov 17 11:58:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 22DEF37B4C5; Fri, 17 Nov 2000 11:58:11 -0800 (PST) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id NAA28899; Fri, 17 Nov 2000 13:55:24 -0600 (CST) Date: Fri, 17 Nov 2000 13:55:24 -0600 From: "Matthew D. Fuller" To: Poul-Henning Kamp Cc: John Baldwin , John Hay , mark@grondar.za, arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. Message-ID: <20001117135523.B20231@futuresouth.com> References: <26014.974490789@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <26014.974490789@critter>; from phk@critter.freebsd.dk on Fri, Nov 17, 2000 at 08:53:09PM +0100 X-OS: FreeBSD Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Nov 17, 2000 at 08:53:09PM +0100, a little birdie told me that Poul-Henning Kamp remarked > > >> Ok, I just thought the "mono" in his function name is for monotonic. If > >> you are staying on one processor it will work, but if the timestamps > >> have scheduling inbetween the timestamps and you land on a different > >> processor it won't be monotonic anymore. > > > >It's close enough. :) > > If it isn't dealing properly with async PCC/TSC counters on SMP machines > it shouldn't be called "monoanyting". > > I guess I totally object to the name now :-) OK, how about bogotime(9)? ;) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 11:59:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 8691137B479; Fri, 17 Nov 2000 11:59:16 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAHKLd726146; Fri, 17 Nov 2000 21:21:39 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: arch@FreeBSD.org, mark@grondar.za, John Hay Subject: Re: new monotime() call for all architectures. In-Reply-To: Your message of "Fri, 17 Nov 2000 11:53:50 PST." Date: Fri, 17 Nov 2000 21:21:39 +0100 Message-ID: <26144.974492499@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , John Baldwin writes: > >On 17-Nov-00 Poul-Henning Kamp wrote: >> >>>> Ok, I just thought the "mono" in his function name is for monotonic. If >>>> you are staying on one processor it will work, but if the timestamps >>>> have scheduling inbetween the timestamps and you land on a different >>>> processor it won't be monotonic anymore. >>> >>>It's close enough. :) >> >> If it isn't dealing properly with async PCC/TSC counters on SMP machines >> it shouldn't be called "monoanyting". >> >> I guess I totally object to the name now :-) > >It will be increasing at least. :) (except for occasional cases when you get >events close together on 2 CPU's that are within the drift between teh CPU's >and in the right order to result in the later event coming "earlier"). It will flicker forth and back, because there may be a finite, but potentially large and pretty constant offset between the counters. Unless this function returns a monotonic increasing (modules the inevietable wraparound) integer of some width, it should not be called "mono*". Unless it returns true units of time it should not be called "*time". -- 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 Nov 17 11:59:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id BA93037B4CF; Fri, 17 Nov 2000 11:59:25 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eAHJtCI58756; Fri, 17 Nov 2000 11:55:12 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Poul-Henning Kamp Cc: Dag-Erling Smorgrav , Cy Schubert - ITSD Open Systems Group , Adrian Chadd , arch@FreeBSD.ORG Subject: "Hi, we're the new core team" In-Reply-To: Message from Poul-Henning Kamp of "Fri, 17 Nov 2000 00:51:47 +0100." <24288.974418707@critter> Date: Fri, 17 Nov 2000 11:55:12 -0800 Message-ID: <58752.974490912@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please let me reassure everybody that we're still alive and discussing quite a few issues regarding FreeBSD's security policies, the proper meaning of the MAINTAINER bit, what to do about various 3rd party resource sites, etc. In all of that, the act of simply saying "HI!" has kind of slipped through the cracks through Mike Smith has sent a few prods exploring whether or not that would be a meaningful gesture or simply a gesture. In any case, rest assured that core is alive and well and trying to do good things. If our saying "Hi!" will seriously reassure people of all that then I guess we'll say it. In the meantime, you can take my hello as the first sign of life. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 12: 0: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id E918A37B479; Fri, 17 Nov 2000 11:59:57 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id eAHKMK726174; Fri, 17 Nov 2000 21:22:20 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Matthew D. Fuller" Cc: John Baldwin , John Hay , mark@grondar.za, arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. In-Reply-To: Your message of "Fri, 17 Nov 2000 13:55:24 CST." <20001117135523.B20231@futuresouth.com> Date: Fri, 17 Nov 2000 21:22:20 +0100 Message-ID: <26172.974492540@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001117135523.B20231@futuresouth.com>, "Matthew D. Fuller" writes: >On Fri, Nov 17, 2000 at 08:53:09PM +0100, a little birdie told me >that Poul-Henning Kamp remarked >> >> >> Ok, I just thought the "mono" in his function name is for monotonic. If >> >> you are staying on one processor it will work, but if the timestamps >> >> have scheduling inbetween the timestamps and you land on a different >> >> processor it won't be monotonic anymore. >> > >> >It's close enough. :) >> >> If it isn't dealing properly with async PCC/TSC counters on SMP machines >> it shouldn't be called "monoanyting". >> >> I guess I totally object to the name now :-) > >OK, how about bogotime(9)? ;) It's not returning units of any known time. "bogocount()" maybe... -- 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 Nov 17 12: 8:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 420DC37B479 for ; Fri, 17 Nov 2000 12:08:35 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA14979; Fri, 17 Nov 2000 13:08:18 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id NAA21404; Fri, 17 Nov 2000 13:08:17 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14869.36912.901949.718314@nomad.yogotech.com> Date: Fri, 17 Nov 2000 13:08:16 -0700 (MST) To: Poul-Henning Kamp Cc: mark@grondar.za, arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. In-Reply-To: <26172.974492540@critter> References: <20001117135523.B20231@futuresouth.com> <26172.974492540@critter> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> >> Ok, I just thought the "mono" in his function name is for monotonic. If > >> >> you are staying on one processor it will work, but if the timestamps > >> >> have scheduling inbetween the timestamps and you land on a different > >> >> processor it won't be monotonic anymore. > >> > > >> >It's close enough. :) > >> > >> If it isn't dealing properly with async PCC/TSC counters on SMP machines > >> it shouldn't be called "monoanyting". > >> > >> I guess I totally object to the name now :-) > > > >OK, how about bogotime(9)? ;) > > It's not returning units of any known time. "bogocount()" maybe... How about 'slushycounter()'? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 12:13:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 4A9D937B479 for ; Fri, 17 Nov 2000 12:13:57 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eAHKAbq27879; Fri, 17 Nov 2000 14:10:37 -0600 (CST) (envelope-from jlemon) Date: Fri, 17 Nov 2000 14:10:37 -0600 From: Jonathan Lemon To: Nate Williams Cc: Poul-Henning Kamp , mark@grondar.za, arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. Message-ID: <20001117141037.E19895@prism.flugsvamp.com> References: <20001117135523.B20231@futuresouth.com> <26172.974492540@critter> <14869.36912.901949.718314@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <14869.36912.901949.718314@nomad.yogotech.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Nov 17, 2000 at 01:08:16PM -0700, Nate Williams wrote: > > >> >> Ok, I just thought the "mono" in his function name is for monotonic. If > > >> >> you are staying on one processor it will work, but if the timestamps > > >> >> have scheduling inbetween the timestamps and you land on a different > > >> >> processor it won't be monotonic anymore. > > >> > > > >> >It's close enough. :) > > >> > > >> If it isn't dealing properly with async PCC/TSC counters on SMP machines > > >> it shouldn't be called "monoanyting". > > >> > > >> I guess I totally object to the name now :-) > > > > > >OK, how about bogotime(9)? ;) > > > > It's not returning units of any known time. "bogocount()" maybe... > > How about 'slushycounter()'? falseticker()? (Okay, probably too NTP specfic) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 12:18: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 180BF37B479 for ; Fri, 17 Nov 2000 12:18:06 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHKHjB00773; Fri, 17 Nov 2000 12:17:45 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001117141037.E19895@prism.flugsvamp.com> Date: Fri, 17 Nov 2000 12:18:27 -0800 (PST) From: John Baldwin To: Jonathan Lemon Subject: Re: new monotime() call for all architectures. Cc: arch@FreeBSD.org, mark@grondar.za, Poul-Henning Kamp , Nate Williams Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Nov-00 Jonathan Lemon wrote: > On Fri, Nov 17, 2000 at 01:08:16PM -0700, Nate Williams wrote: >> > >> >> Ok, I just thought the "mono" in his function name is for monotonic. >> > >> >> If >> > >> >> you are staying on one processor it will work, but if the timestamps >> > >> >> have scheduling inbetween the timestamps and you land on a different >> > >> >> processor it won't be monotonic anymore. >> > >> > >> > >> >It's close enough. :) >> > >> >> > >> If it isn't dealing properly with async PCC/TSC counters on SMP >> > >> machines >> > >> it shouldn't be called "monoanyting". >> > >> >> > >> I guess I totally object to the name now :-) >> > > >> > >OK, how about bogotime(9)? ;) >> > >> > It's not returning units of any known time. "bogocount()" maybe... >> >> How about 'slushycounter()'? > > falseticker()? (Okay, probably too NTP specfic) Let's just go back to CS 101 days and call it my_function(). -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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 Fri Nov 17 13:28:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 8C45337B479; Fri, 17 Nov 2000 13:28:10 -0800 (PST) Received: from harare-60.budapest.interware.hu ([195.70.50.60] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 13wt3B-0006E9-00; Fri, 17 Nov 2000 22:28:01 +0100 Message-ID: <3A15A2C1.1F3FB6CD@elischer.org> Date: Fri, 17 Nov 2000 13:27:29 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: jasone@freebsd.org, arch@freebsd.org Subject: Threads (KSE etc) comments Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi jason. I read your Nov 7 doc on the threading model. I have a few comments.. I've been thinking about the scheduling queues, and how to make sure that the process (KSEG actually) acts fairly with respect to other processes. I was confised for a while by your description. I think part of my confusion came from something that we specified in the meeting but has not been written in your document directly. let me see if we are agreed on what we decided.. A KSEG can only have as a maximum N KSEs associated with it, where N is the number of processors, (unless artificially reduced by a lower concurency declaration). (you said this but only indirectly). In general, KSEs are each assigned to a processor. They do not in general move between processors unless some explicit adjustment is being made(*), and as a general rule, two KSEs will not be assigned to the same processor. (in some transitional moments this may be allowed to briefly happen) This in general if you run a KSEC on the same KSE it was run on last time, you should be on the same processor, (and get any affinity advantages that might exist). (*)I am inclined to make the requirement of binding KSEs to processors HARD, as this allows us to simplify some later decisions. For example, if we hard bind KSEs to procesors then since we assign a different communications mailbox for each KSE we create, we can be sure that different KSEs will never preempt each other when writing out to their mailboxes. this also means that since there can only be one UTS incarnation active per KSE (or one KSE per UTS incarnation), that we can not have a UTS preempted by another incarnation on the same processor. We can therefore make sure that there needs to be no locking on mailboxes, or even any checking. I think this is what we decided.. is this correct? The binding is not really mentioned in your document. When we were talking about it, (at least in my memory) Each KSE had a mailbox. My memory of this was that we called a KSE creation call with a different argument, thus each KSE had a different return stack frame when it made upcalls. In the version you have outlined, there is no KSE creation call only KSEG creation calls. Thus all upcalls have the same frame, and there is the danger of colliding upcalls for different processors. My memory (where is that photo of the whiteboard that Nicole was supposed to send us) is that each KSE is assigned a differnt mailbox address in userland, which is associated with the frame that it will do upcalls on. One of the fields of the mailbox contains a pointer to a userland context structure which contains apece where the KSE should dump the user context should it need to, and a pointer to other such structures. This structure is defined by the kernel, but included in the UTS's 'per thread info'. Since there is one per thread, there is never a problem in running out of them when the kernel links them together in a linked list of completed operations. When the thread makes a system call, the KSE looks in the mailbox for the context structure for this thread, and if the thread blocks or resumes, it can save any information it needs to tell teh UTS there. The UTS sets the pointer into the mailbox when it schedules the thread, so even involintary blockages (e.g. page faults) have the pointer available. When the UTS is running it's own work, it ZERO's this pointer, which lets the kernel know that it is not really in a safe state for pre-emmpting. I think that we decided that a page fault in the UTS simply blocked until it was satisfied. When an upcall occurs, the stack frame it occurs on, and hence the mailbox pointed to are automatically correct, so the UTS doesn't even have to look it up. (the mailbox is allocated as a local variable in the frame of the KSE creation call and is this in the local frame of the upcall. this is something like I imagined the UTS would do to fire off a new KSE. The reason I was thinking of it this way was so that each KSE has a UTS supplied mailbox and (smallish) stack. /* * use make_new_kse() to do exactly that. * Returns -1 on failure and 1 on success. * * cookie allows the UTS to have it's own way of identifying the KSE/thread. * This stack is effectively lost to us so we first switch * to a small throw-away stack. It need only have enough space in it for the * upcalls to call the UTS, and whatever the UTS will need. * Some time after creation, there will be an upcall on the new KSE looking for work. * I could imagine wiring this UTS stack down.. */ void start_new_kse(void * cookie, jmp_buf *jb) /*XXX correct definition for jb? */ { struct kse_mailbox; int return_value; bzero(kse_mailbox, sizeof(kse_mailbox)); return_value = kse_new(&kse_mailbox); switch (return_value) { case -1:  perror("make_new_kse() failed"); _longjmp(jb, -1); case 0: printf ("successfully created kse %d\n", kse_mailbox.kse_id); _longjmp(jb, 1); exit (1); /* not reached */ default: printf(" An upcall of type %d occured\n", return_value); uts_scheduler(cookie, &kse_mailbox, return_value); /* must never return */ printf ("it returned!\n"); exit (1); } } make_new_kse(void * cookie) { int retval; jmp_buf env; if ((retval = _setjmp(env)) == 0) { load_new_stack() /* load a new smaller stack, but copy the top 100 bytes or so from the old stack so that our local variables appear to be the same. */ start_new_kse(cookie, env); /* not reached */ } return (retval) } When we have per-processor scheduling queues, there is only at most ONE KSE from any given KSEG in the scheduling queues for any given processor. With the single scheduling queue we have now do we allow N to be in the queues at once? (or do we put the KSEG in instead?) The terms KSE etc. have probably served their useful life. It's time to think of or find names that really describe them better KSE -- a per process processor.. Scheduler slot? openning? (a-la CAM/SCSI) KSEC ---- stack plus context... KSC.. it's trying to do somethign (a task?) KSEG ---- a class of schedulable entities.. A slot cluster? :-) PROC ---- probably needs to stay the same. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 13:55:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.welearn.com.au (unknown [139.130.44.81]) by hub.freebsd.org (Postfix) with ESMTP id 82E5B37B479 for ; Fri, 17 Nov 2000 13:55:06 -0800 (PST) Received: (from sue@localhost) by phoenix.welearn.com.au (8.9.3/8.9.3) id IAA86022; Sat, 18 Nov 2000 08:58:42 +1100 (EST) (envelope-from sue) Date: Sat, 18 Nov 2000 08:58:38 +1100 From: Sue Blake To: Cy Schubert - ITSD Open Systems Group Cc: Will Andrews , arch@FreeBSD.ORG Subject: Re: updating rdist Message-ID: <20001118085836.U327@welearn.com.au> References: <20001112140045.K555@puck.firepipe.net> <200011131517.eADFHTM01095@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <200011131517.eADFHTM01095@cwsys.cwsent.com>; from Cy Schubert - ITSD Open Systems Group on Mon, Nov 13, 2000 at 07:16:49AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 13, 2000 at 07:16:49AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > In message <20001112140045.K555@puck.firepipe.net>, Will Andrews writes: > > On Sat, Nov 11, 2000 at 03:59:05AM -0800, David O'Brien wrote: > > > I have just committed a `44bsd-rdist' port. > > > So the question is, do we totally remove `rdist' from the base system, > > > or update it to rdist 6.1.5? > > > > I personally think it's better to remove it and update in ports. Cy > > Schubert makes a good point (if it is valid; I didn't check and don't > > know myself) that 44bsd-rdist and rdist6 are interoperable on mutally > > exclusive systems. Hence, it makes sense that a system administrator > > should need to look in ports for what they need. > > The description file from the rdist6 ports states: > > This version of rdist is not directly compatible with rdist > distributed with 4.3BSD and subsequent vendor releases, but does > indirectly provide full backward compatibility. > > >From the rdist6(1) man page: > > The -Server option is recognized to provide partial back- > ward compatible support for older versions of rdist which > used this option to put rdist into server mode. If rdist > is started with the -Server command line option, it will > attempt to exec (run) the old version of rdist. This > option will only work if rdist was compiled with the loca- > tion of the old rdist (usually either /usr/ucb/oldrdist or > /usr/old/rdist) and that program is available at run time. > > To support both the classic rdist and rdist6 protocols, both need to be > installed. [catching up... adding my 2c to the knowledge pool] This information is often requoted, and believed. Please don't. The use of the word "partial" above is optimistic. I haven't heard of anybody ever actually getting it to work that way, but I've heard of people trying and giving up in frustration. I'll give a jelly-bean to anyone who can find the mythical "oldrdist" file for the box at the Linux end. It's quite extinct. If our own old rdist executable will service the kludge described above, and if the FreeBSD system is the one that is sitting at the end of the rdist where that is what's required, then I guess the old file would need to be installed and renamed. I don't know if we've automated or documented that yet, or tested it. As others have said, we do need to be faced with making an informed decision at or after install, based on the OSs to be involved. We also need to avoid regurgitating misleading and untested information if that applies to the quote above as I suspect it still does. -- Regards, -*Sue*- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 14:42:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 8F29A37B479; Fri, 17 Nov 2000 14:42:43 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAHMdtJ07828; Sat, 18 Nov 2000 00:40:01 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011172240.eAHMdtJ07828@gratis.grondar.za> To: John Hay Cc: jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. References: <200011171909.eAHJ9et99988@zibbi.icomtek.csir.co.za> In-Reply-To: <200011171909.eAHJ9et99988@zibbi.icomtek.csir.co.za> ; from John Hay "Sat, 17 Nov 2000 21:09:40 +0200." Date: Sat, 18 Nov 2000 00:39:57 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It doesn't matter. He just needs a psuedo-timestamp for entropy gathering > > purposes. It dosen't need to be entirely precise, so if different CPU's > > counters are not 100% in sync it won't hurt anything. > > Ok, I just thought the "mono" in his function name is for monotonic. If > you are staying on one processor it will work, but if the timestamps > have scheduling inbetween the timestamps and you land on a different > processor it won't be monotonic anymore. Actually, it does mean "monotonic", but I don't need strictly monotonic. The "time" info is used to improve the quality of the harvested entropy, but it is not specifically counted, so the errors introduced by different CPU's counters are "free" ontropy. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 14:46:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 44C7937B479; Fri, 17 Nov 2000 14:46:07 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAHMfNJ07835; Sat, 18 Nov 2000 00:41:23 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011172241.eAHMfNJ07835@gratis.grondar.za> To: Poul-Henning Kamp Cc: John Baldwin , John Hay , arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. References: <26014.974490789@critter> In-Reply-To: <26014.974490789@critter> ; from Poul-Henning Kamp "Fri, 17 Nov 2000 20:53:09 +0100." Date: Sat, 18 Nov 2000 00:41:25 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If it isn't dealing properly with async PCC/TSC counters on SMP machines > it shouldn't be called "monoanyting". > > I guess I totally object to the name now :-) I need the access. What name will please you? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 14:54:33 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 124F037B479 for ; Fri, 17 Nov 2000 14:54:28 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAHMnjJ07866; Sat, 18 Nov 2000 00:49:45 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011172249.eAHMnjJ07866@gratis.grondar.za> To: Jonathan Lemon Cc: Nate Williams , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. References: <20001117141037.E19895@prism.flugsvamp.com> In-Reply-To: <20001117141037.E19895@prism.flugsvamp.com> ; from Jonathan Lemon "Fri, 17 Nov 2000 14:10:37 CST." Date: Sat, 18 Nov 2000 00:49:46 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >OK, how about bogotime(9)? ;) > > > > > > It's not returning units of any known time. "bogocount()" maybe... > > > > How about 'slushycounter()'? > > falseticker()? (Okay, probably too NTP specfic) Whatever. Part of this has gone bikeshed already. What it's called, I don't care. I care that I have the facility, and my customers (AKA the rest of you developers) care that it doesn't break their favourite project. Let's focus on a solution with a minimum of chatter? :-) (Jonathan - not intended to you personally)S Noted - "time" is contentious - perhaps call it monoticks(). Noted - "monotonic" is contentious - perhaps call it bogoticks(). Let's move forward. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 14:59:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0F13737B479; Fri, 17 Nov 2000 14:59:19 -0800 (PST) Received: (from jmz@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA48005; Fri, 17 Nov 2000 14:59:19 -0800 (PST) (envelope-from jmz@FreeBSD.org) Date: Fri, 17 Nov 2000 14:59:19 -0800 (PST) Message-Id: <200011172259.OAA48005@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: jmz set sender to jmz@FreeBSD.org using -f From: Jean-Marc Zucconi To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. In-Reply-To: <200011172249.eAHMnjJ07866@gratis.grondar.za> References: <20001117141037.E19895@prism.flugsvamp.com> <200011172249.eAHMnjJ07866@gratis.grondar.za> X-Mailer: Emacs 20.7.1 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> Mark Murray writes: > Whatever. I suggest markticks() Jean-Marc -- Jean-Marc Zucconi PGP Key: finger jmz@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 Nov 17 15: 1: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CCE7637B479 for ; Fri, 17 Nov 2000 15:01:05 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA16398; Fri, 17 Nov 2000 15:00:52 -0800 Date: Fri, 17 Nov 2000 15:00:49 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mark Murray Cc: arch@FreeBSD.ORG Subject: RE: new monotime() call for all architectures. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG markticks was suggested- which sounds redundant. Why not just 'marks'? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 15: 6:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 846A237B479 for ; Fri, 17 Nov 2000 15:06:55 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eAHN6oQ07848; Fri, 17 Nov 2000 16:06:54 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA78159; Fri, 17 Nov 2000 16:06:50 -0700 (MST) Message-Id: <200011172306.QAA78159@harmony.village.org> To: mjacob@feral.com Subject: Re: new monotime() call for all architectures. Cc: Mark Murray , arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 17 Nov 2000 10:36:15 PST." References: Date: Fri, 17 Nov 2000 16:06:50 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : In case there's ever a sparc port, all of the worthwhile sparc machines have : register onchip too. Ditto MIPS. There's a random register, but it is just a cycle counter that you can use to pick which TLB entry to shoot if you have to randomly pick one. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 15:45:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BBC8D37B4C5 for ; Fri, 17 Nov 2000 15:45:17 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA29546; Fri, 17 Nov 2000 18:44:33 -0500 (EST) Date: Fri, 17 Nov 2000 18:44:33 -0500 (EST) From: Daniel Eischen To: Matthew Jacob Cc: Mark Murray , arch@FreeBSD.ORG Subject: RE: new monotime() call for all architectures. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 17 Nov 2000, Matthew Jacob wrote: > > markticks was suggested- which sounds redundant. Why not just 'marks'? getcycles (not to be confused with bicycle or "bike"shed). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 16:36:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 55EF237B4C5; Fri, 17 Nov 2000 16:36:14 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id TAA10844; Fri, 17 Nov 2000 19:41:22 -0500 (EST) (envelope-from dufault) From: Peter Dufault Message-Id: <200011180041.TAA10844@hda.hda.com> Subject: Re: new monotime() call for all architectures. In-Reply-To: <200011172240.eAHMdtJ07828@gratis.grondar.za> from Mark Murray at "Nov 18, 2000 00:39:57 am" To: Mark Murray Date: Fri, 17 Nov 2000 19:41:22 -0500 (EST) Cc: John Hay , John Baldwin , arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Actually, it does mean "monotonic", but I don't need strictly > monotonic. The "time" info is used to improve the quality of the > harvested entropy, but it is not specifically counted, so the > errors introduced by different CPU's counters are "free" ontropy. almost_monotonic_sequence() (but Bruce will make me shorten it) Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 19:41:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 5F05837B479; Fri, 17 Nov 2000 19:41:33 -0800 (PST) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id eAI3fG972937; Sat, 18 Nov 2000 14:11:16 +1030 (CST) (envelope-from grog) Date: Sat, 18 Nov 2000 14:11:16 +1030 From: Greg Lehey To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: potentially simpler approach than scheduler activations. Message-ID: <20001118141116.E70679@wantadilla.lemis.com> References: <20001116140506.Q830@fw.wintelcom.net> <14868.39578.928654.157924@grasshopper.cs.duke.edu> <20001117094543.A76006@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001117094543.A76006@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Fri, Nov 17, 2000 at 09:45:43AM -0800 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 17 November 2000 at 9:45:43 -0800, David O'Brien wrote: >>> I know that by applying these band-aids we aren't completely >>> solving every problem and as new interfaces pop-up we might >>> have to apply more band-aids to libc_r, but I think this >>> might get us past the point of system that breaks down on >>> disk IO. >> >> This sounds like a really good idea to me, as long as it is qualified >> as an interum solution until KSE is ready and not a competitor to it. > > Also KSE's will never be back ported to RELENG_4. Maybe some of these > ideas can be. I see this as diluting the effort. Once we have a bandaid, we'll be less concerned about doing the right thing. And deliberately introducing different semantics in RELENG_4 seems not to be the Right Thing To Do. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 20:30:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id D383F37B479; Fri, 17 Nov 2000 20:30:18 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13wzfH-0000BC-00; Fri, 17 Nov 2000 21:31:47 -0700 Message-ID: <3A160633.CFAE57F8@softweyr.com> Date: Fri, 17 Nov 2000 21:31:47 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Jonathan Lemon , arch@FreeBSD.org, mark@grondar.za, Poul-Henning Kamp , Nate Williams Subject: Re: new monotime() call for all architectures. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 17-Nov-00 Jonathan Lemon wrote: > > On Fri, Nov 17, 2000 at 01:08:16PM -0700, Nate Williams wrote: > >> > >> >> Ok, I just thought the "mono" in his function name is for monotonic. > >> > >> >> If > >> > >> >> you are staying on one processor it will work, but if the timestamps > >> > >> >> have scheduling inbetween the timestamps and you land on a different > >> > >> >> processor it won't be monotonic anymore. > >> > >> > > >> > >> >It's close enough. :) > >> > >> > >> > >> If it isn't dealing properly with async PCC/TSC counters on SMP > >> > >> machines > >> > >> it shouldn't be called "monoanyting". > >> > >> > >> > >> I guess I totally object to the name now :-) > >> > > > >> > >OK, how about bogotime(9)? ;) > >> > > >> > It's not returning units of any known time. "bogocount()" maybe... > >> > >> How about 'slushycounter()'? > > > > falseticker()? (Okay, probably too NTP specfic) > > Let's just go back to CS 101 days and call it my_function(). Sorry, Mr. Baldwin, you just got a "D" in your assignment. Since the function appears to return an increasing nonsensical counter, "foo" seems somehow appropriate. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 20:54:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 0137E37B479; Fri, 17 Nov 2000 20:54:49 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13x032-0000Bu-00; Fri, 17 Nov 2000 21:56:20 -0700 Message-ID: <3A160BF4.1D05C638@softweyr.com> Date: Fri, 17 Nov 2000 21:56:20 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Wilko Bulte , John Baldwin , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... References: <200011151723.KAA12325@usr01.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > > What is the consensus ? > > > > > > What is the current processor of choice for embedded stuff? Is > > > x86 even a good architecture for embedded work? That is the > > > only place that I would see the 386 still being alive... > > > > x86 has never been a good CPU for embedded. [eyes his trusty books > > collection for Motorola's 680x0 ;) ] > > The Motorola strategy is broken; the processor they are selling > for Palm Pilots has no MMU. It's no good for most embedded work > (and is barely good enough for making Palm Pilots unstable with > one single bad program). > > Cyrix, AMD, and various Card PCs are all 386-class CPUs. The > IBM "Blue Lightning" core is a 386 class core, which is used > to implement macrocell based embedded ASICs. Intel has two > 386 macrocells that are used for embedded work. I'd have to > say that not even the 80186 was dead yet... http://www.zflinux.com/ Embedded x86 for the masses. The Intel information appliance reference designs are great little boards, too, if a bit more pricey in eval form. ZFLinux has been quoting prices of ~ $300 - $400 for eval boards. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 21:21: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 3ED9637B479; Fri, 17 Nov 2000 21:21:06 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13x0Rk-0000D7-00; Fri, 17 Nov 2000 22:21:52 -0700 Message-ID: <3A1611F0.C2A1E839@softweyr.com> Date: Fri, 17 Nov 2000 22:21:52 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Cy Schubert - ITSD Open Systems Group Cc: Terry Lambert , Adrian Chadd , arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... References: <200011151814.eAFIEPu56217@cwsys.cwsent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group wrote: > > In message <200011151739.KAA13021@usr01.primenet.com>, Terry Lambert > writes: > > > > > > 386'en might still have a place for small embedded products but I'm > > > proabably going to be flamed when I say I think FreeBSD-current isn't > > > very suited to "embedded 386 with tiny everything" applications. > > > > That's a problem with FreeBSD-current, not a problem with > > "embedded 386 with tiny everything". > > > > I'm reminded when SVR4s footprint first went to 8M of RAM. > > > > I also find it amusing that I can get an old SVR4.0.2 ES/MP, > > and load it on both SMP boxes, and on 6M 386 boxes, when I > > am quickly becoming unable to do the same for FreeBSD-current. > > > > I guess this is inevitable, as security is increased, since > > the most secure computer is one which doesn't run... > > Garfinkel and Spafford write in their book Practical UNIX and Internet > Security that the most secure system is one berried under six feet of > dirt. Even then tye didn't think it was 100% secure. :) Yeah, to make it fully secure, you open up the case, stir the insides vigorously with a crowbar, fill the case with cement, replace the top, coat with epoxy, then drop it in the ocean off the continental shelf. Optionally, you can replace the last step with stuffing it into a rocket and shooting it into the sun, but that's a little drastic. I suspect Adrian, or whoever the original author was, may not be in touch with how popular 386s are in the embedded world, or with how popular FreeBSD is in the embedded world. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 22:32:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 6510B37B479; Fri, 17 Nov 2000 22:32:23 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 13x1YT-0000Eu-00; Fri, 17 Nov 2000 23:32:54 -0700 Message-ID: <3A162295.9053CC09@softweyr.com> Date: Fri, 17 Nov 2000 23:32:53 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: Warner Losh , Cy Schubert - ITSD Open Systems Group , obrien@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RANDOMDEV inspired realitycheck regarding i386/i486... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > > In message <200011162224.eAGMOnL41055@passer.osg.gov.bc.ca> Cy Schubert writes: > > : What is the purpose of Core then? > > > > Core is the governing body of FreeBSD. > > Which, if I may say, seems to run under the rubric of "That which governs > least, governs best". Yes! Yes! Mr. Jefferson was right! -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 23: 8:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 78FD737B4C5; Fri, 17 Nov 2000 23:08:19 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id eAI786418833; Sat, 18 Nov 2000 09:08:06 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200011180708.eAI786418833@zibbi.icomtek.csir.co.za> Subject: Re: new monotime() call for all architectures. In-Reply-To: <200011172240.eAHMdtJ07828@gratis.grondar.za> from Mark Murray at "Nov 18, 2000 00:39:57 am" To: mark@grondar.za (Mark Murray) Date: Sat, 18 Nov 2000 09:08:06 +0200 (SAT) Cc: jhay@icomtek.csir.co.za (John Hay), jhb@FreeBSD.ORG (John Baldwin), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > It doesn't matter. He just needs a psuedo-timestamp for entropy gathering > > > purposes. It dosen't need to be entirely precise, so if different CPU's > > > counters are not 100% in sync it won't hurt anything. > > > > Ok, I just thought the "mono" in his function name is for monotonic. If > > you are staying on one processor it will work, but if the timestamps > > have scheduling inbetween the timestamps and you land on a different > > processor it won't be monotonic anymore. > > Actually, it does mean "monotonic", but I don't need strictly > monotonic. The "time" info is used to improve the quality of the > harvested entropy, but it is not specifically counted, so the > errors introduced by different CPU's counters are "free" ontropy. Maybe the interface should be private to the random code then. Otherwise a poor unsuspecting soul might assume he can use it in a driver or something and depend on it to be monotonic. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 17 23:36:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-210.dsl.snfc21.pacbell.net [63.202.177.210]) by hub.freebsd.org (Postfix) with ESMTP id 6190A37B479; Fri, 17 Nov 2000 23:36:09 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eAI7fCF01133; Fri, 17 Nov 2000 23:41:21 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011180741.eAI7fCF01133@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: John Baldwin , John Hay , mark@grondar.za, arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. In-reply-to: Your message of "Fri, 17 Nov 2000 20:53:09 +0100." <26014.974490789@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Nov 2000 23:41:12 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >> Ok, I just thought the "mono" in his function name is for monotonic. If > >> you are staying on one processor it will work, but if the timestamps > >> have scheduling inbetween the timestamps and you land on a different > >> processor it won't be monotonic anymore. > > > >It's close enough. :) > > If it isn't dealing properly with async PCC/TSC counters on SMP machines > it shouldn't be called "monoanyting". > > I guess I totally object to the name now :-) In an attempt to tow the bikeshed away behind a truck, can I suggest that we just call it "get_jiffiecount" (to tip our hats to the Linux folks) and get on with it? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 0:11:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 98E4F37B479; Sat, 18 Nov 2000 00:11:12 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAI8B7J11769; Sat, 18 Nov 2000 10:11:07 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011180811.eAI8B7J11769@gratis.grondar.za> To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. References: <200011180741.eAI7fCF01133@mass.osd.bsdi.com> In-Reply-To: <200011180741.eAI7fCF01133@mass.osd.bsdi.com> ; from Mike Smith "Fri, 17 Nov 2000 23:41:12 PST." Date: Sat, 18 Nov 2000 10:11:09 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I guess I totally object to the name now :-) > > In an attempt to tow the bikeshed away behind a truck, can I suggest that > we just call it "get_jiffiecount" (to tip our hats to the Linux folks) > and get on with it? This comes the closest, as far as I am concerned. Any objections? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 0:47:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4E1C337B657; Sat, 18 Nov 2000 00:47:13 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eAI8l7S07938; Sat, 18 Nov 2000 00:47:07 -0800 (PST) Date: Sat, 18 Nov 2000 00:47:07 -0800 From: Alfred Perlstein To: Greg Lehey Cc: "David O'Brien" , arch@FreeBSD.ORG Subject: Re: potentially simpler approach than scheduler activations. Message-ID: <20001118004707.A18037@fw.wintelcom.net> References: <20001116140506.Q830@fw.wintelcom.net> <14868.39578.928654.157924@grasshopper.cs.duke.edu> <20001117094543.A76006@dragon.nuxi.com> <20001118141116.E70679@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001118141116.E70679@wantadilla.lemis.com>; from grog@lemis.com on Sat, Nov 18, 2000 at 02:11:16PM +1030 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Greg Lehey [001117 19:42] wrote: > On Friday, 17 November 2000 at 9:45:43 -0800, David O'Brien wrote: > >>> I know that by applying these band-aids we aren't completely > >>> solving every problem and as new interfaces pop-up we might > >>> have to apply more band-aids to libc_r, but I think this > >>> might get us past the point of system that breaks down on > >>> disk IO. > >> > >> This sounds like a really good idea to me, as long as it is qualified > >> as an interum solution until KSE is ready and not a competitor to it. > > > > Also KSE's will never be back ported to RELENG_4. Maybe some of these > > ideas can be. > > I see this as diluting the effort. Once we have a bandaid, we'll be > less concerned about doing the right thing. And deliberately > introducing different semantics in RELENG_4 seems not to be the Right > Thing To Do. This wasn't meant to start a discussion whether it was an evil thing to do or not, it was meant to provide a framework for someone with the time and skill to do it. Please stop discussing the relative merits, I proposed this idea knowing full well that KSE is better, this is just easier to implement and a worthy project for someone wanting to take that extra step into some hardcode programming. But you can't satisfy everyone can you? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 4: 0:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id E4E7337B479 for ; Sat, 18 Nov 2000 04:00:07 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAIC00J12131 for ; Sat, 18 Nov 2000 14:00:00 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011181200.eAIC00J12131@gratis.grondar.za> To: arch@freebsd.org Subject: "Monotonic" counter/register call - commit candidate. Date: Sat, 18 Nov 2000 13:59:58 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Many thanks to those of you gave me all the constructive suggestions! Here is the commit candidate, taking into account as many of the reasonable ones as I could. WARNING! This is untested on Alpha and IA64. I considered renaming the function to marks(9), as I kinda liked that name, but on reflection, it seems way too arrogant, so Mike Smith's "get_jiffiecounter" won. I'm keeping the function public, as others have expressed an interest in using it. If this is accepted, I'll write a man 9 page for it. I have also included some fixes for ".byte xx,yy" code to use real Pentium opcodes (now that GAS is updated (a while back)). M Index: alpha/include//cpufunc.h =================================================================== RCS file: /home/ncvs/src/sys/alpha/include/cpufunc.h,v retrieving revision 1.9 diff -u -d -r1.9 cpufunc.h --- alpha/include//cpufunc.h 2000/09/07 01:32:40 1.9 +++ alpha/include//cpufunc.h 2000/11/18 11:43:00 @@ -72,6 +72,15 @@ alpha_pal_swpipl(ipl); } +/* + * Standardised jiffy counter interface + */ +static __inline u_int64_t +get_jiffiecount(void) +{ + return alpha_rpcc(); +} + #endif /* _KERNEL */ #endif /* !_MACHINE_CPUFUNC_H_ */ Index: i386/include//cpufunc.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/cpufunc.h,v retrieving revision 1.99 diff -u -d -r1.99 cpufunc.h --- i386/include//cpufunc.h 2000/10/12 17:05:33 1.99 +++ i386/include//cpufunc.h 2000/11/18 11:18:09 @@ -397,10 +397,24 @@ { u_int64_t rv; - __asm __volatile(".byte 0x0f, 0x31" : "=A" (rv)); + __asm __volatile("rdtsc" : "=A" (rv)); return (rv); } +/* + * Standardised jiffy counter interface + */ +static __inline u_int64_t +get_jiffiecount(void) +{ +#if defined(I386_CPU) || defined(I486_CPU) + if (!tsc_present) + return nanotime(); + else +#endif + return rdtsc(); +} + static __inline void wbinvd(void) { @@ -416,7 +430,7 @@ static __inline void wrmsr(u_int msr, u_int64_t newval) { - __asm __volatile(".byte 0x0f, 0x30" : : "A" (newval), "c" (msr)); + __asm __volatile("wrmsr" : : "A" (newval), "c" (msr)); } static __inline u_int Index: ia64/include//cpufunc.h =================================================================== RCS file: /home/ncvs/src/sys/ia64/include/cpufunc.h,v retrieving revision 1.1 diff -u -d -r1.1 cpufunc.h --- ia64/include//cpufunc.h 2000/09/29 13:46:05 1.1 +++ ia64/include//cpufunc.h 2000/11/18 11:46:01 @@ -32,6 +32,7 @@ #ifdef _KERNEL #include +#include #ifdef __GNUC__ @@ -190,6 +191,15 @@ restore_intr(u_int psr) { __asm __volatile ("mov psr.l=%0;; srlz.d" :: "r" (psr)); +} + +/* + * Standardised jiffy counter interface + */ +static __inline u_int64_t +get_jiffiecount(void) +{ + return ia64_get_itc(); } #endif /* _KERNEL */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 5:23:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 51C3837B4C5 for ; Sat, 18 Nov 2000 05:23:54 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA29192; Sat, 18 Nov 2000 08:22:44 -0500 (EST) Date: Sat, 18 Nov 2000 08:22:44 -0500 (EST) From: Daniel Eischen To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. In-Reply-To: <200011181200.eAIC00J12131@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 18 Nov 2000, Mark Murray wrote: > Hi > > Many thanks to those of you gave me all the constructive suggestions! > > Here is the commit candidate, taking into account as many of the > reasonable ones as I could. > > WARNING! This is untested on Alpha and IA64. > > I considered renaming the function to marks(9), as I kinda liked > that name, but on reflection, it seems way too arrogant, so > Mike Smith's "get_jiffiecounter" won. I really hate "jiffie" and would prefer using just get_cyclecount or even better get_counter. It would also be nice to know what resolution the counter was, perhaps get_counter_res(). Do we want an ID associated with the counter if there is more than one available on the hardware? On a somewhat related note, I could use something to measure time that wasn't a system call in the threads library. Is there a way we can get a timer or something that was mmap'able? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 5:50:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-128.dsl.snfc21.pacbell.net [63.202.176.128]) by hub.freebsd.org (Postfix) with ESMTP id 0A88837B479 for ; Sat, 18 Nov 2000 05:50:09 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eAIDuHF04876; Sat, 18 Nov 2000 05:56:17 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011181356.eAIDuHF04876@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Eischen Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. In-reply-to: Your message of "Sat, 18 Nov 2000 08:22:44 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Nov 2000 05:56:17 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I considered renaming the function to marks(9), as I kinda liked > > that name, but on reflection, it seems way too arrogant, so > > Mike Smith's "get_jiffiecounter" won. > > I really hate "jiffie" and would prefer using just get_cyclecount > or even better get_counter. "get_counter" is hopelessly vague. get_cyclecount would be OK too. I don't care. Pick a name and stop bloody arguing about it. > It would also be nice to know what > resolution the counter was, perhaps get_counter_res(). Do we > want an ID associated with the counter if there is more than > one available on the hardware? Stop trying to make it into a timecounter. If you want a timecounter, use a timecounter. We have perfectly good timecounters already. This is not and never will be a facility any good for computing time. The value may wrap unexpectedly, go backwards, proceed forwards erratically, etc. > On a somewhat related note, I could use something to measure time > that wasn't a system call in the threads library. Is there a way > we can get a timer or something that was mmap'able? You could probably arrange for some portion of the timecounter space to be mapped read-only into userspace. How precise does it need to be? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 7:18:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id E2A9337B479; Sat, 18 Nov 2000 07:18:22 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAIFIIJ12462; Sat, 18 Nov 2000 17:18:18 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011181518.eAIFIIJ12462@gratis.grondar.za> To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. References: <200011181356.eAIDuHF04876@mass.osd.bsdi.com> In-Reply-To: <200011181356.eAIDuHF04876@mass.osd.bsdi.com> ; from Mike Smith "Sat, 18 Nov 2000 05:56:17 PST." Date: Sat, 18 Nov 2000 17:18:15 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I really hate "jiffie" and would prefer using just get_cyclecount > > or even better get_counter. > > "get_counter" is hopelessly vague. get_cyclecount would be OK too. I > don't care. Pick a name and stop bloody arguing about it. *Sigh* get_cyclecount it shall be. No more bikeshedding on that issue, please. Apart from that, do I have green light? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 7:25:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1B89637B479; Sat, 18 Nov 2000 07:25:44 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id KAA12879; Sat, 18 Nov 2000 10:25:23 -0500 (EST) Date: Sat, 18 Nov 2000 10:25:22 -0500 (EST) From: Daniel Eischen To: Mike Smith Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. In-Reply-To: <200011181356.eAIDuHF04876@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 18 Nov 2000, Mike Smith wrote: > > On a somewhat related note, I could use something to measure time > > that wasn't a system call in the threads library. Is there a way > > we can get a timer or something that was mmap'able? > > You could probably arrange for some portion of the timecounter space to > be mapped read-only into userspace. How precise does it need to be? Scheduling tick resolution or better. I would like to use it for waking up threads that are in states that timeout. The smallest resolution would be for something like pthread_cond_timedwait() which is timespec (nanosecs), but we don't need to be that resolute. Right now we use gettimeofday(). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 7:48:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 9B39837B479; Sat, 18 Nov 2000 07:48:51 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAIFmOJ12563; Sat, 18 Nov 2000 17:48:24 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011181548.eAIFmOJ12563@gratis.grondar.za> To: Daniel Eischen Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. References: In-Reply-To: ; from Daniel Eischen "Sat, 18 Nov 2000 10:25:22 EST." Date: Sat, 18 Nov 2000 17:48:21 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If this thread is going to go in this direction, then please change the subject. I still haven't got resolution on _my_ thread. M > On Sat, 18 Nov 2000, Mike Smith wrote: > > > On a somewhat related note, I could use something to measure time > > > that wasn't a system call in the threads library. Is there a way > > > we can get a timer or something that was mmap'able? > > > > You could probably arrange for some portion of the timecounter space to > > be mapped read-only into userspace. How precise does it need to be? > > Scheduling tick resolution or better. I would like to use it for > waking up threads that are in states that timeout. The smallest > resolution would be for something like pthread_cond_timedwait() > which is timespec (nanosecs), but we don't need to be that resolute. > Right now we use gettimeofday(). -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 8: 0:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 53A4137B479 for ; Sat, 18 Nov 2000 08:00:15 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 13xAPQ-000M6o-00; Sat, 18 Nov 2000 16:00:08 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.0) id eAIFwth00587; Sat, 18 Nov 2000 16:58:55 +0100 (CET) (envelope-from wkb) Date: Sat, 18 Nov 2000 16:58:55 +0100 From: Wilko Bulte To: Daniel Eischen Cc: Mark Murray , arch@freebsd.org Subject: Re: "Monotonic" counter/register call - commit candidate. Message-ID: <20001118165855.A409@freebie.demon.nl> References: <200011181200.eAIC00J12131@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from eischen@vigrid.com on Sat, Nov 18, 2000 at 08:22:44AM -0500 X-OS: FreeBSD 4.2-BETA X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 18, 2000 at 08:22:44AM -0500, Daniel Eischen wrote: > On Sat, 18 Nov 2000, Mark Murray wrote: > > Hi > > > > Many thanks to those of you gave me all the constructive suggestions! > > > > Here is the commit candidate, taking into account as many of the > > reasonable ones as I could. > > > > WARNING! This is untested on Alpha and IA64. > > > > I considered renaming the function to marks(9), as I kinda liked > > that name, but on reflection, it seems way too arrogant, so > > Mike Smith's "get_jiffiecounter" won. > > I really hate "jiffie" and would prefer using just get_cyclecount > or even better get_counter. It would also be nice to know what get_counter != meaningful naming. IMO it can mean about anything. -- Wilko Bulte Arnhem, the Netherlands wilko@freebsd.org http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 8:41:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1BDD637B4C5; Sat, 18 Nov 2000 08:41:21 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id DAA16891; Sun, 19 Nov 2000 03:41:17 +1100 Date: Sun, 19 Nov 2000 03:41:15 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Mark Murray , arch@FreeBSD.ORG Subject: RE: new monotime() call for all architectures. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 17 Nov 2000, John Baldwin wrote: > Please use existing functions like rdtsc() instead of duplicating the inline > assembly. This will help reduce maintenance down the road. Yes. > In fact, you might > want to move this to machine/cpufunc.h instead of machine/clock.h. No! machine/cpufunc.h is for "Functions to provide access to special cpu instructions", not for functions that happen to call a (primitive) function in cpufunc.h. > Then use > the rdtsc() function for x86, alpha_rpcc() for the alpha, and ia64_get_itc() > for ia64. Note that for ia64, machine/cpufunc.h needs to be fixed to #include > machine/ia64_cpu.h as it does on the alpha. This seems to be a bug in the alpha version. cpufunc.h is spelled alpha_cpu.h in NetBSD. FreeBSD obtained this spelling from NetBSD and attached a few extras in cpufunc.h. There doesn't seem to be any reason to have separate files. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 8:53:13 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 76F5937B4C5 for ; Sat, 18 Nov 2000 08:53:08 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAIGqgJ12738; Sat, 18 Nov 2000 18:52:42 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011181652.eAIGqgJ12738@gratis.grondar.za> To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. References: In-Reply-To: ; from Bruce Evans "Sun, 19 Nov 2000 03:41:15 +1100." Date: Sat, 18 Nov 2000 18:52:38 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > In fact, you might > > want to move this to machine/cpufunc.h instead of machine/clock.h. > > No! machine/cpufunc.h is for "Functions to provide access to special cpu > instructions", not for functions that happen to call a (primitive) function > in cpufunc.h. Then where? clock.h has already been thoroughly objected to. > > Then use > > the rdtsc() function for x86, alpha_rpcc() for the alpha, and ia64_get_itc( ) > > for ia64. Note that for ia64, machine/cpufunc.h needs to be fixed to #incl ude > > machine/ia64_cpu.h as it does on the alpha. > > This seems to be a bug in the alpha version. cpufunc.h is spelled > alpha_cpu.h in NetBSD. FreeBSD obtained this spelling from NetBSD and > attached a few extras in cpufunc.h. There doesn't seem to be any reason > to have separate files. Help me here please :-) I need the function, and I have written it. Either let me commit what I have or suggest to me how I can fix that please. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 12:32:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A4B3A37B479; Sat, 18 Nov 2000 12:32:09 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id HAA22870; Sun, 19 Nov 2000 07:32:05 +1100 Date: Sun, 19 Nov 2000 07:32:04 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mike Smith Cc: Daniel Eischen , Mark Murray , arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. In-Reply-To: <200011181356.eAIDuHF04876@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 18 Nov 2000, Mike Smith wrote: > > > I considered renaming the function to marks(9), as I kinda liked > > > that name, but on reflection, it seems way too arrogant, so > > > Mike Smith's "get_jiffiecounter" won. > > > > I really hate "jiffie" and would prefer using just get_cyclecount > > or even better get_counter. > > "get_counter" is hopelessly vague. get_cyclecount would be OK too. I > don't care. Pick a name and stop bloody arguing about it. How about rdcdtsc() (read cpu-dependent timestamp counter)? :-). > > It would also be nice to know what > > resolution the counter was, perhaps get_counter_res(). Do we > > want an ID associated with the counter if there is more than > > one available on the hardware? > > Stop trying to make it into a timecounter. If you want a timecounter, > use a timecounter. We have perfectly good timecounters already. This is > not and never will be a facility any good for computing time. The value > may wrap unexpectedly, go backwards, proceed forwards erratically, etc. I hesitate to mention that we already have an imperfectly good function for access to certain machine-dependent counters: cputime(). It is only implemented on i386's and only used for profiling. It is almost as slow as a timecounter (not all that slow). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 13: 5: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 9F60037B479 for ; Sat, 18 Nov 2000 13:04:57 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAIL4YJ13194; Sat, 18 Nov 2000 23:04:34 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011182104.eAIL4YJ13194@gratis.grondar.za> To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. References: In-Reply-To: ; from Bruce Evans "Sun, 19 Nov 2000 07:32:04 +1100." Date: Sat, 18 Nov 2000 23:04:29 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > "get_counter" is hopelessly vague. get_cyclecount would be OK too. I > > don't care. Pick a name and stop bloody arguing about it. > > How about rdcdtsc() (read cpu-dependent timestamp counter)? :-). Whatever. I've chosen a name now. Names have bloated this discussion way into the bikeshed arena. > I hesitate to mention that we already have an imperfectly good function > for access to certain machine-dependent counters: cputime(). It is > only implemented on i386's and only used for profiling. It is almost > as slow as a timecounter (not all that slow). That function is kinda bloated; all I need is rdtsc() and its equivalents. I think that John Baldwin and I have converged on something practical. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 14:30:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 58B8237B479 for ; Sat, 18 Nov 2000 14:30:38 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id JAA26545; Sun, 19 Nov 2000 09:30:14 +1100 Date: Sun, 19 Nov 2000 09:30:12 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. In-Reply-To: <200011181652.eAIGqgJ12738@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 18 Nov 2000, Mark Murray wrote: > > No! machine/cpufunc.h is for "Functions to provide access to special cpu > > instructions", not for functions that happen to call a (primitive) function > > in cpufunc.h. > > Then where? clock.h has already been thoroughly objected to. clock.c is a reasonable place for it. On i386's, it needs to access `tsc_present' which is currently only in clock.c. How much more (or less) efficient is the inline version? is another reasonable place for it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 14:48:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E2BB137B479 for ; Sat, 18 Nov 2000 14:48:12 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id JAA27161; Sun, 19 Nov 2000 09:47:56 +1100 Date: Sun, 19 Nov 2000 09:47:55 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. In-Reply-To: <200011182104.eAIL4YJ13194@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I hesitate to mention that we already have an imperfectly good function > > for access to certain machine-dependent counters: cputime(). It is > > only implemented on i386's and only used for profiling. It is almost > > as slow as a timecounter (not all that slow). > > That function is kinda bloated; all I need is rdtsc() and its equivalents. I'm not sure about that. There are many interesting machine-dependent counters. E.g., the counter for the number of instructions executed increases at a similar rate to the TSC but is more random. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 14:51:25 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id A201837B479 for ; Sat, 18 Nov 2000 14:51:20 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAIMp3J13407; Sun, 19 Nov 2000 00:51:03 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011182251.eAIMp3J13407@gratis.grondar.za> To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: new monotime() call for all architectures. References: In-Reply-To: ; from Bruce Evans "Sun, 19 Nov 2000 09:30:12 +1100." Date: Sun, 19 Nov 2000 00:50:57 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Then where? clock.h has already been thoroughly objected to. > > clock.c is a reasonable place for it. On i386's, it needs to access > `tsc_present' which is currently only in clock.c. How much more > (or less) efficient is the inline version? One instruction versus oneinstruction-plus-function-call-overhead. > is another reasonable place for it. Sorta, except that other folks are saying that they want this too. sys/systm.h? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 18 14:52:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 508DE37B479 for ; Sat, 18 Nov 2000 14:52:38 -0800 (PST) Received: from grondar.za (grapevine.grondar.za [196.7.18.17]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id eAIMqPJ13415; Sun, 19 Nov 2000 00:52:25 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200011182252.eAIMqPJ13415@gratis.grondar.za> To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: "Monotonic" counter/register call - commit candidate. References: In-Reply-To: ; from Bruce Evans "Sun, 19 Nov 2000 09:47:55 +1100." Date: Sun, 19 Nov 2000 00:52:20 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > That function is kinda bloated; all I need is rdtsc() and its equivalents. > > I'm not sure about that. There are many interesting machine-dependent > counters. E.g., the counter for the number of instructions executed > increases at a similar rate to the TSC but is more random. I'm not looking for random. I'm looking for a fast counter. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message