From owner-freebsd-arch Mon Jan 1 4:34:41 2001 From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 04:34:39 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by hub.freebsd.org (Postfix) with ESMTP id 6942937B400 for ; Mon, 1 Jan 2001 04:34:38 -0800 (PST) Received: from fwd04.sul.t-online.com by mailout00.sul.t-online.com with smtp id 14D4Af-0000z9-02; Mon, 01 Jan 2001 13:34:37 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.225.194.113]) by fmrl04.sul.t-online.com with esmtp id 14D4Ab-0UN4uuC; Mon, 1 Jan 2001 13:34:33 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id B5DF2AB0C for ; Mon, 1 Jan 2001 13:35:05 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 5C25314AF8; Mon, 1 Jan 2001 13:34:38 +0100 (CET) Date: Mon, 1 Jan 2001 13:34:38 +0100 From: Alexander Langer To: arch@freebsd.org Subject: (fwd) getnanouptime() patch Message-ID: <20010101133438.A4214@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [per suggestion by Chris Faulhaber, I'm forwarding this to -arch] Hello! I have this old mail from BDE sitting here about the print_uptime() bugs. One of these bugs is: - the implementation is buggy. getnanouptime() accesses uninitialized pointers when it is called before timecounters have been initialized. This causes recursive panics which lock up at least my systems (boot with -d and decide you didn't want to boot this kernel after all, and type "panic" at the debugger prompt -- this locks up the system). The following patch to getnanouptime() should fix this. I don't know what the KTR define is for, I stole this from another function in the kern_tc.c file, which also handles uninitialized pointer correctly. Comments? I just noted, that this patch must be applied to the getmicrouptime() function as well. Diff _not_ included. cvs diff: Diffing . Index: kern_tc.c =================================================================== RCS file: /usr/home/ncvs/src/sys/kern/kern_tc.c,v retrieving revision 1.109 diff -u -r1.109 kern_tc.c --- kern_tc.c 2000/09/07 01:32:51 1.109 +++ kern_tc.c 2000/12/31 16:23:27 @@ -188,6 +188,13 @@ ngetnanouptime++; tc = timecounter; +#ifdef KTR + if (tc == NULL) { /* called before initialization */ + tsp->tv_sec = 0; + tsp->tv_nsec = 0; + return; + } +#endif tsp->tv_sec = tc->tc_offset_sec; tsp->tv_nsec = tc->tc_offset_nano >> 32; } -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message ----- End forwarded message ----- -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 1 4:54:13 2001 From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 04:54:12 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B31A237B400 for ; Mon, 1 Jan 2001 04:54:10 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA30442; Mon, 1 Jan 2001 23:53:44 +1100 Date: Mon, 1 Jan 2001 23:54:36 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alexander Langer Cc: arch@FreeBSD.ORG Subject: Re: (fwd) getnanouptime() patch In-Reply-To: <20010101133438.A4214@cichlids.cichlids.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 1 Jan 2001, Alexander Langer wrote: > [per suggestion by Chris Faulhaber, I'm forwarding this to -arch] > > Hello! > > I have this old mail from BDE sitting here about the print_uptime() > bugs. One of these bugs is: > > - the implementation is buggy. getnanouptime() accesses uninitialized > pointers when it is called before timecounters have been > initialized. > This causes recursive panics which lock up at least my systems (boot > with -d and decide you didn't want to boot this kernel after all, > and type "panic" at the debugger prompt -- this locks up the system). Actually, timecounters are statically initialized to a dummy timecounter, so the lock-up is probably caused by some other bug, possibly an uninitialized event handler. So the patch has no effect except to slow down nanotime(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 1 5: 0: 8 2001 From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 05:00:06 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by hub.freebsd.org (Postfix) with ESMTP id 89B4637B400 for ; Mon, 1 Jan 2001 05:00:05 -0800 (PST) Received: from fwd02.sul.t-online.com by mailout06.sul.t-online.com with smtp id 14D4ZH-0006yC-02; Mon, 01 Jan 2001 14:00:03 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.225.194.113]) by fmrl02.sul.t-online.com with esmtp id 14D4Z5-0gd864C; Mon, 1 Jan 2001 13:59:51 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 89CB1AB0C; Mon, 1 Jan 2001 14:00:23 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 8D6C814AF8; Mon, 1 Jan 2001 13:59:55 +0100 (CET) Date: Mon, 1 Jan 2001 13:59:55 +0100 From: Alexander Langer To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: (fwd) getnanouptime() patch Message-ID: <20010101135955.A4625@cichlids.cichlids.com> References: <20010101133438.A4214@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Mon, Jan 01, 2001 at 11:54:36PM +1100 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Bruce Evans (bde@zeta.org.au): > Actually, timecounters are statically initialized to a dummy timecounter, > so the lock-up is probably caused by some other bug, possibly an > uninitialized event handler. > So the patch has no effect except to slow down nanotime(). Oh. That is not good. But I'm curious: Isn't the nanotime() function wrong, too, in this case? void nanotime(struct timespec *ts) { unsigned count; u_int64_t delta; struct timecounter *tc; nnanotime++; tc = timecounter; #ifdef KTR if (tc == NULL) { /* called before initialization */ ts->tv_sec = 0; ts->tv_nsec = 0; return; } #endif [....] That's where I took the code from. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 1 10:47:42 2001 From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 10:47:39 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E77C137B400 for ; Mon, 1 Jan 2001 10:47:37 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA06655; Tue, 2 Jan 2001 05:47:22 +1100 Date: Tue, 2 Jan 2001 05:48:14 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alexander Langer Cc: arch@FreeBSD.ORG Subject: Re: (fwd) getnanouptime() patch In-Reply-To: <20010101135955.A4625@cichlids.cichlids.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 1 Jan 2001, Alexander Langer wrote: > Thus spake Bruce Evans (bde@zeta.org.au): > > > Actually, timecounters are statically initialized to a dummy timecounter, > > so the lock-up is probably caused by some other bug, possibly an > > uninitialized event handler. > > So the patch has no effect except to slow down nanotime(). > > Oh. That is not good. > > But I'm curious: Isn't the nanotime() function wrong, too, in this > case? > ... > void > nanotime(struct timespec *ts) > { > unsigned count; > u_int64_t delta; > struct timecounter *tc; > > nnanotime++; > tc = timecounter; > #ifdef KTR > if (tc == NULL) { /* called before initialization */ > ts->tv_sec = 0; > ts->tv_nsec = 0; > return; > } > #endif This is bogus at best. `timecounter' is never NULL unless there is a bug switching it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 1 21:59:20 2001 From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 21:59:18 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mail.ticonet.co.cr (mail.ticonet.co.cr [196.40.4.5]) by hub.freebsd.org (Postfix) with ESMTP id 913EF37B400; Mon, 1 Jan 2001 21:59:07 -0800 (PST) Received: from Popeye [196.40.53.184] by mail.ticonet.co.cr (SMTPD32-6.05) id AA3C27A01DA; Mon, 01 Jan 2001 22:52:44 +0000 To: Happy@FreeBSD.ORG, New@FreeBSD.ORG, !!@Year.FreeBSD.ORG From: Oldies@FreeBSD.ORG, Online@FreeBSD.ORG, Casino@FreeBSD.ORG Subject: 01-01-2001 Date: Mon, 01 Jan 2001 23:59:11 -0600 Message-Id: <36892.999437418984600.238265@localhost> MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oldies Online Casino - Happy New Year!!!

Oldies Online Casino
Would like to welcome you and your family a Happy New Year!

We Would also like to offer ALL NEW & EXISTING Members a
Holiday 25% Bonus
Oldies Online Casino offers Free no download Flash Internet
gambling, games include craps, keno, slots, video poker,
roulette and blackjack in real time. Play for fun or cash!
http://www.oldiesonlinecasino.com

to unsubscribe click here

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 2 12:17:53 2001 From owner-freebsd-arch@FreeBSD.ORG Tue Jan 2 12:17:49 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 14A3C37B402 for ; Tue, 2 Jan 2001 12:17:49 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YMS25LMG; Tue, 2 Jan 2001 15:17:52 -0500 Reply-To: Randell Jesup To: chris@calldei.com Cc: Peter Pentchev , arch@FreeBSD.ORG Subject: Re: add -I ignoremask option to du(1) References: <20001214034803.C575@ringworld.oblivion.bg> <20001230012354.B20546@holly.calldei.com> <20001230095122.A4285@ringworld.oblivion.bg> <20001230160755.E20546@holly.calldei.com> From: Randell Jesup Date: 02 Jan 2001 15:19:01 -0500 In-Reply-To: Chris Costello's message of "Sat, 30 Dec 2000 16:07:55 -0600" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Costello writes: >On Saturday, December 30, 2000, Peter Pentchev wrote: >> This doesn't 1. exclude subdirectories; 2. provide per-directory stats. >> In no way does it solve the problem I mentioned in the part you quoted - >> excluding CVS/ subdirs from du output on a source tree. > > Sorry. Try: > >find . -maxdepth 1 \! \( -path '*CVS*' \) | xargs du -skc Nope. First, this considers files to be the same as directories. Second, this only excludes CVS directories from the top level - deeper CVS directories are included. Suffice it to say this series of attempts indicates that find/etc is NOT a reasonable(*) way to implement this (reasonable) request. Add the argument to du(1). Randell (*): since no one here in what should be one of the most experienced group of BSD hackers has posted a workable "unix-style" method, I conclude that it's either not possible, or at least is so non-obvious as to be effectively non-existant to any but the most experienced user. That's the problem with the old-school Unix philosophy of no program doing more than one thing, and stringing them together - the "stringing them together" part often ends up being as complicated a task as programming a solution into the program itself - or even more complicated. That's ok (sort of) if everyone using it is a programmer, and doesn't mind reinventing the wheel every few days. It's not ok for 99% of users. Sure, shell's are programming languages - but I don't really want to write a program just to find out how much disk space I'm using, or to sort the output of ls (another old argument), etc. ps. yes, I am a shell-script hacker to a degree, and have written shells, and used shells in all sorts of evil ways - but I don't want to tell everyone else to try to do that. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 8:38: 3 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 08:38:01 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 4C9A337B404 for ; Wed, 3 Jan 2001 08:38:01 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id IAA88851 for ; Wed, 3 Jan 2001 08:38:00 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f03Gbx060952 for arch@FreeBSD.ORG; Wed, 3 Jan 2001 08:37:59 -0800 (PST) (envelope-from obrien) Date: Wed, 3 Jan 2001 08:37:59 -0800 From: "David O'Brien" To: arch@FreeBSD.ORG Subject: Re: add -I ignoremask option to du(1) Message-ID: <20010103083759.B60879@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20001214034803.C575@ringworld.oblivion.bg> <20001230012354.B20546@holly.calldei.com> <20001230095122.A4285@ringworld.oblivion.bg> <20001230160755.E20546@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rjesup@wgate.com on Tue, Jan 02, 2001 at 03:19:01PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: obrien@NUXI.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 02, 2001 at 03:19:01PM -0500, Randell Jesup wrote: > (*): since no one here in what should be one of the most experienced group > of BSD hackers has posted a workable "unix-style" method, I conclude > that it's either not possible, or at least is so non-obvious as to be > effectively non-existant to any but the most experienced user. Agreed. Just commit the -I bits and let those that don't like it, never type it on the command line. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 9:41:27 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 09:41:23 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from puck.firepipe.net (poynting.physics.purdue.edu [128.210.146.58]) by hub.freebsd.org (Postfix) with ESMTP id 0BC6537B400; Wed, 3 Jan 2001 09:41:23 -0800 (PST) Received: from argon.firepipe.net (pm007-022.dialup.bignet.net [64.79.81.54]) by puck.firepipe.net (Postfix) with ESMTP id BCB551999; Wed, 3 Jan 2001 12:41:21 -0500 (EST) Received: by argon.firepipe.net (Postfix, from userid 1000) id EA28219E0; Wed, 3 Jan 2001 12:41:10 -0500 (EST) Date: Wed, 3 Jan 2001 12:41:10 -0500 From: Will Andrews To: Peter Wemm Cc: Stephen McKay , phk@FreeBSD.org, arch@FreeBSD.org Subject: Re: Reinstatement of CIRCLEQ Message-ID: <20010103124110.L86630@argon.firepipe.net> Reply-To: Will Andrews , arch@FreeBSD.org Mail-Followup-To: Will Andrews , Peter Wemm , Stephen McKay , phk@FreeBSD.org, arch@FreeBSD.org References: <200101031259.f03CxvY19161@dungeon.home> <200101031724.f03HOHq04000@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101031724.f03HOHq04000@mobile.wemm.org>; from peter@netplex.com.au on Wed, Jan 03, 2001 at 09:24:17AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: will@argon.firepipe.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ moved to -arch since this is really the correct location for it ] On Wed, Jan 03, 2001 at 09:24:17AM -0800, Peter Wemm wrote: > > Put your complaints about CIRCLEQ in the manual page, and people can choose > > based on facts. All this commit does is reduce code portability. > > I tend to agree, for what it is worth. CIRCLEQ() is an expected part of > the 4.4BSD API and an expected part of . We dont have to use > it, but I feel it is a mistake to nuke an API that is expected to be there. I've never read Knuth's book and am not particularly knowledgeable about queue(3). But I think that unless a good reason (which I have not seen yet) is given for why CIRCLEQ() was nuked, it should be put back. Especially since there doesn't seem to be any kind of move like this in the NetBSD or OpenBSD camps. So this might end up biting FreeBSD in the ass someday as far as portability goes. So, why remove CIRCLEQ()? -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 13: 1:15 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 13:01:13 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by hub.freebsd.org (Postfix) with ESMTP id 27B8A37B402 for ; Wed, 3 Jan 2001 13:01:12 -0800 (PST) Received: from fwd07.sul.t-online.com by mailout03.sul.t-online.com with smtp id 14Dv1x-0004OU-07; Wed, 03 Jan 2001 22:01:09 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.225.194.96]) by fmrl07.sul.t-online.com with esmtp id 14Dv1l-1sXi8eC; Wed, 3 Jan 2001 22:00:57 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 14441AB0C; Wed, 3 Jan 2001 22:01:39 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 98CC414AF9; Wed, 3 Jan 2001 22:01:04 +0100 (CET) Date: Wed, 3 Jan 2001 22:01:04 +0100 From: Alexander Langer To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: (fwd) getnanouptime() patch Message-ID: <20010103220104.A2132@cichlids.cichlids.com> References: <20010101135955.A4625@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Tue, Jan 02, 2001 at 05:48:14AM +1100 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Bruce Evans (bde@zeta.org.au): > > #ifdef KTR > > if (tc == NULL) { /* called before initialization */ > > ts->tv_sec = 0; > > ts->tv_nsec = 0; > > return; > > } > > #endif > This is bogus at best. `timecounter' is never NULL unless there is a bug > switching it. Would someone then please change that? A check if (timecounter == &dummy_timecounter) is the correct one (IMHO), as shown in the tc_init() function. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 15: 0:52 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 15:00:49 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from io.yi.org (cr66388-a.rchrd1.on.wave.home.com [24.114.165.24]) by hub.freebsd.org (Postfix) with ESMTP id 27F6437B400 for ; Wed, 3 Jan 2001 15:00:49 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 03B1EBA7D; Wed, 3 Jan 2001 17:56:03 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Eischen Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: Condition variable patch for review In-Reply-To: Message from Daniel Eischen of "Fri, 29 Dec 2000 14:58:11 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jan 2001 17:56:02 -0500 From: Jake Burkholder Message-Id: <20010103225603.03B1EBA7D@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On 29 Dec 2000, Jason Evans wrote: > > There is a patch that implements condition variables (mostly written by > > Jake Burkholder) at: > > > > http://people.freebsd.org/~jasone/diffs/condvar.diff > > Comments: > > Get rid of the 'pri' parameter. Why is it needed, and if so, > is it needed in the common case? Look for other ways to accomplish > what you need without dirtying the CV interface and making it > non-standard. This is the same comment I have about the mutex > interface and needing to pass the mutex type to every operation. > Please, let's see this eliminated before 5.0-release, otherwise > we are stuck with it as an API. I'm not sure that it can be removed if condition variables are to be used where sleep is now. Maybe it can if the re-write of the kernel scheduler to support kses amounts to more than s/proc/kse/. What it does is give processes a priority jolt when they wake up, so they get to run Real Soon. Look at the priority values that are passed in to tsleep for an example. I don't care either way as long as it works. > > Identify which functions are part of our kernel API. I would > think that cv_waitq_empty and cv_waitq_remove would not be > part of this interface. I assume cv_waitq_remove will eventually > take a struct thread (or something) instead of a struct proc. > I'd rather see this as a macro since it's usage should be > limited. It parallels unsleep. I don't see any reason to make it a macro. It should only be used in one place, in setrunnable when the process that's passed in is on a condition variable queue. > > I prefer cv_timedwait over cv_twait... > > Other than that, I am happy that we finally have condition > variables :-) > > -- > Dan Eischen > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 15:47:57 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 15:47:54 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 57F0537B400 for ; Wed, 3 Jan 2001 15:47:53 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA03981; Wed, 3 Jan 2001 18:47:30 -0500 (EST) Date: Wed, 3 Jan 2001 18:47:30 -0500 (EST) From: Daniel Eischen To: Jake Burkholder Cc: Jason Evans , arch@FreeBSD.ORG Subject: Re: Condition variable patch for review In-Reply-To: <20010103225603.03B1EBA7D@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 3 Jan 2001, Jake Burkholder wrote: > > On 29 Dec 2000, Jason Evans wrote: > > > There is a patch that implements condition variables (mostly written by > > > Jake Burkholder) at: > > > > > > http://people.freebsd.org/~jasone/diffs/condvar.diff > > > > Comments: > > > > Get rid of the 'pri' parameter. Why is it needed, and if so, > > is it needed in the common case? Look for other ways to accomplish > > what you need without dirtying the CV interface and making it > > non-standard. This is the same comment I have about the mutex > > interface and needing to pass the mutex type to every operation. > > Please, let's see this eliminated before 5.0-release, otherwise > > we are stuck with it as an API. > > I'm not sure that it can be removed if condition variables are > to be used where sleep is now. Maybe it can if the re-write of the > kernel scheduler to support kses amounts to more than s/proc/kse/. > What it does is give processes a priority jolt when they wake up, > so they get to run Real Soon. Look at the priority values that are > passed in to tsleep for an example. The priorities in tsleep() are the soft priorities that should now go away. Each thread has its own priority and we also have priority inheritence mutexes. I assume interrupt threads run at higher priority than other threads/processes. What additional "boost" is needed? Look at Solaris kernel condition variables - there is no priority as a parameter and they also transitioned from splXXX/tsleep. They do have ddi_iblock_cookies (ddi_get_iblock_cookie and ddi_get_soft_iblock_cookie) that can be associated with kernel mutexes, though. I suppose this is how they can "boost" the priority of threads that own/wait on mutexes that have been init'd with these cookies. I'd rather see us do something along this line if we have to. > I don't care either way as long as it works. > > > > Identify which functions are part of our kernel API. I would > > think that cv_waitq_empty and cv_waitq_remove would not be > > part of this interface. I assume cv_waitq_remove will eventually > > take a struct thread (or something) instead of a struct proc. > > I'd rather see this as a macro since it's usage should be > > limited. > > It parallels unsleep. I don't see any reason to make it a macro. > It should only be used in one place, in setrunnable when the process > that's passed in is on a condition variable queue. And if it's only used in one place, is it something that we want device drivers to use? Let's keep functions like this out of our advertised kernel API, or at least document those that shouldn't be used by ABI compliant drivers/modules. BTW, I don't see unsleep() in sleep(9) nor in . -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 17: 7:31 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 17:07:28 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from io.yi.org (cr66388-a.rchrd1.on.wave.home.com [24.114.165.24]) by hub.freebsd.org (Postfix) with ESMTP id 353C437B402 for ; Wed, 3 Jan 2001 17:07:28 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 287D0BA7D; Wed, 3 Jan 2001 20:02:41 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Eischen Cc: Jake Burkholder , Jason Evans , arch@FreeBSD.ORG, jake@io.yi.org Subject: Re: Condition variable patch for review In-Reply-To: Message from Daniel Eischen of "Wed, 03 Jan 2001 18:47:30 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jan 2001 20:02:41 -0500 From: Jake Burkholder Message-Id: <20010104010241.287D0BA7D@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 3 Jan 2001, Jake Burkholder wrote: > > > On 29 Dec 2000, Jason Evans wrote: > > > > There is a patch that implements condition variables (mostly written by > > > > Jake Burkholder) at: > > > > > > > > http://people.freebsd.org/~jasone/diffs/condvar.diff > > > > > > Comments: > > > > > > Get rid of the 'pri' parameter. Why is it needed, and if so, > > > is it needed in the common case? Look for other ways to accomplish > > > what you need without dirtying the CV interface and making it > > > non-standard. This is the same comment I have about the mutex > > > interface and needing to pass the mutex type to every operation. > > > Please, let's see this eliminated before 5.0-release, otherwise > > > we are stuck with it as an API. > > > > I'm not sure that it can be removed if condition variables are > > to be used where sleep is now. Maybe it can if the re-write of the > > kernel scheduler to support kses amounts to more than s/proc/kse/. > > What it does is give processes a priority jolt when they wake up, > > so they get to run Real Soon. Look at the priority values that are > > passed in to tsleep for an example. > > The priorities in tsleep() are the soft priorities that should now > go away. Each thread has its own priority and we also have priority > inheritence mutexes. I assume interrupt threads run at higher > priority than other threads/processes. What additional "boost" > is needed? It depends on how urgent the thing that the process is waiting for is. Also, process priority degrades over time. > > Look at Solaris kernel condition variables - there is no priority > as a parameter and they also transitioned from splXXX/tsleep. > They do have ddi_iblock_cookies (ddi_get_iblock_cookie and > ddi_get_soft_iblock_cookie) that can be associated with kernel > mutexes, though. I suppose this is how they can "boost" the > priority of threads that own/wait on mutexes that have been > init'd with these cookies. I'd rather see us do something > along this line if we have to. I've read the headers and the man pages... > > > I don't care either way as long as it works. > > > > > > Identify which functions are part of our kernel API. I would > > > think that cv_waitq_empty and cv_waitq_remove would not be > > > part of this interface. I assume cv_waitq_remove will eventually > > > take a struct thread (or something) instead of a struct proc. > > > I'd rather see this as a macro since it's usage should be > > > limited. > > > > It parallels unsleep. I don't see any reason to make it a macro. > > It should only be used in one place, in setrunnable when the process > > that's passed in is on a condition variable queue. > > And if it's only used in one place, is it something that we want > device drivers to use? Let's keep functions like this out of our > advertised kernel API, or at least document those that shouldn't > be used by ABI compliant drivers/modules. BTW, I don't see unsleep() > in sleep(9) nor in . proc.h:void unsleep __P((struct proc *)); > > -- > Dan Eischen > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 17:39:42 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 17:39:40 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EDB4237B400 for ; Wed, 3 Jan 2001 17:39:39 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id UAA18508; Wed, 3 Jan 2001 20:39:15 -0500 (EST) Date: Wed, 3 Jan 2001 20:39:15 -0500 (EST) From: Daniel Eischen To: Jake Burkholder Cc: Jason Evans , arch@FreeBSD.ORG, jake@io.yi.org Subject: Re: Condition variable patch for review In-Reply-To: <20010104010241.287D0BA7D@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 3 Jan 2001, Jake Burkholder wrote: > > On Wed, 3 Jan 2001, Jake Burkholder wrote: > > > > On 29 Dec 2000, Jason Evans wrote: > > > > > There is a patch that implements condition variables (mostly written by > > > > > Jake Burkholder) at: > > > > > > > > > > http://people.freebsd.org/~jasone/diffs/condvar.diff > > > > > > > > Comments: > > > > > > > > Get rid of the 'pri' parameter. Why is it needed, and if so, > > > > is it needed in the common case? Look for other ways to accomplish > > > > what you need without dirtying the CV interface and making it > > > > non-standard. This is the same comment I have about the mutex > > > > interface and needing to pass the mutex type to every operation. > > > > Please, let's see this eliminated before 5.0-release, otherwise > > > > we are stuck with it as an API. > > > > > > I'm not sure that it can be removed if condition variables are > > > to be used where sleep is now. Maybe it can if the re-write of the > > > kernel scheduler to support kses amounts to more than s/proc/kse/. > > > What it does is give processes a priority jolt when they wake up, > > > so they get to run Real Soon. Look at the priority values that are > > > passed in to tsleep for an example. > > > > The priorities in tsleep() are the soft priorities that should now > > go away. Each thread has its own priority and we also have priority > > inheritence mutexes. I assume interrupt threads run at higher > > priority than other threads/processes. What additional "boost" > > is needed? > > It depends on how urgent the thing that the process is waiting > for is. Also, process priority degrades over time. For time-sharing yes. So let it. The wakeup from cv_wait and friends is also suppose to take the mutex again. If there is any priority boost needed, let it be inherent in the mutex. If you own the mutex, you inherit its priority. When you perform the cv_wait() and atomically release the mutex, don't give up the inherited priority. You *will* wake up again with the mutex regardless of whether you've been signaled or not (in the case of timedwaits or a process signal). In lieu of having something like Solaris iblock cookies, I suppose you could init the mutex with the priority that you intend on using in the cv_wait() functions. You can sneek a peek at the mutex priority inside cv_wait if necessary since the mutex is a parameter. > > > It parallels unsleep. I don't see any reason to make it a macro. > > > It should only be used in one place, in setrunnable when the process > > > that's passed in is on a condition variable queue. > > > > And if it's only used in one place, is it something that we want > > device drivers to use? Let's keep functions like this out of our > > advertised kernel API, or at least document those that shouldn't > > be used by ABI compliant drivers/modules. BTW, I don't see unsleep() > > in sleep(9) nor in . > > proc.h:void unsleep __P((struct proc *)); Right, but my point was that it's not an API that kernel developers should use; othewise it would be in the man page alongside tsleep and friends :-) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 20:47: 5 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 20:47:04 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2766337B400 for ; Wed, 3 Jan 2001 20:47:03 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA18617; Thu, 4 Jan 2001 15:46:35 +1100 Date: Thu, 4 Jan 2001 15:47:27 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alexander Langer Cc: arch@FreeBSD.ORG Subject: Re: (fwd) getnanouptime() patch In-Reply-To: <20010103220104.A2132@cichlids.cichlids.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 3 Jan 2001, Alexander Langer wrote: > Thus spake Bruce Evans (bde@zeta.org.au): > > > > #ifdef KTR > > > if (tc == NULL) { /* called before initialization */ > > > ts->tv_sec = 0; > > > ts->tv_nsec = 0; > > > return; > > > } > > > #endif > > This is bogus at best. `timecounter' is never NULL unless there is a bug > > switching it. > > Would someone then please change that? phk removed it. > A check if (timecounter == &dummy_timecounter) is the correct one > (IMHO), as shown in the tc_init() function. No. The purpose of dummy_timecounter is to avoid the need for code like the above. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 3 23:19:22 2001 From owner-freebsd-arch@FreeBSD.ORG Wed Jan 3 23:19:20 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id D3E5637B400; Wed, 3 Jan 2001 23:19:19 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id XAA04872; Wed, 3 Jan 2001 23:19:02 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200101040719.XAA04872@beastie.mckusick.com> To: Will Andrews Subject: Re: Reinstatement of CIRCLEQ Cc: Peter Wemm , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: Your message of "Wed, 03 Jan 2001 12:41:10 EST." <20010103124110.L86630@argon.firepipe.net> Date: Wed, 03 Jan 2001 23:19:02 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Wed, 3 Jan 2001 12:41:10 -0500 From: Will Andrews To: Peter Wemm Cc: Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ [ moved to -arch since this is really the correct location for it ] On Wed, Jan 03, 2001 at 09:24:17AM -0800, Peter Wemm wrote: > > Put your complaints about CIRCLEQ in the manual page, and people > > can choose based on facts. All this commit does is reduce code > > portability. > > I tend to agree, for what it is worth. CIRCLEQ() is an expected > part of the 4.4BSD API and an expected part of . > We dont have to use it, but I feel it is a mistake to nuke an > API that is expected to be there. I've never read Knuth's book and am not particularly knowledgeable about queue(3). But I think that unless a good reason (which I have not seen yet) is given for why CIRCLEQ() was nuked, it should be put back. Especially since there doesn't seem to be any kind of move like this in the NetBSD or OpenBSD camps. So this might end up biting FreeBSD in the ass someday as far as portability goes. So, why remove CIRCLEQ()? -- wca As the original author of I would like to speak up in support of the removal of CIRCLEQ. They were originally added because I had not thought up a portable way to traverse TAILQ's in reverse and certain applications need that functionality. A few years ago, when reviewing the TAILQ functions, I realized that it is in fact possible to traverse TAILQ's in reverse in a portable way and added the TAILQ_PREV function. With this addition, there were no capabilities left in CIRCLEQ that could not be done with TAILQ in a more efficient manner (TAILQ's generate fewer tests when doing their operations than CIRCLEQ's). Further, the termination conditions for TAILQ's (testing against NULL) are much simpler and more easily coded than the termination condition for CIRCLEQ's (saving the queue head and checking to see if it has been reached). CIRCLEQ's have been very lightly used, and few users will be inconvenienced by their removal. The resulting code base will be simpler, faster, and cleaner. There are times when one should break with the past, and I believe that this is just such a time. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 0:20: 0 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 00:19:58 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0C33137B402; Thu, 4 Jan 2001 00:19:58 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f048Jhf19608; Thu, 4 Jan 2001 00:19:43 -0800 (PST) Date: Thu, 4 Jan 2001 00:19:43 -0800 From: Alfred Perlstein To: Kirk McKusick Cc: Will Andrews , Peter Wemm , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ Message-ID: <20010104001943.T292@fw.wintelcom.net> References: <20010103124110.L86630@argon.firepipe.net> <200101040719.XAA04872@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101040719.XAA04872@beastie.mckusick.com>; from mckusick@mckusick.com on Wed, Jan 03, 2001 at 11:19:02PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kirk McKusick [010103 23:19] wrote: > > As the original author of I would like to speak up > in support of the removal of CIRCLEQ. They were originally added > because I had not thought up a portable way to traverse TAILQ's > in reverse and certain applications need that functionality. A > few years ago, when reviewing the TAILQ functions, I realized that > it is in fact possible to traverse TAILQ's in reverse in a portable > way and added the TAILQ_PREV function. With this addition, there > were no capabilities left in CIRCLEQ that could not be done with > TAILQ in a more efficient manner (TAILQ's generate fewer tests > when doing their operations than CIRCLEQ's). Further, the termination > conditions for TAILQ's (testing against NULL) are much simpler and > more easily coded than the termination condition for CIRCLEQ's > (saving the queue head and checking to see if it has been reached). > CIRCLEQ's have been very lightly used, and few users will be > inconvenienced by their removal. The resulting code base will be > simpler, faster, and cleaner. There are times when one should > break with the past, and I believe that this is just such a time. *blush* You're right, I'm wondering though, would it be possible to change TAILQ_PREV(elm, headname, field) to TAILQ_PREV(elm, field) by using the offset of 'field' into the struct? You could subtract the offset of 'field' from the tqe_prev of the next struct right? This would also reduce it by one memory access. Or is this the unportability/headache you were trying to avoid? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 9: 9: 1 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 09:08:59 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 9474C37B400; Thu, 4 Jan 2001 09:08:58 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id JAA05731; Thu, 4 Jan 2001 09:08:47 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200101041708.JAA05731@beastie.mckusick.com> To: Alfred Perlstein Subject: Re: Reinstatement of CIRCLEQ Cc: Will Andrews , Peter Wemm , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: Your message of "Thu, 04 Jan 2001 00:19:43 PST." <20010104001943.T292@fw.wintelcom.net> Date: Thu, 04 Jan 2001 09:08:47 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Thu, 4 Jan 2001 00:19:43 -0800 From: Alfred Perlstein To: Kirk McKusick Subject: Re: Reinstatement of CIRCLEQ In-Reply-To: <200101040719.XAA04872@beastie.mckusick.com>; from mckusick@mckusick.com on Wed, Jan 03, 2001 at 11:19:02PM -0800 You're right, I'm wondering though, would it be possible to change TAILQ_PREV(elm, headname, field) to TAILQ_PREV(elm, field) by using the offset of 'field' into the struct? You could subtract the offset of 'field' from the tqe_prev of the next struct right? This would also reduce it by one memory access. Or is this the unportability/headache you were trying to avoid? -Alfred You are correct that your suggested change is exactly the unportability/headache that I am trying to avoid. Further, the current code detects the end-condition (reaching the head of the list in the case of TAILQ_PREV or an empty list in the case of TAILQ_LAST) with no conditional code. That is, after the two indirections, the pointer will be null in the above cases; it is not necessary to put in a check for the end condition in the above macros. Using your technique would require adding a condition. On our increasingly pipelined machines these days, avoiding conditional code is generally a win. Note that the lower performance of CIRCLEQ's was that they needed conditional tests in the traversal macros to detect end conditions. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 11: 0:53 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 11:00:51 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id EFDE537B400; Thu, 4 Jan 2001 11:00:49 -0800 (PST) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id UAA44981; Thu, 4 Jan 2001 20:00:39 +0100 (CET) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id UAA88107; Thu, 4 Jan 2001 20:00:39 +0100 (CET) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Thu, 4 Jan 2001 20:00:39 +0100 (CET) From: Marius Bendiksen To: "Bruce A. Mah" Cc: Kris Kennaway , David Xu , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Release notes (was Re: retiring kernfs) In-Reply-To: <200012272151.eBRLpIc51777@bmah-freebsd-0.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > too much detail for our release notes. Basically, the problem is that > the audience for our commit messages and the audience for "release > notes" (as I perceive them anyways) are different. > > I've been doing a lot of the items for RELNOTES.TXT lately; it's > sometimes hard figuring out what impact a given commit message is going > to have on my-conception-of-the-average-user. Some other committers > (I'm going to hold up gshapiro as a great example) do a wonderful job of > documenting their commits in the release notes, which helps immensely. Why not mandate a line of the form RELEASE NOTE: yyyymmdd[hhmm[ss]] account - note and then have an automated script gather these up regularly? Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 11:29: 7 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 11:29:05 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 7A33B37B400; Thu, 4 Jan 2001 11:29:05 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f04JSEG60610; Thu, 4 Jan 2001 11:28:14 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 04 Jan 2001 11:29:11 -0800 (PST) From: John Baldwin To: Marius Bendiksen Subject: Re: Release notes (was Re: retiring kernfs) Cc: arch@FreeBSD.org, Alfred Perlstein , David Xu , Kris Kennaway , "Bruce A. Mah" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 04-Jan-01 Marius Bendiksen wrote: >> too much detail for our release notes. Basically, the problem is that >> the audience for our commit messages and the audience for "release >> notes" (as I perceive them anyways) are different. >> >> I've been doing a lot of the items for RELNOTES.TXT lately; it's >> sometimes hard figuring out what impact a given commit message is going >> to have on my-conception-of-the-average-user. Some other committers >> (I'm going to hold up gshapiro as a great example) do a wonderful job of >> documenting their commits in the release notes, which helps immensely. > > Why not mandate a line of the form > RELEASE NOTE: yyyymmdd[hhmm[ss]] account - note > and then have an automated script gather these up regularly? If that would work, then committers would be adding lines to RELNOTES.TXT directly on their own. > Marius -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 11:43:39 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 11:43:37 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by hub.freebsd.org (Postfix) with ESMTP id 2ECD037B400; Thu, 4 Jan 2001 11:43:37 -0800 (PST) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA07904; Thu, 4 Jan 2001 11:43:35 -0800 (PST) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.1/8.11.1) id f04JhYH10969; Thu, 4 Jan 2001 11:43:34 -0800 (PST) (envelope-from bmah) Message-Id: <200101041943.f04JhYH10969@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.2+ 01/03/2001 with nmh-1.0.4 To: John Baldwin Cc: Marius Bendiksen , arch@FreeBSD.org, Alfred Perlstein , David Xu , Kris Kennaway , "Bruce A. Mah" Subject: Re: Release notes (was Re: retiring kernfs) In-Reply-To: References: Comments: In-reply-to John Baldwin message dated "Thu, 04 Jan 2001 11:29:11 -0800." From: bmah@FreeBSD.org (Bruce A. Mah) Reply-To: bmah@FreeBSD.org X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_275096066P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 04 Jan 2001 11:43:34 -0800 Sender: bmah@cisco.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --==_Exmh_275096066P Content-Type: text/plain; charset=us-ascii If memory serves me right, John Baldwin wrote: > > Why not mandate a line of the form > > RELEASE NOTE: yyyymmdd[hhmm[ss]] account - note > > and then have an automated script gather these up regularly? To Marius: I presume you're referring to a mandatory line in commit messages. The problem is that there's lots of commits that don't really result in release note entries (i.e. fixing a typo in an error message, or eliminating a compiler warning). > If that would work, then committers would be adding lines to RELNOTES.TXT > directly on their own. To John: I agree, but I would love to be proven wrong. (Thanks, by the way, to anyone who's committed to the release notes files, especially gshapiro and sanpei, who have been especially consciencious about this.) Bruce. --==_Exmh_275096066P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE6VNJl2MoxcVugUsMRAqBDAKC4Q/giZ5QULcA+n4MTiX+dt371TACgy+iW sxiKm4LO6CJ1iiMT/KbZmOU= =ieX/ -----END PGP SIGNATURE----- --==_Exmh_275096066P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 11:57:23 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 11:57:21 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id B649637B404; Thu, 4 Jan 2001 11:57:19 -0800 (PST) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 14EGVh-0001lW-00; Thu, 04 Jan 2001 19:57:17 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.1/8.11.1) id f04JwBJ51829; Thu, 4 Jan 2001 20:58:11 +0100 (CET) (envelope-from wkb) Date: Thu, 4 Jan 2001 20:58:10 +0100 From: Wilko Bulte To: "Bruce A. Mah" Cc: John Baldwin , Marius Bendiksen , arch@freebsd.org, Alfred Perlstein , David Xu , Kris Kennaway Subject: Re: Release notes (was Re: retiring kernfs) Message-ID: <20010104205810.H22608@freebie.demon.nl> References: <200101041943.f04JhYH10969@bmah-freebsd-0.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200101041943.f04JhYH10969@bmah-freebsd-0.cisco.com>; from bmah@freebsd.org on Thu, Jan 04, 2001 at 11:43:34AM -0800 X-OS: FreeBSD 4.2-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 04, 2001 at 11:43:34AM -0800, Bruce A. Mah wrote: > If memory serves me right, John Baldwin wrote: > > > > Why not mandate a line of the form > > > RELEASE NOTE: yyyymmdd[hhmm[ss]] account - note > > > and then have an automated script gather these up regularly? > > To Marius: I presume you're referring to a mandatory line in commit > messages. The problem is that there's lots of commits that don't really > result in release note entries (i.e. fixing a typo in an error > message, or eliminating a compiler warning). I don't think automating release note entries would ever work. A carefully handcrafted relnote file is much better than one created automagically. > (Thanks, by the way, to anyone who's committed to the release notes > files, especially gshapiro and sanpei, who have been especially > consciencious about this.) That is exactly the point: consciencious one must be to produce good, readable and understandable information. Forcing people to write something up in a commit message *that is suitable for a relnote file* is impossible IMHO. -- Wilko Bulte Arnhem, the Netherlands wilko@freebsd.org http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 14:26: 2 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 14:26:00 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 90E6037B400; Thu, 4 Jan 2001 14:25:56 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 14EIox-0000Vk-00; Thu, 04 Jan 2001 22:25:19 +0000 Date: Thu, 4 Jan 2001 22:25:19 +0000 From: Tony Finch To: Kirk McKusick Cc: Alfred Perlstein , Will Andrews , Peter Wemm , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ Message-ID: <20010104222519.Y2140@hand.dotat.at> References: <20010104001943.T292@fw.wintelcom.net> <200101041708.JAA05731@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200101041708.JAA05731@beastie.mckusick.com> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kirk McKusick wrote: > From: Alfred Perlstein > > You're right, I'm wondering though, would it be possible > to change TAILQ_PREV(elm, headname, field) to TAILQ_PREV(elm, > field) by using the offset of 'field' into the struct? > You could subtract the offset of 'field' from the tqe_prev > of the next struct right? > >You are correct that your suggested change is exactly the >unportability/headache that I am trying to avoid. The Apache Group needed a linked list structure that would allow insertions before and after a given element without knowing the address of the list header. Although I wanted to use sys/queue.h it didn't quite have that functionality so I wrote some "ring" macros based on code by Dean Gaudet. http://www.apache.org/websrc/cvsweb.cgi/~checkout~/apr-util/include/ap_ring.h?rev=1.5&content-type=text/plain Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "You realize there's a government directive stating that there is no such thing as a flying saucer?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 15:44:17 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 15:44:15 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D14AE37B400 for ; Thu, 4 Jan 2001 15:44:15 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f04Ni4B13059; Thu, 4 Jan 2001 15:44:04 -0800 (PST) Date: Thu, 4 Jan 2001 15:44:04 -0800 From: Alfred Perlstein To: Tony Finch Cc: arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ Message-ID: <20010104154404.F292@fw.wintelcom.net> References: <20010104001943.T292@fw.wintelcom.net> <200101041708.JAA05731@beastie.mckusick.com> <20010104222519.Y2140@hand.dotat.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010104222519.Y2140@hand.dotat.at>; from dot@dotat.at on Thu, Jan 04, 2001 at 10:25:19PM +0000 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Tony Finch [010104 14:25] wrote: > Kirk McKusick wrote: > > From: Alfred Perlstein > > > > You're right, I'm wondering though, would it be possible > > to change TAILQ_PREV(elm, headname, field) to TAILQ_PREV(elm, > > field) by using the offset of 'field' into the struct? > > You could subtract the offset of 'field' from the tqe_prev > > of the next struct right? > > > >You are correct that your suggested change is exactly the > >unportability/headache that I am trying to avoid. > > The Apache Group needed a linked list structure that would allow > insertions before and after a given element without knowing the > address of the list header. Although I wanted to use sys/queue.h it > didn't quite have that functionality so I wrote some "ring" macros > based on code by Dean Gaudet. Why not just use "LIST" then? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 15:52:58 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 15:52:55 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B39F937B400 for ; Thu, 4 Jan 2001 15:52:55 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f04Nqli13376; Thu, 4 Jan 2001 15:52:47 -0800 (PST) Date: Thu, 4 Jan 2001 15:52:47 -0800 From: Alfred Perlstein To: Tony Finch Cc: arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ Message-ID: <20010104155247.G292@fw.wintelcom.net> References: <20010104001943.T292@fw.wintelcom.net> <200101041708.JAA05731@beastie.mckusick.com> <20010104222519.Y2140@hand.dotat.at> <20010104154404.F292@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010104154404.F292@fw.wintelcom.net>; from bright@wintelcom.net on Thu, Jan 04, 2001 at 03:44:04PM -0800 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alfred Perlstein [010104 15:44] wrote: > * Tony Finch [010104 14:25] wrote: > > Kirk McKusick wrote: > > > From: Alfred Perlstein > > > > > > You're right, I'm wondering though, would it be possible > > > to change TAILQ_PREV(elm, headname, field) to TAILQ_PREV(elm, > > > field) by using the offset of 'field' into the struct? > > > You could subtract the offset of 'field' from the tqe_prev > > > of the next struct right? > > > > > >You are correct that your suggested change is exactly the > > >unportability/headache that I am trying to avoid. > > > > The Apache Group needed a linked list structure that would allow > > insertions before and after a given element without knowing the > > address of the list header. Although I wanted to use sys/queue.h it > > didn't quite have that functionality so I wrote some "ring" macros > > based on code by Dean Gaudet. > > Why not just use "LIST" then? Oh, actually for TAILQ one doesn't need the listhead, just a dummy struct declaration: TAILQ_HEAD(wizbangheadp, wizbang); which expands to this: struct wazbangheadp { struct wizbang *tqh_first; struct wizbang **tqh_last; } TAILQ_PREV then just needs these args: TAILQ_PREV(&mywizbang, -> wazbangheadp <-, field); ---------------------------^^^ just the struct name. Yes, it's icky and it's C's fault for not having "typeof()" in the standard. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 17:13:39 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 17:13:36 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 4F04D37B400; Thu, 4 Jan 2001 17:13:35 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f051Dtq61858; Thu, 4 Jan 2001 17:13:55 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101050113.f051Dtq61858@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Tony Finch Cc: Kirk McKusick , Alfred Perlstein , Will Andrews , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ In-Reply-To: <20010104222519.Y2140@hand.dotat.at> Date: Thu, 04 Jan 2001 17:13:54 -0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Finch wrote: > Kirk McKusick wrote: > > From: Alfred Perlstein > > > > You're right, I'm wondering though, would it be possible > > to change TAILQ_PREV(elm, headname, field) to TAILQ_PREV(elm, > > field) by using the offset of 'field' into the struct? > > You could subtract the offset of 'field' from the tqe_prev > > of the next struct right? > > > >You are correct that your suggested change is exactly the > >unportability/headache that I am trying to avoid. > > The Apache Group needed a linked list structure that would allow > insertions before and after a given element without knowing the > address of the list header. Although I wanted to use sys/queue.h it > didn't quite have that functionality so I wrote some "ring" macros > based on code by Dean Gaudet. > > http://www.apache.org/websrc/cvsweb.cgi/~checkout~/apr-util/include/ap_ring.h ?rev=1.5&content-type=text/plain This reminds me a *lot* of the Amiga double linked lists. The one major difference is that the Amiga had a different head/tail node that was constructed in such a way that you didn't need a sentinal. struct list { void *next; void *prev; void *tailprev; } struct node { void *next; void *prev; } The list head was initialized as though it was was two nodes with the "prev" element overlapping. ie: the head had "next" and "prev" as the node next/prev pointers, while the "tail" had "prev" and "tailprev" as the next/ prev pointers. Your beginning and end of list test was (this->next->next == NULL) and the test for first element was (this->prev->prev == NULL). There were no special cases for insert/removal at all. Initialization looked something like this: head->next = &head->prev; head->prev = NULL; head->tailprev = &head->prev; node removal needed no head pointer at all. You could just do REMOVE(node); INSERT_BEFORE(node, node) and INSERT_AFTER(node, node) were also trivial and had no references to the head node or any conditionals. INSERT_FIRST(head, node) was identical to INSERT_AFTER(head, node); INSERT_LAST(head, node) was identical to INSERT_BEFORE(head, node); LIST_EMPTY(head) looked something like this: if (head->next == &head->prev) { list_is_empty; } There were no double pointers, practically no conditionals and it mapped onto the 68000 instruction set beautifully. The only complication compared to macros and traditional linked lists is that the last node did not have a NULL next pointer. The last node pointed to the middle of the 'head' structure. Uh oh, I feel a Terry Lambert Ascii Diagram(TM) coming up: HEAD/TAIL HEAD/TAIL node1 node2 node3 next node3 next -> next -> next -> next -> prev (null) next -> prev (null) <- prev <- prev <- prev <- tailprev prev <- tailprev Note that the HEAD/TAIL structure is the same thing and that I have shown node3 twice to illustrate the wraparound. Note that "node3"->next->next == NULL, even though the next pointer is actually pointing at the "prev" pointer in the head (which happens to be null and "looks like" a valid "node") It was actually very simple and very elegant. I have never seen the polymorphic head/tail/node construct used anywhere else. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 17:48:32 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 17:48:28 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id F008137B400; Thu, 4 Jan 2001 17:48:27 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f051lYr96332; Thu, 4 Jan 2001 17:47:34 -0800 (PST) (envelope-from dillon) Date: Thu, 4 Jan 2001 17:47:34 -0800 (PST) From: Matt Dillon Message-Id: <200101050147.f051lYr96332@earth.backplane.com> To: Peter Wemm Cc: Tony Finch , Kirk McKusick , Alfred Perlstein , Will Andrews , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ References: <200101050113.f051Dtq61858@mobile.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Basically when implementing a doubly linked list the optimization tradeoff comes down to whether you want to remove the conditionals from the list scanning routines, or whether you want to remove the conditionals from the list insertion and removal routines. What it comes down to, in a nutshell, is that a circular-list implementation can be done that has no more conditionals then a non-circular list implementation. You simply have a LIST_EOF() macro which for a circular queue compares the 'next node' or 'previous node' against &listhead (which you probably already have in the L1 cache anyway or can calculate trivially, so no biggy). I use circular queues all over the place. Sometimes to make things easier (when I don't care about performance as much), I embed tests against the list head and return a conventional NULL. Otherwise I compare against the address of the list head, which is always at hand anyway and doesn't cost any extra verses comparing against NULL. For embedded systems I use these sorts of doubly linked queues all over the scheduler, often with at least one embedded 'real' node to remove even more conditionals from the code using the list in question. e.g. for a software interrupt queue I have a terminator node with a -1 software interrupt priority, which of course can never run so the scheduler softint dispatcher stops there, without having to check for list EOF on top of testing the software interrupt priorities verses the current task priority. I just typed this in from memory, so there may be type-o's. Oh, by the way, I think *ALL* the list macros in sys/queue.h suck rocks. (Sorry Kirk!). -Matt typedef struct Node { struct Node *no_Succ; struct Node *no_Pred; } Node; typedef struct List { Node li_Node; } List; #define LIST_EOF(list) (&(list)->li_Node) static __inline void initList(List *list) { list->li_Node.no_Succ = &list->li_Node; list->li_Node.no_Pred = &list->li_Node; } /* * caller tests result against LIST_EOF(list) to determine if the * list is empty (verses checking against NULL). It's one conditional * either way. */ static __inline void * getListHead(List *list) { return(list->li_Node.no_Succ); } static __inline void * getListTail(List *list) { return(list->li_Node.no_Pred); } static __inline void * getListSucc(Node *node) { return(node->no_Succ); } static __inline void * getListPred(Node *node) { return(node->no_Pred); } static __inline void insertNodeBefore(Node *lnode, Node *node) { node->no_Succ = lnode; node->no_Pred = lnode->no_Pred; node->no_Pred->no_Succ = node; lnode->no_Pred = node; } static __inline void insertNodeAfter(Node *lnode, Node *node) { node->no_Pred = lnode; node->no_Succ = lnode->no_Succ; node->no_Succ->no_Pred = node; lnode->no_Succ = node; } static __inline void addListHead(List *list, Node *node) { insertNodeAfter(&list->li_Node, node); } static __inline void addListTail(List *list, Node *node) { insertNodeBefore(&list->li_Node, node); } static __inline void removeNode(Node *node) { node->no_Succ->no_Pred = node->no_Pred; node->no_Pred->no_Succ = node->no_Succ; } /* * Compare result against LIST_EOF(list) to check for empty list */ static __inline void * removeListHead(List *list) { Node *node = list->li_Node.no_Succ; removeNode(node); return(node); } static __inline void * removeListTail(List *list) { Node *node = list->li_Node.no_Pred; removeNode(node); return(node); } -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 18:57: 7 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 18:57:05 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 7BC9737B400; Thu, 4 Jan 2001 18:57:05 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.15 #3) id 14EN3Z-000HvK-00; Fri, 05 Jan 2001 02:56:41 +0000 Date: Fri, 5 Jan 2001 02:56:41 +0000 From: Tony Finch To: Peter Wemm Cc: Kirk McKusick , Alfred Perlstein , Will Andrews , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ Message-ID: <20010105025641.E53179@hand.dotat.at> References: <20010104222519.Y2140@hand.dotat.at> <200101050113.f051Dtq61858@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200101050113.f051Dtq61858@mobile.wemm.org> Organization: Covalent Technologies, Inc Sender: fanf@dotat.at Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: >Tony Finch wrote: >> >> http://www.apache.org/websrc/cvsweb.cgi/~checkout~/apr-util/include/ap_ring.h > ?rev=1.5&content-type=text/plain > >This reminds me a *lot* of the Amiga double linked lists. The one major >difference is that the Amiga had a different head/tail node that was >constructed in such a way that you didn't need a sentinal. Neat. The reason for the sentinel stuff is to allow structures to be on more than one list at a time. If structures are only on one list and the links are at the start of the structure then the sentinel is just the head pointer, and it becomes equivalent to Matt's code. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at "There are flying saucers. There's no doubt they are in our skies. They've been there for some time." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 19: 9:49 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 19:09:42 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 552C337B400; Thu, 4 Jan 2001 19:09:41 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.1/8.11.0) with ESMTP id f0539dl09789; Thu, 4 Jan 2001 20:09:40 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.8.3) with ESMTP id f0539d149502; Thu, 4 Jan 2001 20:09:39 -0700 (MST) Message-Id: <200101050309.f0539d149502@harmony.village.org> To: "Justin T. Gibbs" Subject: Re: Cardbus woes Cc: arch@freebsd.org, current@freebsd.org Reply-To: arch@freebsd.org In-reply-to: Your message of "Wed, 03 Jan 2001 21:29:52 MST." <200101040429.f044Tqs12960@aslan.scsiguy.com> References: <200101040429.f044Tqs12960@aslan.scsiguy.com> Date: Thu, 04 Jan 2001 20:09:39 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ This is drifting over into -arch, so I'm ccing there and asking people to redirect there. ]] [[ The context is what to do about certain kinds of locking with pccard code raising the bigger issue of what to do with interrupts and sleepers in a hostile environemnt ]] In message <200101040429.f044Tqs12960@aslan.scsiguy.com> "Justin T. Gibbs" writes: : I take that back. In pccbb_detach, you need a mechanism to ensure : that you are no-longer executing in your interrupt handler prior to : destroying the softc. There are two sitautions where you need to worry about things. The first one is where your ISR is interrupted and the thing that interrupts it wants to blow away the device. I think that the current pccard (eg oldcard) code queues an soft interrupt to deal with this so it can't interrupt things, but maybe I'm misremembering. Or maybe it does it badly enough to cause problems (I know this is different than the pccbb case, since that's newcard). The second is where you have sleepers that need to "drain" before you can delete the device. The first one strikes me as a special case of the second one, but maybe it needs to be handled specially. At the BSDcon removable device meeting (which I missed because I found out about it too late), the idea was that the detach routine would sleep until all the sleepers had woken up and exited. Then the detach routine would complete. It was suggested that some provision be made for telling the device that this was a forced detach, but I don't think that was nailed down. I think that having the detach routine call the bridge and ask it if the hardware is still there would come close to answering this question. When the hardware is gone, detach cannot return EBUSY and have that be meaningful. The hardware is gone. Who cares if it is busy, it has to cope with it being ripped untimely from the driver's grasp. Gone is gone :-). One way to deal with this would be to have all devices that sleep do a ref/deref on the device around the sleep. There would be an implicit ref/deref in the ISR too. However, that strikes me as unworkable. There are a lot of drivers that do a lot of sleeping and when they wake up. This would require a massive pass through the entire device driver tree (well, at least for the ones that can be removed). I also don't like the idea of doing boatloads of locking/unlocking code on every single interrupt, but maybe that's unavoidable. One way around the interrupt context problem is to ensure that devices are never removed from an interrupt context. Or are at least never detached from an interrupt context. However, I'm not sure the concept of an interrupt context still has meaning in the new threads for ISR. Can an interrupt thread block and allow other non-interrupt threads to run? Warner P.S. Here's two interfaces that I'd like to add to the bus interface file. They try to implement part of the removable feature. They are based on my talking to phk after the arch meeting I missed. I don't see any other way to ensure that interrupts will terminate. # # Ask the bridge if the device is still there. If the bus doesn't # support removal, then it should always return true. If the bus # does support removal, this method must return the real status of # the child. Generally this is done by asking the bridge chip to # see if card is present or not. # # Drivers may call this routine from an interrupt context. Drivers # may assume this call is relatively inexpensive. Bridge drivers # that implement this call should endeavor to make this inexpensive. # METHOD int child_present { device_t dev; device_t child; } DEFAULT bus_generic_child_present; # # Ask the bridge if this instance of a device can be removed. Drivers # may call this at any time. The bus code must guarantee that the # value returned from this function is invariant on a per instance # basis so drivers may cache the results. # # Drivers do not necessarily know that a bus supports device removal # based on the attachment. PCI has both hot-plug and non-hot-plug # variants, for example. # METHOD int is_removable { device_t dev; device_t child; } DEFAULT bus_generic_is_removable; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 21: 0: 1 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 20:59:57 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from caspian.scsiguy.com (caspian.scsiguy.com [63.229.232.105]) by hub.freebsd.org (Postfix) with ESMTP id B388937B400 for ; Thu, 4 Jan 2001 20:59:56 -0800 (PST) Received: from caspian.scsiguy.com (localhost [127.0.0.1]) by caspian.scsiguy.com (8.11.1/8.11.1) with ESMTP id f054xtU00300 for ; Thu, 4 Jan 2001 21:59:55 -0700 (MST) (envelope-from gibbs@caspian.scsiguy.com) Message-Id: <200101050459.f054xtU00300@caspian.scsiguy.com> To: freebsd-arch@FreeBSD.org Subject: Proposed chage to sbuf semantics. Date: Thu, 04 Jan 2001 21:59:55 -0700 From: "Justin T. Gibbs" Sender: gibbs@caspian.scsiguy.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I decided to use the sbuf code in some recent cardbus enhancements. Unfortunately, the sbuf code tried its best to prevent me from doing what I wanted to do. My goal was to fill a fixed sized buffer from a whole slew of data sources that may or may not be available. I didn't care if the end result was a truncated string so long as it was nul terminated. The only additional requirement for this task was the ability to occasionally find out if anything had been written to the sbuf prior to finalizing it (you may want to add a separator before adding new data, etc.) This kind of scenario is all over the CAM code too... you prioritize what you put in the passed in buffer and losing data off the end is okay. The following patches allowed me to get what I needed out of sbuf. I don't think it is unreasonable to allow this kind of behavior, but I'm sure someone will disagree. 8-) 1) Allow the user to finalize an overflowed buffer. If the user really cares about overflow, all they need to do is look at the error code of all previos operations or explicitly check for overflow prior to finalizing. Finalizing now clears the overflow flag as the string is null terminated, which allowes all "after finalize" methods to operate on this sbuf. 2) Remove SBUF_HASOVERFLOWED test in sbuf_data(). It can never be true if we've finalized the sbuf which is an asserted state for this method. 3) Add an SBUF_HASDATA macro that indicates if any data is currently in the sbuf. sbuf_len() is only available once you finalize an sbuf or I would have used that. 4) Add an SBUF_CLEARFLAG macro to mirror SBUF_SETFLAG(). It is debatable whether this should be in the exported sbuf API, but the same could be said for SBUF_SETFLAG(). -- Justin Index: kern/subr_sbuf.c =================================================================== RCS file: /usr/cvs/src/sys/kern/subr_sbuf.c,v retrieving revision 1.1 diff -c -r1.1 subr_sbuf.c *** kern/subr_sbuf.c 2000/12/13 19:51:07 1.1 --- kern/subr_sbuf.c 2001/01/03 20:36:39 *************** *** 220,229 **** assert_sbuf_integrity(s); assert_sbuf_state(s, 0); ! if (SBUF_HASOVERFLOWED(s)) ! return (-1); ! ! s->s_buf[s->s_len++] = '\0'; SBUF_SETFLAG(s, SBUF_FINISHED); return (0); } --- 220,230 ---- assert_sbuf_integrity(s); assert_sbuf_state(s, 0); ! if (SBUF_HASOVERFLOWED(s)) { ! s->s_buf[s->s_len] = '\0'; ! SBUF_CLEARFLAG(s, SBUF_OVERFLOWED); ! } else ! s->s_buf[s->s_len++] = '\0'; SBUF_SETFLAG(s, SBUF_FINISHED); return (0); } *************** *** 237,244 **** assert_sbuf_integrity(s); assert_sbuf_state(s, SBUF_FINISHED); - if (SBUF_HASOVERFLOWED(s)) - return (NULL); return s->s_buf; } --- 238,243 ---- Index: sys/sbuf.h =================================================================== RCS file: /usr/cvs/src/sys/sys/sbuf.h,v retrieving revision 1.1 diff -c -r1.1 sbuf.h *** sys/sbuf.h 2000/12/13 19:51:07 1.1 --- sys/sbuf.h 2001/01/03 20:40:54 *************** *** 53,63 **** --- 53,65 ---- #define SBUF_ISFINISHED(s) ((s)->s_flags & SBUF_FINISHED) #define SBUF_HASOVERFLOWED(s) ((s)->s_flags & SBUF_OVERFLOWED) #define SBUF_HASROOM(s) ((s)->s_len < (s)->s_size - 1) + #define SBUF_HASDATA(s) ((s)->s_len > 0) /* * Other macros */ #define SBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0) + #define SBUF_CLEARFLAG(s, f) do { (s)->s_flags &= ~(f); } while (0) /* * API functions To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 4 21:28:20 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 21:28:18 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from caspian.scsiguy.com (caspian.scsiguy.com [63.229.232.105]) by hub.freebsd.org (Postfix) with ESMTP id 9137737B400 for ; Thu, 4 Jan 2001 21:28:17 -0800 (PST) Received: from caspian.scsiguy.com (localhost [127.0.0.1]) by caspian.scsiguy.com (8.11.1/8.11.1) with ESMTP id f055SGU00338 for ; Thu, 4 Jan 2001 22:28:17 -0700 (MST) (envelope-from gibbs@caspian.scsiguy.com) Message-Id: <200101050528.f055SGU00338@caspian.scsiguy.com> To: freebsd-arch@freebsd.org Subject: Inheritance in new-bus. Date: Thu, 04 Jan 2001 22:28:16 -0700 From: "Justin T. Gibbs" Sender: gibbs@caspian.scsiguy.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've finished a first pass at making cardbus a "sub-class" of pci. Patches for this have been distributed to a few developers and will appear hear as soon as I finish the "play by play" for the formal post to -arch. In doing this work, I ran into several small issues that I have not resolved to my satisfaction. My hope is that this forum will have some ideas. Method Inheritance ================== In my patches, cardbus.c is now 518 lines long. Most of this is copyright and the method table. Like most "sub-classes", cardbus need only specialize a few methods of pci. In a true object oriented environment, you would overload the method and perhaps even call into the parents implementation of that method as part of implementing the new method. In new-bus, method tables are constructed by hand. This means that the cardbus code must fill in the appropriate pci method in its own table in the case of no-override. When the pci method table is changed, chances are high that the cardbus method table will require a similar update. One could imagine devclasses with the concept of a parent and having kobj handle the magic for you. This would be difficult to implemement in the case of multiple parents. Cardbus, for example, will be a subclass of "card services" at some point. If the method tables were broken down in terms of distinct interfaces, single inheritance *per interface* would probably be sufficient. Ivar namespace ============== All busses exporting ivars do so by listing their ivar codes in a simple enumeration. This makes it imposible to write an implemenation of the ivar method that looks like this: static int cardbus_write_ivar(device_t dev, device_t child, int which, uintptr_t value) { struct cardbus_devinfo *dinfo; dinfo = device_get_ivars(child); switch (which) { case CARD_IVAR_CIS_FUNCTION: dinfo->cis_function = value; break; case CARD_IVAR_VENDOR_STR: return (cardbus_update_str(&dinfo->vendor_str, (const char *)value)); case CARD_IVAR_CLASS_STR: return (cardbus_update_str(&dinfo->class_str, (const char *)value)); case CARD_IVAR_MODEL_STR: return (cardbus_update_str(&dinfo->model_str, (const char *)value)); case CARD_IVAR_REVISION_STR: return (cardbus_update_str(&dinfo->revision_str, (const char *)value)); default: return (pci_write_ivar(dev, child, which, value)); } return 0; } The CARD ivars clash with the PCI ivars and cardbus_write_ivar() returns the wrong data 50% of the time. As a temporary kludge, I've started the CARD ivar enumeration at 10000, but we should probably transition to a scheme similar, if not more robust, than the way ioctls are defined. In general, I've been very pleased with the new bus framework. It still needs to be documented better (especially in regards to resource allocation/activateion/deactivateion/release/delete), and it still needs multi-pathing, but its pretty cool stuff. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 5 0: 3: 4 2001 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 00:03:00 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9FBE437B402 for ; Fri, 5 Jan 2001 00:02:58 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.1/8.11.0) with ESMTP id f0582vl10504; Fri, 5 Jan 2001 01:02:57 -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.11.1/8.8.3) with ESMTP id f0582v151429; Fri, 5 Jan 2001 01:02:57 -0700 (MST) Message-Id: <200101050802.f0582v151429@harmony.village.org> To: "Justin T. Gibbs" Subject: Re: Inheritance in new-bus. Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 04 Jan 2001 22:28:16 MST." <200101050528.f055SGU00338@caspian.scsiguy.com> References: <200101050528.f055SGU00338@caspian.scsiguy.com> Date: Fri, 05 Jan 2001 01:02:57 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101050528.f055SGU00338@caspian.scsiguy.com> "Justin T. Gibbs" writes: : Method Inheritance : ================== : In my patches, cardbus.c is now 518 lines long. Most of this is : copyright and the method table. Like most "sub-classes", cardbus : need only specialize a few methods of pci. In a true object oriented : environment, you would overload the method and perhaps even call into : the parents implementation of that method as part of implementing : the new method. In new-bus, method tables are constructed by hand. : This means that the cardbus code must fill in the appropriate pci : method in its own table in the case of no-override. When the pci : method table is changed, chances are high that the cardbus method : table will require a similar update. One could imagine devclasses : with the concept of a parent and having kobj handle the magic for : you. This would be difficult to implemement in the case of multiple : parents. Cardbus, for example, will be a subclass of "card services" : at some point. If the method tables were broken down in terms of : distinct interfaces, single inheritance *per interface* would probably : be sufficient. One can get a fair amount of milage with good defaults. However, there does need to be something like this. Right now PCI implements at least three interfaces (bus, device and pci), so you don't have to go too far afield to find devices that implement many interfaces. For cardbus and card sevices, I'm not so sure that cardbus would be overriding too many things. The only differences that I can think of in the pcmcia standard card services between 16 bit and 32 bit stuff is a) the resource allocation (which we do the bus interface) and b) the CIS parsing in general is a little different, especially for multi-function cards. There's some differences in where to get the data from (from the card's ROM space vs common memory vs attribute memory, every byte vs every other) so maybe that is adding up to enough to make a full blown MI at least desirable. We could do something like perl does. IIRC, each class has a list of parent classes and they are searched, in list order, for the method to call when one isn't defined in that class. I would think that would be sufficient. This would make it not per interface, but rather be more full blown MI w/ about the same effort (or maybe a little less) than having a per interface table. Right now a kobj doesn't know what interface it comes from, if I'm reading the code right, so that might be hard. : Ivar namespace I've wanted this for a long time. It would make the pccard bus a more easily subclassible bus from isa than things are now (see above). Not that I'm sure that pccard should be a subclass of isa, since there are a lot of oddities and unique things in it that aren't in ISA and vice versa (there's no such thing as ISA PNP enumeration with pccard, for example, and ISA cards don't have CIS). It would make it a lot easier to have more generic IVARs than we have now. It would also parallel the interface mathod tables that we have which are fairly generic. Taken to an extreme, it might make sense to have them just be key/value pairs. This would make a lot of things more generic, as well as allowing properties to be set on device nodes that are generic on the whole system. An example I'm thinking of would be that pccard and cardbus could both set removable on the sio devices attached to these two busses, but not on any other bus. This would obviate the need for one of the proposed interfaces that I posted before. But like all cool, generic things, I worry a little over the overhead that something like this would bring. : In general, I've been very pleased with the new bus framework. : It still needs to be documented better (especially in regards : to resource allocation/activateion/deactivateion/release/delete), : and it still needs multi-pathing, but its pretty cool stuff. What is multi-pathing? Are you talking about a tree that is more of a directed graph like so: A0 / \ B1 B2 \ / C1 Where C1 has two parents. I can see how that would be useful in systems where one SCSI bus has mutliple controllers on it for redundnacy. Maybe some other specialized devices could use this too (I think phk had a case where he had a pci device that had two functions and he wanted to connect another device to them pair of them like above). We told him he was nuts for wanting that, but he did have good reasons for it, it seemed. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 5 8:54:44 2001 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 08:54:41 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 68B9F37B400; Fri, 5 Jan 2001 08:54:41 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CJP4VHG5; Fri, 5 Jan 2001 11:54:46 -0500 Reply-To: Randell Jesup To: Matt Dillon Cc: Peter Wemm , Tony Finch , Kirk McKusick , Alfred Perlstein , Will Andrews , Stephen McKay , phk@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: Reinstatement of CIRCLEQ References: <200101050113.f051Dtq61858@mobile.wemm.org> <200101050147.f051lYr96332@earth.backplane.com> From: Randell Jesup Date: 05 Jan 2001 11:56:12 -0500 In-Reply-To: Matt Dillon's message of "Thu, 4 Jan 2001 17:47:34 -0800 (PST)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon writes: > Basically when implementing a doubly linked list the optimization > tradeoff comes down to whether you want to remove the conditionals > from the list scanning routines, or whether you want to remove the > conditionals from the list insertion and removal routines. > > What it comes down to, in a nutshell, is that a circular-list > implementation can be done that has no more conditionals then a > non-circular list implementation. You simply have a LIST_EOF() macro > which for a circular queue compares the 'next node' or 'previous node' > against &listhead (which you probably already have in the L1 cache > anyway or can calculate trivially, so no biggy). The only thing you lose in your implementation (which is, BTW, quite nice) versus the Amiga-style lists is that you can't test for LIST_EOF() unless you already have the list pointer. This means there are cases where for example some code wants to move a node to the head or end of a list _without knowing what list it's on_ will be tougher, or code that wants to search the other nodes on the same list without knowing which list it's on, etc. These are admittedly rare operations (though not unheard of), and there are user-level solutions (like storing the list it's on in the user's structure when this sort of thing is needed, or other ways of obtaining the list pointer). -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 5 14: 2:58 2001 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 14:02:56 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id 547E937B400 for ; Fri, 5 Jan 2001 14:02:55 -0800 (PST) Received: from originative.co.uk (tiddler.originative.co.uk [62.232.68.83]) by mailgate.originative.co.uk (Postfix) with ESMTP id 331B61D140; Fri, 5 Jan 2001 22:02:43 +0000 (GMT) Sender: paul@originative.co.uk Message-ID: <3A564532.ADE40E6E@originative.co.uk> Date: Fri, 05 Jan 2001 22:05:38 +0000 From: Paul Richards X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Justin T. Gibbs" Cc: freebsd-arch@freebsd.org Subject: Re: Inheritance in new-bus. References: <200101050528.f055SGU00338@caspian.scsiguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" wrote: > > I've finished a first pass at making cardbus a "sub-class" of pci. > Patches for this have been distributed to a few developers and will > appear hear as soon as I finish the "play by play" for the formal > post to -arch. In doing this work, I ran into several small issues > that I have not resolved to my satisfaction. My hope is that this > forum will have some ideas. > > Method Inheritance > ================== > In my patches, cardbus.c is now 518 lines long. Most of this is > copyright and the method table. Like most "sub-classes", cardbus > need only specialize a few methods of pci. In a true object oriented > environment, you would overload the method and perhaps even call into > the parents implementation of that method as part of implementing > the new method. In new-bus, method tables are constructed by hand. > This means that the cardbus code must fill in the appropriate pci > method in its own table in the case of no-override. When the pci > method table is changed, chances are high that the cardbus method > table will require a similar update. One could imagine devclasses > with the concept of a parent and having kobj handle the magic for > you. This would be difficult to implemement in the case of multiple > parents. Cardbus, for example, will be a subclass of "card services" > at some point. If the method tables were broken down in terms of > distinct interfaces, single inheritance *per interface* would probably > be sufficient. I looked at implementing kobj inheritance while I was working on my talk. My original thinking was that the upcalls could be done away with if a child device inherited its methods from its parent bus, filling in the child's kobj method table with the parent bus' methods. However, when I discussed it with Doug at the conference he didn't see things being related in that way and having spent some time pondering that I can see what he meant. For instance, an ethernet driver may be a child of a PCI device and at the moment it performs upcalls to the PCI card to carry out various functions, but method inheritance based on the device hierarchy wouldn't be correct since an ethernet kobj is in no way a child of a PCI kobj, they're only related because of their physical association. Cardbus on the other hand is related to PCI and so it would make sense to inherit from PCI. So I think that adding inheritance to kobj would be good thing, so that cardbus can inherit from PCI, but it wouldn't be right if inheritance was based on devclasses or on any other aspect of the device hierarchy, particularly since kobj is meant to be a generic OO mechanism rather than a part of newbus. I don't know which particular take on inheritance you've implemented, I wouldn't mind getting a look at the patches :-) Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 5 14:43:30 2001 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 14:43:28 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 6E50037B400 for ; Fri, 5 Jan 2001 14:43:27 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f05Mh2s40409; Fri, 5 Jan 2001 15:43:08 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101052243.f05Mh2s40409@aslan.scsiguy.com> To: Paul Richards Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Inheritance in new-bus. In-Reply-To: Your message of "Fri, 05 Jan 2001 22:05:38 GMT." <3A564532.ADE40E6E@originative.co.uk> Date: Fri, 05 Jan 2001 15:43:02 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I looked at implementing kobj inheritance while I was working on my >talk. > >My original thinking was that the upcalls could be done away with if a >child device inherited its methods from its parent bus, filling in the >child's kobj method table with the parent bus' methods. However, when I >discussed it with Doug at the conference he didn't see things being >related in that way and having spent some time pondering that I can see >what he meant. > >For instance, an ethernet driver may be a child of a PCI device and at >the moment it performs upcalls to the PCI card to carry out various >functions, but method inheritance based on the device hierarchy wouldn't >be correct since an ethernet kobj is in no way a child of a PCI kobj, >they're only related because of their physical association. Cardbus on >the other hand is related to PCI and so it would make sense to inherit >from PCI. So I think that adding inheritance to kobj would be good >thing, so that cardbus can inherit from PCI, but it wouldn't be right if >inheritance was based on devclasses or on any other aspect of the device >hierarchy, particularly since kobj is meant to be a generic OO mechanism >rather than a part of newbus. Cardbus is no different than your ethernet card example. Cardbus is not a child bus of PCI, but is rather a specialized implementation of PCI. Perhaps my understanding of the devclass is wrong. I didn't think that it had anything to do with the bus hierarchy, but was simply a place for a particular class to store data about that class (for instance drivers for children of the bus implemented by that class). As I metioned in my email, I think the devclass thing won't work. I'd rathre see the method table be an array of "interface structs" with the interfave structs having a list of method overides and an optional pointer to the parent interface to inherit from. >I don't know which particular take on inheritance you've implemented, I >wouldn't mind getting a look at the patches :-) Several of PCI's methods are now exported in pci_private.h. Cardbus's method table now references several of these methods and occassionally one or more of its method overrides also calls into the PCI code to get some amount of work done. I'll be posting the patches RSN. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 5 15:42:50 2001 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 15:42:47 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id E3DFF37B400 for ; Fri, 5 Jan 2001 15:42:46 -0800 (PST) Received: from originative.co.uk (tiddler.originative.co.uk [62.232.68.83]) by mailgate.originative.co.uk (Postfix) with ESMTP id BB2AF1D140; Fri, 5 Jan 2001 23:42:45 +0000 (GMT) Sender: paul@originative.co.uk Message-ID: <3A565CA4.3466BF11@originative.co.uk> Date: Fri, 05 Jan 2001 23:45:40 +0000 From: Paul Richards X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Inheritance in new-bus. References: <200101052243.f05Mh2s40409@aslan.scsiguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Justin T. Gibbs" wrote: > > > Cardbus is no different than your ethernet card example. Cardbus is > not a child bus of PCI, but is rather a specialized implementation of Yes, cardbus is specialized PCI, that's why inheritance would be correct. Ethernet is not anything like PCI though so inheritance would be wrong. > PCI. Perhaps my understanding of the devclass is wrong. I didn't > think that it had anything to do with the bus hierarchy, but was simply > a place for a particular class to store data about that class (for instance > drivers for children of the bus implemented by that class). As I metioned No, that's what I wanted to clarify. Devclass is confusingly named since it suggests it is in some way involved with kobjs but it isn't. In fact, the kobj implementation has no concept of classes, a kobj is just a way of encapsulating the methods for an ineterface and since there's no inheritance at the moment there isn't really any purpose in classes either. One will follow from the other I guess. A devclass on the other hand groups together classes (not really in any OO sense) of devices that are related to the extent that they share the same driver. It's a somewhat overloaded structure in that if the devclass happens to be for a bus then it holds a list of drivers for that bus but this still doesn't have anything to do with kobj. > in my email, I think the devclass thing won't work. I'd rathre see > the method table be an array of "interface structs" with the interfave > structs having a list of method overides and an optional pointer to > the parent interface to inherit from. > > >I don't know which particular take on inheritance you've implemented, I > >wouldn't mind getting a look at the patches :-) > > Several of PCI's methods are now exported in pci_private.h. Cardbus's > method table now references several of these methods and occassionally > one or more of its method overrides also calls into the PCI code to get > some amount of work done. Yeah, this is where inheritance would be useful. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 5 15:50:41 2001 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 15:50:38 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id E98A937B400 for ; Fri, 5 Jan 2001 15:50:37 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f05NoTs42746; Fri, 5 Jan 2001 16:50:29 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101052350.f05NoTs42746@aslan.scsiguy.com> To: Paul Richards Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Inheritance in new-bus. In-Reply-To: Your message of "Fri, 05 Jan 2001 23:45:40 GMT." <3A565CA4.3466BF11@originative.co.uk> Date: Fri, 05 Jan 2001 16:50:29 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >"Justin T. Gibbs" wrote: >> > >> >> Cardbus is no different than your ethernet card example. Cardbus is >> not a child bus of PCI, but is rather a specialized implementation of > >Yes, cardbus is specialized PCI, that's why inheritance would be >correct. Ethernet is not anything like PCI though so inheritance would >be wrong. Hmm. I thought you were implying that your ethernet driver might need to overload some method of its parent bus in order to deal with a special quirk of that piece of hardware. In otherwords, you wouldn't be a specialized version of PCI, but perhaps have a few specialized methods of a particular interface provided by your parent bus. In general, I would not expect this to happen. >> >I don't know which particular take on inheritance you've implemented, I >> >wouldn't mind getting a look at the patches :-) >> >> Several of PCI's methods are now exported in pci_private.h. Cardbus's >> method table now references several of these methods and occassionally >> one or more of its method overrides also calls into the PCI code to get >> some amount of work done. > >Yeah, this is where inheritance would be useful. > And it is only the first example of many to come I think. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 6 15:28: 8 2001 From owner-freebsd-arch@FreeBSD.ORG Sat Jan 6 15:28:06 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id BED9237B400 for ; Sat, 6 Jan 2001 15:28:05 -0800 (PST) Received: from gorean.org (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id PAA26613 for ; Sat, 6 Jan 2001 15:28:04 -0800 (PST) (envelope-from DougB@gorean.org) Message-ID: <3A57AA03.4CEB49E7@gorean.org> Date: Sat, 06 Jan 2001 15:28:03 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Is /etc/mergemaster.conf desirable? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It was suggested to me today that having an /etc/mergemaster.conf file would be desirable. There is already support for $HOME/.mergemasterrc, so adding support to read /etc/mergemaster.conf would be easy, but I've never thought it was really needed. My questions are: 1. Would this be useful? 2. Should there be a blank file (with comments) committed to /usr/src/etc? 3. Another possibility would be to make a directory in /etc/ which could contain the conf file, and example scripts to demonstrate how to always install (or not install) certain files, etc. The reason I suggest this is that this is an often requested addition to mm, but it's better done outside the script itself because IMO there are just too many different possible combinations, and there are already too many options to what's supposed to be a simple program. The fact that I think it's a horrible idea also enters into it. :) I think the idea has merit, but my feelings won't be hurt if the consensus is against the proposal. I eagerly await your comments and suggestions. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 6 18:10:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id CE79437B400 for ; Sat, 6 Jan 2001 18:10:24 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id 68CE71A93; Sat, 6 Jan 2001 21:10:24 -0500 (EST) Date: Sat, 6 Jan 2001 21:10:24 -0500 From: Will Andrews To: Doug Barton Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Is /etc/mergemaster.conf desirable? Message-ID: <20010106211024.H1611@puck.firepipe.net> Reply-To: Will Andrews References: <3A57AA03.4CEB49E7@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A57AA03.4CEB49E7@gorean.org>; from DougB@gorean.org on Sat, Jan 06, 2001 at 03:28:03PM -0800 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 06, 2001 at 03:28:03PM -0800, Doug Barton wrote: > It was suggested to me today that having an /etc/mergemaster.conf file > would be desirable. There is already support for $HOME/.mergemasterrc, > so adding support to read /etc/mergemaster.conf would be easy, but I've > never thought it was really needed. My questions are: Well, I'm not sure it belongs in /etc.. it'd be yet another file that mergemaster would check. :-) Generally, if there is already support for a .mergemasterrc, I don't see the need. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 6 19:13:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 9F99237B400 for ; Sat, 6 Jan 2001 19:13:40 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id TAA13161; Sat, 6 Jan 2001 19:13:39 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f073Dc659054; Sat, 6 Jan 2001 19:13:38 -0800 (PST) (envelope-from obrien) Date: Sat, 6 Jan 2001 19:13:38 -0800 From: "David O'Brien" To: Will Andrews Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Is /etc/mergemaster.conf desirable? Message-ID: <20010106191338.A59025@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <3A57AA03.4CEB49E7@gorean.org> <20010106211024.H1611@puck.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010106211024.H1611@puck.firepipe.net>; from will@physics.purdue.edu on Sat, Jan 06, 2001 at 09:10:24PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 06, 2001 at 09:10:24PM -0500, Will Andrews wrote: > Well, I'm not sure it belongs in /etc.. it'd be yet another file that > mergemaster would check. :-) > > Generally, if there is already support for a .mergemasterrc, I don't see > the need. I argue that ~/.mergemaster is wrong vs. /etc/mergemaster.conf, mergemaster works on the local machine, not a per user basis. It would make more sense to have .ppp.conf than /etc/ppp/ppp.conf which is what we have. We also have /etc/ssh/ssh_config and ~/.ssh/config... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 6 19:15:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 93FFC37B69C for ; Sat, 6 Jan 2001 19:14:45 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id TAA13166; Sat, 6 Jan 2001 19:14:44 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f073EhI59082; Sat, 6 Jan 2001 19:14:43 -0800 (PST) (envelope-from obrien) Date: Sat, 6 Jan 2001 19:14:43 -0800 From: "David O'Brien" To: Doug Barton Cc: freebsd-arch@freebsd.org Subject: Re: Is /etc/mergemaster.conf desirable? Message-ID: <20010106191443.B59025@dragon.nuxi.com> Reply-To: arch@freebsd.org References: <3A57AA03.4CEB49E7@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A57AA03.4CEB49E7@gorean.org>; from DougB@gorean.org on Sat, Jan 06, 2001 at 03:28:03PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 06, 2001 at 03:28:03PM -0800, Doug Barton wrote: > 3. Another possibility would be to make a directory in /etc/ which could > contain the conf file, and example scripts to demonstrate how to always > install (or not install) certain files, etc. I would say "NO". Examples should go into /usr/src/share/examples/, and would be a welcomed thing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 6 19:17: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from puck.firepipe.net (mcut-b-167.resnet.purdue.edu [128.211.209.167]) by hub.freebsd.org (Postfix) with ESMTP id C77F537B69D for ; Sat, 6 Jan 2001 19:16:20 -0800 (PST) Received: by puck.firepipe.net (Postfix, from userid 1000) id 205571B6E; Sat, 6 Jan 2001 22:16:20 -0500 (EST) Date: Sat, 6 Jan 2001 22:16:20 -0500 From: Will Andrews To: arch@FreeBSD.ORG Subject: Re: Is /etc/mergemaster.conf desirable? Message-ID: <20010106221620.I1611@puck.firepipe.net> Reply-To: Will Andrews Mail-Followup-To: Will Andrews , arch@FreeBSD.ORG References: <3A57AA03.4CEB49E7@gorean.org> <20010106211024.H1611@puck.firepipe.net> <20010106191338.A59025@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010106191338.A59025@dragon.nuxi.com>; from TrimYourCc@NUXI.com on Sat, Jan 06, 2001 at 07:13:38PM -0800 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 06, 2001 at 07:13:38PM -0800, David O'Brien wrote: > I argue that ~/.mergemaster is wrong vs. /etc/mergemaster.conf, > mergemaster works on the local machine, not a per user basis. It would > make more sense to have .ppp.conf than /etc/ppp/ppp.conf which is what we > have. We also have /etc/ssh/ssh_config and ~/.ssh/config... You're right. But I don't think it belongs in /etc.. unless mergemaster ignores the file automatically. A technicality, I suppose.. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 6 20:17: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from spammie.svbug.com (unknown [198.79.110.2]) by hub.freebsd.org (Postfix) with ESMTP id 1731737B400; Sat, 6 Jan 2001 20:16:50 -0800 (PST) Received: from spammie.svbug.com (localhost.mozie.org [127.0.0.1]) by spammie.svbug.com (8.9.3/8.9.3) with ESMTP id UAA04408; Sat, 6 Jan 2001 20:16:31 -0800 (PST) (envelope-from jessem@spammie.svbug.com) Message-Id: <200101070416.UAA04408@spammie.svbug.com> Date: Sat, 6 Jan 2001 20:16:29 -0800 (PST) From: opentrax@email.com Reply-To: opentrax@email.com Subject: [Question] CVS and CVS@freebsd To: freebsd-hacker@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Note: I've BCC'd to arch to get advanced implemention suggestions] Hey everyone OpenCountry.org has asked me to setup a CVS repository for them. Their business plan includes packageing, wrapping and selling LINUX open source software. They want to build an infrastructure to support multiple unrelated independent developers. It will include the usual web, mailing list stuff, but they also want CVS, bug reporting and integrationg with the message board (Twiki). I'm considering using Perl, Mysql, Cvsweb and Mason or PHP. Can anyone give me suggestion on implementing this? Specifically I'd like to know about tools available, concepts that would aid developers and any suggestions out-of-scope that would aid developers. Jessem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 6 21:10:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 93CB637B402 for ; Sat, 6 Jan 2001 21:10:06 -0800 (PST) Received: from dragon.nuxi.com (Ipitythefoolthattrustsident@trang.nuxi.com [209.152.133.57]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id VAA13519; Sat, 6 Jan 2001 21:10:05 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.1/8.11.1) id f075A4O59648; Sat, 6 Jan 2001 21:10:04 -0800 (PST) (envelope-from obrien) Date: Sat, 6 Jan 2001 21:10:04 -0800 From: "David O'Brien" To: Will Andrews Cc: arch@FreeBSD.ORG Subject: Re: Is /etc/mergemaster.conf desirable? Message-ID: <20010106211004.A59625@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <3A57AA03.4CEB49E7@gorean.org> <20010106211024.H1611@puck.firepipe.net> <20010106191338.A59025@dragon.nuxi.com> <20010106221620.I1611@puck.firepipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010106221620.I1611@puck.firepipe.net>; from will@physics.purdue.edu on Sat, Jan 06, 2001 at 10:16:20PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 06, 2001 at 10:16:20PM -0500, Will Andrews wrote: > You're right. But I don't think it belongs in /etc.. unless mergemaster > ignores the file automatically. A technicality, I suppose.. If there isn't a /usr/src/etc/mergemaster.conf it will. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message