From owner-freebsd-hackers Sun Jan 9 3:48:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 58F0714E5F for ; Sun, 9 Jan 2000 03:48:27 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id MAA23509 for FreeBSD-hackers@freebsd.org; Sun, 9 Jan 2000 12:40:59 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id MAA61092 for FreeBSD-hackers@freebsd.org; Sun, 9 Jan 2000 12:44:20 +0100 (CET) (envelope-from wilko) Date: Sun, 9 Jan 2000 12:44:20 +0100 From: Wilko Bulte To: FreeBSD hackers list Subject: moving CVS repository Message-ID: <20000109124420.A60996@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the course of reorganising my disks I moved my local CVS repository from /local/CVSfoo to /local2/CVSfoo This has the side-effect(?) that all sources checked out from the 'old' repository location have references to /local/CVSfoo whereas cvs update obviously wants to have the references to /local2/CVSfoo. Running cvs update gives me lots of errors about this. Is there any way, short of running a fresh cvs co, to correct this? Wilko (who is not a cvs guru by any standard ;-) -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 4:23:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lindt.urgle.com (lindt.urgle.com [195.173.172.169]) by hub.freebsd.org (Postfix) with ESMTP id 1E35A14C3F for ; Sun, 9 Jan 2000 04:23:57 -0800 (PST) (envelope-from mike@urgle.com) Received: from mike by lindt.urgle.com with local (Exim 3.03 #1) id 127HNy-0008cL-00; Sun, 09 Jan 2000 12:23:54 +0000 Date: Sun, 9 Jan 2000 12:23:54 +0000 From: Mike Bristow To: Wilko Bulte Cc: FreeBSD hackers list Subject: Re: moving CVS repository Message-ID: <20000109122354.A33101@lindt.urgle.com> References: <20000109124420.A60996@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000109124420.A60996@yedi.iaf.nl>; from wilko@yedi.iaf.nl on Sun, Jan 09, 2000 at 12:44:20PM +0100 X-Rated: LSD, insider dealing Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 09, 2000 at 12:44:20PM +0100, Wilko Bulte wrote: > In the course of reorganising my disks I moved my local CVS repository > from /local/CVSfoo to /local2/CVSfoo > > This has the side-effect(?) that all sources checked out from the 'old' > repository location have references to /local/CVSfoo whereas cvs update > obviously wants to have the references to /local2/CVSfoo. One way to do this would be to: cd /local ln -s CVSfoo ../local2/CVSfoo And the tell your users that they have a week/month/whatever to recheckout all their working sources. > Wilko (who is not a cvs guru by any standard ;-) Me neither, there's probably a better method (I'd guess that you can frib some the files in CVS/ in the working direcrory, but I can't experiment or read the docs for assorted reasons right now) -- Mike Bristow, Geek At Large ``Beware of Invisible Cows'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 4:59:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 5FA8114E5F for ; Sun, 9 Jan 2000 04:59:44 -0800 (PST) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 2.12 #1) id 127HwL-0001Lw-00; Sun, 9 Jan 2000 18:59:25 +0600 Date: Sun, 9 Jan 2000 18:59:23 +0600 (ALMT) From: Boris Popov To: Wilko Bulte Cc: FreeBSD hackers list Subject: Re: moving CVS repository In-Reply-To: <20000109124420.A60996@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 9 Jan 2000, Wilko Bulte wrote: > In the course of reorganising my disks I moved my local CVS repository > from /local/CVSfoo to /local2/CVSfoo > > This has the side-effect(?) that all sources checked out from the 'old' > repository location have references to /local/CVSfoo whereas cvs update > obviously wants to have the references to /local2/CVSfoo. The simplest way is to replace content of CVS/Root files. They contain full path to repository. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 5: 6:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cichlids.com (as10-063.rp-plus.de [149.221.96.63]) by hub.freebsd.org (Postfix) with ESMTP id 55EB714E5F for ; Sun, 9 Jan 2000 05:06:35 -0800 (PST) (envelope-from alex@cichlids.com) Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by cichlids.com (Postfix) with ESMTP id 3EE7CAB92; Sun, 9 Jan 2000 14:06:44 +0100 (CET) Received: (from alex@localhost) by cichlids.cichlids.com (8.9.3/8.9.3) id OAA03858; Sun, 9 Jan 2000 14:06:34 +0100 (CET) (envelope-from alex) Date: Sun, 9 Jan 2000 14:06:33 +0100 From: Alexander Langer To: Boris Popov Cc: Wilko Bulte , FreeBSD hackers list Subject: Re: moving CVS repository Message-ID: <20000109140633.A3812@cichlids.cichlids.com> References: <20000109124420.A60996@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from bp@butya.kz on Sun, Jan 09, 2000 at 06:59:23PM +0600 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Boris Popov (bp@butya.kz): > > This has the side-effect(?) that all sources checked out from the 'old' > > repository location have references to /local/CVSfoo whereas cvs update > > obviously wants to have the references to /local2/CVSfoo. > The simplest way is to replace content of CVS/Root files. They > contain full path to repository. Yes. Shell is your friend. find /local2/CVSfoo -name "Root" | xargs sh -c "mv $a $a.old ; sed -e 's:/local/:/local2/:g' $a.old > $a && rm $a.old" or something. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 5:34:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id EADB2150AE for ; Sun, 9 Jan 2000 05:34:27 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id OAA26469; Sun, 9 Jan 2000 14:34:26 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id C0AF58863; Sun, 9 Jan 2000 13:29:47 +0100 (CET) Date: Sun, 9 Jan 2000 13:29:47 +0100 From: Ollivier Robert To: FreeBSD hackers list Cc: Wilko Bulte Subject: Re: moving CVS repository Message-ID: <20000109132947.A30997@keltia.freenix.fr> Mail-Followup-To: FreeBSD hackers list , Wilko Bulte References: <20000109124420.A60996@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000109124420.A60996@yedi.iaf.nl>; from wilko@yedi.iaf.nl on Sun, Jan 09, 2000 at 12:44:20PM +0100 X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Wilko Bulte: > Is there any way, short of running a fresh cvs co, to correct this? *NOT TESTED* Something along the lines of perl -ni -e 's' **/{Root,Repository} (if using zsh) or find . \( -name Root -o -name Repository \) -path \*CVS\* | xargs perl -ni ... if not. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #77: Thu Dec 30 12:49:51 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 6:27:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 76C4614F2A for ; Sun, 9 Jan 2000 06:27:19 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D84E01CCE; Sun, 9 Jan 2000 22:27:16 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Ollivier Robert Cc: FreeBSD hackers list , Wilko Bulte Subject: Re: moving CVS repository In-Reply-To: Message from Ollivier Robert of "Sun, 09 Jan 2000 13:29:47 +0100." <20000109132947.A30997@keltia.freenix.fr> Date: Sun, 09 Jan 2000 22:27:16 +0800 From: Peter Wemm Message-Id: <20000109142716.D84E01CCE@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ollivier Robert wrote: > According to Wilko Bulte: > > Is there any way, short of running a fresh cvs co, to correct this? > > *NOT TESTED* > > Something along the lines of > > perl -ni -e 's' **/{Root,Repository} (if using zsh) > > or > > find . \( -name Root -o -name Repository \) -path \*CVS\* | xargs perl -ni .. . > > if not. Note that there is an important change in CVS behavior in 1.10.7 (in -current and -stable) relative to 1.10. CVS used to have: CVS/Root: /local/CVSfoo CVS/Repostory: /local/CVSfoo/path/to/directory Now it has: CVS/Root: /local/CVSfoo CVS/Repostory: path/to/directory ie: Repository is now *relative* to the Root, and does not duplicate the Root path. Also, 1.10.7 has "multiroot" capability. If you descend a tree with different CVS/Root's, it will do the expected thing. That means if you have a part local tree and a part remote tree, a 'cvs update' will switch to and from remote mode as required. This can be a bit of a suprise if you are not expecting it! One other thing.. cvs -d new-root-path *unconditionally* overrides *all* CVS/Root files. The CVS_IGNORE_REMOTE_ROOT hack is gone and no longer required. cvs now assumes that if you override the root with -d, then you know what you are doing. ie: you can check out from /local/mycvs and commit with cvs -d user@freefall:/home/ncvs ... and it won't complain. It used to complain bitterly before if the root prefixes (/local/mycvs != /home/ncvs) didn't match. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 7:49: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 8C0E914FEF for ; Sun, 9 Jan 2000 07:49:03 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id QAA31783; Sun, 9 Jan 2000 16:42:06 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id QAA63884; Sun, 9 Jan 2000 16:30:25 +0100 (CET) (envelope-from wilko) Date: Sun, 9 Jan 2000 16:30:25 +0100 From: Wilko Bulte To: Peter Wemm Cc: Ollivier Robert , FreeBSD hackers list Subject: Re: moving CVS repository Message-ID: <20000109163025.A63612@yedi.iaf.nl> References: <20000109142716.D84E01CCE@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000109142716.D84E01CCE@overcee.netplex.com.au>; from peter@netplex.com.au on Sun, Jan 09, 2000 at 10:27:16PM +0800 X-OS: FreeBSD yedi.iaf.nl 3.4-STABLE FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 09, 2000 at 10:27:16PM +0800, Peter Wemm wrote: > Ollivier Robert wrote: > > According to Wilko Bulte: > > > Is there any way, short of running a fresh cvs co, to correct this? > > > > *NOT TESTED* > > > > Something along the lines of > > > > perl -ni -e 's' **/{Root,Repository} (if using zsh) > > > > or > > > > find . \( -name Root -o -name Repository \) -path \*CVS\* | xargs perl -ni .. > . > > > Note that there is an important change in CVS behavior in 1.10.7 (in -current > and -stable) relative to 1.10. CVS used to have: > > CVS/Root: /local/CVSfoo > CVS/Repostory: /local/CVSfoo/path/to/directory > > Now it has: > CVS/Root: /local/CVSfoo > CVS/Repostory: path/to/directory > > ie: Repository is now *relative* to the Root, and does not duplicate the Root > path. Allow me a potentially stupid question: why do the Root files exist at all? I mean, assuming you cvs -q with CVSROOT set to the right place you should be able to work on your checked-out tree without problems. Or am I missing the glaringly obvious here? Maybe the same applies to the Repository files? And if they have to exist, why are they repeated everywhere? > Also, 1.10.7 has "multiroot" capability. If you descend a tree with different > CVS/Root's, it will do the expected thing. That means if you have a part local > tree and a part remote tree, a 'cvs update' will switch to and from remote > mode as required. This can be a bit of a suprise if you are not expecting it! > > One other thing.. cvs -d new-root-path *unconditionally* overrides *all* > CVS/Root files. The CVS_IGNORE_REMOTE_ROOT hack is gone and no longer required. > cvs now assumes that if you override the root with -d, then you know what you > are doing. ie: you can check out from /local/mycvs and commit with This sounds like I would expect (but I have never commited anything to a cvs tree so I have not shot myself in the foot here ;-) Thanks, -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 8: 1:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id D2D3D14FA7 for ; Sun, 9 Jan 2000 08:01:45 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id EB9191CC6; Mon, 10 Jan 2000 00:01:38 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Wilko Bulte Cc: Ollivier Robert , FreeBSD hackers list Subject: Re: moving CVS repository In-Reply-To: Message from Wilko Bulte of "Sun, 09 Jan 2000 16:30:25 +0100." <20000109163025.A63612@yedi.iaf.nl> Date: Mon, 10 Jan 2000 00:01:38 +0800 From: Peter Wemm Message-Id: <20000109160138.EB9191CC6@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wilko Bulte wrote: > On Sun, Jan 09, 2000 at 10:27:16PM +0800, Peter Wemm wrote: > > Ollivier Robert wrote: > > > According to Wilko Bulte: > > > > Is there any way, short of running a fresh cvs co, to correct this? > > > > > > *NOT TESTED* > > > > > > Something along the lines of > > > > > > perl -ni -e 's' **/{Root,Repository} (if using zsh ) > > > > > > or > > > > > > find . \( -name Root -o -name Repository \) -path \*CVS\* | xargs perl -n i .. > > . > > > > > > Note that there is an important change in CVS behavior in 1.10.7 (in -curre nt > > and -stable) relative to 1.10. CVS used to have: > > > > CVS/Root: /local/CVSfoo > > CVS/Repostory: /local/CVSfoo/path/to/directory > > > > Now it has: > > CVS/Root: /local/CVSfoo > > CVS/Repostory: path/to/directory > > > > ie: Repository is now *relative* to the Root, and does not duplicate the Ro ot > > path. > > Allow me a potentially stupid question: why do the Root files exist at all? > I mean, assuming you cvs -q with CVSROOT set to the right place you > should be able to work on your checked-out tree without problems. Or am I > missing the glaringly obvious here? What if you have two repositories from two different cvs trees? what would happen if you forgot to change $CVSROOT when switching from one to the other? IMHO, It's not such a hot idea to leave $CVSROOT set these days. Use cvs -d when doing the initial checkout and then let each checkout identify itself. > Maybe the same applies to the Repository files? No, Repository tells us the path for "this" directory to the repostory. eg: cd /tmp cvs -d /home/ncvs checkout ls Now the name "/tmp/ls" gives no clue where it "fits" into the repository - that's where the Repository files come in. They contain "bin/ls" so that cvs can find where the directory fits. "Root" contains "/home/ncvs" so that cvs knows which repository it came from. > And if they have to exist, why are they repeated everywhere? Because you can have multiple cvsroot's in a single heirarchy. > > Also, 1.10.7 has "multiroot" capability. If you descend a tree with differ ent > > CVS/Root's, it will do the expected thing. That means if you have a part l ocal > > tree and a part remote tree, a 'cvs update' will switch to and from remote > > mode as required. This can be a bit of a suprise if you are not expecting it! > > > > One other thing.. cvs -d new-root-path *unconditionally* overrides *all* > > CVS/Root files. The CVS_IGNORE_REMOTE_ROOT hack is gone and no longer requ ired. > > cvs now assumes that if you override the root with -d, then you know what y ou > > are doing. ie: you can check out from /local/mycvs and commit with > > This sounds like I would expect (but I have never commited anything to a cvs > tree so I have not shot myself in the foot here ;-) Yes, but it never worked this way until recently or if you compiled in relative Repository mode. And even then you couldn't override the cvsroot path with -d. I guess the cvs folks feel that enough people know how to handle cvs that it's safe enough to supply rope and to hope that enough people will be around to prevent accidental hangings. :-] Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 10:40: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 855DD14D39 for ; Sun, 9 Jan 2000 10:39:58 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA15125; Sun, 9 Jan 2000 11:39:33 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA16606; Sun, 9 Jan 2000 11:39:31 -0700 Date: Sun, 9 Jan 2000 11:39:31 -0700 Message-Id: <200001091839.LAA16606@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alexander Langer Cc: Boris Popov , Wilko Bulte , FreeBSD hackers list Subject: Re: moving CVS repository In-Reply-To: <20000109140633.A3812@cichlids.cichlids.com> References: <20000109124420.A60996@yedi.iaf.nl> <20000109140633.A3812@cichlids.cichlids.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > This has the side-effect(?) that all sources checked out from the 'old' > > > repository location have references to /local/CVSfoo whereas cvs update > > > obviously wants to have the references to /local2/CVSfoo. > > The simplest way is to replace content of CVS/Root files. They > > contain full path to repository. > > Yes. Shell is your friend. > > find /local2/CVSfoo -name "Root" | xargs sh -c "mv $a $a.old ; sed -e > 's:/local/:/local2/:g' $a.old > $a && rm $a.old" > > or something. Or even more paranoid and slightly shorter. ;) find /local2/CVSfoo -name Root -print | fgrep CVS | perl -pi -e 's#/local#/local2/#g;' Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 13:47: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta2.rcsntx.swbell.net (mta2.rcsntx.swbell.net [151.164.30.26]) by hub.freebsd.org (Postfix) with ESMTP id BF9DF14D03 for ; Sun, 9 Jan 2000 13:47:00 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta2.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FO300IGH8I4EF@mta2.rcsntx.swbell.net> for FreeBSD-hackers@FreeBSD.ORG; Sun, 9 Jan 2000 15:46:53 -0600 (CST) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id PAA00532; Sun, 09 Jan 2000 15:47:11 -0600 (CST envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Sun, 09 Jan 2000 15:47:10 -0600 From: Chris Costello Subject: Re: moving CVS repository In-reply-to: <200001091839.LAA16606@mt.sri.com> To: Nate Williams Cc: Alexander Langer , Boris Popov , Wilko Bulte , FreeBSD hackers list Reply-To: chris@calldei.com Message-id: <20000109154710.A394@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <20000109124420.A60996@yedi.iaf.nl> <20000109140633.A3812@cichlids.cichlids.com> <200001091839.LAA16606@mt.sri.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 09, 2000, Nate Williams wrote: > find /local2/CVSfoo -name Root -print | fgrep CVS | > perl -pi -e 's#/local#/local2/#g;' ^^^^^ Perhaps in this space you meant to type ``xargs''? -- |Chris Costello |If you don't change your direction, you may end up where you were headed. `------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 16:16:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id CBB4A14A00 for ; Sun, 9 Jan 2000 16:16:43 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.10.0.Beta11/8.10.0.Beta6) with ESMTP id e0A0FQP07232; Sun, 9 Jan 2000 17:15:26 -0700 (MST) Message-Id: <200001100015.e0A0FQP07232@orthanc.ab.ca> To: nate@mt.sri.com (Nate Williams) Cc: Alexander Langer , Boris Popov , Wilko Bulte , FreeBSD hackers list Subject: Re: moving CVS repository In-reply-to: Your message of "Sun, 09 Jan 2000 11:39:31 MST." <200001091839.LAA16606@mt.sri.com> Date: Sun, 09 Jan 2000 17:15:25 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Nate" == Nate Williams writes: Nate> find /local2/CVSfoo -name Root -print | fgrep CVS | perl -pi Nate> -e 's#/local#/local2/#g;' Perl? Bah! (I wrote this to also handle a rename of our CVS server. Adjust as necessary.) #!/bin/sh for i in `find . -type d -name CVS -print`; do if [ -f $i/Root ] ; then echo ':kserver:cvs.example.org:/cvs' > $i/Root fi if [ -f $i/Repository ] ; then ed $i << _EOF %s;/usr/local/cvs/sendmail;/cvs/sendmail; w q _EOF fi done To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 9 21:32:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta3.snfc21.pbi.net (mta3.snfc21.pbi.net [206.13.28.141]) by hub.freebsd.org (Postfix) with ESMTP id 809AD14E7C for ; Sun, 9 Jan 2000 21:32:43 -0800 (PST) (envelope-from jazepeda@pacbell.net) Received: from zippy.dyn.ml.org ([207.214.149.199]) by mta3.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FO3001K0TZBY0@mta3.snfc21.pbi.net> for freebsd-hackers@FreeBSD.ORG; Sun, 9 Jan 2000 21:30:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zippy.dyn.ml.org (Postfix) with ESMTP id 0EB9791588; Sun, 09 Jan 2000 21:30:54 -0800 (PST) Date: Sun, 09 Jan 2000 21:30:54 -0800 (PST) From: Alex Zepeda Subject: Re: Cool little 100BaseTX switch - they're coming down in price In-reply-to: <386D66D4.B3DB5EB3@softweyr.com> To: Wes Peters Cc: freebsd-hackers@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 31 Dec 1999, Wes Peters wrote: > I have a good reason to revive this thread. I thought anyone who followed > this conversation might want to know that one of the switches we dicussed, > the Netgear FS-105, is on a special at CompUSA right now -- THROUGH TOMORROW. > The special is a $20 mail-in rebate, making the price of the switch $99.99 > in the CompUSA stores. [...] > If you're looking for a nice little 5-port 100Base-TX switch, this is a > good opportunity (if you have a CompUSA store nearby). Right now CompUSA has a 5 port Linksys 10/100 and a 5 port D-Link 10/100 switch on sale for $99. No rebates involved. I figured what the hell how bad could they be for a home network, and picked up one of the Linksys ones. Needless to say, paying with a check for one of these, sucks. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 5:32:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from urquell.pilsnet.sunet.se (urquell.pilsnet.sunet.se [192.36.125.77]) by hub.freebsd.org (Postfix) with ESMTP id CD21715AAB for ; Mon, 10 Jan 2000 05:27:55 -0800 (PST) (envelope-from carbon-unit-1@urquell.pilsnet.sunet.se) Received: (from bd@localhost) by urquell.pilsnet.sunet.se (8.9.1/8.9.1) id OAA10919; Mon, 10 Jan 2000 14:27:46 +0100 (CET) (envelope-from carbon-unit-1@urquell.pilsnet.sunet.se) X-Authentication-Warning: urquell.pilsnet.sunet.se: bd set sender to carbon-unit-1@urquell.pilsnet.sunet.se using -f To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: UTC time in crontabs References: <386D0B2C.8F29EDE3@newsguy.com> From: Bjorn Danielsson Date: 10 Jan 2000 14:27:46 +0100 In-Reply-To: "Daniel C. Sobral"'s message of "Sat, 01 Jan 2000 04:59:40 +0900" Message-ID: Lines: 20 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > Bjorn Danielsson wrote: > > > > I have made a small patch (about 10 lines of code) to "cron" that lets > > people choose between localtime and gmtime for their crontab entries. > > The choice is made depending on the setting of an environment variable > > in the crontab file. The cost is a factor 2 for the tiny amount of work > > that cron does when it checks all the crontab entries every minute. > > > > Any interest in this? > > I like it. My UTC patch is available at: http://urquell.pilsnet.sunet.se:8000/cron-utc-patch.txt -- Björn Danielsson KTHNOC / Swedish University Network (mail me for my real e-mail address) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 5:45:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cichlids.com (as15-195.rp-plus.de [149.221.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 84FF015907 for ; Mon, 10 Jan 2000 05:45:17 -0800 (PST) (envelope-from alex@cichlids.com) Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by cichlids.com (Postfix) with ESMTP id 0CC0DAB9E; Mon, 10 Jan 2000 14:44:45 +0100 (CET) Received: (from alex@localhost) by cichlids.cichlids.com (8.9.3/8.9.3) id TAA27056; Sun, 9 Jan 2000 19:47:23 +0100 (CET) (envelope-from alex) Date: Sun, 9 Jan 2000 19:47:23 +0100 From: Alexander Langer To: Nate Williams Cc: Boris Popov , Wilko Bulte , FreeBSD hackers list Subject: Re: moving CVS repository Message-ID: <20000109194723.A26968@cichlids.cichlids.com> References: <20000109124420.A60996@yedi.iaf.nl> <20000109140633.A3812@cichlids.cichlids.com> <200001091839.LAA16606@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001091839.LAA16606@mt.sri.com>; from nate@mt.sri.com on Sun, Jan 09, 2000 at 11:39:31AM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Nate Williams (nate@mt.sri.com): > Or even more paranoid and slightly shorter. ;) > find /local2/CVSfoo -name Root -print | fgrep CVS | > perl -pi -e 's#/local#/local2/#g;' Hehe, yes ;-) But, as bp mentioned already in IRC: find /path/to/checked/out/files/and/not/the/repository ;-) Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 6:34: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mushi.colo.neosoft.com (mushi.colo.neosoft.com [206.109.6.82]) by hub.freebsd.org (Postfix) with SMTP id D06C8150CD for ; Mon, 10 Jan 2000 06:33:58 -0800 (PST) (envelope-from peter@taronga.com) Received: (qmail 5393 invoked from network); 10 Jan 2000 14:33:56 -0000 Received: from citadel.in.taronga.com (10.0.0.43) by mushi.in.taronga.com with SMTP; 10 Jan 2000 14:33:56 -0000 Received: by citadel.in.taronga.com (Postfix, from userid 100) id CD93E32306; Mon, 10 Jan 2000 08:32:35 -0600 (CST) To: hackers@freebsd.org Subject: Project UDI? Message-Id: <20000110143235.CD93E32306@citadel.in.taronga.com> Date: Mon, 10 Jan 2000 08:32:35 -0600 (CST) From: peter@taronga.com (Peter da Silva) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anyone had a look at this? http://www.project-udi.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 9:42: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E661714C9B for ; Mon, 10 Jan 2000 09:41:57 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA00460; Mon, 10 Jan 2000 09:41:55 -0800 Date: Mon, 10 Jan 2000 09:41:44 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Peter da Silva Cc: hackers@FreeBSD.ORG Subject: Re: Project UDI? In-Reply-To: <20000110143235.CD93E32306@citadel.in.taronga.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, I've looked at it. It's a very bad idea. I know some of the people involved, and I spent a substantial portion of the early 90's running aroudn doing the DDI at Sun with the notion it would bring a grand interface for all Unices.... etc... I've seen many, many, efforts in this area. I believe that this is just the wrong thing, now. As someone who develops drivers for multiple platforms I should be interested in this, but I'm not. It's solving yesterday's problems today at tomorrow's prices. The differences between *BSD, Solaris, Linux, AIX and NT for doing drivers is really not a substantial leaf node driver problem as most of these efforts try to address- all of these platforms offer more or less the same services to drivers (mapping registers, thread synchronization of varying kinds, memory allocation. Careful design and modern compilers have made code sharing between all of these platforms with macros && inlines both relatively straightforward and not that inefficient. The real issue then becomes both nexus driver issues and data structure and data movement issues- in this case, IIRC, UDI takes more the approach NT takes in that there are implicit marshalling/demarshalling domains between layers. When you have a huge single product line where you have multiple disjoint variant bus interconnect pieces that can plug together that require substantially different device methods, this approach is cool- this is why the DKI/DDI for sparc was such a great idea- you could have massive main and secondary I/O bus variation and both leaf and a large number of nexus drivers don't have to change- very cool for binary distributions. However, the world is a lot different now. There are a greatly reduced number of different types of hardware that have to programmed differently, and those that would otherwise need to tend to have this solved by h/w engineers who don't want to wait 2 years for the software to be written. The world is also moving to an open-source model so VARs needing binary plugin types of systems is somewhat less critical than it used to be (don't even *begin* to mention win32/NT being a binary plugin model as everyone and his mother has to have separate distributions for each Service Pack release). So the need for such complexity to solve hardware interconnect issues is a helluva lot less than it used to be. The other problem- data structuring- is not really a solvable problem. If your network stack and drivers works in units of mbufs, it's going to have to go through all sorts of contortions for the same driver to do streams as well. Note that both mbufs && streams stacks can exist in the same kernel, so maybe this isn't as good an example as it could be, but I think we'd all agree that the efforts of data structure/movement encapsulation for a single driver to cover multiple systems could be tough. There was a paper at the last Usenix about this (someone help me out here and dig out the reference)... That's my .02 cents..... On Mon, 10 Jan 2000, Peter da Silva wrote: > > Anyone had a look at this? > > http://www.project-udi.org/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 9:55:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mushi.colo.neosoft.com (mushi.colo.neosoft.com [206.109.6.82]) by hub.freebsd.org (Postfix) with SMTP id E446714C9B for ; Mon, 10 Jan 2000 09:55:20 -0800 (PST) (envelope-from peter@taronga.com) Received: (qmail 13649 invoked from network); 10 Jan 2000 17:55:10 -0000 Received: from citadel.in.taronga.com (10.0.0.43) by mushi.in.taronga.com with SMTP; 10 Jan 2000 17:55:10 -0000 Received: by citadel.in.taronga.com (Postfix, from userid 100) id 7557B32306; Mon, 10 Jan 2000 11:54:19 -0600 (CST) Subject: Re: Project UDI? In-Reply-To: from Matthew Jacob at "Jan 10, 2000 09:41:44 am" To: mjacob@feral.com Date: Mon, 10 Jan 2000 11:54:19 -0600 (CST) Cc: peter@taronga.com (Peter da Silva), hackers@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 Message-Id: <20000110175419.7557B32306@citadel.in.taronga.com> From: peter@taronga.com (Peter da Silva) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Yes, I've looked at it. It's a very bad idea. I know some of the people > involved, and I spent a substantial portion of the early 90's running > aroudn doing the DDI at Sun with the notion it would bring a grand > interface for all Unices.... etc... I've seen many, many, efforts in this > area. Hmmm... I didn't see any mention of FreeBSD on the page, so I thought it'd be worthwhile raising a flag. It looked at first glance sort of like an upgraded version of Intel's RMX-86-based UDI stuff from the '80s. I don't recall that being really horrible, but I'll take your word for it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 9:57:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4BD5B152F8 for ; Mon, 10 Jan 2000 09:57:19 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA00508; Mon, 10 Jan 2000 09:57:25 -0800 Date: Mon, 10 Jan 2000 09:57:14 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Peter da Silva Cc: hackers@FreeBSD.ORG Subject: Re: Project UDI? In-Reply-To: <20000110175419.7557B32306@citadel.in.taronga.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith has been interested in getting FreeBSD involved in this. My attitude has been "Over my dead body".... (you have to watch out saying things like that- someone might respond with, "Uh, okay....") On Mon, 10 Jan 2000, Peter da Silva wrote: > > Yes, I've looked at it. It's a very bad idea. I know some of the people > > involved, and I spent a substantial portion of the early 90's running > > aroudn doing the DDI at Sun with the notion it would bring a grand > > interface for all Unices.... etc... I've seen many, many, efforts in this > > area. > > Hmmm... I didn't see any mention of FreeBSD on the page, so I thought it'd be > worthwhile raising a flag. It looked at first glance sort of like an upgraded > version of Intel's RMX-86-based UDI stuff from the '80s. I don't recall that > being really horrible, but I'll take your word for it. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 10:13:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from boromir.vpop.net (dns1.vpop.net [206.117.147.2]) by hub.freebsd.org (Postfix) with ESMTP id 1A6BB14D21 for ; Mon, 10 Jan 2000 10:13:37 -0800 (PST) (envelope-from mreimer@vpop.net) Received: from vpop.net (bilbo.vpop.net [216.160.82.65]) by boromir.vpop.net (8.9.1/8.9.1) with ESMTP id KAA23609 for ; Mon, 10 Jan 2000 10:13:35 -0800 (PST) Message-ID: <387A2158.F2FE991A@vpop.net> Date: Mon, 10 Jan 2000 10:13:44 -0800 From: Matthew Reimer Organization: VPOP Technologies, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Cool little 100BaseTX switch - they're coming down in price References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Netgear FS105 five-port 100BaseTX switch is $84.95 at buy.com (http://www.buy.com/comp/product.asp?SKU=10221960), though they are back-ordered. Matt Alex Zepeda wrote: > > On Fri, 31 Dec 1999, Wes Peters wrote: > > > I have a good reason to revive this thread. I thought anyone who followed > > this conversation might want to know that one of the switches we dicussed, > > the Netgear FS-105, is on a special at CompUSA right now -- THROUGH TOMORROW. > > The special is a $20 mail-in rebate, making the price of the switch $99.99 > > in the CompUSA stores. > [...] > > If you're looking for a nice little 5-port 100Base-TX switch, this is a > > good opportunity (if you have a CompUSA store nearby). > > Right now CompUSA has a 5 port Linksys 10/100 and a 5 port D-Link 10/100 > switch on sale for $99. No rebates involved. I figured what the hell how > bad could they be for a home network, and picked up one of the Linksys > ones. > > Needless to say, paying with a check for one of these, sucks. > > - alex > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 10:52:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 76E211519B for ; Mon, 10 Jan 2000 10:52:42 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id KAA16744; Mon, 10 Jan 2000 10:52:03 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id KAA17467; Mon, 10 Jan 2000 10:52:03 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id KAA13471; Mon, 10 Jan 2000 10:50:46 -0800 (PST) Message-ID: <387A2B20.34737F87@softweyr.com> Date: Mon, 10 Jan 2000 11:55:28 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: Peter da Silva , hackers@freebsd.org Subject: Re: Project UDI? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > Mike Smith has been interested in getting FreeBSD involved in this. My > attitude has been "Over my dead body".... (you have to watch out saying > things like that- someone might respond with, "Uh, okay....") Uh, okay. Anything to help Mike out. ;^) -- "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-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 11: 7:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 3ECDE15718 for ; Mon, 10 Jan 2000 11:07:17 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.10.0.Beta11/8.10.0.Beta6) with ESMTP id e0AJ75P10036; Mon, 10 Jan 2000 12:07:05 -0700 (MST) Message-Id: <200001101907.e0AJ75P10036@orthanc.ab.ca> To: Kazutaka YOKOTA Cc: freebsd-hackers@freebsd.org Subject: Inspiron 7000 ALT/Windows keys In-reply-to: Your message of "Sun, 09 Jan 2000 13:06:15 +0900." <200001090406.NAA07901@zodiac.mech.utsunomiya-u.ac.jp> Date: Mon, 10 Jan 2000 12:07:01 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Kazutaka" == Kazutaka YOKOTA writes: Kazutaka> In what environment do you have the problem? It's coming from the keyboard drivers itself. (I.e. I see the behaviour when logged in on ttyv*.) Kazutaka> If you Kazutaka> have the problem in the X session, it must be the X Kazutaka> server's key mapping which is somewhat wrong. I see the same behaviour in X. Kazutaka> If you have the problem in the text console, tell me Kazutaka> which keymap file in /usr/share/syscons/keymaps you are Kazutaka> using, or dump the keymap by running: I see the same thing with the default keymap and the us.emacs.kbd map. Kazutaka> kbdcontrol -d Kazutaka> in the text console and send it to me for diagnosis. I'll send this seperately. Kazutaka> On more thing. You mention the "standard left ALT Kazutaka> behavior". What do you exactly mean by that? Set the high-bit on the character. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 11:41:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E015514F73 for ; Mon, 10 Jan 2000 11:41:43 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA32067; Mon, 10 Jan 2000 12:41:42 -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 MAA11711; Mon, 10 Jan 2000 12:41:50 -0700 (MST) Message-Id: <200001101941.MAA11711@harmony.village.org> To: Alexander Langer Subject: Re: moving CVS repository Cc: FreeBSD hackers list In-reply-to: Your message of "Sun, 09 Jan 2000 19:47:23 +0100." <20000109194723.A26968@cichlids.cichlids.com> References: <20000109194723.A26968@cichlids.cichlids.com> <20000109124420.A60996@yedi.iaf.nl> <20000109140633.A3812@cichlids.cichlids.com> <200001091839.LAA16606@mt.sri.com> Date: Mon, 10 Jan 2000 12:41:50 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000109194723.A26968@cichlids.cichlids.com> Alexander Langer writes: : Thus spake Nate Williams (nate@mt.sri.com): : > Or even more paranoid and slightly shorter. ;) : > find /local2/CVSfoo -name Root -print | fgrep CVS | : > perl -pi -e 's#/local#/local2/#g;' Yes, but older Repository files must also be frobbed. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 12:51:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id EAE9214C27 for ; Mon, 10 Jan 2000 12:51:16 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA00910; Mon, 10 Jan 2000 12:57:56 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001102057.MAA00910@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: peter@taronga.com (Peter da Silva) Cc: hackers@freebsd.org Subject: Re: Project UDI? In-reply-to: Your message of "Mon, 10 Jan 2000 08:32:35 CST." <20000110143235.CD93E32306@citadel.in.taronga.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jan 2000 12:57:56 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Anyone had a look at this? > > http://www.project-udi.org/ Yes; I've been talking with various of the UDI folks off and on for several years now. It's an interesting project, and may offer us a canned solution for our next major driver architecture upheaval. At the moment, however, the big wait is for their planned open-source reference implementation, due out in the next few months. I think that everyone would agree that we want to see the architecture in action in a form that we can take apart and look carefully at before getting too carried away one way or the other. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 13: 6:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 8ADD615364 for ; Mon, 10 Jan 2000 13:06:30 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA01143; Mon, 10 Jan 2000 13:13:06 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001102113.NAA01143@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: Peter da Silva , hackers@FreeBSD.ORG Subject: Re: Project UDI? In-reply-to: Your message of "Mon, 10 Jan 2000 09:57:14 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jan 2000 13:13:06 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As I hope I conveyed in my initial reply to Peter; I think the UDI architecture is interesting, and may have something for us to learn from next time we feel the need to restructure our driver architecture. UDI's real strengths are likely to show up as we try to improve our multiprocessor performance if anywhere. On the other hand, Matt speaks from a lot of experience, and this is why I'm keen to see what UDI actually translates to in terms of code and performance. Until that time the issue is more or less deadlocked; the UDI folks know that we're cautiously interested, but as I told Mark Evanson late last year, we really need something more substantial to convince us that we should abandon our _very_ thin driver architecture for one that's at least an order of magnitude more complex. > Mike Smith has been interested in getting FreeBSD involved in this. My > attitude has been "Over my dead body".... (you have to watch out saying > things like that- someone might respond with, "Uh, okay....") > > On Mon, 10 Jan 2000, Peter da Silva wrote: > > > > Yes, I've looked at it. It's a very bad idea. I know some of the people > > > involved, and I spent a substantial portion of the early 90's running > > > aroudn doing the DDI at Sun with the notion it would bring a grand > > > interface for all Unices.... etc... I've seen many, many, efforts in this > > > area. > > > > Hmmm... I didn't see any mention of FreeBSD on the page, so I thought it'd be > > worthwhile raising a flag. It looked at first glance sort of like an upgraded > > version of Intel's RMX-86-based UDI stuff from the '80s. I don't recall that > > being really horrible, but I'll take your word for it. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 13:30:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta4.snfc21.pbi.net (mta4.snfc21.pbi.net [206.13.28.142]) by hub.freebsd.org (Postfix) with ESMTP id 1B68C14BE4 for ; Mon, 10 Jan 2000 13:30:19 -0800 (PST) (envelope-from jazepeda@pacbell.net) Received: from zippy.dyn.ml.org ([207.214.116.5]) by mta4.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FO500J9L25OWR@mta4.snfc21.pbi.net> for freebsd-hackers@FreeBSD.ORG; Mon, 10 Jan 2000 13:25:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zippy.dyn.ml.org (Postfix) with ESMTP id 45CE391588; Mon, 10 Jan 2000 13:25:05 -0800 (PST) Date: Mon, 10 Jan 2000 13:25:05 -0800 (PST) From: Alex Zepeda Subject: Re: Cool little 100BaseTX switch - they're coming down in price In-reply-to: <387A2158.F2FE991A@vpop.net> To: Matthew Reimer Cc: freebsd-hackers@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000, Matthew Reimer wrote: > The Netgear FS105 five-port 100BaseTX switch is $84.95 at buy.com > (http://www.buy.com/comp/product.asp?SKU=10221960), though they are > back-ordered. Sure, but these were in stock. :^) - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 13:39:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta2.snfc21.pbi.net (mta2.snfc21.pbi.net [206.13.28.123]) by hub.freebsd.org (Postfix) with ESMTP id 9BFCD14BC8 for ; Mon, 10 Jan 2000 13:39:32 -0800 (PST) (envelope-from jazepeda@pacbell.net) Received: from zippy.dyn.ml.org ([207.214.116.5]) by mta2.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FO500BWX28KKM@mta2.snfc21.pbi.net> for freebsd-hackers@FreeBSD.ORG; Mon, 10 Jan 2000 13:26:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zippy.dyn.ml.org (Postfix) with ESMTP id B9C3F91588; Mon, 10 Jan 2000 13:26:51 -0800 (PST) Date: Mon, 10 Jan 2000 13:26:51 -0800 (PST) From: Alex Zepeda Subject: Re: Cool little 100BaseTX switch - they're coming down in price In-reply-to: <387A2158.F2FE991A@vpop.net> To: Matthew Reimer Cc: freebsd-hackers@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000, Matthew Reimer wrote: > The Netgear FS105 five-port 100BaseTX switch is $84.95 at buy.com > (http://www.buy.com/comp/product.asp?SKU=10221960), though they are > back-ordered. And I hate to reply twice, but the switch I bought (EZXS55W) is listed at $76.95. Hmm. :) - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 13:48:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from news.IAEhv.nl (news.IAE.nl [194.151.64.4]) by hub.freebsd.org (Postfix) with ESMTP id B581B15082 for ; Mon, 10 Jan 2000 13:48:54 -0800 (PST) (envelope-from Arjan.deVet@adv.iae.nl) Received: (from uucp@localhost) by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id WAA08581 for freebsd-hackers@FreeBSD.ORG; Mon, 10 Jan 2000 22:48:53 +0100 (MET) Received: by adv.iae.nl (Postfix, from userid 100) id CE6A3230E; Mon, 10 Jan 2000 22:48:29 +0100 (CET) Date: Mon, 10 Jan 2000 22:48:29 +0100 To: freebsd-hackers@FreeBSD.ORG Subject: Re: AIO was Re: Kernel threads Message-ID: <20000110224829.A24711@adv.iae.nl> References: <20000106095248.A10302@adv.iae.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from cmsedore@mailbox.syr.edu on Thu, Jan 06, 2000 at 02:42:44PM -0500 From: Arjan.deVet@adv.iae.nl (Arjan de Vet) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Sedore wrote: >On Thu, 6 Jan 2000, Arjan de Vet wrote: > >> Jordan K. Hubbard wrote: >> >> >This is very interesting data and I was just wondering about the >> >actual state of functionality in our AIO code just the other day, >> >oddly enough. Does anyone have a PR# for the mentioned patches? >> >> kern/12053 >> >> A Dec 16 version of the patch can be found at: >> >> http://tfeed.maxwell.syr.edu/aio-diff >> >> They won't apply cleanly because some new syscalls have been added. > >There may be another PR related too (although a quick search a few seconds >ago didn't show it)--this patch set also fixes a problem where signals >were not posted for aio completion under certain circumstances (the code >just wasn't there before). > >Just found the PR--kern/13075 Now that we've found the two PRs and a reasonable up to date version of the patch are these changes going to be committed? Or are they still under review? Just curious ;-). Arjan -- Arjan de Vet, Eindhoven, The Netherlands URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 13:51:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by hub.freebsd.org (Postfix) with ESMTP id 2CDE114BC8 for ; Mon, 10 Jan 2000 13:51:00 -0800 (PST) (envelope-from ak@freenet.co.uk) Received: from freenet.co.uk (RAS2-p27.rlz.netvision.net.il [62.0.168.151]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id XAA16255; Mon, 10 Jan 2000 23:50:02 +0200 (IST) Message-ID: <387A54D1.218A00A7@freenet.co.uk> Date: Mon, 10 Jan 2000 21:53:21 +0000 From: Alex X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters Cc: mjacob@feral.com, Peter da Silva , freebsd-hackers@freebsd.org Subject: Re: Project UDI? References: <387A2B20.34737F87@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > Matthew Jacob wrote: > > > > Mike Smith has been interested in getting FreeBSD involved in this. My > > attitude has been "Over my dead body".... (you have to watch out saying > > things like that- someone might respond with, "Uh, okay....") > > Uh, okay. Anything to help Mike out. ;^) "Dead body found in the park - detectives baffled" "FreeBSD joins UDI project" (DaemonNews headlines) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 13:59:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id C122114F61 for ; Mon, 10 Jan 2000 13:59:06 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 32570 invoked by uid 1001); 10 Jan 2000 21:57:53 -0000 Date: Mon, 10 Jan 2000 13:57:53 -0800 From: Jason Evans To: Arjan de Vet Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: AIO was Re: Kernel threads Message-ID: <20000110135752.C4938@sturm.canonware.com> References: <20000106095248.A10302@adv.iae.nl> <20000110224829.A24711@adv.iae.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000110224829.A24711@adv.iae.nl>; from Arjan.deVet@adv.iae.nl on Mon, Jan 10, 2000 at 10:48:29PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 10, 2000 at 10:48:29PM +0100, Arjan de Vet wrote: > Christopher Sedore wrote: > > >On Thu, 6 Jan 2000, Arjan de Vet wrote: > > > >> Jordan K. Hubbard wrote: > >> > >> >This is very interesting data and I was just wondering about the > >> >actual state of functionality in our AIO code just the other day, > >> >oddly enough. Does anyone have a PR# for the mentioned patches? > >> > >> kern/12053 > >> > >> A Dec 16 version of the patch can be found at: > >> > >> http://tfeed.maxwell.syr.edu/aio-diff > >> > >> They won't apply cleanly because some new syscalls have been added. > > > >There may be another PR related too (although a quick search a few seconds > >ago didn't show it)--this patch set also fixes a problem where signals > >were not posted for aio completion under certain circumstances (the code > >just wasn't there before). > > > >Just found the PR--kern/13075 > > Now that we've found the two PRs and a reasonable up to date version of > the patch are these changes going to be committed? Or are they still > under review? Just curious ;-). I'm reviewing them right now. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 14:20: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EFC4D15361; Mon, 10 Jan 2000 14:20:01 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA01333; Mon, 10 Jan 2000 14:20:11 -0800 Date: Mon, 10 Jan 2000 14:20:00 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: Peter da Silva , hackers@FreeBSD.ORG Subject: Re: Project UDI? In-Reply-To: <200001102113.NAA01143@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > convince us that we should abandon our _very_ thin driver architecture > for one that's at least an order of magnitude more complex. Thin is not necessarily bad as it leaves a lot of room to maneuver. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 14:41:41 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6A4F91539C for ; Mon, 10 Jan 2000 14:41:36 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA01401; Mon, 10 Jan 2000 14:41:27 -0800 Date: Mon, 10 Jan 2000 14:41:17 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Alex Cc: Wes Peters , Peter da Silva , freebsd-hackers@freebsd.org Subject: Re: Project UDI? In-Reply-To: <387A54D1.218A00A7@freenet.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000, Alex wrote: > Wes Peters wrote: > > > > Matthew Jacob wrote: > > > > > > Mike Smith has been interested in getting FreeBSD involved in this. My > > > attitude has been "Over my dead body".... (you have to watch out saying > > > things like that- someone might respond with, "Uh, okay....") > > > > Uh, okay. Anything to help Mike out. ;^) > > > "Dead body found in the park - detectives baffled" > > "FreeBSD joins UDI project" Well, basically that'd be it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 15:22:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 3AE3814D64 for ; Mon, 10 Jan 2000 15:22:46 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 291; Mon, 10 Jan 2000 15:17:59 -0800 Message-ID: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> From: "Scott Hess" To: , Subject: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Date: Mon, 10 Jan 2000 15:20:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Recently I was tasked to find a way to scale up our MYSQL server, running MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution, and found that with 6 disks in a RAID5 configuration, the system was only perhaps 30% faster than when running on a single disk. [The 6 disks in the RAID5 are the same model as the single-disk test I was comparing against.] Experimentation determined that pthreads was the problem. FreeBSD's implementation of pthreads using a select() loop, and select() always says that disk I/O is ready to proceed, and disk I/O never return EWOULDBLOCK. Essentially, pthreads was serializing the MYSQL read() requests, and if the dataset exceeds memory size, performance becomes entirely seek bound. I've implemented a rough fix, which is to rfork() processes which I label "iothreads" to handle the disk I/O. The parent process running pthreads has a socketpair() to each of the iothreads. The iothreads wait for requests on the socketpair, and since socketpairs can block, pthreads can handle them efficiently. This essentially allows me to turn blocking disk I/O calls into non-blocking calls. Having multiple pending seeks turns out to be a huge win for MYSQL, allowing it to scale much better as disks are added to the RAID5 array. Unfortunately, I'm concerned about using this code in production, because it needs a fair amount of cleanup to handle signals and administrative functions correctly. For this reason and others, I'm starting a project to move it into the pthreads library itself. Before I embark on that effort, I have a couple questions: 1) Does this seem like a reasonable approach? [It _works_, and well. But it tastes strongly of hack.] 2) Does anyone have suggestions for a solution that will be cleaner and won't take man-months to implement? [Which is the redeeming quality of what I've got - it took me two days to zero in on a very workable solution.] 3) Is anyone working on something I might leverage off of in this area? [For instance, a select()-based interface to async I/O? Or support for blocking disk I/O in select() and read()?] 4) Is there anyone willing to commit to testing my modified pthreads library against MYSQL? [I'll be stress testing it quite heavily, of course. It would probably also be testable against Squid with async I/O and multithreaded Apache 2.0.] Thanks, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 15:39:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3380F15343 for ; Mon, 10 Jan 2000 15:39:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA31453; Mon, 10 Jan 2000 15:36:23 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Jan 2000 15:36:23 -0800 (PST) From: Matthew Dillon Message-Id: <200001102336.PAA31453@apollo.backplane.com> To: "Scott Hess" Cc: , Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Recently I was tasked to find a way to scale up our MYSQL server, running :MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution, :and found that with 6 disks in a RAID5 configuration, the system was only :perhaps 30% faster than when running on a single disk. [The 6 disks in the :RAID5 are the same model as the single-disk test I was comparing against.] : :Experimentation determined that pthreads was the problem. FreeBSD's :implementation of pthreads using a select() loop, and select() always says :that disk I/O is ready to proceed, and disk I/O never return EWOULDBLOCK. :Essentially, pthreads was serializing the MYSQL read() requests, and if the :dataset exceeds memory size, performance becomes entirely seek bound. : :I've implemented a rough fix, which is to rfork() processes which I label :... :Thanks, :scott A better solution may be to shift to FreeBSD4.0 (when it's released - wait for it to become good and stable), and then use the native linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. The linuxthreads port is at least four times faster and, since it uses rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements rfork(...RF_MEM) you can only use it with FreeBSD-4.x (or am I wrong there?). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 15:45:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id AD94A14F47 for ; Mon, 10 Jan 2000 15:45:26 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 32946 invoked by uid 1001); 10 Jan 2000 23:39:17 -0000 From: jasone@canonware.com Date: Mon, 10 Jan 2000 15:39:17 -0800 To: Scott Hess Cc: freebsd-hackers@freebsd.org, developer@lists.mysql.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Message-ID: <20000110153917.D4938@sturm.canonware.com> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i fFrom: Jason Evans In-Reply-To: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com>; from scott@avantgo.com on Mon, Jan 10, 2000 at 03:20:38PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 10, 2000 at 03:20:38PM -0800, Scott Hess wrote: > I've implemented a rough fix, which is to rfork() processes which I label > "iothreads" to handle the disk I/O. The parent process running pthreads > has a socketpair() to each of the iothreads. The iothreads wait for > requests on the socketpair, and since socketpairs can block, pthreads can > handle them efficiently. This essentially allows me to turn blocking disk > I/O calls into non-blocking calls. Having multiple pending seeks turns out > to be a huge win for MYSQL, allowing it to scale much better as disks are > added to the RAID5 array. > > Unfortunately, I'm concerned about using this code in production, because > it needs a fair amount of cleanup to handle signals and administrative > functions correctly. For this reason and others, I'm starting a project to > move it into the pthreads library itself. Before I embark on that effort, > I have a couple questions: > > 1) Does this seem like a reasonable approach? [It _works_, and well. But > it tastes strongly of hack.] I'm not very fond of this approach to the problem, though it can work, as you note. Asynchronous I/O is in my opinion a much cleaner solution. > 2) Does anyone have suggestions for a solution that will be cleaner and > won't take man-months to implement? [Which is the redeeming quality of > what I've got - it took me two days to zero in on a very workable > solution.] Have you tried the linuxthreads port lately? With linuxthreads, each thread is an rfork()ed process, which means that blocking on file I/O only blocks the thread that attempts the I/O. There are various advantages/disadvantages between libc_r and linuxthreads, but you may find linuxthreads to meet your needs at the moment. > 3) Is anyone working on something I might leverage off of in this area? > [For instance, a select()-based interface to async I/O? Or support for > blocking disk I/O in select() and read()?] Though not ideal, it seems to me that using asynchronous I/O will work reasonably well inside libc_r. If there weren't plans to build a much more scalable threads library than what we currently have, this modification would be high on my priority list. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 16:11:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id B9464153B7 for ; Mon, 10 Jan 2000 16:11:10 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id QAA22261; Mon, 10 Jan 2000 16:08:39 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id QAA67821; Mon, 10 Jan 2000 16:08:38 -0800 (PST) (envelope-from jdp@polstra.com) Date: Mon, 10 Jan 2000 16:08:38 -0800 (PST) Message-Id: <200001110008.QAA67821@vashon.polstra.com> To: scott@avantgo.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. In-Reply-To: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com>, Scott Hess wrote: > > I've implemented a rough fix, which is to rfork() processes which I label > "iothreads" to handle the disk I/O. The parent process running pthreads > has a socketpair() to each of the iothreads. The iothreads wait for > requests on the socketpair, and since socketpairs can block, pthreads can > handle them efficiently. ... > Unfortunately, I'm concerned about using this code in production, because > it needs a fair amount of cleanup to handle signals and administrative > functions correctly. For this reason and others, I'm starting a project to > move it into the pthreads library itself. Before I embark on that effort, > I have a couple questions: > > 1) Does this seem like a reasonable approach? [It _works_, and well. But > it tastes strongly of hack.] I think the approach is reasonable, but it shouldn't go into the pthreads library. It's too heavyweight for that -- too much machinery when your average client just wants to read from a file. Pthreads will eventually handle disk I/O better than it does now, using aio calls or some other technique. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 16:23:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pogo.caustic.org (pogo.caustic.org [208.44.193.69]) by hub.freebsd.org (Postfix) with ESMTP id 276DD1531A for ; Mon, 10 Jan 2000 16:23:42 -0800 (PST) (envelope-from jan@caustic.org) Received: from localhost (jan@localhost) by pogo.caustic.org (8.9.3/ignatz) with ESMTP id QAA49261; Mon, 10 Jan 2000 16:23:42 -0800 (PST) Date: Mon, 10 Jan 2000 16:23:42 -0800 (PST) From: "f.johan.beisser" To: Alex Cc: Wes Peters , mjacob@feral.com, Peter da Silva , freebsd-hackers@FreeBSD.ORG Subject: Re: Project UDI? In-Reply-To: <387A54D1.218A00A7@freenet.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000, Alex wrote: > Wes Peters wrote: > > > > Matthew Jacob wrote: > > > > > > Mike Smith has been interested in getting FreeBSD involved in this. My > > > attitude has been "Over my dead body".... (you have to watch out saying > > > things like that- someone might respond with, "Uh, okay....") > > > > Uh, okay. Anything to help Mike out. ;^) > > > "Dead body found in the park - detectives baffled" > > "FreeBSD joins UDI project" > > (DaemonNews headlines) isn't this the reason for ESRs "Geeks With Guns" outings? -- jan +-----// f. johan beisser //------------------------------+ email: jan[at]caustic.org web: http://www.caustic.org/~jan "knowledge is power. power corrupts. study hard, be evil." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 16:25:55 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id 05C7F14F05 for ; Mon, 10 Jan 2000 16:25:46 -0800 (PST) (envelope-from patrykz@ilion.eu.org) Received: from mycenae.ilion.eu.org (localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.3/8.9.3) with ESMTP id LAA31411; Tue, 11 Jan 2000 11:25:37 +1100 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <200001110025.LAA31411@mycenae.ilion.eu.org> To: "Scott Hess" Cc: freebsd-hackers@FreeBSD.ORG, developer@lists.mysql.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. In-reply-to: Your message of "Mon, 10 Jan 2000 15:20:38 -0800." <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> Date: Tue, 11 Jan 2000 11:25:35 +1100 From: Patryk Zadarnowski Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Recently I was tasked to find a way to scale up our MYSQL server, running > MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution, > and found that with 6 disks in a RAID5 configuration, the system was only > perhaps 30% faster than when running on a single disk. [The 6 disks in the > RAID5 are the same model as the single-disk test I was comparing against.] > > Experimentation determined that pthreads was the problem. FreeBSD's > implementation of pthreads using a select() loop, and select() always says > that disk I/O is ready to proceed, and disk I/O never return EWOULDBLOCK. > Essentially, pthreads was serializing the MYSQL read() requests, and if the > dataset exceeds memory size, performance becomes entirely seek bound. > > I've implemented a rough fix, which is to rfork() processes which I label > "iothreads" to handle the disk I/O. The parent process running pthreads > has a socketpair() to each of the iothreads. The iothreads wait for > requests on the socketpair, and since socketpairs can block, pthreads can > handle them efficiently. This essentially allows me to turn blocking disk > I/O calls into non-blocking calls. Having multiple pending seeks turns out > to be a huge win for MYSQL, allowing it to scale much better as disks are > added to the RAID5 array. > > Unfortunately, I'm concerned about using this code in production, because > it needs a fair amount of cleanup to handle signals and administrative > functions correctly. For this reason and others, I'm starting a project to > move it into the pthreads library itself. Before I embark on that effort, > I have a couple questions: > > 1) Does this seem like a reasonable approach? [It _works_, and well. But > it tastes strongly of hack.] > > 2) Does anyone have suggestions for a solution that will be cleaner and > won't take man-months to implement? [Which is the redeeming quality of > what I've got - it took me two days to zero in on a very workable > solution.] > > 3) Is anyone working on something I might leverage off of in this area? > [For instance, a select()-based interface to async I/O? Or support for > blocking disk I/O in select() and read()?] > > 4) Is there anyone willing to commit to testing my modified pthreads > library against MYSQL? [I'll be stress testing it quite heavily, of > course. It would probably also be testable against Squid with async I/O > and multithreaded Apache 2.0.] I'm no expert on pthreads, but, if you decide to proceed with implementing a mixed user-land/rfork pthread implementation, may I suggest that you implement is through POSIX pthread_attr_setscope() interfaces instead of some local extension. pthread_attr_setscope() sounds like a portable interface to precisely what you're trying to achieve. Pat. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 16:29:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 6215A14D9F for ; Mon, 10 Jan 2000 16:29:45 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 250; Mon, 10 Jan 2000 15:52:03 -0800 Message-ID: <1b0e01bf5bc6$10cc9b40$1e80000a@avantgo.com> From: "Scott Hess" To: Cc: , References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> <20000110153917.D4938@sturm.canonware.com> Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Date: Mon, 10 Jan 2000 15:54:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG wrote: > > 2) Does anyone have suggestions for a solution that will be cleaner and > > won't take man-months to implement? [Which is the redeeming quality of > > what I've got - it took me two days to zero in on a very workable > > solution.] > > Have you tried the linuxthreads port lately? With linuxthreads, each > thread is an rfork()ed process, which means that blocking on file I/O only > blocks the thread that attempts the I/O. There are various > advantages/disadvantages between libc_r and linuxthreads, but you may find > linuxthreads to meet your needs at the moment. That's being tested in parallel. The main issue with LinuxThreads is that we'd go from running ~25 processes on this server to running ~800. > > 3) Is anyone working on something I might leverage off of in this area? > > [For instance, a select()-based interface to async I/O? Or support for > > blocking disk I/O in select() and read()?] > > Though not ideal, it seems to me that using asynchronous I/O will work > reasonably well inside libc_r. If there weren't plans to build a much more > scalable threads library than what we currently have, this modification > would be high on my priority list. I've been reviewing the async I/O stuff, but as far as I can see you can do all async I/O and use aio_suspend(), or do all select-based I/O, but you can't do both. libc_r is implemented around select-based I/O, so if an aio_read() is dispatched, how do you catch completion? [The only way I've thought of thus far would be to have a signal raised at completion, resulting in tens of thousands of signals per second in this case, which seems pretty harsh. Even so, I'm still thinking about this option.] Thanks, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 16:38:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id ED439153D7 for ; Mon, 10 Jan 2000 16:38:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA32246; Mon, 10 Jan 2000 16:38:06 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Jan 2000 16:38:06 -0800 (PST) From: Matthew Dillon Message-Id: <200001110038.QAA32246@apollo.backplane.com> To: "Scott Hess" Cc: , , Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> <20000110153917.D4938@sturm.canonware.com> <1b0e01bf5bc6$10cc9b40$1e80000a@avantgo.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :find :> linuxthreads to meet your needs at the moment. : :That's being tested in parallel. The main issue with LinuxThreads is that :we'd go from running ~25 processes on this server to running ~800. Yes, but they are rfork(RF_MEM)'d processes - they share a lot of context between themselves including their page tables so if you up the kernel resources it should work reasonably well. It isn't the best solution, but it's a pretty good temporary solution. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 16:46:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 66DDE153BE for ; Mon, 10 Jan 2000 16:46:00 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id RAA27032; Mon, 10 Jan 2000 17:08:22 -0800 (PST) Date: Mon, 10 Jan 2000 17:08:22 -0800 From: Alfred Perlstein To: Matthew Dillon Cc: Scott Hess , freebsd-hackers@FreeBSD.ORG, developer@lists.mysql.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Message-ID: <20000110170822.J9397@fw.wintelcom.net> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> <200001102336.PAA31453@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001102336.PAA31453@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Jan 10, 2000 at 03:36:23PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Dillon [000110 16:04] wrote: > :Recently I was tasked to find a way to scale up our MYSQL server, running > :MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution, > :and found that with 6 disks in a RAID5 configuration, the system was only > :perhaps 30% faster than when running on a single disk. [The 6 disks in the > :RAID5 are the same model as the single-disk test I was comparing against.] > : > :Experimentation determined that pthreads was the problem. FreeBSD's > :implementation of pthreads using a select() loop, and select() always says > :that disk I/O is ready to proceed, and disk I/O never return EWOULDBLOCK. > :Essentially, pthreads was serializing the MYSQL read() requests, and if the > :dataset exceeds memory size, performance becomes entirely seek bound. > : > :I've implemented a rough fix, which is to rfork() processes which I label > :... > :Thanks, > :scott > > A better solution may be to shift to FreeBSD4.0 (when it's released - > wait for it to become good and stable), and then use the native > linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. > > The linuxthreads port is at least four times faster and, since it uses > rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements > rfork(...RF_MEM) you can only use it with FreeBSD-4.x (or am I wrong > there?). I'm pretty sure RF_MEM doesn't work in 3.x with SMP, under UP it should work fine. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 17:19:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id BD89114F77 for ; Mon, 10 Jan 2000 17:19:14 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id TAA05631; Mon, 10 Jan 2000 19:19:05 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Mon, 10 Jan 2000 19:19:05 -0600 (CST) From: Chris Dillon To: Scott Hess Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. In-Reply-To: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000, Scott Hess wrote: > 4) Is there anyone willing to commit to testing my modified pthreads > library against MYSQL? [I'll be stress testing it quite heavily, of > course. It would probably also be testable against Squid with async I/O > and multithreaded Apache 2.0.] I'm willing to test this on Squid 2.2STABLE5 with async I/O compiled in, assuming I can get it to compile. Currently when I try to compile the Squid port with --enable-async-io, it complains thusly: cc -O -pipe -D_REENTRANT -I. -I../include -I../include -c send-announce.c aiops.o(.text+0x80): undefined reference to `pthread_cond_init' aiops.o(.text+0xaf): undefined reference to `pthread_create' aiops.o: In function `aio_thread_loop': aiops.o(.text+0x130): undefined reference to `pthread_sigmask' aiops.o(.text+0x139): undefined reference to `pthread_mutex_lock' aiops.o(.text+0x169): undefined reference to `pthread_cond_timedwait' aiops.o: In function `aio_process_request_queue': aiops.o(.text+0x64e): undefined reference to `pthread_cond_signal' *** Error code 1 Stop. I'm running a very recent 3.4-STABLE. I'm assuming the work you do will apply to -STABLE since you're running a production server. :-) This box only gets an average load most of the time, but will see an occasional high peak, so it should be a fair test subject. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 18: 6:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from monty.pp.sci.fi (monty.pp.sci.fi [195.74.24.156]) by hub.freebsd.org (Postfix) with ESMTP id 834B2152F0 for ; Mon, 10 Jan 2000 18:06:08 -0800 (PST) (envelope-from monty@monty.pp.sci.fi) Received: (from monty@localhost) by monty.pp.sci.fi (8.9.3/8.8.7) id EAA22715; Tue, 11 Jan 2000 04:08:22 +0200 From: Michael Widenius MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14458.37014.846894.473677@monty.pp.sci.fi> Date: Tue, 11 Jan 2000 04:08:22 +0200 (EET) To: "Scott Hess" Cc: , Subject: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. In-Reply-To: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Reply-To: monty@tcx.se Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Scott" == Scott Hess writes: Scott> Recently I was tasked to find a way to scale up our MYSQL server, running Scott> MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution, Scott> and found that with 6 disks in a RAID5 configuration, the system was only Scott> perhaps 30% faster than when running on a single disk. [The 6 disks in the Scott> RAID5 are the same model as the single-disk test I was comparing against.] Scott> Experimentation determined that pthreads was the problem. FreeBSD's Scott> implementation of pthreads using a select() loop, and select() always says Scott> that disk I/O is ready to proceed, and disk I/O never return EWOULDBLOCK. Scott> Essentially, pthreads was serializing the MYSQL read() requests, and if the Scott> dataset exceeds memory size, performance becomes entirely seek bound. Scott> I've implemented a rough fix, which is to rfork() processes which I label Scott> "iothreads" to handle the disk I/O. The parent process running pthreads Scott> has a socketpair() to each of the iothreads. The iothreads wait for Scott> requests on the socketpair, and since socketpairs can block, pthreads can Scott> handle them efficiently. This essentially allows me to turn blocking disk Scott> I/O calls into non-blocking calls. Having multiple pending seeks turns out Scott> to be a huge win for MYSQL, allowing it to scale much better as disks are Scott> added to the RAID5 array. Scott> Unfortunately, I'm concerned about using this code in production, because Scott> it needs a fair amount of cleanup to handle signals and administrative Scott> functions correctly. For this reason and others, I'm starting a project to Scott> move it into the pthreads library itself. Before I embark on that effort, Scott> I have a couple questions: Scott> 1) Does this seem like a reasonable approach? [It _works_, and well. But Scott> it tastes strongly of hack.] If you can't get the freebsd team to add blocking reads, then this may one solution to speed this up. Scott> 2) Does anyone have suggestions for a solution that will be cleaner and Scott> won't take man-months to implement? [Which is the redeeming quality of Scott> what I've got - it took me two days to zero in on a very workable Scott> solution.] Everything depends of how neatly you can get this into the FreeBSD kernel and if you can get the FreeBSD developers to incorporate your patch in the offical kernel. If not, then this may be a problem. Scott> 3) Is anyone working on something I might leverage off of in this area? Scott> [For instance, a select()-based interface to async I/O? Or support for Scott> blocking disk I/O in select() and read()?] blocking reads would probably be the best option. Scott> 4) Is there anyone willing to commit to testing my modified pthreads Scott> library against MYSQL? [I'll be stress testing it quite heavily, of Scott> course. It would probably also be testable against Squid with async I/O Scott> and multithreaded Apache 2.0.] Sorry, but I don't have a FreeBSD system available that I can use for testing (and I don't have any real good application to use for testing this). Regards, Monty To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 18:24:29 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 5797514BF1 for ; Mon, 10 Jan 2000 18:24:24 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 385; Mon, 10 Jan 2000 18:20:52 -0800 Message-ID: <1c4501bf5bda$da828c10$1e80000a@avantgo.com> From: "Scott Hess" To: "Patryk Zadarnowski" Cc: References: <200001110025.LAA31411@mycenae.ilion.eu.org> Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Date: Mon, 10 Jan 2000 18:23:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Patryk Zadarnowski wrote: > I'm no expert on pthreads, but, if you decide to proceed with > implementing a mixed user-land/rfork pthread implementation, may I > suggest that you implement is through POSIX pthread_attr_setscope() > interfaces instead of some local extension. pthread_attr_setscope() > sounds like a portable interface to precisely what you're trying to > achieve. I must _really_ be missing something. Not only doesn't pthread_attr_setscope() seem to be relevant, but it appears to essentially be a NOP in the FreeBSD3.3 libc_r. Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 18:36:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 321C2153B2 for ; Mon, 10 Jan 2000 18:36:33 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id SAA28517; Mon, 10 Jan 2000 18:35:17 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA26168; Mon, 10 Jan 2000 18:35:17 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id SAA10773; Mon, 10 Jan 2000 18:34:02 -0800 (PST) Message-ID: <387A97B4.CE63164E@softweyr.com> Date: Mon, 10 Jan 2000 19:38:44 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "f.johan.beisser" Cc: Alex , mjacob@feral.com, Peter da Silva , freebsd-hackers@freebsd.org Subject: Re: Project UDI? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "f.johan.beisser" wrote: > > On Mon, 10 Jan 2000, Alex wrote: > > > Wes Peters wrote: > > > > > > Matthew Jacob wrote: > > > > > > > > Mike Smith has been interested in getting FreeBSD involved in this. My > > > > attitude has been "Over my dead body".... (you have to watch out saying > > > > things like that- someone might respond with, "Uh, okay....") > > > > > > Uh, okay. Anything to help Mike out. ;^) > > > > > > "Dead body found in the park - detectives baffled" > > > > "FreeBSD joins UDI project" > > > > (DaemonNews headlines) > > isn't this the reason for ESRs "Geeks With Guns" outings? No, those exist solely to shoot up old MSDN CD-ROMs. I'll try to scan a few of mine tonight. ;^) -- "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-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 18:40:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by hub.freebsd.org (Postfix) with ESMTP id 2031C1532E for ; Mon, 10 Jan 2000 18:40:36 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from qwerty.maxwell.syr.edu (qwerty.maxwell.syr.edu [128.230.129.248]) by maxwell.syr.edu (8.9.3/8.9.1) with ESMTP id CAA79669; Tue, 11 Jan 2000 02:42:00 GMT Date: Mon, 10 Jan 2000 21:40:26 -0500 (EST) From: Chris Sedore To: jasone@canonware.com Cc: Scott Hess , freebsd-hackers@FreeBSD.ORG, developer@lists.mysql.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. In-Reply-To: <20000110153917.D4938@sturm.canonware.com> Message-ID: <77EC013A8765D311974D00A0C9B413A1013A86E9-100000@exchange.maxwell.syr.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000 jasone@canonware.com wrote: [...] > > 1) Does this seem like a reasonable approach? [It _works_, and well. But > > it tastes strongly of hack.] > > I'm not very fond of this approach to the problem, though it can work, as > you note. Asynchronous I/O is in my opinion a much cleaner solution. > > > 2) Does anyone have suggestions for a solution that will be cleaner and > > won't take man-months to implement? [Which is the redeeming quality of > > what I've got - it took me two days to zero in on a very workable > > solution.] > > Have you tried the linuxthreads port lately? With linuxthreads, each > thread is an rfork()ed process, which means that blocking on file I/O only > blocks the thread that attempts the I/O. There are various > advantages/disadvantages between libc_r and linuxthreads, but you may find > linuxthreads to meet your needs at the moment. > > > 3) Is anyone working on something I might leverage off of in this area? > > [For instance, a select()-based interface to async I/O? Or support for > > blocking disk I/O in select() and read()?] > > Though not ideal, it seems to me that using asynchronous I/O will work > reasonably well inside libc_r. If there weren't plans to build a much more > scalable threads library than what we currently have, this modification > would be high on my priority list. I was just poking around a bit, and I don't think it would take too much to add an aio_select() call, that would do an async io select (that is, queue a select as just another aio operation). I've cheated around this a bit, since you can get away (for instance) with executing an aio_read() against a listening socket, waiting for the completion (an error, since you can't read from such a thing), then doing the accept(). It seems that a fair amount of benefit could be had from async select, since it would facilitate using aio in pthreads, innd, etc, which were originally designed for select(), but might like to add async io for disk operations. Maybe it is just bloat in the long-run, since with kernel threads one could just fire off another thread to do select(). Or maybe someone will pipe up and say that select() won't work that way (i.e., just pass in the select parameters and let one of the aiod's call select() on behalf of the main process). -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 21:21:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cx587235-a.chnd1.az.home.com (cx587235-a.chnd1.az.home.com [24.11.88.170]) by hub.freebsd.org (Postfix) with ESMTP id DD29014F66 for ; Mon, 10 Jan 2000 21:21:42 -0800 (PST) (envelope-from jjreynold@home.com) Received: from whale.home-net (whale [192.168.1.2]) by cx587235-a.chnd1.az.home.com (8.9.3/8.9.3) with ESMTP id WAA09886 for ; Mon, 10 Jan 2000 22:21:33 -0700 (MST) (envelope-from jjreynold@home.com) Received: (from jjreynold@localhost) by whale.home-net (8.9.3/8.9.3) id WAA54022; Mon, 10 Jan 2000 22:21:32 -0700 (MST) (envelope-from jjreynold@home.com) From: John and Jennifer Reynolds MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14458.48604.671302.610902@whale.home-net> Date: Mon, 10 Jan 2000 22:21:32 -0700 (MST) To: freebsd-hackers@freebsd.org Subject: useful addition to mergemaster (patch included)? X-Mailer: VM 6.73 under Emacs 20.5.1 Cc: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I was tinkering with mergemaster tonight adding in something that seems useful to me. I track -stable and have found mergemaster very valuable--however, sometimes choosing 'd' over and over again for things I don't want touched (like root's .profile or .cshrc or /etc/networks, etc.) can get tedious. So, I made a quick hack to mergemaster so it would recognize a new "rc" variable called IGNORE_FILE. This file is a list of files mergemaster should ignore, or not compare. One filename per line. Now, when I run mergemaster, it automatically skips these sorts of files and only concentrates on things that need to be brought up-to-date. It's at least useful to me :) ... apply this patch and edit your /root/.mergemasterrc file appropriately and see what you think! --- /usr/sbin/mergemaster Fri Jan 7 23:48:28 2000 +++ mergemaster Mon Jan 10 22:03:31 2000 @@ -260,6 +260,23 @@ ;; esac + # Avoid comparing the files in IGNORE_FILE if the user specifies it in + # .mergemasterrc + # + case "${IGNORE_FILE}" in + '') ;; + *) echo "" + echo "*** IGNORE_FILE variable found in $HOME/.mergemasterrc" + echo " The following files will not be compared:" + echo "" + for tmpfile in `cat ${IGNORE_FILE} | xargs`; do + echo " - ${tmpfile}" + rm ${TEMPROOT}${tmpfile} + done + ;; + esac + + ;; # End of the "RERUN" test esac --------------------- man page --------------------- --- /usr/src/usr.sbin/mergemaster/mergemaster.8 Wed Nov 3 13:58:47 1999 +++ mergemaster.8 Mon Jan 10 22:08:13 2000 @@ -233,6 +233,10 @@ #PATH=/bin:/usr/bin:/usr/sbin # Don't compare the old and new motd files #IGNORE_MOTD=yes +# +# File to contain filenames (full path names) of files in / and /etc to +# ignore. One filename per line. +#IGNORE_FILE=/path/to/file .Ed .Sh SEE ALSO .Xr cvs 1 , -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation jreynold@sedona.ch.intel.com My opinions are mine, not Intel's. Running jjreynold@home.com FreeBSD 3.4-STABLE. FreeBSD: The Power to Serve. http://members.home.com/jjreynold/ Come join us!!! @ http://www.FreeBSD.org/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 10 22: 2:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nyct.net (bsd4.nyct.net [204.141.86.6]) by hub.freebsd.org (Postfix) with ESMTP id 1A7241538C for ; Mon, 10 Jan 2000 22:02:28 -0800 (PST) (envelope-from mbac@nyct.net) Received: from bsd1.nyct.net (mbac@bsd1.nyct.net [204.141.86.3]) by mail.nyct.net (8.8.8/8.8.7) with ESMTP id BAA21409; Tue, 11 Jan 2000 01:02:24 -0500 (EST) (envelope-from mbac@nyct.net) Received: from localhost (mbac@localhost) by bsd1.nyct.net (8.8.8/8.9.3) with ESMTP id BAA26554; Tue, 11 Jan 2000 01:02:24 -0500 (EST) (envelope-from mbac@nyct.net) X-Authentication-Warning: bsd1.nyct.net: mbac owned process doing -bs Date: Tue, 11 Jan 2000 01:02:24 -0500 (EST) From: Michael Bacarella To: Alfred Perlstein Cc: Matthew Dillon , Scott Hess , freebsd-hackers@FreeBSD.ORG Subject: rfork() [was: Concept check] In-Reply-To: <20000110170822.J9397@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000, Alfred Perlstein wrote: > > :I've implemented a rough fix, which is to rfork() processes which I label [snip] > > > > The linuxthreads port is at least four times faster and, since it uses > > rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements > > rfork(...RF_MEM) you can only use it with FreeBSD-4.x (or am I wrong > > there?). This 3.4-STABLE system has an rfork() man page. > I'm pretty sure RF_MEM doesn't work in 3.x with SMP, under UP it should > work fine I'm sorry I missed the discussion on rfork()... but I say this only because I want to understand. What were you thinking? rfork()? Why is it a system call? Almost all of the flags it accepts seem like functionality that can easily be implemented in userspace around fork() (and maybe vfork()). Why? Michael Bacarella To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 1:39:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id E894315414 for ; Tue, 11 Jan 2000 01:39:31 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 127xkR-000PO8-00; Tue, 11 Jan 2000 11:37:55 +0200 From: Sheldon Hearn To: John and Jennifer Reynolds Cc: freebsd-hackers@freebsd.org Subject: Re: useful addition to mergemaster (patch included)? In-reply-to: Your message of "Mon, 10 Jan 2000 22:21:32 MST." <14458.48604.671302.610902@whale.home-net> Date: Tue, 11 Jan 2000 11:37:55 +0200 Message-ID: <97595.947583475@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000 22:21:32 MST, John and Jennifer Reynolds wrote: > So, I made a quick hack to mergemaster so it would recognize a new > "rc" variable called IGNORE_FILE. This file is a list of files > mergemaster should ignore, or not compare. One filename per line. I've been meaning to do something like this for a while, because I also thought it'd be useful. Thanks! I've passed your patch on to the mergemaster maintainers. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 3:34:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id E7CA614EC5 for ; Tue, 11 Jan 2000 03:34:31 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id FAA83774; Tue, 11 Jan 2000 05:34:20 -0600 (CST) (envelope-from dick) Date: Tue, 11 Jan 2000 05:34:20 -0600 From: "Richard Seaman, Jr." To: Matthew Dillon Cc: Scott Hess , freebsd-hackers@FreeBSD.ORG, developer@lists.mysql.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Message-ID: <20000111053419.D360@tar.com> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> <200001102336.PAA31453@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001102336.PAA31453@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Jan 10, 2000 at 03:36:23PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 10, 2000 at 03:36:23PM -0800, Matthew Dillon wrote: > A better solution may be to shift to FreeBSD4.0 (when it's released - > wait for it to become good and stable), and then use the native > linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. > > The linuxthreads port is at least four times faster and, since it uses > rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements > rfork(...RF_MEM) you can only use it with FreeBSD-4.x (or am I wrong > there?). rfork (...RF_MEM) works under 3.X too on uni-processors. Its only SMP that you need 4.0 for. However, if you're going to use dynamic linking, there's a problem in ld-elf.so (its not thread safe) that has only been fixed recently. There are reported problems with both UP and SMP, but the problem is more evident with SMP. In theory the problem should exist for libc_r, but I don't know of any reports. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 6:43:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 81F8F15000 for ; Tue, 11 Jan 2000 06:43:16 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 227; Tue, 11 Jan 2000 06:38:48 -0800 Message-ID: <1d5c01bf5c42$1409d990$1e80000a@avantgo.com> From: "Scott Hess" To: "Michael Bacarella" , "Alfred Perlstein" Cc: "Matthew Dillon" , References: Subject: Re: rfork() [was: Concept check] Date: Tue, 11 Jan 2000 06:42:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Bacarella wrote: > On Mon, 10 Jan 2000, Alfred Perlstein wrote: > > I'm pretty sure RF_MEM doesn't work in 3.x with SMP, under UP it should > > work fine > > I'm sorry I missed the discussion on rfork()... but I say this only > because I want to understand. > > What were you thinking? rfork()? Why is it a system call? > > Almost all of the flags it accepts seem like functionality that can easily > be implemented in userspace around fork() (and maybe vfork()). > > Why? You've got that backwards - fork() and vfork() can easily be implemented in terms of rfork() [in fact, I believe all three are implemented in terms of fork1() in the kernel]. rfork(RFMEM) means that the processes share all memory - current AND FUTURE. You could use minherit() before fork() to share current memory, but not future memory. rfork() without RFFDG shares file descriptor tables - current AND FUTURE. fork() is like rfork(RFFDG) in that the current file descriptors are copied, but going forward they are seperate tables. The pthreads mods I'm proposing use this to allow the iothreads to have access to the same set of file descriptors as the primary process, even if the primary process opened the file descriptor after the iothread was spawned. In fact, the iothread can be used to open() or close() the file descriptor. Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 8:14: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 25617154C6 for ; Tue, 11 Jan 2000 08:14:01 -0800 (PST) (envelope-from rminnich@lanl.gov) Received: from mini.acl.lanl.gov (root@mini.acl.lanl.gov [128.165.147.34]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id JAA992207 for ; Tue, 11 Jan 2000 09:13:53 -0700 (MST) Received: from localhost (rminnich@localhost) by mini.acl.lanl.gov (8.9.3/8.8.8) with ESMTP id JAA01634 for ; Tue, 11 Jan 2000 09:13:53 -0700 X-Authentication-Warning: mini.acl.lanl.gov: rminnich owned process doing -bs Date: Tue, 11 Jan 2000 09:13:52 -0700 (MST) From: "Ronald G. Minnich" X-Sender: rminnich@mini.acl.lanl.gov To: freebsd-hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 11 Jan 2000, Michael Bacarella wrote: > I'm sorry I missed the discussion on rfork()... but I say this only > because I want to understand. > > What were you thinking? rfork()? Why is it a system call? > > Almost all of the flags it accepts seem like functionality that can easily > be implemented in userspace around fork() (and maybe vfork()). nope. This whole issue is about (let me check :-) ) 4.5 years old. I did the first rfork for freebsd ca. 9/1994, and I can tell you that you can't easily get what it does with userland wrappers. Well, actually, in the general case it's impossible. Just think about that fact that with shared file descriptors, a child can open a socket and the parent can use it, right down to using the same FD #. (And yes, I use this). I don't want to try to emulate that behaviour in userland. Fork and vfork, however, are a subset of rfork. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 8:31:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nyct.net (bsd4.nyct.net [204.141.86.6]) by hub.freebsd.org (Postfix) with ESMTP id 5475E151FA for ; Tue, 11 Jan 2000 08:31:39 -0800 (PST) (envelope-from mbac@nyct.net) Received: from bsd1.nyct.net (mbac@bsd1.nyct.net [204.141.86.3]) by mail.nyct.net (8.8.8/8.8.7) with ESMTP id LAA21434; Tue, 11 Jan 2000 11:31:29 -0500 (EST) (envelope-from mbac@nyct.net) Received: from localhost (mbac@localhost) by bsd1.nyct.net (8.8.8/8.9.3) with ESMTP id LAA11469; Tue, 11 Jan 2000 11:31:28 -0500 (EST) (envelope-from mbac@nyct.net) X-Authentication-Warning: bsd1.nyct.net: mbac owned process doing -bs Date: Tue, 11 Jan 2000 11:31:28 -0500 (EST) From: Michael Bacarella To: "Ronald G. Minnich" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Almost all of the flags it accepts seem like functionality that can easily > > be implemented in userspace around fork() (and maybe vfork()). > > nope. This whole issue is about (let me check :-) ) 4.5 years old. I did > the first rfork for freebsd ca. 9/1994, and I can tell you that you can't > easily get what it does with userland wrappers. Well, actually, in the > general case it's impossible. Just think about that fact that with shared > file descriptors, a child can open a socket and the parent can use it, > right down to using the same FD #. (And yes, I use this). I don't want to > try to emulate that behaviour in userland. > Fork and vfork, however, are a subset of rfork. Oh.... Yes, that perspective is much more different and sensible. One such as me might say that it makes more sense to turn fork() and vfork() into userland wrappers for rfork()! Too bad rfork is an afterthought, and then there are those people that want their fork()s without userland overhead. Pfft. :) -MB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 9: 1:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9779E14C3C; Tue, 11 Jan 2000 09:01:25 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id MAA26873; Tue, 11 Jan 2000 12:01:24 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id MAA83067; Tue, 11 Jan 2000 12:00:53 -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: Tue, 11 Jan 2000 12:00:53 -0500 (EST) To: freebsd-hackers@freebsd.org, freebsd-smp@freebsd.org Subject: Dell PowerEdge 2400 & RCC PCI chipset? X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14459.23579.82455.59466@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a bit nervous because the 2400 uses a non-Intel server chipset made by a company called RCC Reliance. The chipset is called the "LE-64 ver 3.0". and I cannot seem to find any info about it. The most I've been able to turn up is somebody else looking for info. I was wondering if anybody was currently using a PowerEdge 2400 (or any other server products with this PCI chipset) with FreeBSD So -- does FreeBSD work with RCC chipsets? Is the chipset robust & reliable? We've been badly burned a few times by buggy DEC PCI chipsets & we're hoping to not repeat the experience with an x86 ;-) Thanks, 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-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 10:35:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 2201F15453 for ; Tue, 11 Jan 2000 10:35:32 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 2721 invoked by uid 1001); 11 Jan 2000 18:35:27 -0000 Date: Tue, 11 Jan 2000 10:35:27 -0800 From: Jason Evans To: "Richard Seaman, Jr." Cc: freebsd-hackers@FreeBSD.ORG Subject: Adding alternate entry points to libc (was Re: Possible libc changes to support LinuxThreads) Message-ID: <20000111103527.A302@sturm.canonware.com> References: <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991209064256.B34152@tar.com>; from dick@tar.com on Thu, Dec 09, 1999 at 06:42:56AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: > It's my impression that glibc uses a three (four?) tiered naming > convention. The "pure" syscall (in our case, eg. _write()). Then > there is the version used internally in glibc (eg. _libc_write(). > And finally, the version exported from glibc (eg. write()). > > The merit to the three tiered system is that you might need to rewrite > the version used internally to libc for threads, but still have this > be different from the version exported from the library (eg. to > implement cancallation points without propagating them throughout > libc). > > In this case, you'd want, for example, an _lseek(), _libc_lseek(), > and _seek(). > > The problem with cancellation points, libc and linuxthreads has been > that you need to wade through libc and replace instances of, for > example, write() with either _write() or _libc_write() in order to > avoid propagating cancellation points where they don't belong. I'm working on adding alternate entry points to libc now. The naming approach I'm taking is: fwrite() <-- Alternate entry point that is used externally unless another library overrides it. _libc_fwrite() <-- `_libc_' prefix. Alternate entry point for internal library use. __fwrite() <-- `__' prefix. Actual name. The reason for a prefix of `__' instead of `_' in the actual name case is that using only one underscore would be ambiguous at least in the cases of setjmp()/_setjmp() and longjmp()/_longjmp(). One issue I'm not sure on is whether *every* libc interface should have alternate entry points added. Doing so would be more consistent, but it probably isn't necessary, since POSIX very clearly defines the set of functions that may act as cancellation points. There end up being a few other functions that need wrapped by threads libraries as well. Of course, doing only the necessary ones is easier for me. =) If only adding alternate entry points for the necessary libc interfaces, there's a good chance I can get this done for 4.0, which will mean compliant thread cancellation for both libc_r and linuxthreads. A genuine libpthread is just a hop, skip, and a jump from there. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 10:49:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 18F31154A3 for ; Tue, 11 Jan 2000 10:49:39 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id MAA85685; Tue, 11 Jan 2000 12:49:32 -0600 (CST) (envelope-from dick) Date: Tue, 11 Jan 2000 12:49:32 -0600 From: "Richard Seaman, Jr." To: Jason Evans Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adding alternate entry points to libc (was Re: Possible libc changes to support LinuxThreads) Message-ID: <20000111124932.E360@tar.com> References: <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com> <20000111103527.A302@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000111103527.A302@sturm.canonware.com>; from jasone@canonware.com on Tue, Jan 11, 2000 at 10:35:27AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote: > I'm working on adding alternate entry points to libc now. Good. > The naming > approach I'm taking is: > > fwrite() <-- Alternate entry point that is used externally unless > another library overrides it. > _libc_fwrite() <-- `_libc_' prefix. Alternate entry point for internal > library use. > __fwrite() <-- `__' prefix. Actual name. > > The reason for a prefix of `__' instead of `_' in the actual name case is > that using only one underscore would be ambiguous at least in the cases of > setjmp()/_setjmp() and longjmp()/_longjmp(). FYI, the actual name with a single '_' is already defined for syscalls via SYS.h. Aliasing '__sycall' to '_syscall' is ok, I assume. Or, are you planning on replacing the '_syscall's? Setjmp/_setjmp are libc calls but not syscalls. I'm under the impression that linux glibc uses both single and double underscore symbols, but I don't recall exactly what distinction they make between the two. > One issue I'm not sure on is whether *every* libc interface should have > alternate entry points added. Doing so would be more consistent, Agreed. > but it > probably isn't necessary, since POSIX very clearly defines the set of > functions that may act as cancellation points. There end up being a few > other functions that need wrapped by threads libraries as well. Of course, > doing only the necessary ones is easier for me. =) Agreed its not necessary. I'm under the impression that linux glibc only does the "necessary" ones (at lease for the _libc_ prefix), but you'd have to check the code if you want to be sure, because I'm not. > If only adding alternate entry points for the necessary libc interfaces, > there's a good chance I can get this done for 4.0, which will mean > compliant thread cancellation for both libc_r and linuxthreads. A genuine > libpthread is just a hop, skip, and a jump from there. I'd say only do whats necessary, if thats the case. Someone really good with sed, or some other text processor, might be able to semi-automate the process, but I know I don't know how. This will be a big help. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 10:56:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 233CD14E52 for ; Tue, 11 Jan 2000 10:56:18 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 2810 invoked by uid 1001); 11 Jan 2000 18:56:12 -0000 Date: Tue, 11 Jan 2000 10:56:12 -0800 From: Jason Evans To: "Richard Seaman, Jr." Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adding alternate entry points to libc (was Re: Possible libc changes to support LinuxThreads) Message-ID: <20000111105612.B302@sturm.canonware.com> References: <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com> <20000111103527.A302@sturm.canonware.com> <20000111124932.E360@tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000111124932.E360@tar.com>; from dick@tar.com on Tue, Jan 11, 2000 at 12:49:32PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 12:49:32PM -0600, Richard Seaman, Jr. wrote: > On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote: > > The naming > > approach I'm taking is: > > > > fwrite() <-- Alternate entry point that is used externally unless > > another library overrides it. > > _libc_fwrite() <-- `_libc_' prefix. Alternate entry point for internal > > library use. > > __fwrite() <-- `__' prefix. Actual name. > > > > The reason for a prefix of `__' instead of `_' in the actual name case is > > that using only one underscore would be ambiguous at least in the cases of > > setjmp()/_setjmp() and longjmp()/_longjmp(). > > FYI, the actual name with a single '_' is already defined for syscalls via > SYS.h. Aliasing '__sycall' to '_syscall' is ok, I assume. Or, are you planning > on replacing the '_syscall's? Setjmp/_setjmp are libc calls but not syscalls. > I'm under the impression that linux glibc uses both single and double underscore > symbols, but I don't recall exactly what distinction they make between the two. It would be more consistent to change to `__' for syscalls, but I was planning on leaving the syscalls with `_', and adding `__' aliases, for fear that changing it would violate some "law of libc". Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 11:30:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (prism.flugsvamp.com [208.139.222.230]) by hub.freebsd.org (Postfix) with ESMTP id 4897A154B4; Tue, 11 Jan 2000 11:29:31 -0800 (PST) (envelope-from jlemon@prism.flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id NAA00549; Tue, 11 Jan 2000 13:31:23 -0600 (CST) (envelope-from jlemon) Date: Tue, 11 Jan 2000 13:31:23 -0600 From: Jonathan Lemon To: Andrew Gallatin , hackers@freebsd.org, smp@freebsd.org Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? Message-ID: <20000111133123.C409@prism.flugsvamp.com> References: <200001111922.NAA07463@free.pcs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200001111922.NAA07463@free.pcs> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 01:22:49PM -0600, Jonathan Lemon wrote: > > We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a > bit nervous because the 2400 uses a non-Intel server chipset made by a > company called RCC Reliance. > > The chipset is called the "LE-64 ver 3.0". and I cannot seem to find > any info about it. The most I've been able to turn up is somebody > else looking for info. I was wondering if anybody was currently using > a PowerEdge 2400 (or any other server products with this PCI chipset) > with FreeBSD > > So -- does FreeBSD work with RCC chipsets? Is the chipset robust & > reliable? We've been badly burned a few times by buggy DEC PCI > chipsets & we're hoping to not repeat the experience with an x86 ;-) It doesn't currently seem to boot with the RCC chipset. I get the following: pci unknown vendor = 0x9005, dev = 0x00cf This is with a RCC-186566-PO3. As for stability, I have another box running Linux with an RCC-xxxx-PO2 that seems fairly stable. The RCC chips are supposed to allow better memory bandwidth @ 133Mhz. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 11:42:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from plab.ku.dk (plab.ku.dk [130.225.105.65]) by hub.freebsd.org (Postfix) with ESMTP id 66DEE150AF for ; Tue, 11 Jan 2000 11:42:39 -0800 (PST) (envelope-from voland@plab.ku.dk) Received: from eagle.plab.ku.dk (voland@eagle.plab.ku.dk [130.225.105.63]) by plab.ku.dk (8.9.3/8.9.3) with ESMTP id UAA40074 for ; Tue, 11 Jan 2000 20:42:42 +0100 (CET) (envelope-from voland@plab.ku.dk) Received: (from voland@localhost) by eagle.plab.ku.dk (8.9.3/8.9.3) id UAA04962; Tue, 11 Jan 2000 20:42:36 +0100 (CET) (envelope-from voland) Mime-version: 1.0 Content-type: text/plain; charset="koi8-r" Content-transfer-encoding: 8bit To: freebsd-hackers@freebsd.org Subject: devfs oddity & bug From: Vadim Belman Date: 11 Jan 2000 20:42:36 +0100 Message-ID: <85u2kk8ker.fsf@eagle.plab.ku.dk> Lines: 9 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Recently I discovered a bug in DEVFS which I gonna try to fix. I have core dump which has been traced and analyzed, so that the place, where page fault occurs, and the way it came to death is known. And the only problem left: I have only few bits of information about DEVFS and VFS subsystems and looking for more details. -- /Voland Vadim Belman E-mail: voland@plab.ku.dk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 11:42:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 9C3DD152AF; Tue, 11 Jan 2000 11:42:46 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id MAA76411; Tue, 11 Jan 2000 12:42:19 -0700 (MST) (envelope-from ken) Date: Tue, 11 Jan 2000 12:42:19 -0700 From: "Kenneth D. Merry" To: Jonathan Lemon Cc: Andrew Gallatin , hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? Message-ID: <20000111124219.A76365@panzer.kdm.org> References: <200001111922.NAA07463@free.pcs> <20000111133123.C409@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000111133123.C409@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Tue, Jan 11, 2000 at 01:31:23PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 13:31:23 -0600, Jonathan Lemon wrote: > On Tue, Jan 11, 2000 at 01:22:49PM -0600, Jonathan Lemon wrote: > > > > We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a > > bit nervous because the 2400 uses a non-Intel server chipset made by a > > company called RCC Reliance. > > > > The chipset is called the "LE-64 ver 3.0". and I cannot seem to find > > any info about it. The most I've been able to turn up is somebody > > else looking for info. I was wondering if anybody was currently using > > a PowerEdge 2400 (or any other server products with this PCI chipset) > > with FreeBSD > > > > So -- does FreeBSD work with RCC chipsets? Is the chipset robust & > > reliable? We've been badly burned a few times by buggy DEC PCI > > chipsets & we're hoping to not repeat the experience with an x86 ;-) > > It doesn't currently seem to boot with the RCC chipset. I get > the following: > > pci unknown vendor = 0x9005, dev = 0x00cf That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not sure what device that is, however. Justin might know. Are you sure that's the RCC chipset? > This is with a RCC-186566-PO3. As for stability, I have another box > running Linux with an RCC-xxxx-PO2 that seems fairly stable. > > The RCC chips are supposed to allow better memory bandwidth @ 133Mhz. Anyone have a URL for RCC? Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 11:48:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (prism.flugsvamp.com [208.139.222.230]) by hub.freebsd.org (Postfix) with ESMTP id 90D6B1552D; Tue, 11 Jan 2000 11:48:10 -0800 (PST) (envelope-from jlemon@prism.flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id NAA00591; Tue, 11 Jan 2000 13:49:59 -0600 (CST) (envelope-from jlemon) Date: Tue, 11 Jan 2000 13:49:59 -0600 From: Jonathan Lemon To: "Kenneth D. Merry" Cc: Jonathan Lemon , Andrew Gallatin , hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? Message-ID: <20000111134959.D409@prism.flugsvamp.com> References: <200001111922.NAA07463@free.pcs> <20000111133123.C409@prism.flugsvamp.com> <20000111124219.A76365@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000111124219.A76365@panzer.kdm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote: > > It doesn't currently seem to boot with the RCC chipset. I get > > the following: > > > > pci unknown vendor = 0x9005, dev = 0x00cf > > That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not > sure what device that is, however. Justin might know. Are you sure > that's the RCC chipset? Oops, you're right. That's probably the onboard Adaptec 7899. The RCC is probably this one: pci: unknown ATA vendor = 0x1166, device = 0x0211 I wonder why it flags it as a ATA device, I'm pretty sure this is the RCC chip -- the vendor id matches. (I checked this time.) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 11:55:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 04F2015508; Tue, 11 Jan 2000 11:55:10 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id MAA76502; Tue, 11 Jan 2000 12:54:53 -0700 (MST) (envelope-from ken) Date: Tue, 11 Jan 2000 12:54:53 -0700 From: "Kenneth D. Merry" To: Jonathan Lemon Cc: Andrew Gallatin , hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? Message-ID: <20000111125453.A76466@panzer.kdm.org> References: <200001111922.NAA07463@free.pcs> <20000111133123.C409@prism.flugsvamp.com> <20000111124219.A76365@panzer.kdm.org> <20000111134959.D409@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000111134959.D409@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Tue, Jan 11, 2000 at 01:49:59PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 13:49:59 -0600, Jonathan Lemon wrote: > On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote: > > > It doesn't currently seem to boot with the RCC chipset. I get > > > the following: > > > > > > pci unknown vendor = 0x9005, dev = 0x00cf > > > > That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not > > sure what device that is, however. Justin might know. Are you sure > > that's the RCC chipset? > > Oops, you're right. That's probably the onboard Adaptec 7899. Yep, it is. I missed the 7899 ID when looking through the Adaptec driver. If you get the latest Adaptec driver in -current, you should be able to use that chip at Ultra2 speeds. > The RCC is probably this one: > > pci: unknown ATA vendor = 0x1166, device = 0x0211 > > > I wonder why it flags it as a ATA device, I'm pretty sure this is the > RCC chip -- the vendor id matches. (I checked this time.) It's proably the chip class or something. That could well be an IDE chip, though. Intel's chipsets usually include an IDE controller. Does anyone have a URL for "RCC"? Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 11:57:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9A8EB15219 for ; Tue, 11 Jan 2000 11:57:30 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id OAA29862; Tue, 11 Jan 2000 14:57:23 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id OAA83371; Tue, 11 Jan 2000 14:56:52 -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: Tue, 11 Jan 2000 14:56:51 -0500 (EST) To: Jonathan Lemon Cc: "Kenneth D. Merry" , hackers@FreeBSD.ORG Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? In-Reply-To: <20000111134959.D409@prism.flugsvamp.com> References: <200001111922.NAA07463@free.pcs> <20000111133123.C409@prism.flugsvamp.com> <20000111124219.A76365@panzer.kdm.org> <20000111134959.D409@prism.flugsvamp.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14459.35165.200209.560925@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Lemon writes: > On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote: > > > It doesn't currently seem to boot with the RCC chipset. I get > > > the following: > > > > > > pci unknown vendor = 0x9005, dev = 0x00cf > > > > That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not > > sure what device that is, however. Justin might know. Are you sure > > that's the RCC chipset? > > Oops, you're right. That's probably the onboard Adaptec 7899. Damn. I was hoping that the Dell docs were something approaching correct. The claim is one 7890 & one 7880 on-board. What is it really? a 7880 & a 7899, or something else? Can you do me a huge favor & run the lmbench bw_mem_cp benchmark from the lmbench or Hbench-OS benchmark suites please? How does it compare to: <2:54pm>boil/gallatin:osf4.0-alpha>./bw_mem_cp 20 8M libc aligned $Id: bw_mem_cp.c,v 1.7 1997/06/27 00:33:58 abrown Exp $ 299.3323 (This is a Compaq XP1000, alpha 21264). Thanks, 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-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 12:52:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.ocsny.com (apollo.ocsny.com [204.107.76.2]) by hub.freebsd.org (Postfix) with ESMTP id A1EA214EF4; Tue, 11 Jan 2000 12:52:21 -0800 (PST) (envelope-from mikel@ocsny.com) Received: from ocsny.com (thoth.upan.org [204.107.76.16]) by apollo.ocsny.com (8.9.2/8.9.3) with ESMTP id PAA44611; Tue, 11 Jan 2000 15:49:51 -0500 (EST) Message-ID: <387B9887.50D71C0B@ocsny.com> Date: Tue, 11 Jan 2000 15:54:31 -0500 From: Mikel Organization: Optimized Computer Solutions, Inc. X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin Cc: freebsd-hackers@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? References: <14459.23579.82455.59466@grasshopper.cs.duke.edu> Content-Type: multipart/mixed; boundary="------------4C9F6C168A65D32F4902B011" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------4C9F6C168A65D32F4902B011 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A friend of mine pick one up for his home...fbsd 3.3 installed with minimal effort. He's now married to it, like it's his second wife...:) Andrew Gallatin wrote: > We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a > bit nervous because the 2400 uses a non-Intel server chipset made by a > company called RCC Reliance. > > The chipset is called the "LE-64 ver 3.0". and I cannot seem to find > any info about it. The most I've been able to turn up is somebody > else looking for info. I was wondering if anybody was currently using > a PowerEdge 2400 (or any other server products with this PCI chipset) > with FreeBSD > > So -- does FreeBSD work with RCC chipsets? Is the chipset robust & > reliable? We've been badly burned a few times by buggy DEC PCI > chipsets & we're hoping to not repeat the experience with an x86 ;-) > > Thanks, > > 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-smp" in the body of the message -- Cheers, Mikel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Optimized Computer Solutions, Inc http://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Labor rates: Tech $125 hourly | Net Engineer $150 hourly | Phone Support $ 33 quarter hourly | Lost Password $ 45 per incedent +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | http://www.ocsny.com/~mikel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ --------------4C9F6C168A65D32F4902B011 Content-Type: text/x-vcard; charset=us-ascii; name="mikel.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Mikel Content-Disposition: attachment; filename="mikel.vcf" begin:vcard n:King;Mikel x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:mikel@ocsny.com title:Procurement Manager tel;fax:2124638402 tel;home:http://www.upan.org/vizkr tel;work:2127272100 adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US x-mozilla-cpt:;0 fn:Mikel King end:vcard --------------4C9F6C168A65D32F4902B011-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 12:53:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (prism.flugsvamp.com [208.139.222.230]) by hub.freebsd.org (Postfix) with ESMTP id 6CD0415468 for ; Tue, 11 Jan 2000 12:53:18 -0800 (PST) (envelope-from jlemon@prism.flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id OAA00696; Tue, 11 Jan 2000 14:55:03 -0600 (CST) (envelope-from jlemon) Date: Tue, 11 Jan 2000 14:55:03 -0600 From: Jonathan Lemon To: Andrew Gallatin Cc: Jonathan Lemon , "Kenneth D. Merry" , hackers@FreeBSD.ORG Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? Message-ID: <20000111145503.E409@prism.flugsvamp.com> References: <200001111922.NAA07463@free.pcs> <20000111133123.C409@prism.flugsvamp.com> <20000111124219.A76365@panzer.kdm.org> <20000111134959.D409@prism.flugsvamp.com> <14459.35165.200209.560925@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <14459.35165.200209.560925@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 02:56:51PM -0500, Andrew Gallatin wrote: > Damn. I was hoping that the Dell docs were something approaching > correct. The claim is one 7890 & one 7880 on-board. > > What is it really? a 7880 & a 7899, or something else? Uh, I didn't say that this was a PowerEdge 2400, just that it's a Dell box with a RCC chipset. > Can you do me a huge favor & run the lmbench bw_mem_cp benchmark from > the lmbench or Hbench-OS benchmark suites please? How does it compare > to: > > <2:54pm>boil/gallatin:osf4.0-alpha>./bw_mem_cp 20 8M libc aligned > $Id: bw_mem_cp.c,v 1.7 1997/06/27 00:33:58 abrown Exp $ > 299.3323 I can't seem to find that version. Here are some results: smp2-733[12:32pm](0)# ./bw_mem_cp 8M libc aligned $Id: bw_mem_cp.c,v 1.2 1995/03/11 02:19:56 lm Exp $ 8.0000 251.41 With the lmbench-2 suite, with the following ID: char *id = "$Id: s.bw_mem.c 1.5 98/06/29 22:37:23-07:00 lm@lm.bitmover.com $" smp2-733[12:37pm](0)# ./bw_mem 8M rd 8.39 1033.33 smp2-733[12:37pm](0)# ./bw_mem 8M wr 8.39 281.68 smp2-733[12:37pm](0)# ./bw_mem 8M rdwr 8.39 307.67 smp2-733[12:37pm](0)# ./bw_mem 8M cp 8.39 243.47 smp2-733[12:38pm](0)# ./bw_mem 8M fwr 8.39 269.50 smp2-733[12:38pm](0)# ./bw_mem 8M frd 8.39 537.94 smp2-733[12:38pm](0)# ./bw_mem 8M fcp 8.39 231.97 smp2-733[12:38pm](0)# ./bw_mem 8M bzero 8.39 450.06 smp2-733[12:38pm](0)# ./bw_mem 8M bcopy 8.39 263.79 -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 13: 9:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id DC95D14EA6 for ; Tue, 11 Jan 2000 13:09:05 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id QAA01163; Tue, 11 Jan 2000 16:09:02 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id QAA83563; Tue, 11 Jan 2000 16:08:32 -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: Tue, 11 Jan 2000 16:08:32 -0500 (EST) To: Jonathan Lemon Cc: "Kenneth D. Merry" , hackers@FreeBSD.ORG Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? In-Reply-To: <20000111145503.E409@prism.flugsvamp.com> References: <200001111922.NAA07463@free.pcs> <20000111133123.C409@prism.flugsvamp.com> <20000111124219.A76365@panzer.kdm.org> <20000111134959.D409@prism.flugsvamp.com> <14459.35165.200209.560925@grasshopper.cs.duke.edu> <20000111145503.E409@prism.flugsvamp.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14459.39797.830898.491908@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Lemon writes: > > Uh, I didn't say that this was a PowerEdge 2400, just that it's a > Dell box with a RCC chipset. If you don't mind me asking, what is it? > > Can you do me a huge favor & run the lmbench bw_mem_cp benchmark from > > the lmbench or Hbench-OS benchmark suites please? How does it compare > > to: > > > > <2:54pm>boil/gallatin:osf4.0-alpha>./bw_mem_cp 20 8M libc aligned > > $Id: bw_mem_cp.c,v 1.7 1997/06/27 00:33:58 abrown Exp $ > > 299.3323 > > I can't seem to find that version. Here are some results: > > smp2-733[12:32pm](0)# ./bw_mem_cp 8M libc aligned > $Id: bw_mem_cp.c,v 1.2 1995/03/11 02:19:56 lm Exp $ > 8.0000 251.41 Not too shabby! Thanks! 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-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 15:24: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 22E8814DF4 for ; Tue, 11 Jan 2000 15:24:03 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 340; Tue, 11 Jan 2000 15:19:36 -0800 Message-ID: <217901bf5c8a$d4c621a0$1e80000a@avantgo.com> From: "Scott Hess" To: "Matthew Dillon" Cc: , References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> <200001102336.PAA31453@apollo.backplane.com> Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Date: Tue, 11 Jan 2000 15:23:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > A better solution may be to shift to FreeBSD4.0 (when it's released - > wait for it to become good and stable), and then use the native > linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. After a number of hours hacking around with linuxthreads under 3.3-stable and 3.4-stable, I'm wondering if this suggestion was a joke of some sort that I just didn't get? As far as I can tell, the linuxthreads source code contains no files newer than mid December 1997. That would predate FreeBSD3.x entirely, wouldn't it? No wonder I'm having such an awful time getting things compiled. Please please please tell me that I'm REALLY missing something, here. Is there newer code hidden somewhere? Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 15:27:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 5880A14F01 for ; Tue, 11 Jan 2000 15:27:50 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 3846 invoked by uid 1001); 11 Jan 2000 23:27:43 -0000 Date: Tue, 11 Jan 2000 15:27:43 -0800 From: Jason Evans To: Scott Hess Cc: freebsd-hackers@FreeBSD.ORG, developer@lists.mysql.com Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Message-ID: <20000111152743.E302@sturm.canonware.com> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com> <200001102336.PAA31453@apollo.backplane.com> <217901bf5c8a$d4c621a0$1e80000a@avantgo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <217901bf5c8a$d4c621a0$1e80000a@avantgo.com>; from scott@avantgo.com on Tue, Jan 11, 2000 at 03:23:13PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 03:23:13PM -0800, Scott Hess wrote: > Matthew Dillon wrote: > > A better solution may be to shift to FreeBSD4.0 (when it's released - > > wait for it to become good and stable), and then use the native > > linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. > > After a number of hours hacking around with linuxthreads under 3.3-stable > and 3.4-stable, I'm wondering if this suggestion was a joke of some sort > that I just didn't get? As far as I can tell, the linuxthreads source code > contains no files newer than mid December 1997. That would predate > FreeBSD3.x entirely, wouldn't it? No wonder I'm having such an awful time > getting things compiled. > > Please please please tell me that I'm REALLY missing something, here. Is > there newer code hidden somewhere? The linuxthreads port switched to glibc-linuxthread-2.1.2 a couple of weeks ago. As mentioned by someone else (Alfred?), you *will* have problems with linuxthreads on -stable SMP, but it may work on -stable otherwise (I haven't tried it). It sounds like you need to do a cvsup. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 17: 6:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 4ABE314E37; Tue, 11 Jan 2000 17:06:29 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA01764; Tue, 11 Jan 2000 17:12:18 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001120112.RAA01764@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jonathan Lemon Cc: Andrew Gallatin , hackers@freebsd.org, smp@freebsd.org Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? In-reply-to: Your message of "Tue, 11 Jan 2000 13:31:23 CST." <20000111133123.C409@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jan 2000 17:12:18 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > So -- does FreeBSD work with RCC chipsets? Is the chipset robust & > > reliable? We've been badly burned a few times by buggy DEC PCI > > chipsets & we're hoping to not repeat the experience with an x86 ;-) > > It doesn't currently seem to boot with the RCC chipset. I get > the following: Can you be more specific than "it doesn't seem to boot:"? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 21:37:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by hub.freebsd.org (Postfix) with ESMTP id 8247614F2D for ; Tue, 11 Jan 2000 21:37:28 -0800 (PST) (envelope-from archer@lucky.net) Received: from 207-172-82-4.s4.as7.xnb.nj.dialup.rcn.com ([207.172.82.4] helo=unknown.nowhere.org) by smtp01.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 128GTG-0005P6-00; Wed, 12 Jan 2000 00:37:26 -0500 Received: (from archer@localhost) by unknown.nowhere.org (8.9.3/8.9.3) id AAA10170; Wed, 12 Jan 2000 00:34:53 -0500 (EST) (envelope-from archer) Date: Wed, 12 Jan 2000 00:34:53 -0500 (EST) Message-Id: <200001120534.AAA10170@unknown.nowhere.org> From: Alexander Litvin To: "Scott Hess" Cc: hackers@freebsd.org Subject: Re: rfork() [was: Concept check] X-Newsgroups: unknown.freebsd.hackers In-Reply-To: <1d5c01bf5c42$1409d990$1e80000a@avantgo.com> User-Agent: tin/1.4-19991113 ("No Labels") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <1d5c01bf5c42$1409d990$1e80000a@avantgo.com> you wrote: > You've got that backwards - fork() and vfork() can easily be implemented in > terms of rfork() [in fact, I believe all three are implemented in terms of > fork1() in the kernel]. rfork(RFMEM) means that the processes share all > memory - current AND FUTURE. You could use minherit() before fork() to > share current memory, but not future memory. BTW, concerning rfork(RFMEM). Could somebody explain me, why the following simple program is coredumping: #include #include volatile int data=0; int main() { volatile int pid=0; int status; pid=rfork(RFPROC|RFMEM|RFCFDG); if(pid==-1) { perror("rfork"); exit(-1); } if(pid!=0) { wait(&status); printf("Data is %d\n",data); } else data=1; } --- The world is coming to an end. Please log off. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 21:57: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8B46015500 for ; Tue, 11 Jan 2000 21:57:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA67332; Tue, 11 Jan 2000 21:56:58 -0800 (PST) (envelope-from dillon) Date: Tue, 11 Jan 2000 21:56:58 -0800 (PST) From: Matthew Dillon Message-Id: <200001120556.VAA67332@apollo.backplane.com> To: Alexander Litvin Cc: "Scott Hess" , hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] References: <200001120534.AAA10170@unknown.nowhere.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> fork1() in the kernel]. rfork(RFMEM) means that the processes share all :> memory - current AND FUTURE. You could use minherit() before fork() to :> share current memory, but not future memory. : :BTW, concerning rfork(RFMEM). Could somebody explain me, why the :following simple program is coredumping: You cannot call rfork() with RFMEM directly from a C program. You have to use assembly (has anyone created a native clone() call yet to do all the hard work?). The reason is that rfork(RFMEM) does not give the new process a new stack, so both the old and new processes wind up on the same original stack and stomp all over each other. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 22:41:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id F01B414FAD for ; Tue, 11 Jan 2000 22:41:38 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 5219 invoked by uid 1001); 12 Jan 2000 06:41:29 -0000 Date: Tue, 11 Jan 2000 22:41:29 -0800 From: Jason Evans To: Matthew Dillon Cc: Alexander Litvin , Scott Hess , hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] Message-ID: <20000111224129.K302@sturm.canonware.com> References: <200001120534.AAA10170@unknown.nowhere.org> <200001120556.VAA67332@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001120556.VAA67332@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Jan 11, 2000 at 09:56:58PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 09:56:58PM -0800, Matthew Dillon wrote: > > :> fork1() in the kernel]. rfork(RFMEM) means that the processes share all > :> memory - current AND FUTURE. You could use minherit() before fork() to > :> share current memory, but not future memory. > : > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the > :following simple program is coredumping: > > You cannot call rfork() with RFMEM directly from a C program. You > have to use assembly (has anyone created a native clone() call yet > to do all the hard work?). > > The reason is that rfork(RFMEM) does not give the new process a new > stack, so both the old and new processes wind up on the same original > stack and stomp all over each other. There is an implementation of clone() in the linuxthreads port, written by Richard Seaman. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 11 23: 1: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 543E614E16 for ; Tue, 11 Jan 2000 23:01:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA67787; Tue, 11 Jan 2000 23:01:04 -0800 (PST) (envelope-from dillon) Date: Tue, 11 Jan 2000 23:01:04 -0800 (PST) From: Matthew Dillon Message-Id: <200001120701.XAA67787@apollo.backplane.com> To: Jason Evans Cc: Alexander Litvin , Scott Hess , hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] References: <200001120534.AAA10170@unknown.nowhere.org> <200001120556.VAA67332@apollo.backplane.com> <20000111224129.K302@sturm.canonware.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> The reason is that rfork(RFMEM) does not give the new process a new :> stack, so both the old and new processes wind up on the same original :> stack and stomp all over each other. : :There is an implementation of clone() in the linuxthreads port, written by :Richard Seaman. : :Jason No manual page, tho :-( -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 2: 8:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from erg.abdn.ac.uk (percy.erg.abdn.ac.uk [139.133.204.86]) by hub.freebsd.org (Postfix) with SMTP id 74BDE14F7E for ; Wed, 12 Jan 2000 02:08:36 -0800 (PST) (envelope-from mahesh@erg.abdn.ac.uk) Received: from erg.abdn.ac.uk (blueberry-mac.erg.abdn.ac.uk [139.133.207.9]) by erg.abdn.ac.uk (8.9.3/8.9.3) with ESMTP id KAA05751; Wed, 12 Jan 2000 10:13:25 GMT Message-ID: <387C5126.59CD0B75@erg.abdn.ac.uk> Date: Wed, 12 Jan 2000 10:02:37 +0000 From: Mahesh Sooriyabandara Organization: Univerity of Aberdeen X-Mailer: Mozilla 4.7 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org, mahesh@erg.abdn.ac.uk Subject: Schedular!! Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I am trying to modify the "ipfw" code to do some additional processing on receiving a packet. I needed to generate some specific delays intentionally. Schedular should process a packet and it should avoid processing of further packets for a certain perod.(ths will be in millisecond range). I think I can achieve this by using a timer. What is the command I can use to get system time. please e-mail me to - mahesh@erg.abdn.ac.uk. Thanks in advance. mahesh. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 2:15: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id A839E14E2F for ; Wed, 12 Jan 2000 02:14:55 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id LAA26390; Wed, 12 Jan 2000 11:15:00 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200001121015.LAA26390@info.iet.unipi.it> Subject: Re: Schedular!! In-Reply-To: <387C5126.59CD0B75@erg.abdn.ac.uk> from Mahesh Sooriyabandara at "Jan 12, 2000 10:02:37 am" To: Mahesh Sooriyabandara Date: Wed, 12 Jan 2000 11:15:00 +0100 (CET) Cc: hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG i think dummynet(4) already does things you need ? cheers luigi > Hi, > > I am trying to modify the "ipfw" code to do some additional processing > on receiving a packet. I needed to generate some specific delays > intentionally. > > Schedular should process a packet and it should avoid processing of > further packets for a certain perod.(ths will be in millisecond range). > I think I can achieve this by using a timer. > > What is the command I can use to get system time. > > please e-mail me to - mahesh@erg.abdn.ac.uk. > > Thanks in advance. > > mahesh. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 3:33:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtppzh.pzh.nl (webshield.pzh.nl [194.178.168.50]) by hub.freebsd.org (Postfix) with SMTP id 6D5A314F7E for ; Wed, 12 Jan 2000 03:33:19 -0800 (PST) (envelope-from MULHUIJZEN@PZH.NL) Received: FROM smtp.pzh.nl BY smtppzh.pzh.nl ; Wed Jan 12 12:32:36 2000 0000 Received: from PZH40-1-Message_Server by smtp.pzh.nl with Novell_GroupWise; Wed, 12 Jan 2000 12:32:41 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Wed, 12 Jan 2000 12:32:21 +0100 From: "ROGIER MULHUIJZEN" To: Subject: Changes in threading support Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I recently upgraded from 3.2-R to 3.4-R and there's a huge difference in running xmms. On 3.2-R I had to give it a realtime priority (lowest rtprio, 31, worked fine) to make it run smoothly. With that realtime prio it usually worked fine, except when it ran into a bug that made it go into an endless loop..... (fun fun fun) On 3.4-R it works straight out of the box. No realtime prio needed (so no suid root, or manual su to root needed, no more machine hangs when it stuffs up, yay!), just a negative renice when there's a fair load on the system. BUT (and a big but at that) it now consumes all CPU available. 'top' reports 85-90% in the process list, and 60-65% user CPU, 35-40% system CPU and 0-1% interrupt with just X, windowmaker and xmms running (OK and an Eterm + top). So my question is, what has changed between 3.2-R and 3.4-R that could cause this? BTW, I compiled xmms myself, and recompiled on 3.4 too. And is this a xmms issue, or is it a FreeBSD issue? (So I know whether to spend time looking at xmms source and patching that, or whether to get into the threading development) One thing I need to add, but I doubt it has much impact, is that I haven't upgraded my OSS to the 3.4-R version yet (because the stupid webproxy here fucks up transfermode on ftp downloads. "Binary mode? whazzat?") Second question, which libpthread do I need to compile with 'cc -kthread'? DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 7: 3: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by hub.freebsd.org (Postfix) with ESMTP id AE42514C32 for ; Wed, 12 Jan 2000 07:03:05 -0800 (PST) (envelope-from archer@lucky.net) Received: from 207-172-82-152.s25.as6.xnb.nj.dialup.rcn.com ([207.172.82.152] helo=unknown.nowhere.org) by smtp02.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 128PId-0000hX-00 for hackers@freebsd.org; Wed, 12 Jan 2000 10:03:03 -0500 Received: (from archer@localhost) by unknown.nowhere.org (8.9.3/8.9.3) id JAA12686; Wed, 12 Jan 2000 09:33:50 -0500 (EST) (envelope-from archer) Date: Wed, 12 Jan 2000 09:33:50 -0500 (EST) Message-Id: <200001121433.JAA12686@unknown.nowhere.org> From: Alexander Litvin To: hackers@freebsd.org Subject: Re: rfork() [was: Concept check] X-Newsgroups: unknown.freebsd.hackers In-Reply-To: <200001120556.VAA67332@apollo.backplane.com> User-Agent: tin/1.4-19991113 ("No Labels") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the > :following simple program is coredumping: > You cannot call rfork() with RFMEM directly from a C program. You > have to use assembly (has anyone created a native clone() call yet > to do all the hard work?). > The reason is that rfork(RFMEM) does not give the new process a new > stack, so both the old and new processes wind up on the same original > stack and stomp all over each other. Oh, well, I suspected something like that (from what I saw, trying to debug that small piece of code). Should it be at least mentioned in rfork(2)? --- You are only young once, but you can stay immature indefinitely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 7:43:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 794F114DB6 for ; Wed, 12 Jan 2000 07:43:51 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id HAA25796; Wed, 12 Jan 2000 07:43:18 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id HAA23563; Wed, 12 Jan 2000 07:43:14 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id HAA17559; Wed, 12 Jan 2000 07:42:03 -0800 (PST) Message-ID: <387CA1EF.5F4C84F4@softweyr.com> Date: Wed, 12 Jan 2000 08:46:55 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: shel@softweyr.com Cc: hackers@freebsd.org Subject: Re: rfork() [was: Concept check] References: <200001120534.AAA10170@unknown.nowhere.org> <200001120556.VAA67332@apollo.backplane.com> <20000111224129.K302@sturm.canonware.com> <200001120701.XAA67787@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :> > :> The reason is that rfork(RFMEM) does not give the new process a new > :> stack, so both the old and new processes wind up on the same original > :> stack and stomp all over each other. > : > :There is an implementation of clone() in the linuxthreads port, written by > :Richard Seaman. > : > :Jason > > No manual page, tho :-( Sheldon, do you want to tackle that one? You seem to be in a manpage mood these days. -- "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-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 7:44:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id B0B7214DB8 for ; Wed, 12 Jan 2000 07:44:09 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id HAA25802; Wed, 12 Jan 2000 07:43:31 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id HAA23576; Wed, 12 Jan 2000 07:43:26 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id HAA17568; Wed, 12 Jan 2000 07:42:14 -0800 (PST) Message-ID: <387CA1FA.3B14779D@softweyr.com> Date: Wed, 12 Jan 2000 08:47:06 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: rfork() [was: Concept check] References: <200001120534.AAA10170@unknown.nowhere.org> <200001120556.VAA67332@apollo.backplane.com> <20000111224129.K302@sturm.canonware.com> <200001120701.XAA67787@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :> > :> The reason is that rfork(RFMEM) does not give the new process a new > :> stack, so both the old and new processes wind up on the same original > :> stack and stomp all over each other. > : > :There is an implementation of clone() in the linuxthreads port, written by > :Richard Seaman. > : > :Jason > > No manual page, tho :-( Sheldon, do you want to tackle that one? You seem to be in a manpage mood these days. -- "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-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 7:47:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id B611014DB8 for ; Wed, 12 Jan 2000 07:47:25 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 128PzL-000LYw-00; Wed, 12 Jan 2000 17:47:11 +0200 From: Sheldon Hearn To: Wes Peters Cc: hackers@freebsd.org Subject: Re: rfork() [was: Concept check] In-reply-to: Your message of "Wed, 12 Jan 2000 08:47:06 MST." <387CA1FA.3B14779D@softweyr.com> Date: Wed, 12 Jan 2000 17:47:11 +0200 Message-ID: <82889.947692031@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 12 Jan 2000 08:47:06 MST, Wes Peters wrote: > Sheldon, do you want to tackle that one? You seem to be in a manpage mood > these days. If someone writes up plain text for the manual page, I'll be more than happy to do mdoc mark-up and grammar clean-ups. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 7:50:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by hub.freebsd.org (Postfix) with ESMTP id AB83B1558B for ; Wed, 12 Jan 2000 07:50:02 -0800 (PST) (envelope-from danhil@cwnt.com) Received: from unspecified.host (ras3-p218.hfa.netvision.net.il [62.0.147.218]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id RAA24546 for ; Wed, 12 Jan 2000 17:49:51 +0200 (IST) Received: from 192.168.0.46 ([192.168.0.46]) by 192.168.0.1 (WinRoute 3.04g) with SMTP; Wed, 12 Jan 2000 17:49:49 +0200 Message-ID: <055801bf5d14$c463ff00$2e00a8c0@cwnt.co.il> From: "Daniel Hilevich" To: Subject: 'File Exists' message in ifconfig Date: Wed, 12 Jan 2000 17:50:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I keep getting the message 'ifconfig: ioctl (SIOCAIFADDR): File exists' when I configuring an interface. The interface I'm configuring works above the sppp interface. I noticed that in the sppp driver code, the first thing it does upon recieving an SIOCSIFADDR ioctl (function aifioctl) is to call if_up(ifp). Maybe this is the problem? Thanx --- Daniel Hilevich mailto:danhil@cwnt.com Tel: +972-4-9592203 ext. 214 Charlotte's Web Networks LTD. http://www.cwnt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 8:52:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id AF9BD14C14 for ; Wed, 12 Jan 2000 08:52:31 -0800 (PST) (envelope-from rminnich@lanl.gov) Received: from mini.acl.lanl.gov (root@mini.acl.lanl.gov [128.165.147.34]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id JAA1030982 for ; Wed, 12 Jan 2000 09:52:29 -0700 (MST) Received: from localhost (rminnich@localhost) by mini.acl.lanl.gov (8.9.3/8.8.8) with ESMTP id JAA06286 for ; Wed, 12 Jan 2000 09:52:29 -0700 X-Authentication-Warning: mini.acl.lanl.gov: rminnich owned process doing -bs Date: Wed, 12 Jan 2000 09:52:29 -0700 (MST) From: "Ronald G. Minnich" X-Sender: rminnich@mini.acl.lanl.gov To: hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] In-Reply-To: <200001121433.JAA12686@unknown.nowhere.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 12 Jan 2000, Alexander Litvin wrote: > Matthew Dillon wrote: > > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the > > :following simple program is coredumping: > > You cannot call rfork() with RFMEM directly from a C program. You > > have to use assembly (has anyone created a native clone() call yet > > to do all the hard work?). OK, I'd like to propose another option to rfork to make it a little more usable for mortals. The option is RFSTACK. This will cause rfork to work like my original version, in that the stack segment (all memory from USERSTACK and up) will be cloned. This would really make a big improvement in rfork usability. Comments? ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 9:47:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 045ED15506 for ; Wed, 12 Jan 2000 09:47:17 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 294; Wed, 12 Jan 2000 09:42:56 -0800 Message-ID: <24d101bf5d24$f54cf350$1e80000a@avantgo.com> From: "Scott Hess" To: "Ronald G. Minnich" , References: Subject: Re: rfork() [was: Concept check] Date: Wed, 12 Jan 2000 09:46:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ronald G. Minnich wrote: > On Wed, 12 Jan 2000, Alexander Litvin wrote: > > Matthew Dillon wrote: > > > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the > > > :following simple program is coredumping: > > > You cannot call rfork() with RFMEM directly from a C program. You > > > have to use assembly (has anyone created a native clone() call yet > > > to do all the hard work?). > > OK, I'd like to propose another option to rfork to make it a little more > usable for mortals. The option is RFSTACK. This will cause rfork to work > like my original version, in that the stack segment (all memory from > USERSTACK and up) will be cloned. > > This would really make a big improvement in rfork usability. > > Comments? That sounds like an _excellent_ suggestion, for general usage. OTOH, it probably wouldn't be useful for building threading libraries, threads couldn't see each other's stacks. A libc version of clone() would probably be more useful, or perhaps an rfork() option which caused it to create a new stack segment which both processes would see (not much different from clone in that case). Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 11:40: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.uni-bielefeld.de (mail.uni-bielefeld.de [129.70.4.90]) by hub.freebsd.org (Postfix) with ESMTP id B0D9314D33 for ; Wed, 12 Jan 2000 11:39:57 -0800 (PST) (envelope-from bfischer@Techfak.uni-bielefeld.de) Received: from frolic.no-support.loc (ppp36-307.hrz.uni-bielefeld.de) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FO800KCIMM9MB@mail.uni-bielefeld.de> for freebsd-hackers@freebsd.org; Wed, 12 Jan 2000 20:39:54 +0100 (MET) Received: (from bjoern@localhost) by frolic.no-support.loc (8.9.3/8.9.3) id UAA00420 for freebsd-hackers@freebsd.org; Wed, 12 Jan 2000 20:35:32 +0100 (CET envelope-from bjoern) Date: Wed, 12 Jan 2000 20:35:32 +0100 From: Bjoern Fischer Subject: Status of NSS/LDAP To: freebsd-hackers@freebsd.org Message-id: <20000112203532.B394@frolic.no-support.loc> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Good morning, I plan to experiment with LDAP, especially using it for distributing the userdb. On the lists I found that some approaches were already discussed. The two major candidates were NSS and userfs, while for the NSS solution someone already posted some initial code (porting NSS fom NetBSD). What is the status of NSS (or userfs) in current? Anyone working on this? Bj=F6rn --=20 -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+=20 ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 12:21:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from tricord.system.pl (tricord.system.pl [195.205.185.10]) by hub.freebsd.org (Postfix) with ESMTP id E58B614BE3; Wed, 12 Jan 2000 12:21:51 -0800 (PST) (envelope-from saper@system.pl) Received: from localhost (saper@localhost [127.0.0.1]) by tricord.system.pl (SYSTEM Internet) with ESMTP id VAA12199; Wed, 12 Jan 2000 21:20:50 +0100 (MET) Date: Wed, 12 Jan 2000 21:20:47 +0100 (MET) From: Marcin Cieslak To: Warner Losh Cc: "Forrest W. Christian" , Mike Smith , Geff Hanoian , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: fbsdboot.exe can't load elf kernels (flash cards off topic) In-Reply-To: <200001121758.KAA15284@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 12 Jan 2000, Warner Losh wrote: > The linear flash cards don't have an ata interface, > so PAO and soon -current won't recognize them. They don't have and we don't need it. Once can easily read them with low-level pccardc interface. In general, flash cards are not meant to be written too often, so I belive we won't put a real filesystem on them. Just a kernel and mfsroot image perhaps? [Added -hackers and please, remove -stable] -- << Marcin Cieslak // saper@system.pl >> ----------------------------------------------------------------- SYSTEM Internet Provider http://www.system.pl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 12:24:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from merc92.us.sas.com (merc92.us.sas.com [192.58.184.17]) by hub.freebsd.org (Postfix) with ESMTP id 25DA114C0F for ; Wed, 12 Jan 2000 12:24:33 -0800 (PST) (envelope-from David.Quattlebaum@sas.com) Received: by merc92.us.sas.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jan 2000 15:24:31 -0500 Message-ID: <5FA575D78630D3118B2E0090276DC89F01B592AF@merc08.us.sas.com> From: David Quattlebaum To: "'mi@aldan.algebra.com'" , 'FreeBSD Hackers' Subject: XPostitPlus-2.3 patch file Date: Wed, 12 Jan 2000 15:24:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Below is a patch file that adds functionality to XPostitPlus-2.3 that I find useful. The patch file adds the following new things. 1) Adds a new "Hide All Notes" menu selection. Files changed are xpostit.h, menu.c, note.c 2) Makes the "Find a Note" window bigger, but not too large. File changed is findnote.c This works fine with my Dell 21" monitor, your mileage may vary. Comments welcome. 3) Sort all notes by title. This helps with "Find a note". Files changed are xpostit.h, note.c For sorting, I changed the notes list to a doubly-linked list and implemented a new MoveNote() function that will move a note to it's sorted order. CompareNotes() is used to compare one note with another in regards to sorted order. CompareNotes() also handles the "Note 2" before "Note 10" problem correctly. This has been built on a FreeBSD 4.0-19991223-SNAP system. --------------------8< cut-here ------------------------------------- --- xpostit.h.orig Sat Sep 14 23:59:14 1996 +++ xpostit.h Tue Jan 11 21:15:32 2000 @@ -245,2 +245,3 @@ struct _PostItNote *pn_next; /* pointer to next note record */ + struct _PostItNote *pn_prev; /* pointer to prev note record */ } PostItNote; @@ -335,2 +336,3 @@ void UnHideAllNotes(); +void HideAllNotes(); void LowerAllNotes(); --- findnote.c.orig Fri Apr 12 13:51:30 1996 +++ findnote.c Sat Jan 8 13:46:51 2000 @@ -219,3 +219,3 @@ nargs = 0; - SetArg(XtNheight, 100); + SetArg(XtNheight, (int)((i>39) ? 839 : i*21.5)); SetArg(XtNwidth, 200); --- menu.c.orig Tue May 7 16:02:32 1996 +++ menu.c Sat Jan 8 10:51:53 2000 @@ -69,11 +69,13 @@ "Unhide All Notes", -#define MenuCascade 12 +#define MenuHideAll 12 + "Hide All Notes", +#define MenuCascade 13 "Cascade Notes", -#define MenuFindANote 13 +#define MenuFindANote 14 "Find A Note", -#define EndNoteFunctions 14 +#define EndNoteFunctions 15 " ", -#define MenuExit 15 +#define MenuExit 16 "Exit", -#define MenuLastEntry 16 +#define MenuLastEntry 17 0, @@ -182,2 +184,5 @@ UnHideAllNotes(); + break; + case MenuHideAll: + HideAllNotes(); break; --- note.c.orig Sat Sep 14 19:31:30 1996 +++ note.c Wed Jan 12 14:37:21 2000 @@ -112,2 +112,4 @@ static PostItNote *AllocNote(); +static PostItNote *MoveNote(); +static int CompareNotes(); @@ -213,2 +215,3 @@ pn = AllocNote(NewIndex); + pn = MoveNote(pn); @@ -369,2 +372,6 @@ * Get a note structure. + * we will allocate this note, + * put it on the note chain, + * when we have finished filling it in, we + * will put note in sorted order. */ @@ -439,2 +446,8 @@ + /* + * Move this note to it's sorted order + * sorted by title (or note number) + */ + MoveNote(pn); + /* @@ -490,2 +503,24 @@ +/* + * HideAllNotes - hide all unhidden notes + */ +void +HideAllNotes() +{ + register PostItNote *pn; + Boolean found; + + found = False; + for (pn = notes; pn != NULL; pn = pn->pn_next) + if ( pn->pn_hidden == False) + { + XtPopdown ( pn->pn_shellwidget ); + pn->pn_hidden = True; + found = True; + } + + if ( !found ) + ErrPopUp("There are no notes to hide."); +} + /* @@ -1590,2 +1625,3 @@ NameIt(pn, confirm, cancel); + } @@ -1841,2 +1877,8 @@ XtSetSensitive ( pn->pn_savewidget, True ); + + /* + * Move the note to it's proper sorted order + */ + MoveNote(pn); + } @@ -2001,4 +2043,3 @@ /* - * Allocate a structure. - */ + * Allocate a structure. */ if (notes == NULL) { @@ -2006,2 +2047,3 @@ pn = notes; + pn->pn_prev = NULL; } @@ -2012,2 +2054,3 @@ pn->pn_next = (PostItNote *) SafeAlloc(sizeof(PostItNote)); + pn->pn_next->pn_prev = pn; pn = pn->pn_next; @@ -2063,2 +2106,107 @@ return(NULL); +} + +/* + * MoveNote - move the given note to it's sorted position in + * list of notes. The sort field is pn_name. + * + * When a note is added, it is always added to + * the end of the list. + */ +static PostItNote * +MoveNote(note) +PostItNote *note; +{ + register PostItNote *pn, *prevn; + + /* + * If first and only note, return + */ + if (notes == note && note->pn_next == NULL ) + return(note); + + /* + * then remove note + */ + /* if last note */ + if (note->pn_next == NULL) + note->pn_prev->pn_next = NULL; + /* if first note */ + else if (note->pn_prev == NULL) { + note->pn_next->pn_prev = NULL; + notes = note->pn_next; + } + /* else in middle of list */ + else { + note->pn_prev->pn_next = note->pn_next; + note->pn_next->pn_prev = note->pn_prev; + } + note->pn_prev = note->pn_next = NULL; + + /* + * find first note with name greater than or equal to this + * note + */ + for (pn = notes; pn != NULL; prevn = pn, pn = pn->pn_next) { + if (CompareNotes(pn, note) >= 0) { + /* if we are inserting at beginning of list */ + if (pn == notes) { + notes = note; + } + else { + pn->pn_prev->pn_next = note; + note->pn_prev = pn->pn_prev; + } + note->pn_next = pn; + pn->pn_prev = note; + break; + } + } + + /* + * if pn is NULL, we have the greatest name so far + */ + if (pn == NULL) { + prevn->pn_next = note; + note->pn_next = NULL; + note->pn_prev = prevn; + } + + return(note); +} + +/* + * CompareNotes - Compare one note with another and + * return -1, 0 or 1 + */ +static int +CompareNotes(na, nb) +PostItNote *na, *nb; +{ + int rc; + + /* + * Let's first see if we are comparing, Say, + * "Note 2" against "Note 10". For this type + * of compare, we need a numeric compare, so + * we don't end up with a bad placement (like ls) + */ + if ((strncmp("Note ", na->pn_name, 5) == 0) + && (strncmp("Note ", nb->pn_name, 5) == 0)) { + int numa = atoi(&na->pn_name[5]); + int numb = atoi(&nb->pn_name[5]); + if (numa > numb) + rc = 1; + else if (numa < numb) + rc = -1; + else + rc = 0; + } + /* + * Else let's just do an Alpha compare + */ + else + rc = strcasecmp(na->pn_name, nb->pn_name); + + return(rc); } -- David Quattlebaum, (david.quattlebaum@sas.com) "The early bird may get the worm, but the second mouse gets the cheese" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 12:25:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 9684014DAA for ; Wed, 12 Jan 2000 12:25:51 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id PAA14283; Wed, 12 Jan 2000 15:25:49 -0500 (EST) (envelope-from luoqi) Date: Wed, 12 Jan 2000 15:25:49 -0500 (EST) From: Luoqi Chen Message-Id: <200001122025.PAA14283@lor.watermarkgroup.com> To: hackers@FreeBSD.ORG, rminnich@lanl.gov Subject: Re: rfork() [was: Concept check] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Matthew Dillon wrote: > > > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the > > > :following simple program is coredumping: > > > You cannot call rfork() with RFMEM directly from a C program. You > > > have to use assembly (has anyone created a native clone() call yet > > > to do all the hard work?). > > OK, I'd like to propose another option to rfork to make it a little more > usable for mortals. The option is RFSTACK. This will cause rfork to work > like my original version, in that the stack segment (all memory from > USERSTACK and up) will be cloned. > > This would really make a big improvement in rfork usability. > > Comments? > > ron > It's almost a regular fork(), we lose all the advantages of a single address space. A rfork(RFMEM) wrapper can achieve the same level of usability without sacrificing the performance, and IMO is a preferred solution. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 12:29:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3D7F015244 for ; Wed, 12 Jan 2000 12:29:30 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA41213; Wed, 12 Jan 2000 13:29:28 -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 NAA16286; Wed, 12 Jan 2000 13:29:48 -0700 (MST) Message-Id: <200001122029.NAA16286@harmony.village.org> To: Marcin Cieslak Subject: Re: fbsdboot.exe can't load elf kernels (flash cards off topic) Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 12 Jan 2000 21:20:47 +0100." References: Date: Wed, 12 Jan 2000 13:29:48 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Marcin Cieslak writes: : Once can easily read them with low-level pccardc interface. : In general, flash cards are not meant to be written too often, : so I belive we won't put a real filesystem on them. : Just a kernel and mfsroot image perhaps? Well, there is mfs, which is a DOS FAT that has had an unfortunate collision with logged file systems and I regret to say that there were survivors. One could use lfs if it worked since it tries to avoid writes to the same page over and over, which is what kills normal flash cards. Having them available as at least a read only device would be useful. The pccardc interface is a pain to use :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 13:42:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (dynamic-9.max4-du-ws.dialnetwork.pavilion.co.uk [212.74.9.137]) by hub.freebsd.org (Postfix) with ESMTP id 943C914E1F for ; Wed, 12 Jan 2000 13:42:09 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id VAA35963; Wed, 12 Jan 2000 21:37:44 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (localhost.lan.Awfulhak.org [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id OAA00764; Wed, 12 Jan 2000 14:32:52 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200001121432.OAA00764@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.0 09/18/1999 To: Sheldon Hearn Cc: John and Jennifer Reynolds , freebsd-hackers@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: useful addition to mergemaster (patch included)? In-Reply-To: Message from Sheldon Hearn of "Tue, 11 Jan 2000 11:37:55 +0200." <97595.947583475@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jan 2000 14:32:52 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Mon, 10 Jan 2000 22:21:32 MST, John and Jennifer Reynolds wrote: > > > So, I made a quick hack to mergemaster so it would recognize a new > > "rc" variable called IGNORE_FILE. This file is a list of files > > mergemaster should ignore, or not compare. One filename per line. > > I've been meaning to do something like this for a while, because I also > thought it'd be useful. Thanks! > > I've passed your patch on to the mergemaster maintainers. Wouldn't a more generic always-do-X-to-this-file be better - perhaps maintained in a config file - say /etc/mergemaster.conf: Delete etc/mail/sendmail.cf Delete etc/motd Install etc/defaults/* > Ciao, > Sheldon. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 14: 9:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id 9F27314BE9 for ; Wed, 12 Jan 2000 14:09:30 -0800 (PST) (envelope-from mwlucas@blackhelicopters.org) Received: (from mwlucas@localhost) by blackhelicopters.org (8.9.3/8.9.3) id RAA44152 for hackers@freebsd.org; Wed, 12 Jan 2000 17:09:29 -0500 (EST) (envelope-from mwlucas) From: Michael Lucas Message-Id: <200001122209.RAA44152@blackhelicopters.org> Subject: Reading the kernel sources To: hackers@freebsd.org Date: Wed, 12 Jan 2000 17:09:29 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I find myself in a contract where I sit for eight hours a day and wait for something to break. It pays obscenely well, so I'm putting up with the tedium. So, if I was to sit down and start reading /usr/src/sys, where's the logical place to start? Or should I start elsehwere? Or is there no logical statring place, and I should just assimilate it all en masse? Minesweeper can only fill so many hours in a day, after all. Thanks, ==ml To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 14:26:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gatewaya.anheuser-busch.com (gatewaya.anheuser-busch.com [151.145.250.252]) by hub.freebsd.org (Postfix) with SMTP id 1E54714C16 for ; Wed, 12 Jan 2000 14:26:19 -0800 (PST) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id QAA05795; Wed, 12 Jan 2000 16:29:15 -0600 Received: from stlexggtw002-pozzoli.fw-users.busch.com(151.145.101.130) by gatewaya.anheuser-busch.com via smap (V5.0) id xma005725; Wed, 12 Jan 00 16:28:36 -0600 Received: from stlabcexg006.anheuser-busch.com ([151.145.101.161]) by 151.145.101.130 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 12 Jan 2000 22:25:37 0000 (GMT) Received: by stlabcexg006.anheuser-busch.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jan 2000 16:25:33 -0600 Message-ID: <299BF5F5EF5ED31196760008C7D9AE5D4E2205@STLABCEXG022> From: "Alton, Matthew" To: "'Michael Lucas'" , hackers@freebsd.org Subject: RE: Reading the kernel sources Date: Wed, 12 Jan 2000 16:25:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Get a copy of the 4.4BSD book and read the relevant code along with the various topics. "Of course you're the Messiah! I say you are and I should know, I've followed a few!" -- John Cleese in "Life of Brian" Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 matthew.alton@anheuser-busch.com alton@plantnet.com > -----Original Message----- > From: Michael Lucas [SMTP:mwlucas@blackhelicopters.org] > Sent: Wednesday, January 12, 2000 4:09 PM > To: hackers@freebsd.org > Subject: Reading the kernel sources > > I find myself in a contract where I sit for eight hours a day and wait > for something to break. It pays obscenely well, so I'm putting up > with the tedium. > > So, if I was to sit down and start reading /usr/src/sys, where's the > logical place to start? Or should I start elsehwere? Or is there no > logical statring place, and I should just assimilate it all en masse? > > Minesweeper can only fill so many hours in a day, after all. > > Thanks, > ==ml > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 14:55:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nyct.net (bsd4.nyct.net [204.141.86.6]) by hub.freebsd.org (Postfix) with ESMTP id CF66214DFD for ; Wed, 12 Jan 2000 14:55:49 -0800 (PST) (envelope-from mbac@nyct.net) Received: from bsd1.nyct.net (mbac@bsd1.nyct.net [204.141.86.3]) by mail.nyct.net (8.8.8/8.8.7) with ESMTP id RAA28266; Wed, 12 Jan 2000 17:55:48 -0500 (EST) (envelope-from mbac@nyct.net) Received: from localhost (mbac@localhost) by bsd1.nyct.net (8.8.8/8.9.3) with ESMTP id RAA27407; Wed, 12 Jan 2000 17:55:48 -0500 (EST) (envelope-from mbac@nyct.net) X-Authentication-Warning: bsd1.nyct.net: mbac owned process doing -bs Date: Wed, 12 Jan 2000 17:55:47 -0500 (EST) From: Michael Bacarella To: Michael Lucas Cc: hackers@FreeBSD.ORG Subject: Re: Reading the kernel sources In-Reply-To: <200001122209.RAA44152@blackhelicopters.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I find myself in a contract where I sit for eight hours a day and wait > for something to break. It pays obscenely well, so I'm putting up > with the tedium. Wow, how does one come across such a contract? -MB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 15:30:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7693D154F0 for ; Wed, 12 Jan 2000 15:30:38 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id PAA27730; Wed, 12 Jan 2000 15:54:13 -0800 (PST) Date: Wed, 12 Jan 2000 15:54:13 -0800 From: Alfred Perlstein To: Michael Lucas Cc: hackers@FreeBSD.ORG Subject: Re: Reading the kernel sources Message-ID: <20000112155413.U9397@fw.wintelcom.net> References: <200001122209.RAA44152@blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001122209.RAA44152@blackhelicopters.org>; from mwlucas@blackhelicopters.org on Wed, Jan 12, 2000 at 05:09:29PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Michael Lucas [000112 14:35] wrote: > I find myself in a contract where I sit for eight hours a day and wait > for something to break. It pays obscenely well, so I'm putting up > with the tedium. > > So, if I was to sit down and start reading /usr/src/sys, where's the > logical place to start? Or should I start elsehwere? Or is there no > logical statring place, and I should just assimilate it all en masse? I think the answer is to figure out what you're interested in first, some people can write drivers in thier sleep, others fix NFS for kicks, some do both *nudges Luoqi* :) > Minesweeper can only fill so many hours in a day, after all. heh. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 17: 7:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id C57D915565 for ; Wed, 12 Jan 2000 17:07:06 -0800 (PST) (envelope-from mwlucas@blackhelicopters.org) Received: (from mwlucas@localhost) by blackhelicopters.org (8.9.3/8.9.3) id UAA44683; Wed, 12 Jan 2000 20:07:03 -0500 (EST) (envelope-from mwlucas) From: Michael Lucas Message-Id: <200001130107.UAA44683@blackhelicopters.org> Subject: Re: Reading the kernel sources In-Reply-To: <20000112155413.U9397@fw.wintelcom.net> from Alfred Perlstein at "Jan 12, 2000 3:54:13 pm" To: bright@wintelcom.net (Alfred Perlstein) Date: Wed, 12 Jan 2000 20:07:03 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [various offers to take my place deleted] Geez, you people are a lot of help. ;^) So, I have just as much chance of getting it worked out if I just go into netinet as anywhere? Will do. Thanks, ==ml > * Michael Lucas [000112 14:35] wrote: > > I find myself in a contract where I sit for eight hours a day and wait > > for something to break. It pays obscenely well, so I'm putting up > > with the tedium. > > > > So, if I was to sit down and start reading /usr/src/sys, where's the > > logical place to start? Or should I start elsehwere? Or is there no > > logical statring place, and I should just assimilate it all en masse? > > I think the answer is to figure out what you're interested in first, > some people can write drivers in thier sleep, others fix NFS for kicks, > some do both *nudges Luoqi* :) > > > Minesweeper can only fill so many hours in a day, after all. > > heh. > > -Alfred > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 17:21:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 128A9154E7 for ; Wed, 12 Jan 2000 17:21:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA75671; Wed, 12 Jan 2000 17:21:06 -0800 (PST) (envelope-from dillon) Date: Wed, 12 Jan 2000 17:21:06 -0800 (PST) From: Matthew Dillon Message-Id: <200001130121.RAA75671@apollo.backplane.com> To: hackers@freebsd.org Subject: Encryption rules changes coming up - win for open source Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The last two paragraphs are the most relevant to us. http://www.nytimes.com/reuters/technology/tech-tech-encryption.html -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 17:30:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 1334D14E2F for ; Wed, 12 Jan 2000 17:30:22 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id MAA17152; Thu, 13 Jan 2000 12:00:03 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200001130121.RAA75671@apollo.backplane.com> Date: Thu, 13 Jan 2000 12:00:03 +1030 (CST) From: "Daniel O'Connor" To: Matthew Dillon Subject: RE: Encryption rules changes coming up - win for open source Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 13-Jan-00 Matthew Dillon wrote: > The last two paragraphs are the most relevant to us. > http://www.nytimes.com/reuters/technology/tech-tech-encryption.html So does this mean we OpenSSH in the base system some time soon? :) (Post RSA patent expiry?) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 18:23:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 67F0314CF9 for ; Wed, 12 Jan 2000 18:23:10 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.9.3/8.9.3) id DAA62690; Thu, 13 Jan 2000 03:01:01 +0100 (CET) (envelope-from olli) Date: Thu, 13 Jan 2000 03:01:01 +0100 (CET) Message-Id: <200001130201.DAA62690@dorifer.heim3.tu-clausthal.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG Reply-To: freebsd-hackers@FreeBSD.ORG Subject: Re: Encryption rules changes coming up - win for open source X-Newsgroups: list.freebsd-hackers In-Reply-To: <85j9fc$1mso$1@atlantis.rz.tu-clausthal.de> User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (FreeBSD/3.4-19991219-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote in list.freebsd-hackers: > The last two paragraphs are the most relevant to us. > > http://www.nytimes.com/reuters/technology/tech-tech-encryption.html Hmm. These paragraphs don't sound that nice: [...] complex restrictions still affect programrs and others who want to exchange programs or source code to write programs. [...] ``The bad news is, if you want to send an encryption program outside of the United States, you still need to hire a lawyer,'' Davidson added. But then, at the end: People posting ``open source'' programs would be required to send the code, or a Web site address where the code was displayed, to the government. Basically, does this mean something like tar cf - /usr/src/crypto | mail president@whitehouse.gov ? :-) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 19:34:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cx587235-a.chnd1.az.home.com (cx587235-a.chnd1.az.home.com [24.11.88.170]) by hub.freebsd.org (Postfix) with ESMTP id 839E414CD0 for ; Wed, 12 Jan 2000 19:34:29 -0800 (PST) (envelope-from jjreynold@home.com) Received: from whale.home-net (whale [192.168.1.2]) by cx587235-a.chnd1.az.home.com (8.9.3/8.9.3) with ESMTP id UAA05958; Wed, 12 Jan 2000 20:34:10 -0700 (MST) (envelope-from jjreynold@home.com) Received: (from jjreynold@localhost) by whale.home-net (8.9.3/8.9.3) id UAA68798; Wed, 12 Jan 2000 20:34:13 -0700 (MST) (envelope-from jjreynold@home.com) From: John and Jennifer Reynolds MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14461.18357.702309.861628@whale.home-net> Date: Wed, 12 Jan 2000 20:34:13 -0700 (MST) To: Brian Somers Cc: Sheldon Hearn , freebsd-hackers@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: useful addition to mergemaster (patch included)? In-Reply-To: <200001121432.OAA00764@hak.lan.Awfulhak.org> References: <97595.947583475@axl.noc.iafrica.com> <200001121432.OAA00764@hak.lan.Awfulhak.org> X-Mailer: VM 6.73 under Emacs 20.5.1 Cc: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ On Wednesday, January 12, Brian Somers wrote: ] > > Wouldn't a more generic always-do-X-to-this-file be better - perhaps > maintained in a config file - say /etc/mergemaster.conf: > > Delete etc/mail/sendmail.cf > Delete etc/motd > Install etc/defaults/* > Indeed that would be a better way to do it, I concur. Perhaps further hacks will amount to that. I'll just be happy if my hack is committed ;-). -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation jreynold@sedona.ch.intel.com My opinions are mine, not Intel's. Running jjreynold@home.com FreeBSD 3.4-STABLE. FreeBSD: The Power to Serve. http://members.home.com/jjreynold/ Come join us!!! @ http://www.FreeBSD.org/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 20:32: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226]) by hub.freebsd.org (Postfix) with ESMTP id 0977514F00 for ; Wed, 12 Jan 2000 20:32:00 -0800 (PST) (envelope-from jabley@tardis.patho.gen.nz) Received: (from jabley@localhost) by tardis.patho.gen.nz (8.9.3/8.9.3) id RAA08246 for freebsd-hackers@FreeBSD.ORG; Thu, 13 Jan 2000 17:31:57 +1300 (NZDT) Date: Thu, 13 Jan 2000 17:31:57 +1300 From: Joe Abley To: freebsd-hackers@FreeBSD.ORG Subject: Re: Encryption rules changes coming up - win for open source Message-ID: <20000113173155.B8613@patho.gen.nz> References: <85j9fc$1mso$1@atlantis.rz.tu-clausthal.de> <200001130201.DAA62690@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001130201.DAA62690@dorifer.heim3.tu-clausthal.de>; from olli@dorifer.heim3.tu-clausthal.de on Thu, Jan 13, 2000 at 03:01:01AM +0100 X-Files: the Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 13, 2000 at 03:01:01AM +0100, Oliver Fromme wrote: > People posting ``open source'' programs would be required > to send the code, or a Web site address where the code was > displayed, to the government. > > Basically, does this mean something like > tar cf - /usr/src/crypto | mail president@whitehouse.gov > ? :-) Oh, be nice. Put "uuencode" in that pipeline somewhere, at least :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 20:41:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 02B1614E0D; Wed, 12 Jan 2000 20:41:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E14A91CD43B for ; Wed, 12 Jan 2000 20:41:30 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Wed, 12 Jan 2000 20:41:30 -0800 (PST) From: Kris Kennaway To: freebsd-hackers@FreeBSD.ORG Subject: Re: Encryption rules changes coming up - win for open source In-Reply-To: <200001130201.DAA62690@dorifer.heim3.tu-clausthal.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 13 Jan 2000, Oliver Fromme wrote: > But then, at the end: > > People posting ``open source'' programs would be required > to send the code, or a Web site address where the code was > displayed, to the government. > > Basically, does this mean something like > tar cf - /usr/src/crypto | mail president@whitehouse.gov > ? :-) Oh come on, where's your imagination? tar cf - /usr/src/crypto | openssl enc -des-cbc -a -e -k TheOwlFliesAtMidnight | mail echelon@nsa.gov Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 21:25:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (Postfix) with SMTP id 9E07C14D25 for ; Wed, 12 Jan 2000 21:25:06 -0800 (PST) (envelope-from mrcpu@internetcds.com) Received: (qmail 11574 invoked from network); 13 Jan 2000 05:25:03 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 13 Jan 2000 05:25:03 -0000 Date: Wed, 12 Jan 2000 21:23:27 -0800 (PST) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@freebsd.org Subject: 4 port intel card source? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Intel used to have a 4 port 100mbit card in the PRO line. I have lots of the duals and they work fine with FreeBSD, but need the 4 porter for a 1U case... Anybody know of a supplier or can sell me one? It would be much appreciated... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 22:15:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by hub.freebsd.org (Postfix) with ESMTP id 7A87A15000 for ; Wed, 12 Jan 2000 22:15:09 -0800 (PST) (envelope-from crbowman@erols.com) Received: from crbowman.erols.com ([209.122.47.155] helo=fermion) by smtp02.mrf.mail.rcn.net with smtp (Exim 2.12 #3) id 128dXG-00063a-00 for freebsd-hackers@FreeBSD.ORG; Thu, 13 Jan 2000 01:15:07 -0500 X-Sender: crbowman@pop.erols.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 13 Jan 2000 01:14:21 -0500 To: freebsd-hackers@FreeBSD.ORG From: "Christopher R. Bowman" Subject: Re: Encryption rules changes coming up - win for open source In-Reply-To: <200001130201.DAA62690@dorifer.heim3.tu-clausthal.de> References: <85j9fc$1mso$1@atlantis.rz.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 03:01 AM 1/13/00 +0100, you wrote: >Matthew Dillon wrote in list.freebsd-hackers: > > The last two paragraphs are the most relevant to us. > > > > http://www.nytimes.com/reuters/technology/tech-tech-encryption.html > >Hmm. These paragraphs don't sound that nice: > > [...] complex restrictions still affect programrs and > others who want to exchange programs or source code to > write programs. > [...] ``The bad news is, if you want to send an encryption > program outside of the United States, you still need to > hire a lawyer,'' Davidson added. > >But then, at the end: > > People posting ``open source'' programs would be required > to send the code, or a Web site address where the code was > displayed, to the government. > >Basically, does this mean something like >tar cf - /usr/src/crypto | mail president@whitehouse.gov >? :-) The last paragraph would be a step in the right direction but still seems silly. What are they going to do with it? I would really like to see people educate them on the stupidity of sending code to Washington. I think it would be neat if there was one of those blue ribbon campaign where on a flag day every one put all the open source encryption programs they could find up on their web pages, and then sent them to Washington, one to a floppy disk/envelope. It would be kinda neat if 1, 5, 10 or even a hundred thousand little envelopes with 1 floppy a piece showed up it the appropriate Washington office on the same day. Wonder how long the silly send a copy to Washington rule would remain after that. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 12 23:44:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 81E2D150CC for ; Wed, 12 Jan 2000 23:44:21 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 10013 invoked by uid 1001); 13 Jan 2000 07:44:02 -0000 Date: Wed, 12 Jan 2000 23:44:02 -0800 From: Jason Evans To: David O'Brien Cc: hackers@freebsd.org Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile Message-ID: <20000112234402.F302@sturm.canonware.com> References: <200001130455.UAA93546@freefall.freebsd.org> <20000112231010.E302@sturm.canonware.com> <20000112232140.G17687@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000112232140.G17687@dragon.nuxi.com>; from obrien@NUXI.com on Wed, Jan 12, 2000 at 11:21:41PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [CCed to -hackers since this may be of general interest.] On Wed, Jan 12, 2000 at 11:21:41PM -0800, David O'Brien wrote: > I'm still a little puzzled why every call to open got changed to > _libc_open rather than do the magic w/in open(). Consider as an example that open() is a thread cancellation point according to POSIX. If libpthread overrides the libc open() with its own version of open(), then by extension, every function that calls open() can potentially cause thread cancellation. This propagation of cancellation points is legal in a specified list of libc functions, but POSIX also says that *no* functions not in that list may act as cancellation points. That means that we have to be absolutely sure not to propagate cancellation points within libc, and short of constructing and analyzing a full call graph of the libc internals, this is the only way (that I can think of) to assure that libc doesn't incorrectly propagate cancellation points. So, once we switch from libc_r to libpthread, we will have to implement, for example open() and _libc_open() in libpthread, where open() tests for cancellation, then calls into _libc_open(), which does the real work and presumably culminates in a call to _open(). In fact, we can probably make cancellation work correctly even in libc_r now, but I'll convert to libpthread first (the order these things are done in doesn't matter much). Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 1:28:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtppzh.pzh.nl (webshield.pzh.nl [194.178.168.50]) by hub.freebsd.org (Postfix) with SMTP id E67E615073 for ; Thu, 13 Jan 2000 01:28:34 -0800 (PST) (envelope-from MULHUIJZEN@PZH.NL) Received: FROM smtp.pzh.nl BY smtppzh.pzh.nl ; Thu Jan 13 10:27:43 2000 0000 Received: from PZH40-1-Message_Server by smtp.pzh.nl with Novell_GroupWise; Thu, 13 Jan 2000 10:27:45 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 13 Jan 2000 10:27:23 +0100 From: "ROGIER MULHUIJZEN" To: Subject: Fwd: Re: GTK & threading on FreeBSD (and possibly other unices) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_366F7E81.36573B7A" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_366F7E81.36573B7A Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline I'm forwarding this from the GTK development list. According to Owen their is something wrong with the threads implementation.... Is that true? or is it a "It's not the way Linux works, so it must be wrong"-pigheadedness? =) DocWilco --=_366F7E81.36573B7A Content-Type: message/rfc822 Received: from smtppzh.pzh.nl (webshield.pzh.nl [194.178.168.50]) by smtp.pzh.nl; Wed, 12 Jan 2000 20:28:46 +0100 Received: FROM lists.redhat.com BY smtppzh.pzh.nl ; Wed Jan 12 20:28:01 2000 0000 Received: (qmail 20818 invoked by uid 501); 12 Jan 2000 19:24:54 -0000 Resent-Date: 12 Jan 2000 19:24:53 -0000 Resent-Cc: recipient list not shown: ; MBOX-Line: From gtk-devel-list-request@redhat.com Wed Jan 12 14:24:53 2000 X-Authentication-Warning: fresnel.labs.redhat.com: otaylor set sender to otaylor@fresnel.labs.redhat.com using -f To: gtk-devel-list@redhat.com Subject: Re: GTK & threading on FreeBSD (and possibly other unices) References: From: Owen Taylor Date: 12 Jan 2000 12:37:20 -0500 In-Reply-To: "ROGIER MULHUIJZEN"'s message of "Wed, 12 Jan 2000 18:42:14 +0100" Message-ID: Lines: 76 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"RfAIQ2.0.g45.5KDVu"@lists.redhat.com> Resent-From: gtk-devel-list@redhat.com Reply-To: gtk-devel-list@redhat.com X-Mailing-List: archive/latest/538 X-Loop: gtk-devel-list@redhat.com Precedence: list Resent-Sender: gtk-devel-list-request@redhat.com X-URL: http://www.redhat.com "ROGIER MULHUIJZEN" writes: > Hi, > > After getting a bit more intimate with FreeBSD's implementation of > POSIX threads I had another stab at getting gFTP to work. > > The problem I had (after fixing a rather simple compile error with > include files) is that file-transfers (which get their own thread) just > weren't moving. Except when I was doing stuff with the interface. > > After checking gFTP's code I found that all it is rather well coded for > threading, and was using sleep(0) in all the right places. So I had a > look at the main loop, which was gtk_main(). Now that (AFAIK) doesn't > use a sleep(0). So I added it, and presto, gFTP ran as smooth as a > newborn baby. > > What I did exactly was in gtkmain.c at line 476 I added: > > if (g_main_is_running (main_loops->data)) > { > GDK_THREADS_LEAVE (); > sleep(0); > g_main_run (loop); > GDK_THREADS_ENTER (); > gdk_flush (); > } This change doesn't make much sense to me - when there is nothing for the GUI thread to do, then the GUI thread is blocking in select(). And if the main thread is blocking in select() and your other threads aren't running, then you have a bug in your threading implementation. But this wouldn't be the right place to put it anyways, since a) program is free to use g_main_run() directly without going through gtk_main() b) gtk_main() is only called once in a typical program, so this really shouldn't have any effect. Maybe you can explain more about why you think a sleep(0) is necessary. The reason I would expect to see this would be if you had one thread that was constantly locking and unlocking a lock and you wanted to give other threads a chance to get scheduled and grab the lock. But putting a sleep(0) in this spot really shouldn't make any difference, unless gFTP is constantly running recursive main loops. > Now I'm pretty new to GTK's internals, so I'm not sure if the sleep is > in the right place or not. > > The way I figured is: > - It should NOT be outside the LEAVE/ENTER statements, because they > translate to unlock and lock mutex. Sleeping after a lock and before an > unlock seems unhealthy to me Well, sleeping inside the lock would absolutely no good if the purpose of your sleep(0) is to give other threads a chance to grab the lock. > - The gdk_flush should probably follow the g_main_run(loop) ASAP (not > sure what it does) The flush() is basically there makes sure that pending X calls get done before a program exits. (There is an implicit XFlush() before GDK goes into a select(), but at this point, there may be no subsequent iterations, so we need an explicit flush. Regards, Owen -- To unsubscribe: mail gtk-devel-list-request@redhat.com with "unsubscribe" as the Subject. --=_366F7E81.36573B7A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 2:44: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from security.za.net (security.za.net [209.212.100.194]) by hub.freebsd.org (Postfix) with ESMTP id ECF5114CA6 for ; Thu, 13 Jan 2000 02:44:00 -0800 (PST) (envelope-from lists@security.za.net) Received: from localhost (lists@localhost) by security.za.net (8.9.3/8.9.3) with ESMTP id MAA05515 for ; Thu, 13 Jan 2000 12:44:43 +0200 (SAST) (envelope-from lists@security.za.net) Date: Thu, 13 Jan 2000 12:44:43 +0200 (SAST) From: To: freebsd-hackers@freebsd.org Subject: Pthreads Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quick question, Does anyone on here know what the equivelant macro for PTHREAD_RECURSIVE_MUTEX_INITALIZER_NP is under freebsd? I cant find anything like this in pthread.h, and Im wondering without it what do I use to initialize a recursive mutex. Any advice would be appreciated Many thanks Andrew Alston Citec Network Securities (Director) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 2:59:41 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id E7FED14CA6 for ; Thu, 13 Jan 2000 02:59:38 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 10818 invoked by uid 1001); 13 Jan 2000 10:59:18 -0000 Date: Thu, 13 Jan 2000 02:59:18 -0800 From: Jason Evans To: ROGIER MULHUIJZEN Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: Re: GTK & threading on FreeBSD (and possibly other unices) Message-ID: <20000113025918.J302@sturm.canonware.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from MULHUIJZEN@PZH.NL on Thu, Jan 13, 2000 at 10:27:23AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 13, 2000 at 10:27:23AM +0100, ROGIER MULHUIJZEN wrote: > I'm forwarding this from the GTK development list. According to Owen > their is something wrong with the threads implementation.... > > Is that true? or is it a "It's not the way Linux works, so it must be > wrong"-pigheadedness? =) Chances are that there is a bug in the application in question. Buggy threaded programs behave differently, depending on the underlying threads implememtation, so the brokenness may not be apparent on another platform. The email exchange that you forwarded doesn't give too much insight into what the problem is (at least not that I picked up). However, the fact that the author thinks sleep(0) is a good idea for encouraging thread switching isn't a good sign (i.e. the author probably doesn't have a good grasp on threaded programming), and makes me further suspect that the application in question is buggy. Chances are good that the application has one or more threads in a buzz loop, which is causing the GUI thread to starve. On Linux, the fact that threads are scheduled by the kernel may nice down the buzzing threads and make the application appear to be working okay. This is all highly speculative. Take it for what it's worth. =) Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 3:58: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D4BA715566 for ; Thu, 13 Jan 2000 03:58:00 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id GAA02950; Thu, 13 Jan 2000 06:57:48 -0500 (EST) Date: Thu, 13 Jan 2000 06:57:48 -0500 (EST) From: Daniel Eischen Message-Id: <200001131157.GAA02950@pcnet1.pcnet.com> To: MULHUIJZEN@PZH.NL, freebsd-hackers@FreeBSD.ORG Subject: Re: Fwd: Re: GTK & threading on FreeBSD (and possibly other unices) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm forwarding this from the GTK development list. According to Owen > their is something wrong with the threads implementation.... > > Is that true? or is it a "It's not the way Linux works, so it must be > wrong"-pigheadedness? =) What version of FreeBSD are you using? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 4: 1:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtppzh.pzh.nl (webshield.pzh.nl [194.178.168.50]) by hub.freebsd.org (Postfix) with SMTP id EBAFD1533D for ; Thu, 13 Jan 2000 04:01:47 -0800 (PST) (envelope-from MULHUIJZEN@PZH.NL) Received: FROM smtp.pzh.nl BY smtppzh.pzh.nl ; Thu Jan 13 13:00:29 2000 0000 Received: from PZH40-1-Message_Server by smtp.pzh.nl with Novell_GroupWise; Thu, 13 Jan 2000 13:00:32 +0100 Message-Id: X-Mailer: Novell GroupWise 5.5.2 Date: Thu, 13 Jan 2000 13:00:16 +0100 From: "ROGIER MULHUIJZEN" To: Subject: Re: Fwd: Re: GTK & threading on FreeBSD (and possibly other unices) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm running 3.4-RELEASE. DocWilco >>> Daniel Eischen 01/13 12:57 PM >>> > I'm forwarding this from the GTK development list. According to Owen > their is something wrong with the threads implementation.... > > Is that true? or is it a "It's not the way Linux works, so it must be > wrong"-pigheadedness? =) What version of FreeBSD are you using? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 4: 5: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8529714C24 for ; Thu, 13 Jan 2000 04:05:05 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA03880; Thu, 13 Jan 2000 07:05:00 -0500 (EST) Date: Thu, 13 Jan 2000 07:05:00 -0500 (EST) From: Daniel Eischen Message-Id: <200001131205.HAA03880@pcnet1.pcnet.com> To: freebsd-hackers@FreeBSD.ORG, lists@security.za.net Subject: Re: Pthreads Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Quick question, > > Does anyone on here know what the equivelant macro for > PTHREAD_RECURSIVE_MUTEX_INITALIZER_NP is under freebsd? I cant find > anything like this in pthread.h, and Im wondering without it what do I use > to initialize a recursive mutex. > > Any advice would be appreciated Well, the '_NP' in PTHREAD_RECURSIVE_MUTEX_INITALIZER_NP should give you some idea. Hint: Non-portable. There is no PTHREAD_RECURSIVE_MUTEX_INITALIZER_NP in the POSIX standard, and one shouldn't rely on its use. Recursive mutexes can be easily done by the application, just by wrapping them in a structure with an owner and count. That said, SUSv2 does provide a recursive mutex (unlike POSIX). To use a recursive mutex under FreeBSD, use: pthread_mutex_settype(PTHREAD_MUTEX_RECURSIVE); Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 4:18:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3DA831505B for ; Thu, 13 Jan 2000 04:18:22 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA05212; Thu, 13 Jan 2000 07:18:12 -0500 (EST) Date: Thu, 13 Jan 2000 07:18:12 -0500 (EST) From: Daniel Eischen Message-Id: <200001131218.HAA05212@pcnet1.pcnet.com> To: jasone@canonware.com, obrien@NUXI.com Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Consider as an example that open() is a thread cancellation point according > to POSIX. If libpthread overrides the libc open() with its own version of > open(), then by extension, every function that calls open() can potentially > cause thread cancellation. This propagation of cancellation points is > legal in a specified list of libc functions, but POSIX also says that *no* > functions not in that list may act as cancellation points. That means that > we have to be absolutely sure not to propagate cancellation points within > libc, and short of constructing and analyzing a full call graph of the libc > internals, this is the only way (that I can think of) to assure that libc > doesn't incorrectly propagate cancellation points. Use _open internally within libc and libpthread. Have one "open" entry point that is the cancellation version of open. > So, once we switch from libc_r to libpthread, we will have to implement, > for example open() and _libc_open() in libpthread, where open() tests for > cancellation, then calls into _libc_open(), which does the real work and > presumably culminates in a call to _open(). In fact, we can probably make > cancellation work correctly even in libc_r now, but I'll convert to > libpthread first (the order these things are done in doesn't matter much). How are you going to handle locking inside libc, if the locking functions are not inside libc? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 4:24:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id E25BE1523F for ; Thu, 13 Jan 2000 04:24:26 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id HAA05781; Thu, 13 Jan 2000 07:24:19 -0500 (EST) Date: Thu, 13 Jan 2000 07:24:19 -0500 (EST) From: Daniel Eischen Message-Id: <200001131224.HAA05781@pcnet1.pcnet.com> To: MULHUIJZEN@PZH.NL, freebsd-hackers@FreeBSD.ORG Subject: Re: Fwd: Re: GTK & threading on FreeBSD (and possibly other unices) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm running 3.4-RELEASE. Try upgrading to -stable and see if that helps. There were some changes recently merged from -current. If the application uses signals to wakeup threads, then perhaps the -stable version may fix the problems your seeing. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 6:14:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 4CE35154F3 for ; Thu, 13 Jan 2000 06:13:55 -0800 (PST) (envelope-from gjvc@extremis.demon.co.uk) Received: from extremis.demon.co.uk ([194.222.242.30]) by anchor-post-30.mail.demon.net with smtp (Exim 2.12 #1) id 128l0P-000847-0U for hackers@freebsd.org; Thu, 13 Jan 2000 14:13:42 +0000 Received: (qmail 22918 invoked by uid 1010); 13 Jan 2000 12:43:54 -0000 Date: Thu, 13 Jan 2000 12:43:54 +0000 From: George Cox To: Michael Lucas Cc: hackers@freebsd.org Subject: Re: Reading the kernel sources Message-ID: <20000113124354.B321@extremis.demon.co.uk> References: <200001122209.RAA44152@blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <200001122209.RAA44152@blackhelicopters.org>; from mwlucas@blackhelicopters.org on Wed, Jan 12, 2000 at 05:09:29PM -0500 X-Operating-System: FreeBSD 4.0-CURRENT (i386) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12/01 17:09, Michael Lucas wrote: > Minesweeper can only fill so many hours in a day, after all. Must be a long day in your part of the world, then, because it's an NP-complete problem! (http://www.mat.bham.ac.uk/R.W.Kaye/minesw.htm) Heh :-) obSources: try /usr/src/sys/contrib/softupdates/ffs_softdep.c :-) best; gjvc -- [gjvc] 4.4BSD 4.ever! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 6:55:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 8B3081559B for ; Thu, 13 Jan 2000 06:55:30 -0800 (PST) (envelope-from rminnich@lanl.gov) Received: from mini.acl.lanl.gov (root@mini.acl.lanl.gov [128.165.147.34]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id HAA170135 for ; Thu, 13 Jan 2000 07:55:25 -0700 (MST) Received: from localhost (rminnich@localhost) by mini.acl.lanl.gov (8.9.3/8.8.8) with ESMTP id HAA10079 for ; Thu, 13 Jan 2000 07:55:25 -0700 X-Authentication-Warning: mini.acl.lanl.gov: rminnich owned process doing -bs Date: Thu, 13 Jan 2000 07:55:25 -0700 (MST) From: "Ronald G. Minnich" X-Sender: rminnich@mini.acl.lanl.gov To: hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] In-Reply-To: <200001122025.PAA14283@lor.watermarkgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 12 Jan 2000, Luoqi Chen wrote: > It's almost a regular fork(), we lose all the advantages of a single > address space. A rfork(RFMEM) wrapper can achieve the same level of > usability without sacrificing the performance, and IMO is a preferred > solution. I don't see this at all. You get many of the advantages of the single address space: everything is shared save the stack. Most people who have brought this up over the years want this type of behaviour, and find themselves having to hack it in user mode, and not enjoying the experience. I used this very version of rfork extensively for years for shared-memory programming and it was fine. Anyway, if I get to this it goes on my web page .. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 7: 0:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from yyy.or.jp (mail.yyy.or.jp [202.214.252.21]) by hub.freebsd.org (Postfix) with SMTP id 3517B1561B for ; Thu, 13 Jan 2000 07:00:21 -0800 (PST) (envelope-from hnokubi@yyy.or.jp) Received: (qmail 38712 invoked from network); 14 Jan 2000 00:00:10 +0900 Received: from urayasu105.interwave.or.jp (HELO ppp-client.yyy.or.jp) (210.138.157.141) by mail.yyy.or.jp with SMTP; 14 Jan 2000 00:00:10 +0900 Received: from sassaby.nokubi.or.jp (sassaby [192.168.9.3]) by ppp-client.yyy.or.jp (8.9.1/3.5Wpl7-ppp) with ESMTP id XAA05743; Thu, 13 Jan 2000 23:56:26 +0900 (JST) Received: from sassaby.nokubi.or.jp (localhost.nokubi.or.jp [127.0.0.1]) by sassaby.nokubi.or.jp (8.9.3/3.5Wpl7-glove) with ESMTP id XAA00494; Thu, 13 Jan 2000 23:55:52 +0900 (JST) To: "Kenneth D. Merry" Cc: Jonathan Lemon , Andrew Gallatin , hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? In-reply-to: Your message of "Tue, 11 Jan 2000 12:54:53 -0700 ." <20000111125453.A76466@panzer.kdm.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 13 Jan 2000 23:55:52 +0900 From: NOKUBI Hirotaka Message-Id: <20000113150021.3517B1561B@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000111125453.A76466@panzer.kdm.org>, "Kenneth D. Merry" writes: >On Tue, Jan 11, 2000 at 13:49:59 -0600, Jonathan Lemon wrote: >> The RCC is probably this one: >> >> pci: unknown ATA vendor = 0x1166, device = 0x0211 >> >> >> I wonder why it flags it as a ATA device, I'm pretty sure this is the >> RCC chip -- the vendor id matches. (I checked this time.) > >It's proably the chip class or something. That could well be an IDE chip, >though. Intel's chipsets usually include an IDE controller. > >Does anyone have a URL for "RCC"? I also want to know a URL. My NEC PC98 (using x86 CPU, but not PC-AT compatible) uses RCC Champion as it's chipset. (Sorry not Champion II/III, it's slightly old machine.) I'll attach dmesg from it. RCC Champion is attached like this. > pcib0: on motherboard FreeBSD-3.2 (I'm not sure, 3.1?) was running fine too. ---- NOKUBI Hirotaka Fingerprint20 = DEBC 0793 7CD6 92F1 0A1F A792 9E2F EEEE A41B 171D Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1994-1999 FreeBSD(98) porting team. Copyright (c) 1992 A.Kojima F.Ukai M.Ishii (KMC). Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Tue Dec 14 23:41:04 JST 1999 h-nokubi@alphazeal.nokubi.or.jp:/usr/src/src/sys/compile/MP Calibrating clock(s) ... TSC clock: 265922163 Hz, i8254 clock: 2457598 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 2457600 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II (265.92-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping = 3 Features=0x80fbff real memory = 100638720 (98280K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00318000 - 0x05ff7fff, 97386496 bytes (23776 pages) avail memory = 94453760 (92240K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpint 7 -> irq 8 IOAPIC #0 intpint 8 -> irq 9 IOAPIC #0 intpint 9 -> irq 10 IOAPIC #0 intpint 10 -> irq 11 IOAPIC #0 intpint 11 -> irq 12 IOAPIC #0 intpint 12 -> irq 13 IOAPIC #0 intpint 13 -> irq 14 IOAPIC #0 intpint 14 -> irq 15 SMP: CPU0 apic_initialize(): lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 bios32: Found BIOS32 Service Directory header at 0xc00f4c40 bios32: Entry = 0xf5612 (c00f5612) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x1bb9b pnpbios: Found PnP BIOS data at 0xc00f51b0 pnpbios: Entry = d8000:3a Rev = 1.0 Other BIOS signatures found: ACPI: 00000000 Preloaded elf kernel "kernel.up" at 0xc02fc000. Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x000001ff pci_open(1): mode 1 addr port (0x0cf8) is 0x80000070 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=00051166) npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=00051166) pcib0: on motherboard found-> vendor=0x1166, dev=0x0005, revid=0x00 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 found-> vendor=0x1033, dev=0x003b, revid=0x01 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 found-> vendor=0x1033, dev=0x0009, revid=0x02 class=03-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 found-> vendor=0x9004, dev=0x6078, revid=0x01 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base 00006800, size 8 map[14]: type 1, range 32, base 20000000, size 12 found-> vendor=0x8086, dev=0x1229, revid=0x02 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=3 map[10]: type 1, range 32, base 20001000, size 12 map[14]: type 1, range 32, base 00006000, size 5 map[18]: type 1, range 32, base fed00000, size 20 found-> vendor=0x102b, dev=0x0519, revid=0x01 class=03-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base 20004000, size 14 map[14]: type 1, range 32, base 23000000, size 23 pci0: on pcib0 isab0: at device 6.0 on pci0 isa0: on isab0 vga-pci0: at device 7.0 on pci0 ahc0: irq 10 at device 10.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs ahc0: Downloading Sequencer Program... 409 instructions downloaded fxp0: irq 3 at device 11.0 on pci0 fxp0: Ethernet address 00:00:4c:13:ea:bc vga-pci1: irq 10 at device 14.0 on pci0 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices fdc0 at port 0x90-0x97 irq 11 drq 2 on isa0 fd0: <1.44M FDD> on fdc0 drive 0 wdc0 at port 0x640-0x647 irq 9 on isa0 wdc0: unit 1 (atapi): , removable, iordis wcd0: drive speed 1033KB/sec, 256KB cache wcd0: supported read types: CD-DA wcd0: Audio: play, 256 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: no/blank disc inside, unlocked pckbd0: at port 0x41 irq 1 on isa0 kbd0: pckbd0, generic (0), config:0x0, flags:0x1d0000 gdc0: on isa0 fb0: gdc0, gdc, type:PC-98x1 (6), flags:0x70043 fb0: port:0x60-0x6f, crtc:0x60, mem:0xa0000 0x48000 fb0: init mode:98, bios mode:98, current mode:98 fb0: window:0xc00a0000 size:32k gran:32k, buf:0 size:0k sc0: on isa0 sc0: PC-98x1 <16 virtual consoles, flags=0x0> sc0: fb0 kbd0 sio0 at port 0x30 irq 4 on isa0 sio0: type 8251 (internal fast) sio1: irq maps: 0x8001 0x8021 0x8001 0x8001 sio1 at port 0x238 irq 5 flags 0x12000010 on isa0 sio1: type 16550A, console ppc: parallel port found at 0x140 ppc0: ECP SPP ECP+EPP SPP ppc0 at port 0x140-0x147 irq 14 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip: irq 14 plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 mse0 at port 0x7fd9 irq 13 on isa0 mss0 at port 0xf40 irq 12 drq 1 on isa0 [IRQ Conflict?]snd0: isa_probe_children: probing PnP devices stray irq 7 SMP: enabled INTs: 1, 3, 4, 5, 7, 9, 10, 11, 12, 13, 14, apic_imen: 0x00ff8145 BIOS Geometries: 0:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. APIC_IO: routing 8254 via 8259 on pin 0 new masks: bio 48000a00, tty 43006032, net 4700603a Waiting 15 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. SMP: AP CPU #1 Launched! SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff ahc0: Selection Timeout on A:1. 1 SCBs aborted ahc0: Selection Timeout on A:2. 1 SCBs aborted ahc0: Selection Timeout on A:3. 1 SCBs aborted ahc0: Selection Timeout on A:4. 1 SCBs aborted ahc0: Selection Timeout on A:5. 1 SCBs aborted ahc0: Selection Timeout on A:6. 1 SCBs aborted ahc0: target 0 synchronous at 20.0MHz, offset = 0xf Creating DISK da0 pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number F25D9969 pass0: 20.000MB/s transfers (20.000MHz, offset 15) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number F25D9969 da0: 20.000MB/s transfers (20.000MHz, offset 15) da0: 2063MB (4226725 512 byte sectors: 8H 32S/T 16509C) Mounting root from ufs:/dev/da0s2a da0s1: mid 0xa0, start 256, end = 1024255, size 1024000: OK da0s2: mid 0x94, start 1024256, end = 2048255, size 1024000: OK da0s3: mid 0xa0, start 2048256, end = 2458111, size 409856: OK da0s4: mid 0x94, start 2458112, end = 4226303, size 1768192: OK start_init: trying /sbin/init To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 7:36:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id EFC3615207 for ; Thu, 13 Jan 2000 07:36:09 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E00981CA0; Thu, 13 Jan 2000 23:36:07 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: "Ronald G. Minnich" Cc: hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] In-Reply-To: Message from "Ronald G. Minnich" of "Thu, 13 Jan 2000 07:55:25 MST." Date: Thu, 13 Jan 2000 23:36:07 +0800 From: Peter Wemm Message-Id: <20000113153607.E00981CA0@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Ronald G. Minnich" wrote: > On Wed, 12 Jan 2000, Luoqi Chen wrote: > > > It's almost a regular fork(), we lose all the advantages of a single > > address space. A rfork(RFMEM) wrapper can achieve the same level of > > usability without sacrificing the performance, and IMO is a preferred > > solution. > > I don't see this at all. You get many of the advantages of the single > address space: everything is shared save the stack. Most people who have > brought this up over the years want this type of behaviour, and find > themselves having to hack it in user mode, and not enjoying the > experience. I used this very version of rfork extensively for years for > shared-memory programming and it was fine. One of the things that rfork(RFMEM) does in our implementation is to share the everything from the VM data structures down to the page tables themselves. In that sharing style, it isn't possible to have processes sharing everything but the stack, at least not without context switching PTD[] slots. We used to do this on SMP for the per-cpu pages which is what prevented us from doing RFMEM style threads on SMP boxes for so long as the same pmap page directory couldn't be loaded twice on different cpus. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 8:55:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 94C5914DBE for ; Thu, 13 Jan 2000 08:55:51 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id IAA27216; Thu, 13 Jan 2000 08:55:49 -0800 (PST) (envelope-from obrien) Date: Thu, 13 Jan 2000 08:55:49 -0800 From: "David O'Brien" To: Daniel Eischen Cc: jasone@canonware.com, hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile Message-ID: <20000113085549.R14330@relay.nuxi.com> Reply-To: obrien@NUXI.com References: <200001131218.HAA05212@pcnet1.pcnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <200001131218.HAA05212@pcnet1.pcnet.com> X-Operating-System: FreeBSD 3.4-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: > > Use _open internally within libc and libpthread. Have one "open" > entry point that is the cancellation version of open. This is what it appears Solaris 7 does. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 9:40:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CE3D3155D1 for ; Thu, 13 Jan 2000 09:40:14 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id MAA20749; Thu, 13 Jan 2000 12:40:06 -0500 (EST) Date: Thu, 13 Jan 2000 12:40:05 -0500 (EST) From: Daniel Eischen To: "David O'Brien" Cc: jasone@canonware.com, hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile In-Reply-To: <20000113085549.R14330@relay.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 13 Jan 2000, David O'Brien wrote: > On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: > > > > Use _open internally within libc and libpthread. Have one "open" > > entry point that is the cancellation version of open. > > This is what it appears Solaris 7 does. Yeah, I've noticed that too. If you look at the CVS logs you can see that this was thought about back in '98: $ cvs log -r1.12 libc/i386/SYS.h [ ... ] description: ---------------------------- revision 1.12 date: 1998/05/05 22:06:16; author: jb; state: Exp; lines: +9 -3 branches: 1.12.2; Build the syscalls (in libc, not libc_r) with weak symbols so that libpthread can override them as required. ============================================================================= I don't quite understand the need to have _libc_XXX variants. I think we should just use _XXX internally. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 9:51:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id C334214F16; Thu, 13 Jan 2000 09:51:26 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id JAA18465; Thu, 13 Jan 2000 09:47:05 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA05236; Thu, 13 Jan 2000 09:46:59 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id JAA23621; Thu, 13 Jan 2000 09:45:47 -0800 (PST) Message-ID: <387E1075.6ADE62A5@softweyr.com> Date: Thu, 13 Jan 2000 10:50:45 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Marcin Cieslak Cc: Warner Losh , "Forrest W. Christian" , Mike Smith , Geff Hanoian , freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: fbsdboot.exe can't load elf kernels (flash cards off topic) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcin Cieslak wrote: > > On Wed, 12 Jan 2000, Warner Losh wrote: > > > The linear flash cards don't have an ata interface, > > so PAO and soon -current won't recognize them. > > They don't have and we don't need it. > Once can easily read them with low-level pccardc interface. > In general, flash cards are not meant to be written too often, > so I belive we won't put a real filesystem on them. > Just a kernel and mfsroot image perhaps? Modern flash chips support on the order of 1,000,000 write cycles, so this is not such a concern anymore. There is no reason why we shouldn't put a filesystem on a flash card. A better choice might be the flash disk cards from SanDisk and others, since they do have an ATA interface and look like a small ATA drive to the pccard code. Unless the linear flash cards are a LOT less expensive, there isn't a lot of reason to do all the extra work. -- "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-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 10:33:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B839A14F0C; Thu, 13 Jan 2000 10:33:01 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA44836; Thu, 13 Jan 2000 11:09:09 -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 LAA22848; Thu, 13 Jan 2000 11:09:36 -0700 (MST) Message-Id: <200001131809.LAA22848@harmony.village.org> To: Wes Peters Subject: Re: fbsdboot.exe can't load elf kernels (flash cards off topic) Cc: Marcin Cieslak , "Forrest W. Christian" , Mike Smith , Geff Hanoian , freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org In-reply-to: Your message of "Thu, 13 Jan 2000 10:50:45 MST." <387E1075.6ADE62A5@softweyr.com> References: <387E1075.6ADE62A5@softweyr.com> Date: Thu, 13 Jan 2000 11:09:36 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <387E1075.6ADE62A5@softweyr.com> Wes Peters writes: : Modern flash chips support on the order of 1,000,000 write cycles, so this : is not such a concern anymore. There is no reason why we shouldn't put : a filesystem on a flash card. We weren't talking about modern flash cards :-). These flash cards have 10,000 to 100,000 write cycles per page. : A better choice might be the flash disk cards from SanDisk and others, : since they do have an ATA interface and look like a small ATA drive : to the pccard code. Unless the linear flash cards are a LOT less : expensive, there isn't a lot of reason to do all the extra work. That's why I've done support for the ata flash cards, but haven't yet done the linear flash cards. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 12:40:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 3D9EC1510B for ; Thu, 13 Jan 2000 12:40:29 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id MAA22481; Thu, 13 Jan 2000 12:39:53 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id MAA15326; Thu, 13 Jan 2000 12:39:53 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id MAA04099; Thu, 13 Jan 2000 12:38:37 -0800 (PST) Message-ID: <387E38F7.2DC0C433@softweyr.com> Date: Thu, 13 Jan 2000 13:43:35 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Lucas Cc: hackers@freebsd.org Subject: Re: Reading the kernel sources References: <200001122209.RAA44152@blackhelicopters.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Lucas wrote: > > I find myself in a contract where I sit for eight hours a day and wait > for something to break. It pays obscenely well, so I'm putting up > with the tedium. > > So, if I was to sit down and start reading /usr/src/sys, where's the > logical place to start? Or should I start elsehwere? Or is there no > logical statring place, and I should just assimilate it all en masse? Start with the PR database. Grab a PR, see if you can figure out what makes it go wrong, and then see if you can make it go right. Call this "directed research" of anyone asks what you're doing. Remember, real hackers run -CURRENT on their laptops. ;^) -- "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-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 12:49:44 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.utexas.edu (wb3-a.mail.utexas.edu [128.83.126.138]) by hub.freebsd.org (Postfix) with SMTP id D871B151CC for ; Thu, 13 Jan 2000 12:49:36 -0800 (PST) (envelope-from ramral@mail.utexas.edu) Received: (qmail 29692 invoked by uid 0); 13 Jan 2000 20:49:35 -0000 Received: from begpc77.beg.utexas.edu (HELO begpc77) (129.116.198.120) by umbs-smtp-3 with SMTP; 13 Jan 2000 20:49:35 -0000 Message-Id: <3.0.5.32.20000113150319.009604a0@mail.utexas.edu> X-Sender: ramral@mail.utexas.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 Jan 2000 15:03:19 -0600 To: freebsd-hackers@freebsd.org From: Ramiro Amaya Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am new in this mail list, so I do not have so much experience about the questions I should ask, If I am in the worng place let me know, please. Well my question is related with Solaris 2.6, the story is like this: I have a Solaris 2.5 server which has configured all the printers so I can perint from that machine without any problem; The printers are remotes so I use the IP address on /etc/hosts ( Nis database ). Recently, I update the nis clients to Solaris 2.6, but I am not sure how to configure the printers, is there anybody there who can give me a hand?. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 13:39:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 7DEA9151A7 for ; Thu, 13 Jan 2000 13:39:13 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FOA003HRMRKK0@mta4.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Thu, 13 Jan 2000 15:38:08 -0600 (CST) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id PAA13278; Thu, 13 Jan 2000 15:38:12 -0600 (CST envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Thu, 13 Jan 2000 15:38:08 -0600 From: Chris Costello Subject: Re: your mail In-reply-to: <3.0.5.32.20000113150319.009604a0@mail.utexas.edu> To: Ramiro Amaya Cc: freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000113153808.J2463@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <3.0.5.32.20000113150319.009604a0@mail.utexas.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 13, 2000, Ramiro Amaya wrote: > I am new in this mail list, so I do not have so much experience about the > questions I should ask, If I am in the worng place let me know, please. > Well my question is related with Solaris 2.6, the story is like this: What does this have to do with the FreeBSD operating system? -- |Chris Costello |Software is mind work. Having the right frame of mind is essential. `-------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 13:45:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id C77DB14C29 for ; Thu, 13 Jan 2000 13:45:07 -0800 (PST) (envelope-from mwlucas@blackhelicopters.org) Received: (from mwlucas@localhost) by blackhelicopters.org (8.9.3/8.9.3) id QAA48936; Thu, 13 Jan 2000 16:44:59 -0500 (EST) (envelope-from mwlucas) From: Michael Lucas Message-Id: <200001132144.QAA48936@blackhelicopters.org> Subject: Re: Reading the kernel sources In-Reply-To: <387E38F7.2DC0C433@softweyr.com> from Wes Peters at "Jan 13, 2000 1:43:35 pm" To: wes@softweyr.com (Wes Peters) Date: Thu, 13 Jan 2000 16:44:59 -0500 (EST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > Michael Lucas wrote: > > > > I find myself in a contract where I sit for eight hours a day and wait > > for something to break. It pays obscenely well, so I'm putting up > > with the tedium. > > > > So, if I was to sit down and start reading /usr/src/sys, where's the > > logical place to start? Or should I start elsehwere? Or is there no > > logical statring place, and I should just assimilate it all en masse? > > Start with the PR database. Grab a PR, see if you can figure out what makes > it go wrong, and then see if you can make it go right. Call this "directed > research" of anyone asks what you're doing. Gut reaction: "Geez, I'd like to learn how to swim." "No problem! Just tie these cinderblocks to your wrists and ankles, jump off the deep end, and you'll be ready to go." Second reaction: Ah, what the hell. I might actually fix something. ==ml > Remember, real hackers run -CURRENT on their laptops. ;^) PS: Anyone know the status of zp0 in -current? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 13:47: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id B6D5515599 for ; Thu, 13 Jan 2000 13:47:05 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 35DBF1C2B; Thu, 13 Jan 2000 16:47:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 26BE53819; Thu, 13 Jan 2000 16:47:05 -0500 (EST) Date: Thu, 13 Jan 2000 16:47:05 -0500 (EST) From: Bill Fumerola To: Michael Lucas Cc: Wes Peters , hackers@freebsd.org Subject: Re: Reading the kernel sources In-Reply-To: <200001132144.QAA48936@blackhelicopters.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 13 Jan 2000, Michael Lucas wrote: > PS: Anyone know the status of zp0 in -current? It was a hack and it was put to sleep by someone wielding an axe. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 13:50:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 3C6B314EA2 for ; Thu, 13 Jan 2000 13:50:35 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 13398 invoked by uid 1001); 13 Jan 2000 21:50:10 -0000 Date: Thu, 13 Jan 2000 13:50:10 -0800 From: Jason Evans To: Daniel Eischen Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile Message-ID: <20000113135010.L302@sturm.canonware.com> References: <200001131218.HAA05212@pcnet1.pcnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001131218.HAA05212@pcnet1.pcnet.com>; from eischen@vigrid.com on Thu, Jan 13, 2000 at 07:18:12AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: > > Consider as an example that open() is a thread cancellation point according > > to POSIX. If libpthread overrides the libc open() with its own version of > > open(), then by extension, every function that calls open() can potentially > > cause thread cancellation. This propagation of cancellation points is > > legal in a specified list of libc functions, but POSIX also says that *no* > > functions not in that list may act as cancellation points. That means that > > we have to be absolutely sure not to propagate cancellation points within > > libc, and short of constructing and analyzing a full call graph of the libc > > internals, this is the only way (that I can think of) to assure that libc > > doesn't incorrectly propagate cancellation points. > > Use _open internally within libc and libpthread. Have one "open" > entry point that is the cancellation version of open. It isn't adequate to only have two names with a libpthread. There has to be: 1) _open() -- A name to access the actual system call. 2) _libc_open() -- A name that libc uses internally which by default is the same as _open(), but can be overridden. 3) open() -- The name that an application uses (and cancellation point). As mentioned in my previous email, if we were to remove _libc_open() and use open() instead inside of libc, we would incorrectly propagate cancellation points. If we were to remove _libc_open() and use _open() instead inside of libc, then we would have the problem of some libc functions using system calls directly, where libpthread needs to do call conversion and/or extra bookkeeping work. (I experienced this problem in tests first-hand while doing the conversion; hence the renaming of functions in libc_r.) We can argue about names, but I don't see any way to get around having three names. That said, I get momentarily confused about this every time I have to think about it, so if I'm really missing something, please help me to figure it out. =) > How are you going to handle locking inside libc, if the locking > functions are not inside libc? I dunno. =) Seriously, I haven't given much thought to this yet, and can't claim to understand all the issues involved. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 14:56:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sasknow.com (h139-142-245-96.ss.fiberone.net [139.142.245.96]) by hub.freebsd.org (Postfix) with ESMTP id 957B6152B1 for ; Thu, 13 Jan 2000 14:56:20 -0800 (PST) (envelope-from freebsd@sasknow.com) Received: from localhost (freebsd@localhost) by sasknow.com (8.9.3/8.9.3) with ESMTP id QAA28865; Thu, 13 Jan 2000 16:56:36 -0600 (CST) (envelope-from freebsd@sasknow.com) Date: Thu, 13 Jan 2000 16:56:36 -0600 (CST) From: Ryan Thompson To: Ramiro Amaya Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: your mail In-Reply-To: <3.0.5.32.20000113150319.009604a0@mail.utexas.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 13 Jan 2000, Ramiro Amaya wrote: > I am new in this mail list, so I do not have so much experience about the > questions I should ask, If I am in the worng place let me know, please. > Well my question is related with Solaris 2.6, the story is like this: > > I have a Solaris 2.5 server which has configured all the printers so I can > perint from that machine without any problem; The printers are remotes so I > use the IP address on /etc/hosts ( Nis database ). Recently, I update the > nis clients to Solaris 2.6, but I am not sure how to configure the > printers, is there anybody there who can give me a hand?. Thanks > Hi, Ramiro.. You are indeed in the wrong mailing list (and on the wrong server :-) freebsd-hackers@freebsd.org is, firstly, pertaining to the FreeBSD UNIX operating system, available on CD, or at ftp.cdrom.com in freely downloadable forms. This -hackers list is meant for the more technical array of questions and their responses. "More technical" generally means questions pertaining to the source code of the operating system itself. -- Ryan Thompson 50% Owner, Technical and Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 15: 1:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D6AC8151E7 for ; Thu, 13 Jan 2000 15:01:04 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA08773; Thu, 13 Jan 2000 18:00:45 -0500 (EST) Date: Thu, 13 Jan 2000 18:00:45 -0500 (EST) From: Daniel Eischen To: Jason Evans Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile In-Reply-To: <20000113135010.L302@sturm.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 13 Jan 2000, Jason Evans wrote: > On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: > > > Consider as an example that open() is a thread cancellation point according > > > to POSIX. If libpthread overrides the libc open() with its own version of > > > open(), then by extension, every function that calls open() can potentially > > > cause thread cancellation. This propagation of cancellation points is > > > legal in a specified list of libc functions, but POSIX also says that *no* > > > functions not in that list may act as cancellation points. That means that > > > we have to be absolutely sure not to propagate cancellation points within > > > libc, and short of constructing and analyzing a full call graph of the libc > > > internals, this is the only way (that I can think of) to assure that libc > > > doesn't incorrectly propagate cancellation points. > > > > Use _open internally within libc and libpthread. Have one "open" > > entry point that is the cancellation version of open. > > It isn't adequate to only have two names with a libpthread. There has to > be: > > 1) _open() -- A name to access the actual system call. > > 2) _libc_open() -- A name that libc uses internally which by default is the > same as _open(), but can be overridden. I don't think we need 2) > > 3) open() -- The name that an application uses (and cancellation point). > > As mentioned in my previous email, if we were to remove _libc_open() and > use open() instead inside of libc, we would incorrectly propagate > cancellation points. Right, use _open instead. > > If we were to remove _libc_open() and use _open() instead inside of libc, > then we would have the problem of some libc functions using system calls > directly, where libpthread needs to do call conversion and/or extra > bookkeeping work. (I experienced this problem in tests first-hand while > doing the conversion; hence the renaming of functions in libc_r.) Forget about libc_r for the moment. It's on it's last breath. Think about the thread system proposed in -arch. It is OK to have libc make system calls directly, because when they block, you'll get an upcall in another context when libpthread is linked in. If libpthread isn't linked in, then the call just blocks. Having _libc_open() used internally within libc doesn't allow libpthread to override _libc_open() because the linker has already resolved references to _libc_open() within libc to the _libc_open() that is in libc, not the _libc_open() in libpthread. Boy, that looks and sounds awfully strange as I re-read it ;-) I think you'd have to modify the linker to make this work the way you envision - jdp could tell you better. > > We can argue about names, but I don't see any way to get around having > three names. That said, I get momentarily confused about this every time I > have to think about it, so if I'm really missing something, please help me > to figure it out. =) I know, it confuses me a bit too ;-) I'm not 100% sure of the way the linker works, but my [last] understanding was that references to weak symbols within libc, would be resolved to libc, and that you couldn't override these from another library (libpthread). I hope that I'll be corrected if I've got this wrong. I'm not sure that it matters much anyways, because we don't need to override references to blocking system calls (at least with the proposed threading architecture). Some things will need to be overridden, though, such as locking mechanisms. I noticed that Solaris has all the pthread mutex/condvar calls in libc, and they're all weak symbols. They must be null bodies because if you write a program to lock a mutex twice (without linking in libpthread), you don't get an error and it doesn't hang on the second lock attempt. > > > How are you going to handle locking inside libc, if the locking > > functions are not inside libc? > > I dunno. =) Seriously, I haven't given much thought to this yet, and can't > claim to understand all the issues involved. I guess you'll learn :-) I can think of 2 different methods: 1. Locking routines would be fully implemented within libc. 2. Locking routines have null bodies in libc, and are implemented in libpthread, and a. Modify the linker to allow references to weak symbols within libc, to be overidden from libpthread, or b. Use function pointers to access the necessary functions which libpthread can overwrite with the fully implemented versions. I kind of like 2b because it seems easier. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 15:21:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from tetron02.tetronsoftware.com (ftp.tetronsoftware.com [208.236.46.106]) by hub.freebsd.org (Postfix) with ESMTP id 4A7A4152B1 for ; Thu, 13 Jan 2000 15:21:20 -0800 (PST) (envelope-from zeus@tetronsoftware.com) Received: from tetron02.tetronsoftware.com (tetron02.tetronsoftware.com [208.236.46.106]) by tetron02.tetronsoftware.com (8.9.3/8.9.3) with ESMTP id RAA29329; Thu, 13 Jan 2000 17:24:04 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Thu, 13 Jan 2000 17:24:04 -0600 (CST) From: Gene Harris To: Ramiro Amaya Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: your mail In-Reply-To: <3.0.5.32.20000113150319.009604a0@mail.utexas.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This list is for FreeBSD, not Solaris. *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* On Thu, 13 Jan 2000, Ramiro Amaya wrote: > I am new in this mail list, so I do not have so much experience about the > questions I should ask, If I am in the worng place let me know, please. > Well my question is related with Solaris 2.6, the story is like this: > > I have a Solaris 2.5 server which has configured all the printers so I can > perint from that machine without any problem; The printers are remotes so I > use the IP address on /etc/hosts ( Nis database ). Recently, I update the > nis clients to Solaris 2.6, but I am not sure how to configure the > printers, is there anybody there who can give me a hand?. Thanks > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 16: 3:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 15E5914D92 for ; Thu, 13 Jan 2000 16:03:56 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id QAA26494; Thu, 13 Jan 2000 16:03:23 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA27003; Thu, 13 Jan 2000 16:03:23 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id QAA15780; Thu, 13 Jan 2000 16:02:07 -0800 (PST) Message-ID: <387E68A8.582F5D16@softweyr.com> Date: Thu, 13 Jan 2000 17:07:04 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: hackers@freebsd.org, rab@cdrom.com Subject: Re: Encryption rules changes coming up - win for open source References: <200001130121.RAA75671@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > The last two paragraphs are the most relevant to us. > > http://www.nytimes.com/reuters/technology/tech-tech-encryption.html > Have we had an opportunity to have the Walnut Creek (or other) legal staff review the actual rules for gotchas? -- "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-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 16: 6:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0B48914EEB for ; Thu, 13 Jan 2000 16:06:44 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id QAA26522 for ; Thu, 13 Jan 2000 16:06:43 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA27109; Thu, 13 Jan 2000 16:06:43 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id QAA15956 for ; Thu, 13 Jan 2000 16:05:27 -0800 (PST) Message-ID: <387E6971.4F204F31@softweyr.com> Date: Thu, 13 Jan 2000 17:10:25 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Encryption rules changes coming up - win for open source References: <200001130201.DAA62690@dorifer.heim3.tu-clausthal.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oliver Fromme wrote: > > Basically, does this mean something like > tar cf - /usr/src/crypto | mail president@whitehouse.gov > ? :-) No. Mail to "root@whitehouse.gov", Hilary is handling the database. -- "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-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 16: 8:58 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id AB33414D43 for ; Thu, 13 Jan 2000 16:08:56 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA67663; Thu, 13 Jan 2000 16:08:54 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Wes Peters Cc: Matthew Dillon , hackers@FreeBSD.ORG, rab@cdrom.com Subject: Re: Encryption rules changes coming up - win for open source In-reply-to: Your message of "Thu, 13 Jan 2000 17:07:04 MST." <387E68A8.582F5D16@softweyr.com> Date: Thu, 13 Jan 2000 16:08:54 -0800 Message-ID: <67660.947808534@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Have we had an opportunity to have the Walnut Creek (or other) legal staff > review the actual rules for gotchas? No, this is something I hope to sit down with our corporate counsel over very shortly. It's an annoying drive to San Jose from here, but I'm prepared to make that sacrifice. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 16:14:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 1C65314E0C for ; Thu, 13 Jan 2000 16:14:38 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id QAA26631; Thu, 13 Jan 2000 16:14:35 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA27534; Thu, 13 Jan 2000 16:14:35 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id QAA16438; Thu, 13 Jan 2000 16:13:20 -0800 (PST) Message-ID: <387E6B49.4FFAABF9@softweyr.com> Date: Thu, 13 Jan 2000 17:18:17 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Christopher R. Bowman" Cc: freebsd-hackers@freebsd.org Subject: Re: Encryption rules changes coming up - win for open source References: <85j9fc$1mso$1@atlantis.rz.tu-clausthal.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Christopher R. Bowman" wrote: > > The last paragraph would be a step in the right direction but still seems > silly. What are they going to do with it? I would really like to see people > educate them on the stupidity of sending code to Washington. I think it would > be neat if there was one of those blue ribbon campaign where on a flag day > every one put all the open source encryption programs they could find up on > their web pages, and then sent them to Washington, one to a floppy > disk/envelope. It would be kinda neat if 1, 5, 10 or even a hundred thousand > little envelopes with 1 floppy a piece showed up it the appropriate Washington > office on the same day. Wonder how long the silly send a copy to Washington > rule would remain after that. Forever. You are making the mistake of thinking they play to do something with all of this information. They do not, they play to print it out on greenbar paper and store it in some warehouse somewhere, along with all the extra B-17 toilet seats and WWI-vintage helmets and other piles of useless crap they own. Never underestimate the silliness of a beauracracy, for it is boundless. -- "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-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 16:34:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail4.aracnet.com (mail4.aracnet.com [216.99.193.36]) by hub.freebsd.org (Postfix) with ESMTP id 17E17155BC; Thu, 13 Jan 2000 16:34:13 -0800 (PST) (envelope-from beattie@aracnet.com) Received: from shell1.aracnet.com (IDENT:root@shell1.aracnet.com [216.99.193.21]) by mail4.aracnet.com (8.9.3/8.9.3) with ESMTP id QAA28716; Thu, 13 Jan 2000 16:34:11 -0800 Received: from localhost by shell1.aracnet.com (8.9.3) id QAA21010; Thu, 13 Jan 2000 16:34:57 -0800 X-Authentication-Warning: shell1.aracnet.com: beattie owned process doing -bs Date: Thu, 13 Jan 2000 16:34:57 -0800 (PST) From: Brian Beattie To: hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: UDF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I was wondering if anybody was working on it. I'm thinking about trying to implement it for CD-RW's and would like to avoid duplication of effort and the anoyance of getting half way through the effort and having somebody else show up with a completed implementation. Brian Beattie | The only problem with beattie@aracnet.com | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 16:38:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 592A115095 for ; Thu, 13 Jan 2000 16:38:44 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40323>; Fri, 14 Jan 2000 11:30:38 +1100 Content-return: prohibited From: Peter Jeremy Subject: Re: Reading the kernel sources To: mwlucas@blackhelicopters.org Cc: freebsd-hackers@FreeBSD.ORG Message-Id: <00Jan14.113038est.40323@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii Date: Fri, 14 Jan 2000 11:30:36 +1100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 12 Jan 2000 17:09:29 -0500 (EST), Michael Lucas wrote: >I find myself in a contract where I sit for eight hours a day and wait >for something to break. It pays obscenely well, so I'm putting up >with the tedium. How does one go about getting such contracts? >So, if I was to sit down and start reading /usr/src/sys, where's the >logical place to start? In general, a good place to start is looking though the open PRs: pick one that looks interesting and either verify the enclosed fix or write one yourself. (This works best if you have a friendly committer who will commit the fixes for you). Given that -current is about a day away from a feature feeze, trying to break -current would also be useful (though this seems to be overly easy at present). Even more so if you can work out why it broke and how to fix it. Within -current, the major rough edges appear to be: - IPv6 (KAME): Testing would be much appreciated by Yoshinobu Inoue - Soren's new ATA driver needs some bugs ironed out - it still has a tendency to get the system into a needs-a-power-cycle-to-fix state at times. - There is an interaction between Vinum RAID5 and softupdates that (AFAIK) hasn't been tracked down. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 21:57:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8CD7A14D7C for ; Thu, 13 Jan 2000 21:57:36 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id WAA47294; Thu, 13 Jan 2000 22:57:35 -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 WAA27229; Thu, 13 Jan 2000 22:58:07 -0700 (MST) Message-Id: <200001140558.WAA27229@harmony.village.org> To: NOKUBI Hirotaka Subject: Re: Dell PowerEdge 2400 & RCC PCI chipset? Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 13 Jan 2000 23:55:52 +0900." <20000113150021.3517B1561B@hub.freebsd.org> References: <20000113150021.3517B1561B@hub.freebsd.org> Date: Thu, 13 Jan 2000 22:58:07 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000113150021.3517B1561B@hub.freebsd.org> NOKUBI Hirotaka writes: : I also want to know a URL. : : My NEC PC98 (using x86 CPU, but not PC-AT compatible) uses : RCC Champion as it's chipset. (Sorry not Champion II/III, it's slightly : old machine.) I'll attach dmesg from it. : : RCC Champion is attached like this. : > pcib0: on motherboard : : FreeBSD-3.2 (I'm not sure, 3.1?) was running fine too. Which version is busted? I might have broken it in my hacking on pccard if this is in -current. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 22:17: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 5B5E914D48 for ; Thu, 13 Jan 2000 22:17:01 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id WAA01032; Thu, 13 Jan 2000 22:16:27 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id WAA19569; Thu, 13 Jan 2000 22:16:26 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id WAA02234; Thu, 13 Jan 2000 22:15:09 -0800 (PST) Message-ID: <387EC019.29BCBA6C@softweyr.com> Date: Thu, 13 Jan 2000 23:20:09 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Lucas Cc: hackers@freebsd.org Subject: Re: Reading the kernel sources References: <200001132144.QAA48936@blackhelicopters.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Lucas wrote: > > Wes Peters wrote: > > Michael Lucas wrote: > > > > > > I find myself in a contract where I sit for eight hours a day and wait > > > for something to break. It pays obscenely well, so I'm putting up > > > with the tedium. > > > > > > So, if I was to sit down and start reading /usr/src/sys, where's the > > > logical place to start? Or should I start elsehwere? Or is there no > > > logical statring place, and I should just assimilate it all en masse? > > > > Start with the PR database. Grab a PR, see if you can figure out what makes > > it go wrong, and then see if you can make it go right. Call this "directed > > research" of anyone asks what you're doing. > > Gut reaction: > > "Geez, I'd like to learn how to swim." > > "No problem! Just tie these cinderblocks to your wrists and ankles, > jump off the deep end, and you'll be ready to go." Close. Leave off the cinderblocks, just jump in. > Second reaction: > > Ah, what the hell. I might actually fix something. You might. Take your time, there's no hurry. ;^) > PS: Anyone know the status of zp0 in -current? Having interrupt problems, at least on the 589D. Get an NE2000 clone. -- "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-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 13 22:30:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 8793914FD9 for ; Thu, 13 Jan 2000 22:30:13 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id WAA01073; Thu, 13 Jan 2000 22:29:39 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id WAA19835; Thu, 13 Jan 2000 22:29:38 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id WAA02724; Thu, 13 Jan 2000 22:28:21 -0800 (PST) Message-ID: <387EC331.EC74EEE7@softweyr.com> Date: Thu, 13 Jan 2000 23:33:21 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Jordan K. Hubbard" Cc: hackers@freebsd.org, rab@cdrom.com Subject: Re: Encryption rules changes coming up - win for open source References: <67660.947808534@zippy.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jordan K. Hubbard" wrote: > > > Have we had an opportunity to have the Walnut Creek (or other) legal staff > > review the actual rules for gotchas? > > No, this is something I hope to sit down with our corporate counsel > over very shortly. It's an annoying drive to San Jose from here, but > I'm prepared to make that sacrifice. :) There's no such thing as a relaxing visit to a lawyer's office, in my experience. The last time I visited one, it was to keep my empoyee and friend from being thrown out of the country. Thanks, as usual, for your contributions. -- "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-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 0:30: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 429AA15182; Fri, 14 Jan 2000 00:30:05 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id JAA40109; Fri, 14 Jan 2000 09:29:58 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200001140829.JAA40109@freebsd.dk> Subject: Re: UDF In-Reply-To: from Brian Beattie at "Jan 13, 2000 04:34:57 pm" To: beattie@aracnet.com (Brian Beattie) Date: Fri, 14 Jan 2000 09:29:58 +0100 (CET) Cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Brian Beattie wrote: > I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I > was wondering if anybody was working on it. I'm thinking about trying to > implement it for CD-RW's and would like to avoid duplication of effort and > the anoyance of getting half way through the effort and having somebody > else show up with a completed implementation. I have it on my TODO list, but I'm not started yet, and probably wont for some time to come. The reason I've put it on the backburner for now, is that DVD's can be read using the cd9660 filesystem, and that is sufficient for my needs for the time being. I have however started to implement the needed functionality in the ata driver, so we should probably coordinate that part of the matter.. -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 5:34:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id 92FC8155E4 for ; Fri, 14 Jan 2000 05:34:18 -0800 (PST) (envelope-from howardjp@wam.umd.edu) Received: from rac3.wam.umd.edu (root@rac3.wam.umd.edu [128.8.10.143]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id IAA09956 for ; Fri, 14 Jan 2000 08:34:11 -0500 (EST) Received: from rac3.wam.umd.edu (sendmail@localhost [127.0.0.1]) by rac3.wam.umd.edu (8.9.3/8.9.3) with SMTP id IAA05784 for ; Fri, 14 Jan 2000 08:34:15 -0500 (EST) Received: from localhost (howardjp@localhost) by rac3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id IAA05780 for ; Fri, 14 Jan 2000 08:34:15 -0500 (EST) X-Authentication-Warning: rac3.wam.umd.edu: howardjp owned process doing -bs Date: Fri, 14 Jan 2000 08:34:15 -0500 (EST) From: James Howard To: freebsd-hackers@freebsd.org Subject: libelf and Elf Interface Routines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was playing with a program written for Solaris to see if I could port it to FreeBSD (another learning experience thing;). The program uses Solaris's libelf to talk to Elf files. It does this quite extensively in fact. Does FreeBSD provide a similar interface? Poking around the man pages has revealed nothing but I wanted to ask before I gave up. If no interface is currently provided, is there one currently being planned? Thank you, Jamie -- Jamie Howard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 6: 3: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [212.74.0.25]) by hub.freebsd.org (Postfix) with ESMTP id 21ACE14CE1 for ; Fri, 14 Jan 2000 06:03:01 -0800 (PST) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.3/8.8.8) id OAA12050; Fri, 14 Jan 2000 14:01:38 GMT (envelope-from joe) Date: Fri, 14 Jan 2000 14:01:38 +0000 From: Josef Karthauser To: James Howard Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: libelf and Elf Interface Routines Message-ID: <20000114140138.O74467@florence.pavilion.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, Lees House, 21-23 Dyke Road, Brighton, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 14, 2000 at 08:34:15AM -0500, James Howard wrote: > I was playing with a program written for Solaris to see if I could port it > to FreeBSD (another learning experience thing;). The program uses > Solaris's libelf to talk to Elf files. It does this quite extensively in > fact. Does FreeBSD provide a similar interface? Poking around the man > pages has revealed nothing but I wanted to ask before I gave up. If no > interface is currently provided, is there one currently being planned? > > Thank you, Jamie The elf(5) manual page may be a good place to start. (It's on modern versions of FreeBSD). We don't have a libelf though. Joe -- Josef Karthauser FreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 10:10:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id DD009156AE for ; Fri, 14 Jan 2000 09:54:32 -0800 (PST) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 0A41C2DC07; Fri, 14 Jan 2000 18:54:10 +0100 (CET) Received: by mx.webgiro.com (Postfix, from userid 1001) id 9E5A47811; Fri, 14 Jan 2000 18:55:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 9991910E10; Fri, 14 Jan 2000 18:55:01 +0100 (CET) Date: Fri, 14 Jan 2000 18:55:01 +0100 (CET) From: Andrzej Bialecki To: Josef Karthauser Cc: James Howard , freebsd-hackers@FreeBSD.ORG Subject: Re: libelf and Elf Interface Routines In-Reply-To: <20000114140138.O74467@florence.pavilion.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 14 Jan 2000, Josef Karthauser wrote: > On Fri, Jan 14, 2000 at 08:34:15AM -0500, James Howard wrote: > > I was playing with a program written for Solaris to see if I could port it > > to FreeBSD (another learning experience thing;). The program uses > > Solaris's libelf to talk to Elf files. It does this quite extensively in > > fact. Does FreeBSD provide a similar interface? Poking around the man > > pages has revealed nothing but I wanted to ask before I gave up. If no > > interface is currently provided, is there one currently being planned? > > > > Thank you, Jamie > > The elf(5) manual page may be a good place to start. (It's on modern > versions of FreeBSD). > > We don't have a libelf though. Does libbfd provide the functionality you need? (see gdb sources). Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 10:35:14 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from biggusdiskus.flyingfox.com (parker-T1-2-gw.sf3d.best.net [209.157.165.30]) by hub.freebsd.org (Postfix) with ESMTP id 2BBB315823 for ; Fri, 14 Jan 2000 10:31:27 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.8/8.8.5) id KAA18379 for hackers@freebsd.org; Fri, 14 Jan 2000 10:25:28 -0800 (PST) Date: Fri, 14 Jan 2000 10:25:28 -0800 (PST) From: Jim Shankland Message-Id: <200001141825.KAA18379@biggusdiskus.flyingfox.com> To: hackers@freebsd.org Subject: "very dangerously dedicated mode" is Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was experimenting with disk formats yesterday, and wanted to see if the BIOS on one of my machines would boot a hard drive with a boot sector (like on a floppy), but no real MBR (i.e., the "AA55" magic number is in place at offset 510, but there is no partition table; more specifically, the "partition table" contains code). This is what Bruce Evans has called "very dangerously dedicated" (see http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=102186+104290+/usr/local/www/db/text/1999/freebsd-current/19990808.freebsd-current). The BIOS on my machine couldn't deal with it, which didn't surprise me that much. The surprise came when I booted FreeBSD 3.2 off a floppy to try to fix my hard disk. The wd driver tries to read the garbage partition table, and wedges: wd0: error reading extended partition table reading fsbn 338137092 wd0s1c: hard error reading fsbn 1 (status 51 error 4) wd0s2c: timeout waiting to give command reading fsbn 1 (status 0 error ) with the last line being repeated at about 1-second intervals, ad infinitum. Now, this strikes me as a bug: sure, the partition table contains garbage, so go ahead and return ENODEV or ENXIO on access to wd0s1, but the whole system is unbootable, even if the kernel is on a floppy. By the way, I also struck out with DOS fdisk: it took one look at the garbage partition table, and wedged. I'll be trying a Linux rescue disk next. If that fails, too, then I seem to have generated a 1-Gigabyte hockey puck (you didn't think I was trying this with a new disk, did you)? Anyway, now you know, my friends, how "very dangerously dedicated mode" got its name :-). Jim Shankland NLynx Systems, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 11:44:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 4ABE314CDE for ; Fri, 14 Jan 2000 11:44:56 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id LAA54649; Fri, 14 Jan 2000 11:44:51 -0800 (PST) To: Jim Shankland Cc: hackers@FreeBSD.ORG Subject: Re: "very dangerously dedicated mode" is In-reply-to: Your message of Fri, 14 Jan 2000 10:25:28 -0800. <200001141825.KAA18379@biggusdiskus.flyingfox.com> Date: Fri, 14 Jan 2000 11:44:51 -0800 Message-ID: <54647.947879091@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200001141825.KAA18379@biggusdiskus.flyingfox.com>, Jim Shankland wrote: >By the way, I also struck out with DOS fdisk: it took one look >at the garbage partition table, and wedged. I'll be trying a >Linux rescue disk next. If that fails, too, then I seem to >have generated a 1-Gigabyte hockey puck (you didn't think I >was trying this with a new disk, did you)? > >Anyway, now you know, my friends, how "very dangerously dedicated mode" >got its name :-). Is this disk by any chance a SCSI drive? I also managed to seriously snafu one SCSI drive that I was playing around with recently. I don't think that my situation was quite as bad as your's, but it was close. The FreeBSD FAQ (Installation section) has some very good info about the ins and outs of SCSI disk geometry. It's very much worth reading if you are working with SCSI drives. See: http://www.freebsd.org/FAQ/install.html#GEOMETRY One fact that I found out the hard way however... and that ISN'T in the FAQ... is that if you have a SCSI drive that was low-level formatted while your SCSI _controller_ was set with ``BIOS address translation'' either on or off, and if you then _change_ this SCSI controller setting (off -> on, or on -> off) and then try to use the previously-low-level- formatted drive on the controller while it is set that way, you may per- haps experience some grief. I had one SCSI drive in a system that was working perfectly well, and then I tried to add another _identical model_ drive from a different system and every tool I used to tell me what the second drive believed its geometry to be showed the geomery for the drive as being clearly incorrect... according to the info contained in the FAQ page at the above URL... for the current translation/non-translation setting of my SCSI controller. Fortunately, the SCSI controller in question was a non-cheap Adaptec. Every Adaptech that has a model number >= 1520 (I think) has on-card built-in ROM-based utilities, and among these is a low-level formatting utility. I ran that on the drive in question and it cured it... the thing started to act like it had a proper sort of geometry (based upon the current translation/non-translation setting of the controller) after that, and all was well again. I then partitioned the drive normally (using DOS fdisk) and it has been just fine ever since. Apparently, SCSI drives for PeeCee-type system really just DO NOT like to be moved from one SCSI controller to another if the two controllers have different translation/non-translation settings. P.S. I don't know if any of this has a damn thing to do with _your_ specific problem, but I felt like sharing this tiny bit of hard-won knowledge anyway. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 12:19:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 0533D158D9 for ; Fri, 14 Jan 2000 12:19:07 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id MAA54936; Fri, 14 Jan 2000 12:19:02 -0800 (PST) To: James Howard Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: libelf and Elf Interface Routines In-reply-to: Your message of Fri, 14 Jan 2000 08:34:15 -0500. Date: Fri, 14 Jan 2000 12:19:02 -0800 Message-ID: <54934.947881142@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , James Howard wrote: >I was playing with a program written for Solaris to see if I could port it >to FreeBSD (another learning experience thing;). The program uses >Solaris's libelf to talk to Elf files. It does this quite extensively in >fact. Does FreeBSD provide a similar interface? Poking around the man >pages has revealed nothing but I wanted to ask before I gave up. If no >interface is currently provided, is there one currently being planned? > >Thank you, Jamie The original libelf code was/is owned by, and developed by AT&T's Unix Systems Group (USG) which AT&T sold to (I think) Novell and which Novell then sold to SCO. Bottom line is that the _real_ libelf is proprietary code. FreeBSD (and Linux, and ...) all use GNU software development tools, and some of theese tools that need to diddle around with low-level object file bits and pieces (e.g. the GNU linker and also gdb) were converted some time ago to use a marvelous <*snicker*> format-independent object file access/diddling library that was created by Cygnus Support (now Cygnus Solutions) called "libbfd". (I never asked what the letters B-F-D stood for. I always figured that they had the obvious meaning. :-) Anyway, you could probably use libbfd to do what you want. It's coplefted, and available (I believe) at ftp.gnu.org/pub/gnu but you'll probably find a fresher version somewhere on Cygus's ftp site. (Start at www.cygnus.com and then scrounge around till you find it.) Hummm... I just tried doing a "locate" to see if this library was already installed on my FreeBSD 3.3 system, and it _did_ find it, but it looks like it is mixed in with the Linux compatability stuff: /usr/compat/linux/usr/lib/libbfd.a I dunno how well that will work if you are not running in Linux compatability mode, so you probably want to fetch a fresh set of sources for libbfd and build it yourself on/for FreeBSD. So the good news is that there _is_ an object file access library that you may be able to use to fish out (or create) bits and pieces of ELF object files. The bad news is that because libbfd was designed to be independent of any single object file format, the API for it is (in my opinion) really rather ugly and complicated, and certainly a lot less simple than the API for libelf, which only had to deal with ELF format files. Anyway, pragmatically speaking, ELF format object files are really fairly simple anyway, and depending upon the complexity of what you want to do, you may not need an access library at all. You could perhaps just hand code the operations that you need yourself from scratch. ELF files are really quite simple to pick apart... *if* you have the ELF spec. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 12:43: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (Postfix) with ESMTP id 49F0014CD0; Fri, 14 Jan 2000 12:42:53 -0800 (PST) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id VAA14696; Fri, 14 Jan 2000 21:42:34 +0100 (CET) Message-ID: <20000114214234.A14486@foobar.franken.de> Date: Fri, 14 Jan 2000 21:42:34 +0100 From: Harold Gutch To: Soren Schmidt , Brian Beattie Cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: UDF References: <200001140829.JAA40109@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <200001140829.JAA40109@freebsd.dk>; from Soren Schmidt on Fri, Jan 14, 2000 at 09:29:58AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 14, 2000 at 09:29:58AM +0100, Soren Schmidt wrote: > It seems Brian Beattie wrote: > > I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I > > was wondering if anybody was working on it. I'm thinking about trying to > > implement it for CD-RW's and would like to avoid duplication of effort and > > the anoyance of getting half way through the effort and having somebody > > else show up with a completed implementation. > > I have it on my TODO list, but I'm not started yet, and probably wont for > some time to come. > The reason I've put it on the backburner for now, is that DVD's can > be read using the cd9660 filesystem, and that is sufficient for my > needs for the time being. I was under the impression that this was only possible as long as the DVDs actually had an ISO9660 filesystem as well - which all of my DVDs have, but which still doesn't mean that there are no DVDs with only UDF, but no ISO9660 filesystem. bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 13:30:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from calvin.saturn-tech.com (calvin.saturn-tech.com [207.229.19.6]) by hub.freebsd.org (Postfix) with ESMTP id DA97914D5C for ; Fri, 14 Jan 2000 13:30:00 -0800 (PST) (envelope-from drussell@saturn-tech.com) Received: from localhost (drussell@localhost) by calvin.saturn-tech.com (8.8.8/8.8.8) with SMTP id OAA05210; Fri, 14 Jan 2000 14:28:53 -0700 (MST) (envelope-from drussell@saturn-tech.com) Date: Fri, 14 Jan 2000 14:28:53 -0700 (MST) From: Doug Russell To: Michael Lucas Cc: Wes Peters , hackers@FreeBSD.ORG Subject: Re: Reading the kernel sources In-Reply-To: <200001132144.QAA48936@blackhelicopters.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 13 Jan 2000, Michael Lucas wrote: > > > So, if I was to sit down and start reading /usr/src/sys, where's the > > > logical place to start? Or should I start elsehwere? Or is there no > > > > Start with the PR database. Grab a PR, see if you can figure out what makes > > it go wrong, and then see if you can make it go right. Call this "directed > > research" of anyone asks what you're doing. > > Gut reaction: > > "Geez, I'd like to learn how to swim." > > "No problem! Just tie these cinderblocks to your wrists and ankles, > jump off the deep end, and you'll be ready to go." > > Second reaction: > > Ah, what the hell. I might actually fix something. ROFL... :) Actually, usually when I look, there are lots of PRs that are relatively easy to fix, just nobody ever gets around to many of them. :) One example from memory... Once upon a time, (probably back in about 1.x) FTP displayed fast transfer rates incorrectly after a transfer. Everyone knew it was there, and I always meant to go fix the one line and send in a patch, but never got to it. Later...... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 13:47:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta3.rcsntx.swbell.net (mta3.rcsntx.swbell.net [151.164.30.27]) by hub.freebsd.org (Postfix) with ESMTP id F2721152FC for ; Fri, 14 Jan 2000 13:47:49 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta3.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FOC00NNLHQV4Z@mta3.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Fri, 14 Jan 2000 15:44:56 -0600 (CST) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id PAA17203; Fri, 14 Jan 2000 15:44:51 -0600 (CST envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Fri, 14 Jan 2000 15:44:46 -0600 From: Chris Costello Subject: Re: libelf and Elf Interface Routines In-reply-to: <54934.947881142@monkeys.com> To: "Ronald F. Guilmette" Cc: James Howard , freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000114154446.Q2463@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <54934.947881142@monkeys.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 14, 2000, Ronald F. Guilmette wrote: > (I never asked what the letters B-F-D stood for. I always figured > that they had the obvious meaning. :-) BFD stands for Binary File Descriptor. -- |Chris Costello |I'm sorry my Karma ran over your Dogma. `---------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 14:16:54 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id EFC8214CF1 for ; Fri, 14 Jan 2000 14:16:50 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id OAA55465; Fri, 14 Jan 2000 14:16:34 -0800 (PST) To: chris@calldei.com Cc: James Howard , freebsd-hackers@FreeBSD.ORG Subject: Re: libelf and Elf Interface Routines In-reply-to: Your message of Fri, 14 Jan 2000 15:44:46 -0600. <20000114154446.Q2463@holly.calldei.com> Date: Fri, 14 Jan 2000 14:16:34 -0800 Message-ID: <55463.947888194@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000114154446.Q2463@holly.calldei.com>, you wrote: >On Fri, Jan 14, 2000, Ronald F. Guilmette wrote: >> (I never asked what the letters B-F-D stood for. I always figured >> that they had the obvious meaning. :-) > > BFD stands for Binary File Descriptor. Oh sure. That's one interpretation. However given the amount of hoopla that Cygnus tried to attach to the initial roll-out of this library, and given that the early releases of libbfd actually broke a lot more things that they ever benefitted, I personally was always more inclined towards the belief that `BFD' actually stood for `Big F***ing Deal', as in ``Who gives a damn?'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 14:20:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta3.rcsntx.swbell.net (mta3.rcsntx.swbell.net [151.164.30.27]) by hub.freebsd.org (Postfix) with ESMTP id 272FE14D7F for ; Fri, 14 Jan 2000 14:20:50 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta3.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FOC00N0CJDV4Z@mta3.rcsntx.swbell.net> for hackers@FreeBSD.ORG; Fri, 14 Jan 2000 16:20:20 -0600 (CST) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id QAA17948; Fri, 14 Jan 2000 16:20:19 -0600 (CST envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Fri, 14 Jan 2000 16:20:18 -0600 From: Chris Costello Subject: Re: "very dangerously dedicated mode" is In-reply-to: <54647.947879091@monkeys.com> To: "Ronald F. Guilmette" Cc: Jim Shankland , hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000114162018.R2463@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <200001141825.KAA18379@biggusdiskus.flyingfox.com> <54647.947879091@monkeys.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 14, 2000, Ronald F. Guilmette wrote: > Is this disk by any chance a SCSI drive? No, the message discusses errors coming from the wd(4) driver. -- |Chris Costello |Today's assembler command : EXOP Execute Operator `---------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 14:23:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from germanium.xtalwind.net (germanium.xtalwind.net [205.160.242.5]) by hub.freebsd.org (Postfix) with ESMTP id DFFAF14A18 for ; Fri, 14 Jan 2000 14:23:13 -0800 (PST) (envelope-from jack@germanium.xtalwind.net) Received: from localhost (jack@localhost) by germanium.xtalwind.net (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id e0EMMtO36339; Fri, 14 Jan 2000 17:22:55 -0500 (EST) Date: Fri, 14 Jan 2000 17:22:54 -0500 (EST) From: jack To: "Ronald F. Guilmette" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: libelf and Elf Interface Routines In-Reply-To: <55463.947888194@monkeys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Today Ronald F. Guilmette wrote: > I personally was always more inclined towards the belief that > `BFD' actually stood for `Big F***ing Deal', as in ``Who > gives a damn?'' Unless you're being chased by a Big F***ing Dog. :) -------------------------------------------------------------------------- Jack O'Neill Systems Administrator / Systems Analyst jack@germanium.xtalwind.net Crystal Wind Communications, Inc. Finger jack@germanium.xtalwind.net for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages > /dev/null -------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 15:54: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nyct.net (bsd4.nyct.net [204.141.86.6]) by hub.freebsd.org (Postfix) with ESMTP id 79A0614C28 for ; Fri, 14 Jan 2000 15:53:59 -0800 (PST) (envelope-from mbac@nyct.net) Received: from bsd1.nyct.net (mbac@bsd1.nyct.net [204.141.86.3]) by mail.nyct.net (8.8.8/8.8.7) with ESMTP id SAA17015; Fri, 14 Jan 2000 18:53:57 -0500 (EST) (envelope-from mbac@nyct.net) Received: from localhost (mbac@localhost) by bsd1.nyct.net (8.8.8/8.9.3) with ESMTP id SAA26530; Fri, 14 Jan 2000 18:53:57 -0500 (EST) (envelope-from mbac@nyct.net) X-Authentication-Warning: bsd1.nyct.net: mbac owned process doing -bs Date: Fri, 14 Jan 2000 18:53:57 -0500 (EST) From: Michael Bacarella To: Harold Gutch Cc: Soren Schmidt , Brian Beattie , hackers@FreeBSD.ORG Subject: NT life spans [was: UDF] In-Reply-To: <20000114214234.A14486@foobar.franken.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Someone should do a study to find out how many human life spans have > been lost waiting for NT to reboot. > Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc Hmm. Our Compaq Proliant (running NT) takes about 5 whole minutes from the moment I click reboot to the time when I can log in as Administrator and actually do something. The Proliant has 4 Pentium Pros at 200 MHz and half a gig of RAM, with a 24 gig array. It is running IIS (for our Front Page clients) and is also acting as a PDC. The results would be slightly more horrfying if you had a slower server. Less horrifying if you had a faster server. If I spend an entire day on it doing something, it usually needs two reboots or so. More if something major happened. So, let's say I worked on it for an entire year. ~18 work days per month, times 12 months per year. 10 minutes per day.. 18 days/month * 12 months/year * 10 minutes/day = 2160 minutes/year 2160 minutes / 60 minutes/hour = 36 hours/year The average number of hours that a human being lives, if they live to 80 is 691200 hours (GAH). 19200 humans working with NT for a year, a single lifespan is lost waiting for NT to reboot. (19200 * 36 = 691200) Some other perspectives: If 1,000,000 people use Windows NT for 1 year, 52 human lives are lost. That's a human life per week! 1,000,000 people using NT for 5 years = 260 lives. I'll let the numbers speak for themselves about the TCO involved in deploying Windows NT across your enterprise. Michael Bacarella To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 22:17: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id EE6A3156F4 for ; Fri, 14 Jan 2000 22:17:02 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id XAA01526 for freebsd-hackers@freebsd.org; Fri, 14 Jan 2000 23:49:07 -0600 (CST) Date: Fri, 14 Jan 2000 23:49:07 -0600 (CST) From: Mohit Aron Message-Id: <200001150549.XAA01526@cs.rice.edu> To: freebsd-hackers@freebsd.org Subject: question regarding FreeBSD memory mgmt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, is it possible from within FreeBSD to set a range of physical/virtual addresses to be uncacheable ? I'm using FreeBSD-2.2.6 and I'd appreciate if someone can tell me functions/instructions on how to make certain memory ranges to be uncachable on a Pentium III. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 22:28: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta3.rcsntx.swbell.net (mta3.rcsntx.swbell.net [151.164.30.27]) by hub.freebsd.org (Postfix) with ESMTP id 241B814CFB for ; Fri, 14 Jan 2000 22:28:06 -0800 (PST) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org ([216.62.157.60]) by mta3.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FOD004GT5O1WB@mta3.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Sat, 15 Jan 2000 00:21:38 -0600 (CST) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id AAA43277; Sat, 15 Jan 2000 00:21:35 -0600 (CST envelope-from chris) X-URL: http://www.FreeBSD.org/~chris/ Date: Sat, 15 Jan 2000 00:21:34 -0600 From: Chris Costello Subject: Re: question regarding FreeBSD memory mgmt In-reply-to: <200001150549.XAA01526@cs.rice.edu> To: Mohit Aron Cc: freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000115002134.A43216@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <200001150549.XAA01526@cs.rice.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 14, 2000, Mohit Aron wrote: > Hi, > is it possible from within FreeBSD to set a range of physical/virtual > addresses to be uncacheable ? I'm using FreeBSD-2.2.6 and I'd appreciate if > someone can tell me functions/instructions on how to make certain memory > ranges to be uncachable on a Pentium III. STABLE (3.x) has a memcontrol(8) program that can do just that. I don't know off hand whether it can be ported back to 2.2.6, but it's worth a try. From the memcontrol(8) man page: set Set memory range attributes. -b base Memory range base address -l length Length of memory range in bytes, power of 2 -o owner Text identifier for this setting (7 char max) attribute Attributes applied to this range; one of uncacheable, write-combine, write-through, write-back, write-protect -- |Chris Costello |Programmer: One who is too lacking in people skills | to be a software engineer. `--------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 14 22:54:58 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 618D914F84 for ; Fri, 14 Jan 2000 22:54:55 -0800 (PST) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id RAA02764; Sat, 15 Jan 2000 17:01:15 +1030 (CST) (envelope-from newton) Date: Sat, 15 Jan 2000 17:01:15 +1030 From: Mark Newton To: Michael Bacarella Cc: Harold Gutch , Soren Schmidt , Brian Beattie , hackers@FreeBSD.ORG Subject: Re: NT life spans [was: UDF] Message-ID: <20000115170115.E2610@internode.com.au> References: <20000114214234.A14486@foobar.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: X-PGP-Key: http://www.on.net/~newton/pgpkey.txt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 14, 2000 at 06:53:57PM -0500, Michael Bacarella wrote: > ~18 work days per month, times 12 months per year. 10 minutes per day.. > 18 days/month * 12 months/year * 10 minutes/day = 2160 minutes/year > 2160 minutes / 60 minutes/hour = 36 hours/year > The average number of hours that a human being lives, if they live to 80 > is 691200 hours (GAH). > 19200 humans working with NT for a year, a single lifespan is lost waiting > for NT to reboot. (19200 * 36 = 691200) > Some other perspectives: > If 1,000,000 people use Windows NT for 1 year, 52 human lives are lost. > That's a human life per week! > 1,000,000 people using NT for 5 years = 260 lives. > I'll let the numbers speak for themselves about the TCO involved in > deploying Windows NT across your enterprise. The life insurance costs alone would be a killer :-) - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 0:23:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6FAAD14CF1 for ; Sat, 15 Jan 2000 00:23:17 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA18921 for ; Fri, 14 Jan 2000 23:31:35 -0800 Date: Fri, 14 Jan 2000 23:31:35 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: hackers@freebsd.org Subject: looking for victims, err, uh, 'volunteers' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've just committed into -current a bare-bones SES/SAF-TE driver that will be fleshed out somewhat over the next couple of days, but will remain a bare bones driver. It's a stub right now (just matches && attaches), but the rest of it will show up tomorrow. There will be a simple ioctl API to get to it, but I won't be putting any management daemons into the source tree- there has been no clear consensus on how to manage a lot of this, so any tools to extract info at best will be in /usr/contrib or /usr/ports. That said... if anyone out there has (they believe) any SES or SAF-TE (or even Sun RSM trays that have the Unisys SEN card in them) and wants perhaps act as a guinea pig, I'd appreciate hearing about it. The tools and usage is pretty lightweight and I just pretty much need to crosscheck/port some tools I did on Solaris for FreeBSD. Basically, I have SES units in a Sun A5000 disk box, SAF-TE in a Sun D1000, SEN in an RSM tray, and a couple random other bits and pieces that show up. If anyone has other devices than these, particularly SAF-TE ones (which the driver emulates as SES), please consider trying the driver and letting me know what transpires. TIA and all that... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 0:32: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 993DA14F48 for ; Sat, 15 Jan 2000 00:32:02 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 864271C03; Sat, 15 Jan 2000 16:32:00 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: hackers@freebsd.org Subject: Re: looking for victims, err, uh, 'volunteers' In-Reply-To: Message from Matthew Jacob of "Fri, 14 Jan 2000 23:31:35 PST." Date: Sat, 15 Jan 2000 16:32:00 +0800 From: Peter Wemm Message-Id: <20000115083200.864271C03@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: Umm, would you mind explaining this in english instead of acronyms? :-) Otherwise it means abosolutely nothing to the average bystander... > I've just committed into -current a bare-bones SES/SAF-TE driver that will > be fleshed out somewhat over the next couple of days, but will remain a > bare bones driver. It's a stub right now (just matches && attaches), but > the rest of it will show up tomorrow. > > There will be a simple ioctl API to get to it, but I won't be putting > any management daemons into the source tree- there has been no clear > consensus on how to manage a lot of this, so any tools to extract info at > best will be in /usr/contrib or /usr/ports. > > That said... if anyone out there has (they believe) any SES or SAF-TE (or > even Sun RSM trays that have the Unisys SEN card in them) and wants > perhaps act as a guinea pig, I'd appreciate hearing about it. The tools > and usage is pretty lightweight and I just pretty much need to > crosscheck/port some tools I did on Solaris for FreeBSD. > > Basically, I have SES units in a Sun A5000 disk box, SAF-TE in a Sun > D1000, SEN in an RSM tray, and a couple random other bits and pieces that > show up. If anyone has other devices than these, particularly SAF-TE ones > (which the driver emulates as SES), please consider trying the driver > and letting me know what transpires. > > TIA and all that... > > -matt Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 0:42:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 555DE14E3F for ; Sat, 15 Jan 2000 00:42:26 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id AAA19090; Sat, 15 Jan 2000 00:42:03 -0800 Date: Sat, 15 Jan 2000 00:42:03 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Peter Wemm Cc: hackers@freebsd.org Subject: Re: looking for victims, err, uh, 'volunteers' In-Reply-To: <20000115083200.864271C03@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Matthew Jacob wrote: > > Umm, would you mind explaining this in english instead of acronyms? :-) > Otherwise it means abosolutely nothing to the average bystander... Umm, sorry, this is the hacker's list isn't it??? :-) Here's part of mail (editted) I just sent out - maybe this will help... ---------------------------------------- SES is "SCSI Environmental Services". This is a whole wheat all singing all dancing device type in SCSI-3. It's actually pretty neat. It's known either by a device type, or a bit in the inquiry data that says a device supports it. You find out things and set things via a mechanism similar to Mode Sense/Mode Select but via the SEND/GET DIAGNOSTIC commands. It can be enclosure information like power supplies (and status) and temperature or fans, or it can be device slot status- like, you can flash LEDs with it. It's got a whole wad 'o interesting stuff for managing enclosures. ... SAF-TE is a joint HP/COMPAQ/?? effort that's somewhat simpler and a tad orthogonal to SES- you identify this by looking at an offset in INQUIRY DATA bytes 48-54 for the string "SAF-TE". You access it via the WRITE BUFFER/READ BUFFER commands. There are a *lot* of SAF-TE devices out there- primarily because there are cheap chips (the GEM2 chips come to mind) the implement all of SAF-TE in one die so you can slap one onto you're device and have enough board space left over to play checkers. With a couple minor exceptions, SES nomenclature/structures are a proper superset of SAF-TE, so this driver translates SAF-TE to/from SES. Examples (from my solaris version) from userland below to give you a sense... -matt SAF-TE device emulated as SCSI: <<<<< SHOULD HAVE SAID 'SES' slowbird > root getnobj /dev/es/ses0 Jan 15 00:25:54 slowbird unix: ses30 at glm0: Jan 15 00:25:54 slowbird unix: target e lun 0 Jan 15 00:25:54 slowbird unix: ses30 is /pci@1f,0/pci@1/scsi@2/ses@e,0 /dev/es/ses0: 25 objects slowbird > slowbird > root getobjmap /dev/es/ses0 /dev/es/ses0: 25 objects Object 0: ID 0x0 Type 'Cooling element' Object 1: ID 0x1 Type 'Cooling element' Object 2: ID 0x2 Type 'Power supply' Object 3: ID 0x3 Type 'Power supply' Object 4: ID 0x4 Type 'Temperature sensors' Object 5: ID 0x5 Type 'Temperature sensors' Object 6: ID 0x6 Type 'Temperature sensors' Object 7: ID 0x7 Type 'Temperature sensors' Object 8: ID 0x8 Type 'Temperature sensors' Object 9: ID 0x9 Type 'Temperature sensors' Object 10: ID 0xa Type 'Temperature sensors' Object 11: ID 0xb Type 'Temperature sensors' Object 12: ID 0xc Type 'Temperature sensors' Object 13: ID 0xd Type 'Temperature sensors' Object 14: ID 0xe Type 'Temperature sensors' Object 15: ID 0xf Type 'Temperature sensors' Object 16: ID 0x10 Type 'Temperature sensors' Object 17: ID 0x11 Type 'Temperature sensors' Object 18: ID 0x12 Type 'Temperature sensors' Object 19: ID 0x13 Type 'Temperature sensors' Object 20: ID 0x14 Type 'Audible alarm' Object 21: ID 0x15 Type 'Device' Object 22: ID 0x16 Type 'Device' Object 23: ID 0x17 Type 'Device' Object 24: ID 0x18 Type 'Device' slowbird > root getencstat -v /dev/es/ses0 /dev/es/ses0: Enclosure Status Cooling element Element(0): OK (Status=ok (bytes=0x01 0x00 0x00 0x07)) Cooling element Element(1): OK (Status=ok (bytes=0x01 0x00 0x00 0x07)) Power supply Element(2): OK (Status=ok (bytes=0x01 0x00 0x00 0x20)) Power supply Element(3): Status=status not supported (bytes=0x00 0x00 0x00 0x61) Temperature sensors Element(4): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(5): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(6): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(7): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(8): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(9): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(a): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(b): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(c): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(d): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(e): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(f): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(10): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(11): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(12): Status=status not available (bytes=0x07 0x00 0x32 0x00) Temperature sensors Element(13): Status=status not available (bytes=0x07 0x00 0x32 0x00) Audible alarm Element(14): OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Device Element(15): OK (Status=ok (bytes=0x01 0x00 0x00 0x00)) Device Element(16): OK (Status=ok (bytes=0x01 0x01 0x00 0x00)) Device Element(17): OK (Status=ok (bytes=0x01 0x02 0x00 0x00)) Device Element(18): OK (Status=ok (bytes=0x01 0x03 0x00 0x00)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 1:20:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 65CD61503D; Sat, 15 Jan 2000 01:20:43 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id KAA98140; Sat, 15 Jan 2000 10:20:29 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200001150920.KAA98140@freebsd.dk> Subject: Re: UDF In-Reply-To: <20000114214234.A14486@foobar.franken.de> from Harold Gutch at "Jan 14, 2000 09:42:34 pm" To: logix@foobar.franken.de (Harold Gutch) Date: Sat, 15 Jan 2000 10:20:29 +0100 (CET) Cc: beattie@aracnet.com (Brian Beattie), hackers@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Harold Gutch wrote: > On Fri, Jan 14, 2000 at 09:29:58AM +0100, Soren Schmidt wrote: > > It seems Brian Beattie wrote: > > > I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I > > > was wondering if anybody was working on it. I'm thinking about trying to > > > implement it for CD-RW's and would like to avoid duplication of effort and > > > the anoyance of getting half way through the effort and having somebody > > > else show up with a completed implementation. > > > > I have it on my TODO list, but I'm not started yet, and probably wont for > > some time to come. > > The reason I've put it on the backburner for now, is that DVD's can > > be read using the cd9660 filesystem, and that is sufficient for my > > needs for the time being. > > I was under the impression that this was only possible as long as > the DVDs actually had an ISO9660 filesystem as well - which all > of my DVDs have, but which still doesn't mean that there are no > DVDs with only UDF, but no ISO9660 filesystem. I'm pretty sure all DVD's produced to date have an iso9660 file sys on them, but they might change that in the future, so having UDF support would be a win for us in the long run. Again, I'll do the needed things in the ata driver for packet writing etc, but I dont have the time to take on UDF right now... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 9:55:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from elektra.bbn.com (ELEKTRA.BBN.COM [128.89.27.73]) by hub.freebsd.org (Postfix) with ESMTP id 9441114C84 for ; Sat, 15 Jan 2000 09:55:17 -0800 (PST) (envelope-from dwiggins@elektra.bbn.com) Received: from elektra.bbn.com (localhost.127.in-addr.arpa [127.0.0.1]) by elektra.bbn.com (8.8.8/8.8.8) with ESMTP id MAA03830 for ; Sat, 15 Jan 2000 12:55:16 -0500 (EST) Message-Id: <200001151755.MAA03830@elektra.bbn.com> To: freebsd-hackers@freebsd.org Subject: propose enlarging ifnet.if_flags Date: Sat, 15 Jan 2000 12:55:15 -0500 From: David Wiggins Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to suggest changing struct ifnet.if_flags from a short to an int and changing ifreq.ifru_flags to match. For the project I have been working on, we've needed to define three new interface flags. All 16 current flags are allocated, so we had to add more bits. We didn't want to use IFF_LINK0-LINK2 for our flags because those are "per link layer defined" and our flags don't exactly fit that description. Briefly, one flag identifies radio interfaces, another says if the interface is capable of issuing predictions about its future state, and the third tells if the interface is connected to a pointable antenna. Some consequences of such a change: o kernel code that copies if_flags to another variable should be updated to use the new type for if_flags, though such code would probably continue to work (after recompiling) even without changing the type because the additional high bits would be dropped when copying to a short. o changing struct ifreq affects the interface to userland. Maybe this triggers some shlib-version-numbering rules? On little-endian machines, userland programs that use ifr_flags should continue to work without even recompiling since the lower two bytes of flags will land in the same place. This would break big-endian machines without recompiling. As with the kernel, userland programs that copy the flags should ideally be changed to use the new type. o userland programs that read struct ifnets from kernel memory (e.g., netstat) would also need recompiling. o divergence with [Open|Net]BSD unless they change too. I should confess here that the change I've requested is not the change we made. We were worried about possible binary compatibility problems, so we added a short "extension flags" field at the end of struct ifnet, and added a new ioctl to get the extension flags. But this is a kludge, and we'd like to be able to do away with it by enlarging the existing flags field. I see that in if.h:1.50 ifreq.ifru_flags changed from a short to an array of two shorts, with the second short being the previous flags. I think this is OK; just change it to an array of two ints. The size of struct ifreq still won't change because ifru_flags is part of a union containing a sockaddr, which is bigger than two ints. The checkin message for if.h:1.48 mentions adding fields to struct ifreq; perhaps this change could be done at this same time. Note: I just unsubscribed from the -digest form of this list and subscribed to the non-digest address, but I'm not sure the latter has gone through yet, so please cc: me on any replies. Thanks. David Wiggins To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 17:47:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sapphire.looksharp.net (mcdouga9.user.msu.edu [35.10.148.141]) by hub.freebsd.org (Postfix) with ESMTP id 3950A14D50 for ; Sat, 15 Jan 2000 17:47:41 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by sapphire.looksharp.net (8.9.3/8.9.3) with ESMTP id UAA17752; Sat, 15 Jan 2000 20:47:06 -0500 (EST) (envelope-from bsdx@looksharp.net) X-Authentication-Warning: sapphire.looksharp.net: bsdx owned process doing -bs Date: Sat, 15 Jan 2000 20:47:06 -0500 (EST) From: Adam To: "Ronald F. Guilmette" Cc: hackers@FreeBSD.ORG Subject: Re: "very dangerously dedicated mode" is In-Reply-To: <54647.947879091@monkeys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've also fixed screwed scsi disks by doing a low level format; I usually do it anyway when moving a disk from one controller to another if its not a temporary thing. Among my scsi cards is a Tekram 390F, and on one sickly drive the bios LLF would stall but another freebsd system saved the day with camcontrol; I used it to initiate a LLF which luckily "took". > Fortunately, the SCSI controller in question was a non-cheap Adaptec. > Every Adaptech that has a model number >= 1520 (I think) has on-card > built-in ROM-based utilities, and among these is a low-level formatting > utility. I ran that on the drive in question and it cured it... the > thing started to act like it had a proper sort of geometry (based upon > the current translation/non-translation setting of the controller) after > that, and all was well again. I then partitioned the drive normally > (using DOS fdisk) and it has been just fine ever since. > > Apparently, SCSI drives for PeeCee-type system really just DO NOT like > to be moved from one SCSI controller to another if the two controllers > have different translation/non-translation settings. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 19:32:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from laurasia.com.au (lauras.lnk.telstra.net [139.130.93.142]) by hub.freebsd.org (Postfix) with ESMTP id A83A41518B for ; Sat, 15 Jan 2000 19:32:45 -0800 (PST) (envelope-from mike@laurasia.com.au) Received: (from mike@localhost) by laurasia.com.au (8.9.1a/8.9.1) id LAA24167 for hackers@freebsd.org; Sat, 15 Jan 2000 11:32:37 +0800 (WST) Date: Sat, 15 Jan 2000 11:32:37 +0800 (WST) From: Michael Kennett Message-Id: <200001150332.LAA24167@laurasia.com.au> To: hackers@freebsd.org Subject: Use of newbus in sys/pci/pci.c Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello All, I have a question on the sys/pci/pci.c code, and its use of the newbus architecture. An example of the code in question is: static struct resource * pci_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { struct pci_devinfo *dinfo = device_get_ivars(child); ^^^^^ Looks wrong struct resource_list *rl = &dinfo->resources; return resource_list_alloc(rl, dev, child, type, rid, start, end, count, flags); } I don't understand the line that extracts the ivars from the child device. Isn't it the case that the ivars are a property of the bus device (dev)? In any case, the child device might not be directly descended from the pci bus (e.g. it could be attached thru' the bridge isab0: ). It strikes me that the assignment is unsafe. I would have thought that the code should be: static struct resource * pci_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { struct pci_devinfo *dinfo = device_get_ivars(dev); ^^^ CHANGED struct resource_list *rl = &dinfo->resources; return resource_list_alloc(rl, dev, child, type, rid, start, end, count, flags); } Why are the ivars extracted from the child, and not the bus device? Kind Regards, Mike Kennett (mike@laurasia.com.au) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 19:41:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from moo.sysabend.org (moo.sysabend.org [209.0.55.68]) by hub.freebsd.org (Postfix) with ESMTP id 137C2152BF for ; Sat, 15 Jan 2000 19:41:34 -0800 (PST) (envelope-from ragnar@sysabend.org) Received: by moo.sysabend.org (Postfix, from userid 1004) id 53D1E757D; Sat, 15 Jan 2000 19:42:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by moo.sysabend.org (Postfix) with ESMTP id 43A111D8F; Sat, 15 Jan 2000 19:42:39 -0800 (PST) Date: Sat, 15 Jan 2000 19:42:39 -0800 (PST) From: Jamie Bowden To: Jim Shankland Cc: hackers@freebsd.org Subject: Re: "very dangerously dedicated mode" is In-Reply-To: <200001141825.KAA18379@biggusdiskus.flyingfox.com> Message-ID: Approved: yep X-representing: Only myself. X-badge: We don't need no stinking badges. X-obligatory-profanity: Fuck X-moo: Moo. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 14 Jan 2000, Jim Shankland wrote: :By the way, I also struck out with DOS fdisk: it took one look :at the garbage partition table, and wedged. I'll be trying a :Linux rescue disk next. If that fails, too, then I seem to :have generated a 1-Gigabyte hockey puck (you didn't think I :was trying this with a new disk, did you)? If it were SCSI I'd say plug it in to the nearest adaptec controller and low level it (I fixed a drive one of my SGI's ate like this), but it's IDE. You might want to give NT or OS/2 a whack at it if you've got them laying around. There are programs to let you low level IDE drives out there, I believe they're mostly DOS based though, so that probably doesn't help. Jamie Bowden -- "Of course, that's sort of like asking how other than Marketing, Microsoft is different from any other software company..." Kenneth G. Cavness To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 19:52:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 8BE0F151EC for ; Sat, 15 Jan 2000 19:52:39 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id VAA58059; Sat, 15 Jan 2000 21:52:30 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Sat, 15 Jan 2000 21:52:30 -0600 (CST) From: Chris Dillon To: Matthew Jacob Cc: hackers@FreeBSD.ORG Subject: Re: looking for victims, err, uh, 'volunteers' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 14 Jan 2000, Matthew Jacob wrote: > I've just committed into -current a bare-bones SES/SAF-TE driver that will > be fleshed out somewhat over the next couple of days, but will remain a > bare bones driver. It's a stub right now (just matches && attaches), but > the rest of it will show up tomorrow. Yay! > There will be a simple ioctl API to get to it, but I won't be putting > any management daemons into the source tree- there has been no clear > consensus on how to manage a lot of this, so any tools to extract info at > best will be in /usr/contrib or /usr/ports. > > That said... if anyone out there has (they believe) any SES or SAF-TE (or > even Sun RSM trays that have the Unisys SEN card in them) and wants > perhaps act as a guinea pig, I'd appreciate hearing about it. The tools > and usage is pretty lightweight and I just pretty much need to > crosscheck/port some tools I did on Solaris for FreeBSD. I've got a Compaq Proliant 3000 with three drives in a hot-plug chassis that I was told by someone else a while back (you?) speak SAF-TE. Unfortunately, I'm running -STABLE on that box. If this would happen to work with -STABLE, I just _happen_ to have a disk that is giving me fits (medium errors resulting in unrecoverable read errors) and am about to go in tomorrow to swap it with another disk. Since the disk wasn't really doing anything too terribly important (holding one-third of my Squid cache, /usr/obj, and a copy of the FreeBSD CVS repository), I can hold off replacing it for a while if it needs to be used as a test subject. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 20: 7:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 9AC4B15007 for ; Sat, 15 Jan 2000 20:07:34 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id XAA32782; Sat, 15 Jan 2000 23:07:23 -0500 (EST) Date: Sat, 15 Jan 2000 23:07:23 -0500 (EST) From: "Matthew N. Dodd" To: Michael Kennett Cc: hackers@FreeBSD.ORG Subject: Re: Use of newbus in sys/pci/pci.c In-Reply-To: <200001150332.LAA24167@laurasia.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 15 Jan 2000, Michael Kennett wrote: > I don't understand the line that extracts the ivars from the child > device. Isn't it the case that the ivars are a property of the bus > device (dev)? No since the parent may not be a PCI device. In any case we're dealing with a device (child) that wishes to make a resource allocation; the parent device provides methods for this and its methods store the relevent information on the structure assigned to the device IVARS (by the parent). The IVARS belong to the device, not the parent. I've probably not helped much but the code is correct. -- | 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-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 15 21:39:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from laurasia.com.au (lauras.lnk.telstra.net [139.130.93.142]) by hub.freebsd.org (Postfix) with ESMTP id AC2681520B for ; Sat, 15 Jan 2000 21:39:09 -0800 (PST) (envelope-from mike@laurasia.com.au) Received: (from mike@localhost) by laurasia.com.au (8.9.1a/8.9.1) id NAA20602; Sun, 16 Jan 2000 13:38:24 +0800 (WST) Date: Sun, 16 Jan 2000 13:38:24 +0800 (WST) From: Michael Kennett Message-Id: <200001160538.NAA20602@laurasia.com.au> To: hackers@freebsd.org, winter@jurai.net Subject: Re: Use of newbus in sys/pci/pci.c Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 15 Jan 2000, Michael Kennett wrote: > > I don't understand the line that extracts the ivars from the child > > device. Isn't it the case that the ivars are a property of the bus > > device (dev)? > > No since the parent may not be a PCI device. In any case we're dealing > with a device (child) that wishes to make a resource allocation; the > parent device provides methods for this and its methods store the relevent > information on the structure assigned to the device IVARS (by the parent). > > The IVARS belong to the device, not the parent. Thanks for the explanation - I can see that now in the code (function pci_add_children()). > > I've probably not helped much but the code is correct. > I'm still not convinced :-). Let me explain my concerns. The child device does not necessarily have to be a direct child of the pci bus (i.e. it is not necessarily true that device_get_parent(child) == dev). This can occur, for example, with the pci-isa bridge which just passes through resource requests from the ISA bus to the PCI bus. For the isab bridge, this is documented in sys/pci/pcisupport.c: static device_method_t isab_methods[] = { /* ... [edited] ... */ DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource), /* ... [edited] ... */ }; From sys/kern/subr_bus.c we have: struct resource * bus_generic_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { /* Propagate up the bus hierarchy until someone handles it. */ if (dev->parent) return (BUS_ALLOC_RESOURCE(dev->parent, child, type, rid, start, end, count, flags)); else return (NULL); } So, after a resource allocation request has come through the pci-isa bridge, the child device is no longer a direct child of the bus (i.e. it is not true that device_get_parent(child)==dev). As a consequence, in the sys/pci/pci.c code, the line struct pci_devinfo *dinfo = device_get_ivars(child); can be extracting ivars from a (grand)child device that has not been initialised with the pci_devinfo ivar structure. This is dangerous! It appears that the only reason the code works is because of the sentinel in resource_list_alloc(): struct resource * resource_list_alloc(struct resource_list *rl .... /* edited */ { struct resource_list_entry *rle = 0; int passthrough = (device_get_parent(child) != bus); int isdefault = (start == 0UL && end == ~0UL); if (passthrough) { return BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, start, end, count, flags); } rle = resource_list_find(rl, type, *rid); /* ... edited */ } In the case of a passthrough, the resource list extracted from the ivars are never referenced. In other words, the incorrect cast never blows up :-) Wouldn't the code below be safer and clearer? It should also be functionally equivalent to the existing code. static struct resource * pci_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { int passthrough = (device_get_parent(child) != dev); if (passthrough) { return BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, start, end, count, flags); } else { struct pci_devinfo *dinfo = device_get_ivars(child); struct resource_list *rl = &dinfo->resources; return resource_list_alloc(rl, dev, child, type, rid, start, end, count, flags); } } Regards, Mike Kennett (mike@laurasia.com.au) PS. Sorry about the faulty dates - using an old version of elm. Main machine is down due to power surges/lightening last night. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message