From owner-freebsd-arch Sun Feb 23 1:23:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28BC737B401 for ; Sun, 23 Feb 2003 01:23:24 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B08543FE0 for ; Sun, 23 Feb 2003 01:23:23 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1N9NIlI081798; Sun, 23 Feb 2003 10:23:18 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Jeff Roberson Cc: arch@FreeBSD.ORG Subject: Re: More buf cache locking. (patch) From: phk@phk.freebsd.dk In-Reply-To: Your message of "Sat, 22 Feb 2003 22:10:41 EST." <20030222221028.J1116-100000@mail.chesapeake.net> Date: Sun, 23 Feb 2003 10:23:18 +0100 Message-ID: <81797.1045992198@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20030222221028.J1116-100000@mail.chesapeake.net>, Jeff Roberson writes: >I forgot, the patch is at: > >http://www.chesapeake.net/~jroberson/bcache.diff I just quickly browsed this, and the only question I really have is about patch in vm/uma_core.c: what does that do ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 5:14:24 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A9A37B401; Sun, 23 Feb 2003 05:14:23 -0800 (PST) Received: from watery.cc.kogakuin.ac.jp (watery.cc.kogakuin.ac.jp [133.80.152.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id C64FC43F85; Sun, 23 Feb 2003 05:14:22 -0800 (PST) (envelope-from nyan@jp.FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) by watery.cc.kogakuin.ac.jp (8.12.6/8.12.6) with ESMTP id h1NDEHxR064684; Sun, 23 Feb 2003 22:14:21 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Sun, 23 Feb 2003 22:13:08 +0900 (JST) Message-Id: <20030223.221308.74692574.nyan@jp.FreeBSD.org> To: ru@freebsd.org Cc: arch@freebsd.org Subject: Re: hw.machine on PC98 From: Takahashi Yoshihiro In-Reply-To: <20030220145142.GA93982@sunbay.com> References: <20011214173056.A94075@sunbay.com> <20011217.233630.74667853.yosihiro@cc.kogakuin.ac.jp> <20030220145142.GA93982@sunbay.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20030220145142.GA93982@sunbay.com> Ruslan Ermilov writes: > > *I* think that hw.machine should be "pc98" on PC-98. > > > Any progress in this area any time soon? I don't work anything and make sure of any effects to userland tools. --- TAKAHASHI Yoshihiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 16:16:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E69037B401 for ; Sun, 23 Feb 2003 16:16:47 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A4F643F75 for ; Sun, 23 Feb 2003 16:16:47 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.7/8.12.2) with ESMTP id h1O0Gj2p067282 for ; Sun, 23 Feb 2003 16:16:45 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.7/8.12.7/Submit) id h1O0GjFt067281 for freebsd-arch@freebsd.org; Sun, 23 Feb 2003 16:16:45 -0800 (PST) Date: Sun, 23 Feb 2003 16:16:44 -0800 From: "David O'Brien" To: freebsd-arch@freebsd.org Subject: [RFC] splitting of conf/NOTES Message-ID: <20030224001644.GA67255@dragon.nuxi.com> Reply-To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Please don't CC me on your public replies -- I don't want every message in this thread to end up in my personal mailbox. I'll read them in the list, thank you very much.] I can now create a sparc64 LINT kernel with the patches at http://people.freebsd.org/~obrien/sp64notes.diff. The essence of this patch is to split sys/conf/NOTES into NOTES, NOTES.bt, NOTES.ext2fs, NOTES.ps2, NOTES.raid, and NOTES.syscons. Each /sys//conf/Makefile now looks like: NOTES= ../../conf/NOTES \ ../../conf/NOTES.bt \ ../../conf/NOTES.ext2fs \ ../../conf/NOTES.ps2 \ ../../conf/NOTES.raid \ ../../conf/NOTES.syscons \ NOTES LINT: ${NOTES} ../../conf/makeLINT.sed cat ${NOTES} | sed -E -n -f ../../conf/makeLINT.sed > LINT Any comments before I commit this? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 16:30: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BB6E37B401 for ; Sun, 23 Feb 2003 16:29:59 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51F5243FB1 for ; Sun, 23 Feb 2003 16:29:58 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1O0Ts1o038481 for ; Sun, 23 Feb 2003 16:29:58 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1O0To3U009356 for ; Sun, 23 Feb 2003 16:29:50 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1O0Touw009355 for freebsd-arch@FreeBSD.ORG; Sun, 23 Feb 2003 16:29:50 -0800 (PST) (envelope-from marcel) Date: Sun, 23 Feb 2003 16:29:49 -0800 From: Marcel Moolenaar To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224002949.GA9302@athlon.pn.xcllnt.net> References: <20030224001644.GA67255@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224001644.GA67255@dragon.nuxi.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Feb 23, 2003 at 04:16:44PM -0800, David O'Brien wrote: > > I can now create a sparc64 LINT kernel with the patches at > http://people.freebsd.org/~obrien/sp64notes.diff. ENOENT :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 16:33:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6E7F37B401 for ; Sun, 23 Feb 2003 16:33:32 -0800 (PST) Received: from franky.speednet.com.au (franky.speednet.com.au [203.57.65.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A682843FB1 for ; Sun, 23 Feb 2003 16:33:31 -0800 (PST) (envelope-from andyf@speednet.com.au) Received: from hewey.af.speednet.com.au (hewey.af.speednet.com.au [203.38.96.242]) by franky.speednet.com.au (8.12.6/8.12.6) with ESMTP id h1O0XTdC070086 for ; Mon, 24 Feb 2003 11:33:29 +1100 (EST) (envelope-from andyf@speednet.com.au) Received: from hewey.af.speednet.com.au (hewey.af.speednet.com.au [172.22.2.17]) by hewey.af.speednet.com.au (8.12.6/8.12.6) with ESMTP id h1O0XSOn021355 for ; Mon, 24 Feb 2003 10:33:29 +1000 (EST) (envelope-from andyf@speednet.com.au) Date: Mon, 24 Feb 2003 10:33:28 +1000 (EST) From: Andy Farkas X-X-Sender: andyf@hewey.af.speednet.com.au To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES In-Reply-To: <20030224001644.GA67255@dragon.nuxi.com> Message-ID: <20030224102732.S20871-100000@hewey.af.speednet.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > I can now create a sparc64 LINT kernel with the patches at > http://people.freebsd.org/~obrien/sp64notes.diff. 404 > The essence of this > patch is to split sys/conf/NOTES into NOTES, NOTES.bt, NOTES.ext2fs, > NOTES.ps2, NOTES.raid, and NOTES.syscons. I think its confusing enough have MI and MD NOTES files already (think users migrating from 4.x) as seen previously on various lists. My wish is to see sys/conf/NOTES and sys/conf/NOTES. in the same directory. -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 17: 4:28 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4739537B401 for ; Sun, 23 Feb 2003 17:04:27 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1A2E43FDD for ; Sun, 23 Feb 2003 17:04:26 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id h1O14PnN065824 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 23 Feb 2003 17:04:26 -0800 (PST)?g (envelope-from sam@errno.com)њ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <1b6c01c2dba0$ad01c5a0$52557f42@errno.com> From: "Sam Leffler" To: References: <20030224001644.GA67255@dragon.nuxi.com> Subject: Re: [RFC] splitting of conf/NOTES Date: Sun, 23 Feb 2003 17:03:58 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > [Please don't CC me on your public replies -- I don't want every message > in this thread to end up in my personal mailbox. I'll read them in the > list, thank you very much.] > > I can now create a sparc64 LINT kernel with the patches at > http://people.freebsd.org/~obrien/sp64notes.diff. The essence of this > patch is to split sys/conf/NOTES into NOTES, NOTES.bt, NOTES.ext2fs, > NOTES.ps2, NOTES.raid, and NOTES.syscons. Each /sys//conf/Makefile > now looks like: > > NOTES= ../../conf/NOTES \ > ../../conf/NOTES.bt \ > ../../conf/NOTES.ext2fs \ > ../../conf/NOTES.ps2 \ > ../../conf/NOTES.raid \ > ../../conf/NOTES.syscons \ > NOTES > > LINT: ${NOTES} ../../conf/makeLINT.sed > cat ${NOTES} | sed -E -n -f ../../conf/makeLINT.sed > LINT > > > Any comments before I commit this? If this is taking us down the path of breaking things into module-specific configuration information then perhaps that information belongs in the directory where the code is. I believe there is precedence for this in other BSD systems. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 17:16: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87DD637B401 for ; Sun, 23 Feb 2003 17:15:59 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3644B43FCB for ; Sun, 23 Feb 2003 17:15:58 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id MAA29355 for ; Mon, 24 Feb 2003 12:15:55 +1100 Date: Mon, 24 Feb 2003 12:17:08 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES In-Reply-To: <20030224001644.GA67255@dragon.nuxi.com> Message-ID: <20030224120037.D4403-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Feb 2003, David O'Brien wrote: > I can now create a sparc64 LINT kernel with the patches at > http://people.freebsd.org/~obrien/sp64notes.diff. The essence of this > patch is to split sys/conf/NOTES into NOTES, NOTES.bt, NOTES.ext2fs, > NOTES.ps2, NOTES.raid, and NOTES.syscons. Each /sys//conf/Makefile > now looks like: > > NOTES= ../../conf/NOTES \ > ../../conf/NOTES.bt \ > ../../conf/NOTES.ext2fs \ > ../../conf/NOTES.ps2 \ > ../../conf/NOTES.raid \ > ../../conf/NOTES.syscons \ > NOTES > > LINT: ${NOTES} ../../conf/makeLINT.sed > cat ${NOTES} | sed -E -n -f ../../conf/makeLINT.sed > LINT > > Any comments before I commit this? Please don't commit this. Splitting NOTES into 2 files (for each arch) already made it harder to maintain and use. Parts of the above split is wrong anyway: - ext2fs is inherently MI. It doesn't compile on some arches since it has some optimizations which are only implemented (in asm) on i386's and alphas's. These optimizations are bogus -- slightly (;-) more important filesystem like ffs just use C code for the corresponding things (scanning bitmaps). - syscons is supposed to be MI. If it weren't MI, then it wouldn't be in /sys/dev ;-). - bt and some other devices may be fairly bus-dependent and have no future, but they can be removed from ../../conf/NOTES using a whole 1 `nodevice' line (but don't do too much of this or ../../conf/NOTES files would grow to have almost as much duplication as separate files). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 18:31:24 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C53837B401 for ; Sun, 23 Feb 2003 18:31:22 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E279B43FB1 for ; Sun, 23 Feb 2003 18:31:21 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.7/8.12.2) with ESMTP id h1O2VJ2p004400; Sun, 23 Feb 2003 18:31:19 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.7/8.12.7/Submit) id h1O2VIGp004399; Sun, 23 Feb 2003 18:31:18 -0800 (PST) Date: Sun, 23 Feb 2003 18:31:18 -0800 From: "David O'Brien" To: Bruce Evans Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224023118.GD67312@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224120037.D4403-100000@gamplex.bde.org> User-Agent: Mutt/1.4i 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 12:17:08PM +1100, Bruce Evans wrote: > > Any comments before I commit this? > > Please don't commit this. Splitting NOTES into 2 files (for each arch) > already made it harder to maintain and use. [picking a random email to respond to...] Those saying this need to offer alternatives. > Parts of the above split is wrong anyway: > - ext2fs is inherently MI. It doesn't compile on some arches since it has > some optimizations which are only implemented (in asm) on i386's and > alphas's. These optimizations are bogus -- slightly (;-) more important > filesystem like ffs just use C code for the corresponding things > (scanning bitmaps). ext2fs is piss-poorly documented where we got the Linux bits from what had to be done to make then work for us. I have up after an hour trying to get the right sys/gnu/ext2fs/sparc64-bitopts.h. So I don't think anyone is going to do it anytime soon. I'll just move it to sys/{i386,alpha}/conf/NOTES > - syscons is supposed to be MI. If it weren't MI, then it wouldn't be in > /sys/dev ;-). "meant" != is. The work to make it truly MI is immense. > - bt and some other devices may be fairly bus-dependent and have no future, > but they can be removed from ../../conf/NOTES using a whole 1 `nodevice' > line (but don't do too much of this or ../../conf/NOTES files would grow > to have almost as much duplication as separate files). I doubt bt(4) will work on sparc64, PowerPC, or IA-64. So do people want all that's in NOTES.bt (and that's a lot of docs) to be duplicated three times in sys/{alpha,i386,pc98}/conf/NOTES or split out as I have?? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 18:52:56 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F6737B401 for ; Sun, 23 Feb 2003 18:52:55 -0800 (PST) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB66D43FE0 for ; Sun, 23 Feb 2003 18:52:54 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.3/8.12.3) with ESMTP id h1O2qpFL066069; Sun, 23 Feb 2003 18:52:51 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200302240252.h1O2qpFL066069@beastie.mckusick.com> To: Jeff Roberson Subject: Re: More buf cache locking. (patch) Cc: arch@FreeBSD.ORG In-Reply-To: Your message of "Sat, 22 Feb 2003 22:10:41 EST." <20030222221028.J1116-100000@mail.chesapeake.net> Date: Sun, 23 Feb 2003 18:52:51 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Date: Sat, 22 Feb 2003 22:10:41 -0500 (EST) From: Jeff Roberson To: arch@FreeBSD.ORG Subject: Re: More buf cache locking. (patch) In-Reply-To: <20030222220659.D1116-100000@mail.chesapeake.net> X-ASK-Info: Whitelist match I forgot, the patch is at: http://www.chesapeake.net/~jroberson/bcache.diff These changes look reasonable to me. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 19:13:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB7437B401 for ; Sun, 23 Feb 2003 19:13:47 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF61843FAF for ; Sun, 23 Feb 2003 19:13:46 -0800 (PST) (envelope-from wes@softweyr.com) Received: from 204.68.178.4 (66-75-151-22.san.rr.com [66.75.151.22]) by smtp-relay.omnis.com (Postfix) with ESMTP id F33D4455DD; Sun, 23 Feb 2003 19:02:57 -0800 (PST) From: Wes Peters Organization: Softweyr LLC To: Garance A Drosihn Subject: Re: NEWSYSLOG changes Date: Sun, 23 Feb 2003 19:11:14 -0800 User-Agent: KMail/1.5 Cc: arch@FreeBSD.ORG References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302231911.14264.wes@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday 20 February 2003 09:33 pm, Garance A Drosihn wrote: > At 11:35 PM -0500 2/20/03, Garance A Drosihn wrote: > >Offshoot of the "syslog.conf syntax change" thread. > > Arg. My previous message was supposed to go out with this > new subject, instead of just repeating the subject of the > thread "it was an offshoot of". Pasting from that: > What follows is part #1 of what I plan to do. This adds the > notion of a "default rotation action" to newsyslog. This > action will *only* be significant when newsyslog is run with > a specific list of filenames. > > The patch picks some plausible behavior for that default action, > but users can set a different default-action by adding a line > to newsyslog.conf which uses as the filename. This > should cause no change in behavior for the standard usage of > newsyslog (ie, run without listing specific filenames). I don't see where your patch addressed the concern Terry raised about oversize files being rolled improperly on startup. I.e. if newsyslog encounters a file that it is supposed to roll at 256K and the file is 40M long, what do you do? Possible answers include "roll only the last 256K of it" and "roll it in 256K chunks," all of which are better than "roll the entire 40M file contents, leaving the log filesystem out of space." Were you going to look into that? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 19:41:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F77737B401 for ; Sun, 23 Feb 2003 19:41:58 -0800 (PST) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C66943F85 for ; Sun, 23 Feb 2003 19:41:57 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.12.7/8.12.7) with ESMTP id h1O3ftqX011660; Sun, 23 Feb 2003 22:41:55 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200302231911.14264.wes@softweyr.com> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302231911.14264.wes@softweyr.com> Date: Sun, 23 Feb 2003 22:41:54 -0500 To: Wes Peters From: Garance A Drosihn Subject: Re: NEWSYSLOG changes Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-Spam-Score: -0.8 () IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:11 PM -0800 2/23/03, Wes Peters wrote: > >I don't see where your patch addressed the concern Terry raised >about oversize files being rolled improperly on startup. I.e. >if newsyslog encounters a file that it is supposed to roll at >256K and the file is 40M long, what do you do? ... > >Were you going to look into that? Yes, I have an idea of what I want to do for that, but it will be done as a separate patch. I have several different changes in mind, and I'm trying to figure out the best order to make them. Note that the problem isn't the first roll (where the 40-meg file turns into /var/log/somelog.0), it's that later checking may see that /var/log/somelog is 0 bytes (particularly if /var/log is out of disk space), and thus the 40-meg logfile is *never* rotated after that first shot. Once I add the -R option, and once you add the improvements to syslogd itself, then the situation that Terry describes is less likely to happen. I do want to do something about it, though. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 19:48: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0E9537B401 for ; Sun, 23 Feb 2003 19:47:58 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D314A43F93 for ; Sun, 23 Feb 2003 19:47:57 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h1O3lns20401; Sun, 23 Feb 2003 22:47:49 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 23 Feb 2003 22:47:49 -0500 (EST) From: Jeff Roberson To: phk@phk.freebsd.dk Cc: arch@FreeBSD.ORG Subject: Re: More buf cache locking. (patch) In-Reply-To: <81797.1045992198@critter.freebsd.dk> Message-ID: <20030223224612.H19976-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Feb 2003 phk@phk.freebsd.dk wrote: > In message <20030222221028.J1116-100000@mail.chesapeake.net>, Jeff Roberson writes: > >I forgot, the patch is at: > > > >http://www.chesapeake.net/~jroberson/bcache.diff > > I just quickly browsed this, and the only question I really have is about > patch in vm/uma_core.c: what does that do ? I have that in my tree to detect LOR with giant. UMA doesn't often need giant but it may in some cases. This caused problems with the fdesc code before. I'd really like something in witness that says "May acquire giant" or maybe even more generally "May acquire lock x" to detect corner cases. Anyway, I Just forgot to delete this diff when I diffed my tree. It has nothing to do with the buf cache. :-) Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 19:52: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE9E337B401 for ; Sun, 23 Feb 2003 19:52:05 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C65943FD7 for ; Sun, 23 Feb 2003 19:52:05 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h1O3q3M21887; Sun, 23 Feb 2003 22:52:03 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 23 Feb 2003 22:52:02 -0500 (EST) From: Jeff Roberson To: Kirk McKusick Cc: arch@FreeBSD.ORG Subject: Re: More buf cache locking. (patch) In-Reply-To: <200302240252.h1O2qpFL066069@beastie.mckusick.com> Message-ID: <20030223224757.R19976-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Feb 2003, Kirk McKusick wrote: > I forgot, the patch is at: > > http://www.chesapeake.net/~jroberson/bcache.diff > > These changes look reasonable to me. > Thanks, I'm really glad you looked that over. I will have some changes to the softdep code for you to review soon. It needs to acquire the vnode interlock to protect the dirty and clean queues. The interlock is required since io can complete while the vnode lock is not held and these lists are modified at interrupt time. I intend to add an interlock argument to getdirtybuf(). Also, what are your thoughts on how smp safe ufs/ffs is? Are there any internal datastructures that need locking? If vnodes and mounts were locked along with the buf cache and name cache do you think it would be safe to drop Giant? We're very close to this point now. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 20: 2:54 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A33D737B401 for ; Sun, 23 Feb 2003 20:02:52 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B9B343FA3 for ; Sun, 23 Feb 2003 20:02:51 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1O42o1o039369 for ; Sun, 23 Feb 2003 20:02:51 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1O42o3U040757 for ; Sun, 23 Feb 2003 20:02:50 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1O42oUP040750 for freebsd-arch@FreeBSD.ORG; Sun, 23 Feb 2003 20:02:50 -0800 (PST) (envelope-from marcel) Date: Sun, 23 Feb 2003 20:02:50 -0800 From: Marcel Moolenaar To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224040250.GA19558@athlon.pn.xcllnt.net> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224023118.GD67312@dragon.nuxi.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Using snippets of the patch as the red line... \begin{snippet} -LINT: ../../conf/NOTES NOTES ../../conf/makeLINT.sed - cat ../../conf/NOTES NOTES | sed -E -n -f ../../conf/makeLINT.sed > LINT +NOTES= ../../conf/NOTES \ + ../../conf/NOTES.bt \ + ../../conf/NOTES.ext2fs \ + ../../conf/NOTES.ps2 \ + ../../conf/NOTES.raid \ + ../../conf/NOTES.syscons \ + NOTES + +LINT: ${NOTES} ../../conf/makeLINT.sed + cat ${NOTES} | sed -E -n -f ../../conf/makeLINT.sed > LINT \end{snippet} As I said before, I like the idea. I don't think this is the best separation though. To me it makes more sense to categorize based on hardware characteristics, such as bus. In that light, I probably would merge NOTES.ps2 and NOTES.syscons into a NOTES.legacy. There's probably also a chicken and egg problem in that we may want to clean up the code in relation to the categorization. A split by itself (ie without the code cleanup) is probably sub-optimal no matter how you split. \begin{snippet} @@ -150,8 +150,13 @@ u_int32_t target_address:12; u_int32_t initiator_address:12; u_int32_t function:8; +#if defined(__alpha__) || defined(__sparc64__) + u_int64_t initiator_context; + u_int64_t transaction_context; +#else u_int32_t initiator_context; u_int32_t transaction_context; +#endif u_int16_t detailed_status; #define I2O_DETAIL_STATUS_SUCCESS 0x0000 #define I2O_DETAIL_STATUS_BAD_KEY 0x0002 \end{snippet} It makes sense in the above case to be able to test for __ILP32__ or __LP64__ rather than listing all the 64-architectures. Needless to say that the above code is broken on ia64 (irrespective whether it could actually be used on ia64). On ia64, _LP64 and __LP64__ are defined, but I don't know if that's true for all 64-bit platforms that we support. \begin{snippet} Index: sparc64/isa/isa_dma.c =================================================================== RCS file: sparc64/isa/isa_dma.c diff -N sparc64/isa/isa_dma.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sparc64/isa/isa_dma.c 23 Feb 2003 23:12:42 -0000 @@ -0,0 +1,105 @@ \end{snippet} This file appears to be glue only. We really should get rid of our isa/legacy infected MI code so that we don't have to pollute new architectures with this. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 21:17:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED0537B401 for ; Sun, 23 Feb 2003 21:17:19 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 367EC43FD7 for ; Sun, 23 Feb 2003 21:17:17 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA30255 for ; Mon, 24 Feb 2003 16:17:06 +1100 Date: Mon, 24 Feb 2003 16:18:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES In-Reply-To: <20030224023118.GD67312@dragon.nuxi.com> Message-ID: <20030224160214.D5342-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Feb 2003, David O'Brien wrote: > On Mon, Feb 24, 2003 at 12:17:08PM +1100, Bruce Evans wrote: > > > Any comments before I commit this? > > > > Please don't commit this. Splitting NOTES into 2 files (for each arch) > > already made it harder to maintain and use. > > [picking a random email to respond to...] > Those saying this need to offer alternatives. They did (put everything in conf/NOTES and cancel the broken parts in the MD NOTES'). They had nightmares about things moving back and forth between NOTES files and suggested canceling things to prevent this. ru finally finished the implementation of canceling devices. You could cancel using simple MD sed scripts until config can do it. > > Parts of the above split is wrong anyway: > > - ext2fs is inherently MI. It doesn't compile on some arches since it has > > some optimizations which are only implemented (in asm) on i386's and > > alphas's. These optimizations are bogus -- slightly (;-) more important > > filesystem like ffs just use C code for the corresponding things > > (scanning bitmaps). > > ext2fs is piss-poorly documented where we got the Linux bits from what > had to be done to make then work for us. I have up after an hour trying > to get the right sys/gnu/ext2fs/sparc64-bitopts.h. So I don't think Why not ask those familiar with the code? It would take more than an hour to get an answer but this is not urgent. > anyone is going to do it anytime soon. I'll just move it to > sys/{i386,alpha}/conf/NOTES > > > - syscons is supposed to be MI. If it weren't MI, then it wouldn't be in > > /sys/dev ;-). > > "meant" != is. The work to make it truly MI is immense. Getting the non-isa parts to just compile shouldn't be so hard. Once it compiles, having it in all LINTS is good since it prevents more i386'isms creeping in. > > - bt and some other devices may be fairly bus-dependent and have no future, > > but they can be removed from ../../conf/NOTES using a whole 1 `nodevice' > > line (but don't do too much of this or ../../conf/NOTES files would grow > > to have almost as much duplication as separate files). > > I doubt bt(4) will work on sparc64, PowerPC, or IA-64. So do people want > all that's in NOTES.bt (and that's a lot of docs) to be duplicated three > times in sys/{alpha,i386,pc98}/conf/NOTES or split out as I have?? I want no duplication and as little splitting as possible maintainence and documentation aspects of NOTES. NOTES serves as a place to bring together some of the documentation that is scattered across man pages where hardly anyway can find it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 21:29:13 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEA9837B401 for ; Sun, 23 Feb 2003 21:29:11 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9B3943FB1 for ; Sun, 23 Feb 2003 21:29:10 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.7/8.12.2) with ESMTP id h1O5TA2p006082; Sun, 23 Feb 2003 21:29:10 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.7/8.12.7/Submit) id h1O5T9QB006081; Sun, 23 Feb 2003 21:29:09 -0800 (PST) Date: Sun, 23 Feb 2003 21:29:09 -0800 From: "David O'Brien" To: Marcel Moolenaar Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224052909.GA6020@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <20030224040250.GA19558@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224040250.GA19558@athlon.pn.xcllnt.net> User-Agent: Mutt/1.4i 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Feb 23, 2003 at 08:02:50PM -0800, Marcel Moolenaar wrote: > \begin{snippet} > @@ -150,8 +150,13 @@ > u_int32_t target_address:12; > u_int32_t initiator_address:12; > u_int32_t function:8; > +#if defined(__alpha__) || defined(__sparc64__) > + u_int64_t initiator_context; > + u_int64_t transaction_context; > +#else > u_int32_t initiator_context; > u_int32_t transaction_context; > +#endif > u_int16_t detailed_status; > #define I2O_DETAIL_STATUS_SUCCESS 0x0000 > #define I2O_DETAIL_STATUS_BAD_KEY 0x0002 > \end{snippet} > > It makes sense in the above case to be able to test for __ILP32__ > or __LP64__ rather than listing all the 64-architectures. Needless > to say that the above code is broken on ia64 (irrespective whether > it could actually be used on ia64). On ia64, _LP64 and __LP64__ > are defined, but I don't know if that's true for all 64-bit > platforms that we support. This was only posted so people could play with the real goal of a LINT everywhere. Obivisouly the changes are totally bogus and sos needs to figure out the best way to handle this. This snippet I did so I could at least point out the problems to him. > \begin{snippet} > Index: sparc64/isa/isa_dma.c > =================================================================== > RCS file: sparc64/isa/isa_dma.c > diff -N sparc64/isa/isa_dma.c > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ sparc64/isa/isa_dma.c 23 Feb 2003 23:12:42 -0000 > @@ -0,0 +1,105 @@ > \end{snippet} > > This file appears to be glue only. We really should get rid of > our isa/legacy infected MI code so that we don't have to pollute > new architectures with this. It is. Jake seems violently opposed to this. I wish we would come to an agreement that LINT should compile every piece of code, or just code that could reasonably be expected to work on said platform. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 21:56:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9047237B401 for ; Sun, 23 Feb 2003 21:56:45 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id D140243F93 for ; Sun, 23 Feb 2003 21:56:44 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0040.cvx22-bradley.dialup.earthlink.net ([209.179.198.40] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nBbV-0000J1-00; Sun, 23 Feb 2003 21:56:42 -0800 Message-ID: <3E59B3C9.650144CC@mindspring.com> Date: Sun, 23 Feb 2003 21:55:21 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Wes Peters , arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302231911.14264.wes@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4032de80802fffe8120812ed874b7bec2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > Yes, I have an idea of what I want to do for that, but it will be > done as a separate patch. I have several different changes in > mind, and I'm trying to figure out the best order to make them. I'm pretty happy with what Garance has said he intends to do in this area. > Note that the problem isn't the first roll (where the 40-meg file > turns into /var/log/somelog.0), it's that later checking may see > that /var/log/somelog is 0 bytes (particularly if /var/log is out > of disk space), and thus the 40-meg logfile is *never* rotated > after that first shot. Actually, the problem in the case of the InterJet was that in the case of an out-of-space, the space was not available, not that there would not be subsequent log rolls, as you imply here. Specifically, there are a lot of things that go on /var besides log files. One of these is the pid files for various programs, which fail to start if they cannot be created, and many of which do not necessarily run as root. Another is temporary files, for things like mail queue entries, which may occur on /var/tmp, if it is the designated /tmp directory. This is a common case, when /var is the only writeable FS in the system (for example). > Once I add the -R option, and once you add the improvements to > syslogd itself, then the situation that Terry describes is less > likely to happen. I do want to do something about it, though. As long as it's possible to set *some* option up to drain the FS down to a less than full state, I'm mostly agnostic on the method used to specifically do it. I've stated my preferences, from a product design and remote support perspective (rewrite history and save only the last XXX of the last log file); I think that's the most reasonable approach, but there's also something to be said about saving the events around the time the failure started that ended up leaving me with a full disk. So... I'm mostly agnostic. I never fixed this at Whistle because it was Archie's code, and the best way to piss off your coworkers is to rewrite their code out from under them. 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 22: 5:20 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB04037B401 for ; Sun, 23 Feb 2003 22:05:18 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C944A43F75 for ; Sun, 23 Feb 2003 22:05:17 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp53.pn.xcllnt.net (dhcp53.pn.xcllnt.net [192.168.4.253]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1O65H1o039895 for ; Sun, 23 Feb 2003 22:05:17 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp53.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp53.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1O65HTM009817 for ; Sun, 23 Feb 2003 22:05:17 -0800 (PST) (envelope-from marcel@dhcp53.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp53.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1O65HD2009816 for freebsd-arch@FreeBSD.ORG; Sun, 23 Feb 2003 22:05:17 -0800 (PST) Date: Sun, 23 Feb 2003 22:05:17 -0800 From: Marcel Moolenaar To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224060517.GA9757@dhcp53.pn.xcllnt.net> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <20030224040250.GA19558@athlon.pn.xcllnt.net> <20030224052909.GA6020@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224052909.GA6020@dragon.nuxi.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Feb 23, 2003 at 09:29:09PM -0800, David O'Brien wrote: > > > \begin{snippet} > > Index: sparc64/isa/isa_dma.c > > =================================================================== > > RCS file: sparc64/isa/isa_dma.c > > diff -N sparc64/isa/isa_dma.c > > --- /dev/null 1 Jan 1970 00:00:00 -0000 > > +++ sparc64/isa/isa_dma.c 23 Feb 2003 23:12:42 -0000 > > @@ -0,0 +1,105 @@ > > \end{snippet} > > > > This file appears to be glue only. We really should get rid of > > our isa/legacy infected MI code so that we don't have to pollute > > new architectures with this. > > It is. Jake seems violently opposed to this. I wish we would come to an > agreement that LINT should compile every piece of code, or just code that > could reasonably be expected to work on said platform. I think we can only have platform specific LINTs. A single LINT that compiles every piece of code must be able to compile all existing pmap.c, machdep.c and other overlapping MD files in a single kernel. Obviously an impossibility in this universe. I think the hard part is: can we work with the elementary MD/MI distinction we have now, or do we need to have a more fine grained selection mechanism and if the latter, what? Take for example powerpc or mips, do we need to distinguish between little-endian and big-endian kernels? Do we need a selection based on platform (rather than just architecture)? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 22:20:31 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6C0B37B401 for ; Sun, 23 Feb 2003 22:20:30 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D77643FCB for ; Sun, 23 Feb 2003 22:20:30 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.7/8.12.2) with ESMTP id h1O6KT2p006679 for ; Sun, 23 Feb 2003 22:20:29 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.7/8.12.7/Submit) id h1O6KTZn006678 for freebsd-arch@FreeBSD.ORG; Sun, 23 Feb 2003 22:20:29 -0800 (PST) Date: Sun, 23 Feb 2003 22:20:29 -0800 From: "David O'Brien" To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224062029.GA6648@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <20030224040250.GA19558@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224040250.GA19558@athlon.pn.xcllnt.net> User-Agent: Mutt/1.4i 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Feb 23, 2003 at 08:02:50PM -0800, Marcel Moolenaar wrote: > As I said before, I like the idea. I don't think this is the best > separation though. Unfortunately too many others didn't. I have a new patch http://people.freebsd.org/~obrien/sp64notes.diff (same name) that uses "nodevice" and sed to remove options. I would like someone to test it on PC98 thought. The patch undoes all of of nyan's last commit. But I think I have sys/pc86/conf/{Makefile,NOTES} so that it should work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 22:32:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7E1D37B401 for ; Sun, 23 Feb 2003 22:32:48 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF8D443F3F for ; Sun, 23 Feb 2003 22:32:47 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1O6WklI008288 for ; Mon, 24 Feb 2003 07:32:46 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES From: phk@phk.freebsd.dk In-Reply-To: Your message of "Sun, 23 Feb 2003 22:05:17 PST." <20030224060517.GA9757@dhcp53.pn.xcllnt.net> Date: Mon, 24 Feb 2003 07:32:46 +0100 Message-ID: <8287.1046068366@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am violently in favour of having compilable LINT kernels on all platforms, but I do not like the path we are heading down splitting NOTES into per feature files: It does not solve the fundamental problem and it simply does not scale in the long term. Part of the fundamental problem is that a single LINT kernel, even per architecture is not able to test both branches of an #ifdef/#else/#endif construct. Generating a LINT1 and LINT2 per architecture would give us much better code coverage. Going down the path of NOTES.this and NOTES.that does not help us solve this problem becuase it does not capture the information we need to know, but it does take us down a path of total fragmentation into umpteen files which nobody will have any kind of overview off how is stuck together in a few months time. There are two ways to do this right: Either one large or strictly per feature information files which capture the knowledge today captured in GENERIC/NOTES, conf/options* and conf/files* and in addition contains the bits of information we need to generate correct LINT files per architecture. I would personally prefer that it be strictly per-feature files since huge files tend to become unmanagable as well. I am not going to raise a bikeshed about the format of said files, I'll just leave my bucket of blue paint here for those who will do the bikeshed. Summary: 1. Strictly per feature files, not "adhoc groupings" 2. Much more expressive format than NOTES needed. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 22:41:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46D0F37B401 for ; Sun, 23 Feb 2003 22:41:35 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A48443FA3 for ; Sun, 23 Feb 2003 22:41:30 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp53.pn.xcllnt.net (dhcp53.pn.xcllnt.net [192.168.4.253]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1O6fT1o040051 for ; Sun, 23 Feb 2003 22:41:29 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp53.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp53.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1O6fTTM034321 for ; Sun, 23 Feb 2003 22:41:29 -0800 (PST) (envelope-from marcel@dhcp53.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp53.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1O6fTK9034320 for freebsd-arch@FreeBSD.ORG; Sun, 23 Feb 2003 22:41:29 -0800 (PST) Date: Sun, 23 Feb 2003 22:41:29 -0800 From: Marcel Moolenaar To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224064129.GA13290@dhcp53.pn.xcllnt.net> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <20030224040250.GA19558@athlon.pn.xcllnt.net> <20030224062029.GA6648@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224062029.GA6648@dragon.nuxi.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Feb 23, 2003 at 10:20:29PM -0800, David O'Brien wrote: > On Sun, Feb 23, 2003 at 08:02:50PM -0800, Marcel Moolenaar wrote: > > As I said before, I like the idea. I don't think this is the best > > separation though. > > Unfortunately too many others didn't. > I have a new patch http://people.freebsd.org/~obrien/sp64notes.diff > (same name) that uses "nodevice" and sed to remove options. I think this is worse: o devices, options and hints are related in a particular way that config(8) doesn't handle. Removal of a device automaticly implies removal of its options and hints. On the other hand, Removal of hints and/or options does not imply removal of the device. The "nodevice" approach has no way for config(8) to honour the relationship and causes pollution and duplication (such as the sed in the makefile), or worse: conflicts. o The addition of a new driver must almost always be accompanied by a number of nodevice entries for platforms on which the device does not work, which generally yields a worsed case approximation (= disabled on architectures the committer is not able to test on). o The list of nodevice entries can get pretty large on some systems. This pollutes the config file, possibly to the extend that the nodevice list is longer than the device list. In short: I think the nodevice construct is a kludge. Just another quick and dirty hack that apparently has a high risk of being promoted to "solution". Don't let my opinion stand in your way of getting LINT on sparc, though. $0.02 -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Feb 23 23:38:28 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DE8537B401 for ; Sun, 23 Feb 2003 23:38:27 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5560B43FBF for ; Sun, 23 Feb 2003 23:38:26 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA14852 for ; Mon, 24 Feb 2003 18:38:24 +1100 Date: Mon, 24 Feb 2003 18:39:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES In-Reply-To: <20030224062029.GA6648@dragon.nuxi.com> Message-ID: <20030224183144.G5729-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Feb 2003, David O'Brien wrote: > On Sun, Feb 23, 2003 at 08:02:50PM -0800, Marcel Moolenaar wrote: > > As I said before, I like the idea. I don't think this is the best > > separation though. > > Unfortunately too many others didn't. > I have a new patch http://people.freebsd.org/~obrien/sp64notes.diff > (same name) that uses "nodevice" and sed to remove options. I like this much better. The sparc64 NOTES is not too large to have enclosed in the mail :-), and will hopefully become smaller as more device drivers are made MI or go away. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 0: 2:53 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3C7537B401 for ; Mon, 24 Feb 2003 00:02:51 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EF3A43FB1 for ; Mon, 24 Feb 2003 00:02:51 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 63FBB5308; Mon, 24 Feb 2003 09:02:48 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Marcel Moolenaar Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES From: Dag-Erling Smorgrav Date: Mon, 24 Feb 2003 09:02:48 +0100 In-Reply-To: <20030224064129.GA13290@dhcp53.pn.xcllnt.net> (Marcel Moolenaar's message of "Sun, 23 Feb 2003 22:41:29 -0800") Message-ID: User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386--freebsd) References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <20030224040250.GA19558@athlon.pn.xcllnt.net> <20030224062029.GA6648@dragon.nuxi.com> <20030224064129.GA13290@dhcp53.pn.xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Marcel Moolenaar writes: > o devices, options and hints are related in a particular way that > config(8) doesn't handle. Removal of a device automaticly > implies removal of its options and hints. On the other hand, > Removal of hints and/or options does not imply removal of the > device. The "nodevice" approach has no way for config(8) to > honour the relationship and causes pollution and duplication > (such as the sed in the makefile), or worse: conflicts. Run the combined ../../conf/NOTES and ./NOTES through cpp on the way to LINT. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 0:15:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EDD237B401 for ; Mon, 24 Feb 2003 00:15:33 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C96643F93 for ; Mon, 24 Feb 2003 00:15:32 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA19689; Mon, 24 Feb 2003 19:15:27 +1100 Date: Mon, 24 Feb 2003 19:16:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES In-Reply-To: <20030224064129.GA13290@dhcp53.pn.xcllnt.net> Message-ID: <20030224185033.H6037-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Feb 2003, Marcel Moolenaar wrote: > On Sun, Feb 23, 2003 at 10:20:29PM -0800, David O'Brien wrote: > > On Sun, Feb 23, 2003 at 08:02:50PM -0800, Marcel Moolenaar wrote: > > > As I said before, I like the idea. I don't think this is the best > > > separation though. > > > > Unfortunately too many others didn't. > > I have a new patch http://people.freebsd.org/~obrien/sp64notes.diff > > (same name) that uses "nodevice" and sed to remove options. > > I think this is worse: > o devices, options and hints are related in a particular way that > config(8) doesn't handle. Removal of a device automaticly > implies removal of its options and hints. On the other hand, > Removal of hints and/or options does not imply removal of the > device. The "nodevice" approach has no way for config(8) to > honour the relationship and causes pollution and duplication > (such as the sed in the makefile), or worse: conflicts. Sed to remove options is just a hack until config can do it. Hints are of no interest here since they are only for humans to read (they are not stripped by makeLINT.sed). Unremoved options for a removed device are almost as irrelevant (they may be confusing but shouldn't affect the object code). David's sed script has to remove options mainly because they are not present for all arches, not because their device driver is removed. It would be much larger if it removed all irrelevant options. I don't want to deal with configuring perfectly consistent options now (maybe you do? -). I had little success even getting everyone to use orthogonal optional names (like SC_FOO associated with driver sc). > o The addition of a new driver must almost always be accompanied > by a number of nodevice entries for platforms on which the device > does not work, which generally yields a worsed case approximation > (= disabled on architectures the committer is not able to test on). New drivers should just be added to the platforms that it works on or is intended to work on. This doesn't work so well for old drivers because their maintainers aren't all active and there are so many drivers not written with portability in mind, so much so that even drivers that should be portable aren't. > o The list of nodevice entries can get pretty large on some systems. > This pollutes the config file, possibly to the extend that the > nodevice list is longer than the device list. True. I think this is better than putting only the devices that work on all systems in /sys/conf/NOTES. That would essentially regress to the setup before the central NOTES existed, since there are no devies that work on all arches. > In short: I think the nodevice construct is a kludge. Just another > quick and dirty hack that apparently has a high risk of being > promoted to "solution". I agree that it is a klduge. But it is easy to use. I tried setting up some configurations without it and soon found that I needed lots of little files, with nested includes working to avoid duplication (they don't). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 1:43:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D2D237B401 for ; Mon, 24 Feb 2003 01:43:34 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4FF743FBD for ; Mon, 24 Feb 2003 01:43:33 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0041.cvx40-bradley.dialup.earthlink.net ([216.244.42.41] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nF92-0007N9-00; Mon, 24 Feb 2003 01:43:33 -0800 Message-ID: <3E59E8F4.884C9160@mindspring.com> Date: Mon, 24 Feb 2003 01:42:12 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@FreeBSD.ORG Cc: Bruce Evans Subject: Re: [RFC] splitting of conf/NOTES References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a410a5bd9de588a40d2ef3e8d01a7423873ca473d225a0f487350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > I doubt bt(4) will work on sparc64, PowerPC, or IA-64. So do people want > all that's in NOTES.bt (and that's a lot of docs) to be duplicated three > times in sys/{alpha,i386,pc98}/conf/NOTES or split out as I have?? What they probably *want* is for bt(4) to work on sparc64, PowerPC, or IA-64. 8-) 8-). What they should probably *get* is per machine exceptions, via "nodevice", which are then correctable on a case by case basis, instead of having to be corrected globally for all the platforms all at once. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 1:49: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E13C37B401 for ; Mon, 24 Feb 2003 01:48:58 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BB1C43F85 for ; Mon, 24 Feb 2003 01:48:57 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1O9mu1o040748; Mon, 24 Feb 2003 01:48:56 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1O9mu3U021232; Mon, 24 Feb 2003 01:48:56 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1O9muck021231; Mon, 24 Feb 2003 01:48:56 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 01:48:56 -0800 From: Marcel Moolenaar To: Bruce Evans Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224094856.GA21088@athlon.pn.xcllnt.net> References: <20030224064129.GA13290@dhcp53.pn.xcllnt.net> <20030224185033.H6037-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224185033.H6037-100000@gamplex.bde.org> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 07:16:41PM +1100, Bruce Evans wrote: > are not stripped by makeLINT.sed). Unremoved options for a removed > device are almost as irrelevant (they may be confusing but shouldn't > affect the object code). I don't think they will cause problems now, but that does not mean that they could eventually. When it possibly does cause problems at a later time, it's likely much harder to do it right then than it will be now. > David's sed script has to remove options > mainly because they are not present for all arches, not because their > device driver is removed. The advantage of centralized documentation is in my opinion of less importance than the disadvantage of having options listed outside kernel config files (including NOTES), which begs for documentation... > It would be much larger if it removed all > irrelevant options. I don't want to deal with configuring perfectly > consistent options now (maybe you do? -). Not necessarily right now, but definitely in the end. > I had little success even > getting everyone to use orthogonal optional names (like SC_FOO > associated with driver sc). I think it's the underscore :-) :-) > > o The addition of a new driver must almost always be accompanied > > by a number of nodevice entries for platforms on which the device > > does not work, which generally yields a worsed case approximation > > (= disabled on architectures the committer is not able to test on). > > New drivers should just be added to the platforms that it works on or > is intended to work on. I think this is an unrealistic model, because it assumes research, planning and motivation beyond what I think is realistic. The research part is needed to get a good understand of which platforms use (or can likely use) the device, so that the driver can be designed and implemented for that. The planning is required because most of the time the developer has only a subset of the platforms for which the driver can be written and thus needs the help of others and the motivation is needed because the complexity and the work involved is generally much higher. > This doesn't work so well for old drivers > because their maintainers aren't all active and there are so many > drivers not written with portability in mind, so much so that even > drivers that should be portable aren't. Given time, this applies to new drivers as well :-) > > o The list of nodevice entries can get pretty large on some systems. > > This pollutes the config file, possibly to the extend that the > > nodevice list is longer than the device list. > > True. I think this is better than putting only the devices that work > on all systems in /sys/conf/NOTES. That would essentially regress > to the setup before the central NOTES existed, since there are no > devies that work on all arches. Yes, with the addition that it implies something differently for me. I still like the bus-centric approach. A driver that has a PCI front-end should be compilable on any machine that supports the PCI bus. Whether there's actual hardware in existence that works on the platform is not important. Put all the drivers with a PCI front-end in NOTES.pci and you should have a fairly convenient bucket. At this time (I haven't had much feedback yet or run into walls myself) I think that the bus-centric approach yields a good categorization, with redundancy or duplication that has nice (=logic) properties: bus-specific options (and hints) are mentioned in the most logic place. > > In short: I think the nodevice construct is a kludge. Just another > > quick and dirty hack that apparently has a high risk of being > > promoted to "solution". > > I agree that it is a klduge. But it is easy to use. It better be. A kludge that's hard to use is more often than not a bug :-) > I tried setting > up some configurations without it and soon found that I needed lots > of little files, with nested includes working to avoid duplication > (they don't). I think there will be duplication no matter what we do. I think the trick is to find the imperfection that feels natural enough that it isn't perceived as a flaw. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 2: 3:39 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BFA837B401 for ; Mon, 24 Feb 2003 02:03:38 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C7D43F85 for ; Mon, 24 Feb 2003 02:03:37 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1OA3a1o040813; Mon, 24 Feb 2003 02:03:36 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1OA3a3U021315; Mon, 24 Feb 2003 02:03:36 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1OA3aRQ021314; Mon, 24 Feb 2003 02:03:36 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 02:03:36 -0800 From: Marcel Moolenaar To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224100336.GB21088@athlon.pn.xcllnt.net> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <3E59E8F4.884C9160@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E59E8F4.884C9160@mindspring.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 01:42:12AM -0800, Terry Lambert wrote: > David O'Brien wrote: > > I doubt bt(4) will work on sparc64, PowerPC, or IA-64. So do people want > > all that's in NOTES.bt (and that's a lot of docs) to be duplicated three > > times in sys/{alpha,i386,pc98}/conf/NOTES or split out as I have?? > > What they probably *want* is for bt(4) to work on sparc64, PowerPC, > or IA-64. 8-) 8-). ia64 is designed to promote migration. If bt(4) has no PC legacy stuff, it's very well possible that such a device may end up in an ia64 eventually (I'll do it just to make my point :-) > What they should probably *get* is per machine exceptions, via > "nodevice", which are then correctable on a case by case basis, > instead of having to be corrected globally for all the platforms > all at once. Isn't that's like voting for spam because people can install filters? or like an opt out mailing list: remove yourself if you think you're exceptional? Isn't it also more related to kernel config files where we list devices when we want to add support for them, not to list devices we don't want to support? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 2:41: 3 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA4D737B401 for ; Mon, 24 Feb 2003 02:41:01 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2121B43F75 for ; Mon, 24 Feb 2003 02:41:01 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0041.cvx40-bradley.dialup.earthlink.net ([216.244.42.41] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nG2c-0003uu-00; Mon, 24 Feb 2003 02:40:59 -0800 Message-ID: <3E59F665.DCD54EAF@mindspring.com> Date: Mon, 24 Feb 2003 02:39:33 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <3E59E8F4.884C9160@mindspring.com> <20030224100336.GB21088@athlon.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f8b2dfa54f90d49d84e6f7316ecc169e3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > On Mon, Feb 24, 2003 at 01:42:12AM -0800, Terry Lambert wrote: > > What they should probably *get* is per machine exceptions, via > > "nodevice", which are then correctable on a case by case basis, > > instead of having to be corrected globally for all the platforms > > all at once. > > Isn't that's like voting for spam because people can install > filters? or like an opt out mailing list: remove yourself if > you think you're exceptional? > Isn't it also more related to kernel config files where we list > devices when we want to add support for them, not to list devices > we don't want to support? No, it's closer to NOT_FOR_ARCHS and ONLY_FOR_ARCHS in the ports system Makefiles, such that ports are allowed to be broken for particular architectures, where the port maintainer has no way of verifying that they actually work. In fact, it's exactly like that, except instead of a port maintainer, we're talking about a driver maintainer. I think people need to fact the fact that i386 is the FreeBSD reference platform, and all other platforms are second class citizens. The onus of supporting a port (or a driver) on an architecture that the port (or driver) maintainer doesn't have readily available to them for testing needs to be on the proponents for that architecture. PS: The whole idea config adding/removing support for devices is really very bogus, and has more to do with lacking ELF section attribution for code, data, probe code, probe data, paging path, non-paging path, etc. (all of which Microsoft readily supports in their OSs, via PELDR, and which GCC can also support through section attribution), than it has to do with any real technical argument to the contrary. The "config" program should die. PPS: Both Julian and Poul have spoken eloquently and at length about not varying the size of kernel structures based on compilation options in the config files. Their arguments are made on the basis of module options not matching kernel options, but the same argument applies to the ability to both statically and dynamically link the same object files, and the ability to use an ELF archiver to add/remove modules in an already compiled kernel (the main effort that this entails is editing the linker set contents for SYSINIT() created linker sets; if they are sectioned properly, then you don't care: you just regenerate them). The config program should die. PPPS: The config program should die. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 4:56:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40BF337B401 for ; Mon, 24 Feb 2003 04:56:13 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62DEF43F93 for ; Mon, 24 Feb 2003 04:56:12 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1OCuA3Y087681; Mon, 24 Feb 2003 05:56:10 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 24 Feb 2003 05:55:21 -0700 (MST) Message-Id: <20030224.055521.11262802.imp@bsdimp.com> To: marcel@xcllnt.net Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES From: "M. Warner Losh" In-Reply-To: <20030224060517.GA9757@dhcp53.pn.xcllnt.net> References: <20030224040250.GA19558@athlon.pn.xcllnt.net> <20030224052909.GA6020@dragon.nuxi.com> <20030224060517.GA9757@dhcp53.pn.xcllnt.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20030224060517.GA9757@dhcp53.pn.xcllnt.net> Marcel Moolenaar writes: : Take for example powerpc or mips, do we need to distinguish between : little-endian and big-endian kernels? Do we need a selection based : on platform (rather than just architecture)? Take pc98 as our queue and we know the answer is 'yes' Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 5: 4:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A5DE37B401 for ; Mon, 24 Feb 2003 05:04:29 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FFFC43F3F for ; Mon, 24 Feb 2003 05:04:28 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1OD4R3Y087744 for ; Mon, 24 Feb 2003 06:04:27 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 24 Feb 2003 06:03:15 -0700 (MST) Message-Id: <20030224.060315.63039059.imp@bsdimp.com> To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES From: "M. Warner Losh" In-Reply-To: <20030224094856.GA21088@athlon.pn.xcllnt.net> References: <20030224064129.GA13290@dhcp53.pn.xcllnt.net> <20030224185033.H6037-100000@gamplex.bde.org> <20030224094856.GA21088@athlon.pn.xcllnt.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20030224094856.GA21088@athlon.pn.xcllnt.net> Marcel Moolenaar writes: : Yes, with the addition that it implies something differently for : me. I still like the bus-centric approach. A driver that has a : PCI front-end should be compilable on any machine that supports : the PCI bus. Whether there's actual hardware in existence that : works on the platform is not important. Put all the drivers : with a PCI front-end in NOTES.pci and you should have a fairly : convenient bucket. At this time (I haven't had much feedback yet : or run into walls myself) I think that the bus-centric approach : yields a good categorization, with redundancy or duplication that : has nice (=logic) properties: bus-specific options (and hints) : are mentioned in the most logic place. I'd agree with this. All PCI devices are available for all platforms that support PCI, as a general rule (exception to this rule will likely be rare). Those exceptions can just be left out of the NOTES.pci file. The exceptions are very likely to be MACHINE dependent (some of the pc98 built-in chips are this way). I'd also put in the exception camp all drivers that aren't written to be MI, or at least make some pretense at being MI. The big problem is with the ISA bus. The ISA bus has too many overloaded meanings right now. It means those funky old cards that we know and love, as well as devices that look like they are on an ISA or ISA-like bus, but really are just a few gates in some bridge chip. I have some thoughts on the cbus vs isa bus thread that I'd like a chance to prototype before going into in detail. This whole discussion shows that our tree is still to x86 centric (with alpha hacks for extra lovin' goodness). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 8:36: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A631837B401 for ; Mon, 24 Feb 2003 08:35:57 -0800 (PST) Received: from espresso.bsdmike.org (espresso.bsdmike.org [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D1F843FAF for ; Mon, 24 Feb 2003 08:35:57 -0800 (PST) (envelope-from mike@espresso.bsdmike.org) Received: by espresso.bsdmike.org (Postfix, from userid 1002) id 2A1D39C58; Mon, 24 Feb 2003 11:23:23 -0500 (EST) Date: Mon, 24 Feb 2003 11:23:23 -0500 From: Mike Barcroft To: freebsd-arch@freebsd.org Subject: [RFC] Merging NOTES (was: Re: [RFC] splitting of conf/NOTES) Message-ID: <20030224112323.A61907@espresso.bsdmike.org> References: <20030224001644.GA67255@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20030224001644.GA67255@dragon.nuxi.com>; from obrien@freebsd.org on Sun, Feb 23, 2003 at 04:16:44PM -0800 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline David O'Brien writes: > I can now create a sparc64 LINT kernel with the patches at > http://people.freebsd.org/~obrien/sp64notes.diff. The essence of this > patch is to split sys/conf/NOTES into NOTES, NOTES.bt, NOTES.ext2fs, > NOTES.ps2, NOTES.raid, and NOTES.syscons. Each /sys//conf/Makefile > now looks like: Counter-proposal: Merge all sys/*/conf/NOTES and sys/conf/NOTES into one file, and add CPP parsing. With this patch one has the ability to specify things like: .if defined(__alpha__) || defined(__i386__) or: .ifndef __pc98__ This patch could also be extended to allow bus specific defines: .ifdef __sparc64__ .define SBUS_SUPPORT .endif .if defined(__alpha__) || defined(__i386__) .define ISA_SUPPORT .endif .ifdef SBUS_SUPPORT ... .endif Also, when making a driver MD -> MI, one need only move it up a few lines, so history is preserved in a single file. Best regards, Mike Barcroft --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="NOTES.diff" Index: alpha/conf/Makefile =================================================================== RCS file: /work/repo/src/sys/alpha/conf/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- alpha/conf/Makefile 15 Jul 2002 17:50:17 -0000 1.1 +++ alpha/conf/Makefile 24 Feb 2003 16:22:18 -0000 @@ -6,5 +6,5 @@ clean: rm -f LINT -LINT: ../../conf/NOTES NOTES ../../conf/makeLINT.sed - cat ../../conf/NOTES NOTES | sed -E -n -f ../../conf/makeLINT.sed > LINT +LINT: ../../conf/NOTES ../../conf/makeLINT.sed + cat ../../conf/NOTES NOTES | sed -E -n -f ../../conf/makeLINT.sed | cpp -P -D__alpha__=1 | sed 's/"@/\\"/g' > LINT Index: conf/NOTES =================================================================== RCS file: /work/repo/src/sys/conf/NOTES,v retrieving revision 1.1130 diff -u -r1.1130 NOTES --- conf/NOTES 23 Feb 2003 13:32:32 -0000 1.1130 +++ conf/NOTES 24 Feb 2003 16:20:26 -0000 @@ -2118,3 +2118,23 @@ options METEOR_TEST_VIDEO options NDEVFSINO=1025 options NDEVFSOVERFLOW=32769 + +##################################################################### +# ALPHA SPECIFIC OPTIONS + +.ifdef __alpha__ + +# All of sys/alpha/conf/NOTES moved here. + +.endif # __alpha__ + +##################################################################### +# I386 SPECIFIC OPTIONS + +.ifdef __i386__ + +# All of sys/i386/conf/NOTES moved here. + +.endif # __i386__ + +# ... ETC ... Index: conf/makeLINT.sed =================================================================== RCS file: /work/repo/src/sys/conf/makeLINT.sed,v retrieving revision 1.2 diff -u -r1.2 makeLINT.sed --- conf/makeLINT.sed 23 Feb 2003 19:40:45 -0000 1.2 +++ conf/makeLINT.sed 24 Feb 2003 16:08:29 -0000 @@ -1,7 +1,9 @@ #!/usr/bin/sed -E -n -f # $FreeBSD: src/sys/conf/makeLINT.sed,v 1.2 2003/02/23 19:40:45 obrien Exp $ -/^(machine|ident|device|nodevice|makeoptions|options|profile|cpu|option|maxusers)[[:space:]]/ { +/^(((machine|ident|device|nodevice|makeoptions|options|profile|cpu|option|maxusers|\.if|\.ifdef|\.ifndef)[[:space:]])|\.endif)/ { s/[[:space:]]*#.*$// + s/^\./#/ + s/\\"/"@/g p } Index: i386/conf/Makefile =================================================================== RCS file: /work/repo/src/sys/i386/conf/Makefile,v retrieving revision 1.7 diff -u -r1.7 Makefile --- i386/conf/Makefile 15 Jul 2002 17:48:47 -0000 1.7 +++ i386/conf/Makefile 24 Feb 2003 16:10:12 -0000 @@ -6,5 +6,5 @@ clean: rm -f LINT -LINT: ../../conf/NOTES NOTES ../../conf/makeLINT.sed - cat ../../conf/NOTES NOTES | sed -E -n -f ../../conf/makeLINT.sed > LINT +LINT: ../../conf/NOTES ../../conf/makeLINT.sed + cat ../../conf/NOTES NOTES | sed -E -n -f ../../conf/makeLINT.sed | cpp -P -D__i386__=1 | sed 's/"@/\\"/g' > LINT --OgqxwSJOaUobr8KG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 9:28:39 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECC9C37B401 for ; Mon, 24 Feb 2003 09:28:38 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25C6243FE0 for ; Mon, 24 Feb 2003 09:28:38 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.7/8.12.2) with ESMTP id h1OHSQ2p047957; Mon, 24 Feb 2003 09:28:26 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.7/8.12.7/Submit) id h1OHSI4x047948; Mon, 24 Feb 2003 09:28:18 -0800 (PST) Date: Mon, 24 Feb 2003 09:28:18 -0800 From: "David O'Brien" To: "M. Warner Losh" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224172818.GA47872@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.ORG References: <20030224064129.GA13290@dhcp53.pn.xcllnt.net> <20030224185033.H6037-100000@gamplex.bde.org> <20030224094856.GA21088@athlon.pn.xcllnt.net> <20030224.060315.63039059.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224.060315.63039059.imp@bsdimp.com> User-Agent: Mutt/1.4i 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 List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 06:03:15AM -0700, M. Warner Losh wrote: > I'd agree with this. All PCI devices are available for all platforms > that support PCI, as a general rule (exception to this rule will > likely be rare). Those exceptions can just be left out of the > NOTES.pci file. The exceptions are very likely to be MACHINE > dependent (some of the pc98 built-in chips are this way). I agree with this sentiment, and knowing nothing about the PC98 I don't understand why nyan took a lot of PCI cards (mostly RAID) out of the PC98 LINT. Do know why? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 10:46: 3 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3E8837B401; Mon, 24 Feb 2003 10:46:02 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E259F43FDD; Mon, 24 Feb 2003 10:46:01 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1OIjx3Y089998; Mon, 24 Feb 2003 11:46:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 24 Feb 2003 11:44:05 -0700 (MST) Message-Id: <20030224.114405.41526431.imp@bsdimp.com> To: freebsd-arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES From: "M. Warner Losh" In-Reply-To: <20030224172818.GA47872@dragon.nuxi.com> References: <20030224094856.GA21088@athlon.pn.xcllnt.net> <20030224.060315.63039059.imp@bsdimp.com> <20030224172818.GA47872@dragon.nuxi.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20030224172818.GA47872@dragon.nuxi.com> "David O'Brien" writes: : On Mon, Feb 24, 2003 at 06:03:15AM -0700, M. Warner Losh wrote: : > I'd agree with this. All PCI devices are available for all platforms : > that support PCI, as a general rule (exception to this rule will : > likely be rare). Those exceptions can just be left out of the : > NOTES.pci file. The exceptions are very likely to be MACHINE : > dependent (some of the pc98 built-in chips are this way). : : I agree with this sentiment, and knowing nothing about the PC98 I don't : understand why nyan took a lot of PCI cards (mostly RAID) out of the PC98 : LINT. Do know why? No. The pc98 specific pci devices that I'm aware of tend not to have drivers yet (some do, however). Maybe he didn't have the cards for testing? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 11:12:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DEF137B401 for ; Mon, 24 Feb 2003 11:12:12 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A99D43F75 for ; Mon, 24 Feb 2003 11:12:11 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1OJCA1o043370; Mon, 24 Feb 2003 11:12:10 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1OJCAWk000592; Mon, 24 Feb 2003 11:12:10 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1OJCANQ000591; Mon, 24 Feb 2003 11:12:10 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 11:12:09 -0800 From: Marcel Moolenaar To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224191209.GA559@athlon.pn.xcllnt.net> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <3E59E8F4.884C9160@mindspring.com> <20030224100336.GB21088@athlon.pn.xcllnt.net> <3E59F665.DCD54EAF@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E59F665.DCD54EAF@mindspring.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 02:39:33AM -0800, Terry Lambert wrote: > Marcel Moolenaar wrote: > > On Mon, Feb 24, 2003 at 01:42:12AM -0800, Terry Lambert wrote: > > > What they should probably *get* is per machine exceptions, via > > > "nodevice", which are then correctable on a case by case basis, > > > instead of having to be corrected globally for all the platforms > > > all at once. > > > > Isn't that's like voting for spam because people can install > > filters? or like an opt out mailing list: remove yourself if > > you think you're exceptional? > > Isn't it also more related to kernel config files where we list > > devices when we want to add support for them, not to list devices > > we don't want to support? > > No, it's closer to NOT_FOR_ARCHS and ONLY_FOR_ARCHS in the ports > system Makefiles, such that ports are allowed to be broken for > particular architectures, where the port maintainer has no way > of verifying that they actually work. > > In fact, it's exactly like that, except instead of a port maintainer, > we're talking about a driver maintainer. I think there's a fundamental difference. NOT_FOR_ and ONLY_FOR_ are variables set in a ports makefile. To get the list of ports that could be compiled on a platform, one has to visit each and every port first. The "nodevice" approach is exactly the opposite. It's not the driver that tells for which architectures it's meant to be written, it's the architecture that "rejects" drivers. The NOT_FOR_ and ONLY_FOR_ approach would work in the kernel as well. > I think people need to fact the fact that i386 is the FreeBSD > reference platform, and all other platforms are second class > citizens. Our i386 platform is still the best maintained and supported. This however doesn't contribute anything to a possible solution other than to indicate that a i386 centric solution at the cost of non-i386 platforms is acceptable. I disagree... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 12:41:28 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84E8D37B401 for ; Mon, 24 Feb 2003 12:41:27 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DB7E43F85 for ; Mon, 24 Feb 2003 12:41:26 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1OKfE1o043756; Mon, 24 Feb 2003 12:41:14 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1OKfEWk000822; Mon, 24 Feb 2003 12:41:14 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1OKfDRj000821; Mon, 24 Feb 2003 12:41:13 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 12:41:13 -0800 From: Marcel Moolenaar To: "M. Warner Losh" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224204113.GC661@athlon.pn.xcllnt.net> References: <20030224064129.GA13290@dhcp53.pn.xcllnt.net> <20030224185033.H6037-100000@gamplex.bde.org> <20030224094856.GA21088@athlon.pn.xcllnt.net> <20030224.060315.63039059.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224.060315.63039059.imp@bsdimp.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 06:03:15AM -0700, M. Warner Losh wrote: > > The big problem is with the ISA bus. The ISA bus has too many > overloaded meanings right now. It means those funky old cards that we > know and love, as well as devices that look like they are on an ISA or > ISA-like bus, but really are just a few gates in some bridge chip. Maybe ACPI helps out here a bit. On i386 and ia64, where the ISA legacy rears its ugly head the most (I think), ACPI can be used to enumerate the legacy devices. In that sense I treat ACPI as a bus. The tricky part still is that there's a lot of assumptions about the BIOS and the BIOS data area that, if I understand correctly, goes beyond plain ISA and is best described as PC specific. I think this is more a driver issue than anything else. I think if we can tackle ISA or PC legacy fairly decently, we should have something that would work good in general. > This whole discussion shows that our tree is still to x86 centric > (with alpha hacks for extra lovin' goodness). With non-i386 platforms the common case now, I think it's time to bring the balance back. Anakin, bring me my lightsaber... and coffee... no, the green one... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 12:47:22 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0666337B405; Mon, 24 Feb 2003 12:47:21 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07C4543F3F; Mon, 24 Feb 2003 12:47:20 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1OKlJ1o043780; Mon, 24 Feb 2003 12:47:19 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1OKlJWk000847; Mon, 24 Feb 2003 12:47:19 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1OKlJBn000846; Mon, 24 Feb 2003 12:47:19 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 12:47:19 -0800 From: Marcel Moolenaar To: Mike Barcroft Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] Merging NOTES (was: Re: [RFC] splitting of conf/NOTES) Message-ID: <20030224204719.GD661@athlon.pn.xcllnt.net> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224112323.A61907@espresso.bsdmike.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224112323.A61907@espresso.bsdmike.org> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 11:23:23AM -0500, Mike Barcroft wrote: > David O'Brien writes: > > I can now create a sparc64 LINT kernel with the patches at > > http://people.freebsd.org/~obrien/sp64notes.diff. The essence of this > > patch is to split sys/conf/NOTES into NOTES, NOTES.bt, NOTES.ext2fs, > > NOTES.ps2, NOTES.raid, and NOTES.syscons. Each /sys//conf/Makefile > > now looks like: > > Counter-proposal: > Merge all sys/*/conf/NOTES and sys/conf/NOTES into one file, and add > CPP parsing. Good one. There's another thing that we didn't touch and that may be related: modules. sys/modules/Makefile now has all the complexity and in- accuracy to deal with compiling modules. It would be nice to come up with something that can be used for module selection as well. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 13:42: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3304F37B430 for ; Mon, 24 Feb 2003 13:42:00 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1014843FBF for ; Mon, 24 Feb 2003 13:41:59 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1OLfq3Y091273; Mon, 24 Feb 2003 14:41:53 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 24 Feb 2003 14:39:57 -0700 (MST) Message-Id: <20030224.143957.17279856.imp@bsdimp.com> To: marcel@xcllnt.net Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES From: "M. Warner Losh" In-Reply-To: <20030224204113.GC661@athlon.pn.xcllnt.net> References: <20030224094856.GA21088@athlon.pn.xcllnt.net> <20030224.060315.63039059.imp@bsdimp.com> <20030224204113.GC661@athlon.pn.xcllnt.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20030224204113.GC661@athlon.pn.xcllnt.net> Marcel Moolenaar writes: : The tricky part still is that there's a lot of assumptions about : the BIOS and the BIOS data area that, if I understand correctly, : goes beyond plain ISA and is best described as PC specific. I think : this is more a driver issue than anything else. Well, I'm not sure I understand what you are getting at here, so I'll take a stab at guessing (dangerous I know): There's a PC standard for ROMs that live in the ISA hole. One can identify them by scanning this area. This applies to motherboard ROMs as well as ROMs on expansion cards. The ISA hole is memory between 0xa0000 and 0xfffff. The ISA hole is ISA bus specifc, even if the 'hole' is mapped into a different memory range. The ISA cards cannot decode addresses higher than 16MB, and some can only decode them in the first 1MB. This is why, for example, the OLDCARD pccard code tries to allocate things in the above range (well, 0xc0000 to 0xdfffff by default since that tends to be more free). Bus space is supposed to hide these differences by adding or subtracting the "CPU SIDE" offset from the "BUS SPACE" side of the address. So if a machine had a ISA bus mapped at 0x800000000, say, the driver would do a bus space read of location 0xc0000, but the bus_space layer would translate that to an actual read of 0x8000c0000. There are parts of the BIOS RAM that are in segment 0x40 that describe the machine, but most drivers don't deal with that. I agree that ACPI is a bus, but it is only applicable on i386 and ia64. There are no other architectures that use it. pc98 never will, alpha doesn't (and likely never will given its EOL), sparc64 doesn't (but in theory could). While arm, powerpc and mips could, in theory use it, I'm not aware of any that actually do use it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 14: 8:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B073337B401 for ; Mon, 24 Feb 2003 14:08:11 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BCC843FDF for ; Mon, 24 Feb 2003 14:08:11 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0300.cvx22-bradley.dialup.earthlink.net ([209.179.199.45] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nQlb-0002HD-00; Mon, 24 Feb 2003 14:08:08 -0800 Message-ID: <3E5A9777.F951598@mindspring.com> Date: Mon, 24 Feb 2003 14:06:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <3E59E8F4.884C9160@mindspring.com> <20030224100336.GB21088@athlon.pn.xcllnt.net> <3E59F665.DCD54EAF@mindspring.com> <20030224191209.GA559@athlon.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4b8640d4ce7e31193e735633e9fc268db350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > On Mon, Feb 24, 2003 at 02:39:33AM -0800, Terry Lambert wrote: > > Marcel Moolenaar wrote: > > > On Mon, Feb 24, 2003 at 01:42:12AM -0800, Terry Lambert wrote: > > > > What they should probably *get* is per machine exceptions, via > > > > "nodevice", which are then correctable on a case by case basis, > > > > instead of having to be corrected globally for all the platforms > > > > all at once. > > > > > > Isn't that's like voting for spam because people can install > > > filters? or like an opt out mailing list: remove yourself if > > > you think you're exceptional? > > > Isn't it also more related to kernel config files where we list > > > devices when we want to add support for them, not to list devices > > > we don't want to support? > > > > No, it's closer to NOT_FOR_ARCHS and ONLY_FOR_ARCHS in the ports > > system Makefiles, such that ports are allowed to be broken for > > particular architectures, where the port maintainer has no way > > of verifying that they actually work. > > > > In fact, it's exactly like that, except instead of a port maintainer, > > we're talking about a driver maintainer. > > I think there's a fundamental difference. NOT_FOR_ and ONLY_FOR_ > are variables set in a ports makefile. To get the list of ports > that could be compiled on a platform, one has to visit each and > every port first. The "nodevice" approach is exactly the opposite. > It's not the driver that tells for which architectures it's meant > to be written, it's the architecture that "rejects" drivers. > The NOT_FOR_ and ONLY_FOR_ approach would work in the kernel as > well. I've left the rest of this because I don't understand your original statement to which I was replying, given this context. If each architecture port of FreeBSD had a NOTES.ppc or whatever file, and it used "nodevice" to remove things from the global case, I don't really see how this differs from the "NOT_FOR_" approach. If each little driver or subsystem like EXT2FS, which was what had been suggested, has it's onl list of architectures that "it supports", then that's tantamount to each driver or whatever being treated as a seperate port, and using the "ONLY_FOR_" approach. What people are objecting to in the proposed "scatter the data over every file in the system" approach is exactly the "ONLY_FOR_" approach. > > I think people need to fact the fact that i386 is the FreeBSD > > reference platform, and all other platforms are second class > > citizens. > > Our i386 platform is still the best maintained and supported. > This however doesn't contribute anything to a possible solution > other than to indicate that a i386 centric solution at the > cost of non-i386 platforms is acceptable. I disagree... So do I, which is why I believe *everything* should be present by default, and have to be "commented out" on a per platform basis. This also gives control to the platform maintainer over the decision of whether or not they are going to make something work on, for example, the PPC, or if they are going to add a "nodevice" entry to the /sys/ppc/conf/NOTES file to dike it out -- *only for the PPC*. This also supports the philosophy that *you* stated, at one point, where if something is a PCI driver, it should be present on all PCI systems, except those it specifically is known to not work on. If maintaining these per-architecture "nodevice" lists starts to become cumbersome, then there's an easy answer: attract more volunteers for that platform, and start fixing the drivers to make them work, so you can remove the "nodevice" lines. It's really unreasonable, IMO, to expect someone whose life is understanding i386 PC's and some oddball video card to also have to understand the places where Alpha and PPC and ... are different from i386. Not every driver writer should have to become a FreeBSD architecture porting, PPC inline assembler expert (for example). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 14:22:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A94A37B401 for ; Mon, 24 Feb 2003 14:22:20 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E56643FA3 for ; Mon, 24 Feb 2003 14:22:17 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1OMM61o044242; Mon, 24 Feb 2003 14:22:06 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1OMM5Wk001124; Mon, 24 Feb 2003 14:22:05 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1OMM5ct001123; Mon, 24 Feb 2003 14:22:05 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 14:22:05 -0800 From: Marcel Moolenaar To: "M. Warner Losh" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224222205.GA1032@athlon.pn.xcllnt.net> References: <20030224094856.GA21088@athlon.pn.xcllnt.net> <20030224.060315.63039059.imp@bsdimp.com> <20030224204113.GC661@athlon.pn.xcllnt.net> <20030224.143957.17279856.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224.143957.17279856.imp@bsdimp.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 02:39:57PM -0700, M. Warner Losh wrote: > In message: <20030224204113.GC661@athlon.pn.xcllnt.net> > Marcel Moolenaar writes: > : The tricky part still is that there's a lot of assumptions about > : the BIOS and the BIOS data area that, if I understand correctly, > : goes beyond plain ISA and is best described as PC specific. I think > : this is more a driver issue than anything else. > > Well, I'm not sure I understand what you are getting at here, so I'll > take a stab at guessing (dangerous I know): > > There's a PC standard for ROMs that live in the ISA hole. What I'm getting at is: will this only be i386 ROMs (ie with i386 code) or is it possible that when a machine has ISA emulation, one should be able to scan for ROMs in the ISA hole and find something that can actually be used. I'm inclined to assume that ROMs found in the ISA hole are i386 specific and ISA emulation is limited to I/O ports and registers only. Thus: even if ISA (sec) is not i386 specific, there may be ISA drivers that depend on ROM, BIOS and/or BIOS data (see sys/fb/vga.c) and consequently are not pure ISA drivers. They are PC drivers. This is the driver part I was referring to in my previous mail. On the ia64 branch I fiddled with sys/conf/files.* to make PC/ISA device drivers actually depend on the existence of "device isa", so that I could create an ISA-less kernel (needed for pluto{1|2}). This triggered some interesting bugs, such as the fact that the high-level syscons code (ie sc(4) itself) has been attached to the ISA bus and is identified/probed as an ISA device. I had to break the artificial dependency to get syscons working (with the supprt of a PCI VGA wannabe driver). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 14:53:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C953637B401 for ; Mon, 24 Feb 2003 14:53:26 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9051643FCB for ; Mon, 24 Feb 2003 14:53:25 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1OMrP1o044361; Mon, 24 Feb 2003 14:53:25 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1OMrOWk001177; Mon, 24 Feb 2003 14:53:24 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1OMrONE001176; Mon, 24 Feb 2003 14:53:24 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 14:53:24 -0800 From: Marcel Moolenaar To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030224225324.GB1032@athlon.pn.xcllnt.net> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <3E59E8F4.884C9160@mindspring.com> <20030224100336.GB21088@athlon.pn.xcllnt.net> <3E59F665.DCD54EAF@mindspring.com> <20030224191209.GA559@athlon.pn.xcllnt.net> <3E5A9777.F951598@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5A9777.F951598@mindspring.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 02:06:47PM -0800, Terry Lambert wrote: > > > I think people need to fact the fact that i386 is the FreeBSD > > > reference platform, and all other platforms are second class > > > citizens. > > > > Our i386 platform is still the best maintained and supported. > > This however doesn't contribute anything to a possible solution > > other than to indicate that a i386 centric solution at the > > cost of non-i386 platforms is acceptable. I disagree... > > So do I, which is why I believe *everything* should be present by > default, and have to be "commented out" on a per platform basis. I think a scheme to create a couple of buckets and define the inclusion or exclusion based on those buckets generally scales better. We already have that now in the form of MI/MD buckets, but this scheme does not work well, because drivers hardly ever are truly MI and/or truly MD. > This also gives control to the platform maintainer over the decision > of whether or not they are going to make something work on, for > example, the PPC, or if they are going to add a "nodevice" entry to > the /sys/ppc/conf/NOTES file to dike it out -- *only for the PPC*. I think in practice that platform maintainers will base their decision on the busses to which a driver can attach. I for one don't know how else to determine if a driver can work on a particular platform. One might as well use a system that does this by design (or allows this to be done by policy) and thus avoid X platform maintainers (given X platforms) to have to make the deduction manually. > This also supports the philosophy that *you* stated, at one point, > where if something is a PCI driver, it should be present on all > PCI systems, except those it specifically is known to not work on. The condition "if something is a PCI driver" is already a selection that has happened before the "nodevice" filtering. people object to having such an a priori selection and propose a solution on nodevice only. I argue that the preselection is good. I did not state that I reject nodevice as a mechanism to handle the exception, although I did state that nodevice is flawed in that it doesn't deal with options and hints. > If maintaining these per-architecture "nodevice" lists starts to > become cumbersome, then there's an easy answer: attract more > volunteers for that platform, and start fixing the drivers to > make them work, so you can remove the "nodevice" lines. I think this is unrealistic and I think that we only have to look at the current state of affairs and our history (or the history of drivers) to see the proof of it. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 15:25:56 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 378C237B401 for ; Mon, 24 Feb 2003 15:25:53 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 778B543FA3 for ; Mon, 24 Feb 2003 15:25:52 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0300.cvx22-bradley.dialup.earthlink.net ([209.179.199.45] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nRym-0004KD-00; Mon, 24 Feb 2003 15:25:49 -0800 Message-ID: <3E5AA9AC.64576E06@mindspring.com> Date: Mon, 24 Feb 2003 15:24:28 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES References: <20030224001644.GA67255@dragon.nuxi.com> <20030224120037.D4403-100000@gamplex.bde.org> <20030224023118.GD67312@dragon.nuxi.com> <3E59E8F4.884C9160@mindspring.com> <20030224100336.GB21088@athlon.pn.xcllnt.net> <3E59F665.DCD54EAF@mindspring.com> <20030224191209.GA559@athlon.pn.xcllnt.net> <3E5A9777.F951598@mindspring.com> <20030224225324.GB1032@athlon.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ea4c80fe2d99fc9996861311edd62cf02601a10902912494350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > On Mon, Feb 24, 2003 at 02:06:47PM -0800, Terry Lambert wrote: > > So do I, which is why I believe *everything* should be present by > > default, and have to be "commented out" on a per platform basis. > > I think a scheme to create a couple of buckets and define the > inclusion or exclusion based on those buckets generally scales > better. We already have that now in the form of MI/MD buckets, > but this scheme does not work well, because drivers hardly > ever are truly MI and/or truly MD. This isn't really a scalability issue. If the default case is accepted to be "supported if the bus it attaches to is supported", then the files are going to be small because the exception matrix is going to be very sparse. > > This also gives control to the platform maintainer over the decision > > of whether or not they are going to make something work on, for > > example, the PPC, or if they are going to add a "nodevice" entry to > > the /sys/ppc/conf/NOTES file to dike it out -- *only for the PPC*. > > I think in practice that platform maintainers will base their > decision on the busses to which a driver can attach. I for one > don't know how else to determine if a driver can work on a > particular platform. The base case is "compile it on the platform". The case that was the start of this thread was making SPARC64 LINT cleanly. I don't know if this was a result of "make universe" on an i386, or a "make world" on a SPARC64, though I suspect the latter. The next case is "turn it off if the kernel panic's in that code over an alignment error or some other problem". I don't think that there's any way short of running to catch runtime problems. The "turn it off" case should only be on a compilation failure, or a runtime failure when the hardware isn't present, or a runtime failure when the hardware *is* present... in that order. I view a "nodevice" entry in one of these files as nothing more than a comment that says "This needs to be worked on, but rather than work on it, I'm going to ignore it for now and work on something else I consider more important, such as rolling a release without bt(4) support at this time". There's really no other excuse for having a "nodevice" at all, if the thing is truly not architecture specific. > One might as well use a system that does > this by design (or allows this to be done by policy) and thus > avoid X platform maintainers (given X platforms) to have to make > the deduction manually. That would be nice, but you can't catch alignment errors, except at runtime. The only two choices there are: (1) turn on the bit in 486/586 to make it bit about alignment or (2) fixup all alignment errors by default on platforms that cause alignment faults. > > This also supports the philosophy that *you* stated, at one point, > > where if something is a PCI driver, it should be present on all > > PCI systems, except those it specifically is known to not work on. > > The condition "if something is a PCI driver" is already a selection > that has happened before the "nodevice" filtering. people object > to having such an a priori selection and propose a solution on > nodevice only. I argue that the preselection is good. I did not > state that I reject nodevice as a mechanism to handle the exception, > although I did state that nodevice is flawed in that it doesn't > deal with options and hints. Options and hints are only an issue when a namespace collision occurs. This may be an issue at some point in the future, but it is not an issue now. For sure, it will be caught as a different problem altogether, if the global definition is shadowed by an architecture specific definition, in any case, so it will be caught (i.e. you have to have a bus designator to have a hint). Personally, I *like* the idea that "everything is expected to work everywhere, and exceptions to this rule require explicitly noted exceptions", which is what comes out of making it a set of global rules with exceptions, rather than a set of per platform rules. > > If maintaining these per-architecture "nodevice" lists starts to > > become cumbersome, then there's an easy answer: attract more > > volunteers for that platform, and start fixing the drivers to > > make them work, so you can remove the "nodevice" lines. > > I think this is unrealistic and I think that we only have to look > at the current state of affairs and our history (or the history > of drivers) to see the proof of it. Give away PPC code commit bits in crackerjack boxes. If you are having trouble getting PPC volunteers, lower the bar on what it takes for the project to permit someone to volunteer in that area. If you want to argue history, we're back to acknowledging that non-i386 platforms are second class citizens. You *can't* reasonably expect me to make a driver work on hardware I don't own, if I'm a driver writer. I don't care if it *is* "PCI", I'm not going to catch alignment problems if my hardware doesn't catch alignment problems, and I'm not going to be able to write PPC or Alpha asm() statements, just because I can do them for i386. The *best* you can *possibly* hope for is that I'll have 1TB of disk an a 3THz processor lying around, and be willing to do a "make universe" to check and see if it at least compiles (that's an exaggeration, but it's one based in fact: most people do not have the resources to do a "make universe" as a compilability test for a new driver). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 16:49:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0F6137B401 for ; Mon, 24 Feb 2003 16:49:39 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CFBB43F93 for ; Mon, 24 Feb 2003 16:49:39 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1P0nb3Y092542 for ; Mon, 24 Feb 2003 17:49:37 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 24 Feb 2003 17:47:42 -0700 (MST) Message-Id: <20030224.174742.21056478.imp@bsdimp.com> To: arch@freebsd.org Subject: Fw: Proposed new sysctl MIB nodes From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Feb_24_17:47:42_2003_356)--" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----Next_Part(Mon_Feb_24_17:47:42_2003_356)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jason makes a good suggestion. Comments? Warner ----Next_Part(Mon_Feb_24_17:47:42_2003_356)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Delivery-Date: Mon, 24 Feb 2003 17:10:02 -0700 Received: from rover.village.org (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1P09u3Y092353 for ; Mon, 24 Feb 2003 17:09:56 -0700 (MST) (envelope-from owner-bsd-api-discuss+imp=harmony.village.org@wasabisystems.com) Received: from mononoke.wasabisystems.com (mononoke.wasabisystems.com [166.84.0.13]) by rover.village.org (8.12.5/8.12.3) with ESMTP id h1P09seJ015436 for ; Mon, 24 Feb 2003 17:09:55 -0700 (MST) (envelope-from owner-bsd-api-discuss+imp=harmony.village.org@wasabisystems.com) Received: by mononoke.wasabisystems.com (Postfix, from userid 96) id 301A35E44A; Mon, 24 Feb 2003 19:09:52 -0500 (EST) X-Original-To: bsd-api-discuss@wasabisystems.com Delivered-To: bsd-api-discuss@wasabisystems.com Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mononoke.wasabisystems.com (Postfix) with ESMTP id C9DC95E447 for ; Mon, 24 Feb 2003 19:09:51 -0500 (EST) Received: by snark.piermont.com (Postfix, from userid 1000) id A869BD97C5; Mon, 24 Feb 2003 19:09:45 -0500 (EST) X-Original-To: bsd-api-discuss@wasabisystems.com Received: from yeah-baby.shagadelic.org (yeah-baby.shagadelic.org [208.176.2.162]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 2820D5E441 for ; Mon, 24 Feb 2003 18:59:30 -0500 (EST) Received: by yeah-baby.shagadelic.org (Postfix, from userid 2158) id AE52A7DB0; Mon, 24 Feb 2003 15:59:26 -0800 (PST) Date: Mon, 24 Feb 2003 15:59:26 -0800 From: Jason R Thorpe To: bsd-api-discuss@wasabisystems.com Subject: Proposed new sysctl MIB nodes Message-ID: <20030224235926.GA22177@yeah-baby.shagadelic.org> Mail-Followup-To: Jason R Thorpe , bsd-api-discuss@wasabisystems.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Organization: Wasabi Systems, Inc. Sender: owner-bsd-api-discuss@wasabisystems.com Precedence: bulk X-Spam-Status: No, hits=-9.9 required=5.0 tests=NOSPAM_INC,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02, TO_BE_REMOVED_REPLY,USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: The GCC folks have recently started using the HW_PHYSMEM and HW_USERMEM sysctl MIB nodes to tune the behavior of the garbage collecting memory allocator in GCC. It was pointed out there that these totally fall over with >=4G of RAM, since it's a 32-bit quantity that returns the number of bytes. I'd like to propose new HW_PHYSPAGES and HW_USERPAGES MIB nodes that return the same information, but in a 32-bit page count, instead. The implementation is left as an exercise to the reader. I just want to get consensus on the names, so that I can tell the GCC people about it, and have it work on all the BSD platforms (as their current sysctl code does). -- -- Jason R. Thorpe --------------------------------------------------------------------- The BSD APIs Discussion Mailing List To unsubscribe: send "unsubscribe bsd-api-discuss" to majordomo@wasabisystems.com ----Next_Part(Mon_Feb_24_17:47:42_2003_356)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 16:55:56 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35B1E37B405 for ; Mon, 24 Feb 2003 16:55:55 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA23A43F85 for ; Mon, 24 Feb 2003 16:55:53 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0030.cvx22-bradley.dialup.earthlink.net ([209.179.198.30] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nTNp-0005Ql-00; Mon, 24 Feb 2003 16:55:46 -0800 Message-ID: <3E5ABEBE.5D036BE7@mindspring.com> Date: Mon, 24 Feb 2003 16:54:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: arch@freebsd.org Subject: Re: Fw: Proposed new sysctl MIB nodes References: <20030224.174742.21056478.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a46760937c19e979fb1de84ec8026a619e387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > > Jason makes a good suggestion. Comments? How big is a page? 8-). Seems you'd need that MIB entry, too... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 16:59:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D40A637B401 for ; Mon, 24 Feb 2003 16:59:20 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7B6443FBF for ; Mon, 24 Feb 2003 16:59:19 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1P0xC1o044875; Mon, 24 Feb 2003 16:59:12 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1P0xCWk001613; Mon, 24 Feb 2003 16:59:12 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1P0xCx8001612; Mon, 24 Feb 2003 16:59:12 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 16:59:12 -0800 From: Marcel Moolenaar To: "M. Warner Losh" Cc: arch@FreeBSD.ORG Subject: Re: Fw: Proposed new sysctl MIB nodes Message-ID: <20030225005912.GA1583@athlon.pn.xcllnt.net> References: <20030224.174742.21056478.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224.174742.21056478.imp@bsdimp.com> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 05:47:42PM -0700, M. Warner Losh wrote: > > From: Jason R Thorpe > > I'd like to propose new HW_PHYSPAGES and HW_USERPAGES MIB nodes that > return the same information, but in a 32-bit page count, instead. The > implementation is left as an exercise to the reader. I just want to get > consensus on the names, so that I can tell the GCC people about it, and > have it work on all the BSD platforms (as their current sysctl code does). What's the reason to not use a 64-bit entity whether it represents bytes or pages? Or to be more presice, an integral entity that can be used to cast to from a pointer without data loss? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 17:32:18 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 306BD37B401 for ; Mon, 24 Feb 2003 17:32:15 -0800 (PST) Received: from purple.the-7.net (purple.the-7.net [209.126.178.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29CAC43F3F for ; Mon, 24 Feb 2003 17:32:14 -0800 (PST) (envelope-from ab@purple.the-7.net) Received: from purple.the-7.net (localhost [IPv6:::1]) by purple.the-7.net (8.12.6/8.12.6) with ESMTP id h1P1WAmV021315 for ; Mon, 24 Feb 2003 17:32:10 -0800 (PST) (envelope-from ab@purple.the-7.net) Received: (from ab@localhost) by purple.the-7.net (8.12.6/8.12.6/Submit) id h1P1WAsS021314 for freebsd-arch@FreeBSD.ORG; Mon, 24 Feb 2003 17:32:10 -0800 (PST) (envelope-from ab) Date: Mon, 24 Feb 2003 17:32:10 -0800 From: "Eugene M. Kim" To: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES Message-ID: <20030225013210.GA21089@purple.the-7.net> References: <8287.1046068366@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-IMAPbase: 1046136501 3 X-UID: 3 X-Spam-Status: No, hits=-1.1 required=5.0 tests=PRIORITY_NO_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY,USER_AGENT, USER_AGENT_MUTT version=2.44 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have this creepy feeling that I may be just blindly retracking a well-explored path, but how about adopting and extending the model we already use for our ports tree, i.e.: o Each part of the kernel is reorganized into a module which: - Provides one or more features, - (Optionally) requires a list of other features, and - (Optionally) refuses to compile or load when some features are already present. o This `feature description' resides in a separate file along with the module source files. Feature files shall follow a consistent naming convention (*.feature for example). o The kernel configurator scans the kernel source tree for these feature files to construct the global feature database. This eliminates the need for manual maintenance of a monolithic feature database file. o A feature is uniquely identified by a string. o Each module has at least one globally unique feature identifier. The kernel configurator shall generate an error if it finds, after scanning the source tree, multiple modules that declares the same unique provider. o Multiple modules can provide the same feature, but only one of those modules can be compiled in and/or loaded at the same time. For example, features "ule-scheduler" and "4bsd-scheduler" could both provide the "scheduler" feature, and features "i386-machine" and "alpha-machine" could both provide the "machine" feature. o A module can declare itself as a default feature provider. For example, "4bsd-scheduler" can be the default provider of "scheduler" feature. The kernel configurator shall generate an error if it finds multiple default providers for the same feature. o There are two kinds of dependencies; strong versus weak. o Strong dependency prevents the module from being compiled/loaded if the dependency can't be met (by compiling in or loading the required module). o Weak dependency permits the module to be compiled/loaded even if the dependency can't be met. o A `metafeature' is a feature that contains no actual code but a list of other required features (analogous to metaports). For example, "snd" would require (through weak dependencies) on "snd-pcm" and bunch of other soundcard driver modules. These are as much as I can think up now. Anyhow, the goal here is to come up with a framework that can handle not just platform dependencies but also intermodule dependencies. Thanks, Eugene ----- Original Message ----- From: To: Sent: Sunday, February 23, 2003 10:32 PM Subject: Re: [RFC] splitting of conf/NOTES > > I am violently in favour of having compilable LINT kernels on all > platforms, but I do not like the path we are heading down splitting > NOTES into per feature files: It does not solve the fundamental > problem and it simply does not scale in the long term. > > Part of the fundamental problem is that a single LINT kernel, even > per architecture is not able to test both branches of an > #ifdef/#else/#endif construct. > > Generating a LINT1 and LINT2 per architecture would give us much > better code coverage. > > Going down the path of NOTES.this and NOTES.that does not help us > solve this problem becuase it does not capture the information we > need to know, but it does take us down a path of total fragmentation > into umpteen files which nobody will have any kind of overview off > how is stuck together in a few months time. > > There are two ways to do this right: Either one large or strictly > per feature information files which capture the knowledge today > captured in GENERIC/NOTES, conf/options* and conf/files* and in > addition contains the bits of information we need to generate > correct LINT files per architecture. > > I would personally prefer that it be strictly per-feature files > since huge files tend to become unmanagable as well. > > I am not going to raise a bikeshed about the format of said files, > I'll just leave my bucket of blue paint here for those who will do > the bikeshed. > > Summary: > > 1. Strictly per feature files, not "adhoc groupings" > > 2. Much more expressive format than NOTES needed. > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 17:54:12 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93A4A37B401 for ; Mon, 24 Feb 2003 17:54:11 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D311143FBD for ; Mon, 24 Feb 2003 17:54:10 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.7/8.12.7) with ESMTP id h1P1s43q022548; Mon, 24 Feb 2003 20:54:04 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030225005912.GA1583@athlon.pn.xcllnt.net> References: <20030224.174742.21056478.imp@bsdimp.com> <20030225005912.GA1583@athlon.pn.xcllnt.net> Date: Mon, 24 Feb 2003 20:54:03 -0500 To: Marcel Moolenaar , "M. Warner Losh" From: Garance A Drosihn Subject: Re: Fw: Proposed new sysctl MIB nodes Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-Spam-Score: -1.7 () IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 4:59 PM -0800 2/24/03, Marcel Moolenaar wrote: >On Mon, Feb 24, 2003 at 05:47:42PM -0700, M. Warner Losh wrote: >> >> From: Jason R Thorpe >> > > I'd like to propose new HW_PHYSPAGES and HW_USERPAGES MIB nodes > > that return the same information, but in a 32-bit page count, > > instead. The implementation is left as an exercise to the reader. > > I just want to get consensus on the names, so that I can tell > > the GCC people about it, and have it work on all the BSD > > platforms (as their current sysctl code does). > >What's the reason to not use a 64-bit entity whether it represents >bytes or pages? > >Or to be more presice, an integral entity that can be used to cast >to from a pointer without data loss? Jason first asked his question on the bsd-api mailing list (which hopefully has people from all the main BSD's on it). In a later message on that mailing list, he replied to a similar question: > How about simply having a total memory count in quads > instead? That way we won't run out when we pass 2^48 > or 49th bytes in 10 or 15 years. Ok, a u_quad (page count) it is. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 18:13: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5082637B401 for ; Mon, 24 Feb 2003 18:13:07 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DB1143FD7 for ; Mon, 24 Feb 2003 18:13:03 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1P2CY1o045159; Mon, 24 Feb 2003 18:12:34 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1P2CYWk001868; Mon, 24 Feb 2003 18:12:34 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1P2CY0j001867; Mon, 24 Feb 2003 18:12:34 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 18:12:34 -0800 From: Marcel Moolenaar To: Garance A Drosihn Cc: "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Fw: Proposed new sysctl MIB nodes Message-ID: <20030225021234.GA1835@athlon.pn.xcllnt.net> References: <20030224.174742.21056478.imp@bsdimp.com> <20030225005912.GA1583@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 08:54:03PM -0500, Garance A Drosihn wrote: > > > I'd like to propose new HW_PHYSPAGES and HW_USERPAGES MIB nodes > > > that return the same information, but in a 32-bit page count, > > > instead. The implementation is left as an exercise to the reader. > > > I just want to get consensus on the names, so that I can tell > > > the GCC people about it, and have it work on all the BSD > > > platforms (as their current sysctl code does). > > > >What's the reason to not use a 64-bit entity whether it represents > >bytes or pages? > > > >Or to be more presice, an integral entity that can be used to cast > >to from a pointer without data loss? > > Jason first asked his question on the bsd-api mailing list (which > hopefully has people from all the main BSD's on it). In a later > message on that mailing list, he replied to a similar question: > > > How about simply having a total memory count in quads > > instead? That way we won't run out when we pass 2^48 > > or 49th bytes in 10 or 15 years. > > Ok, a u_quad (page count) it is. This isn't really a similar question. On 64-bit machines it's rather odd to use a 32-bit entity to hold the amount of memory. The most logical step is to make it a 64-bit entity, not to increase the granularity. Also, why a sysctl to get the total amount of memory in the box. Isn't getrlimit a much better approach to tune process behaviour? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 19:50:56 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29BBA37B401 for ; Mon, 24 Feb 2003 19:50:55 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26DB743F3F for ; Mon, 24 Feb 2003 19:50:54 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.7/8.12.7) with ESMTP id h1P3oo0H027665; Mon, 24 Feb 2003 22:50:51 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030225021234.GA1835@athlon.pn.xcllnt.net> References: <20030224.174742.21056478.imp@bsdimp.com> <20030225005912.GA1583@athlon.pn.xcllnt.net> <20030225021234.GA1835@athlon.pn.xcllnt.net> Date: Mon, 24 Feb 2003 22:50:49 -0500 To: Marcel Moolenaar From: Garance A Drosihn Subject: Re: Fw: Proposed new sysctl MIB nodes Cc: "M. Warner Losh" , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-Spam-Score: -1.7 () IN_REP_TO,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 6:12 PM -0800 2/24/03, Marcel Moolenaar wrote: >On Mon, Feb 24, 2003, Garance A Drosihn wrote: > > Jason first asked his question on the bsd-api mailing list (which >> hopefully has people from all the main BSD's on it). In a later >> message on that mailing list, he replied to a similar question: >> >> > How about simply having a total memory count in quads >> > instead? That way we won't run out when we pass 2^48 >> > or 49th bytes in 10 or 15 years. >> >> Ok, a u_quad (page count) it is. > >This isn't really a similar question. On 64-bit machines it's rather >odd to use a 32-bit entity to hold the amount of memory. The most >logical step is to make it a 64-bit entity, not to increase the >granularity. > >Also, why a sysctl to get the total amount of memory in the box. >Isn't getrlimit a much better approach to tune process behaviour? Well, I was just passing along the comment from the other mailing list. I'm not sure what's the best solution for the problem that Jason is hoping to solve, but I do like the idea that it would be good if all BSD's provide the same solution, so that people outside the BSD world can cover all the BSD's with a single change. Jason is asking on the bsd-api-discuss@wasabisystems.com mailing list. I assume people could get onto it by sending "subscribe bsd-api-discuss" to majordomo@wasabisystems.com -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 19:54:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 660EE37B401 for ; Mon, 24 Feb 2003 19:54:29 -0800 (PST) Received: from espresso.bsdmike.org (espresso.bsdmike.org [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBAD843F85 for ; Mon, 24 Feb 2003 19:54:28 -0800 (PST) (envelope-from mike@espresso.bsdmike.org) Received: by espresso.bsdmike.org (Postfix, from userid 1002) id 310DD9C5F; Mon, 24 Feb 2003 22:41:54 -0500 (EST) Date: Mon, 24 Feb 2003 22:41:54 -0500 From: Mike Barcroft To: Marcel Moolenaar Cc: Garance A Drosihn , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Fw: Proposed new sysctl MIB nodes Message-ID: <20030224224154.F61907@espresso.bsdmike.org> References: <20030224.174742.21056478.imp@bsdimp.com> <20030225005912.GA1583@athlon.pn.xcllnt.net> <20030225021234.GA1835@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030225021234.GA1835@athlon.pn.xcllnt.net>; from marcel@xcllnt.net on Mon, Feb 24, 2003 at 06:12:34PM -0800 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Marcel Moolenaar writes: > Also, why a sysctl to get the total amount of memory in the box. > Isn't getrlimit a much better approach to tune process behaviour? Good point, a process may also have resource limits, so the system memory is almost irrelevant. Too bad we don't support the standardized RLIMIT_AS option for getrlimit(). Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 20:11:45 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A39937B401 for ; Mon, 24 Feb 2003 20:11:43 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8347243F3F for ; Mon, 24 Feb 2003 20:11:42 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.7/8.12.7) with ESMTP id h1P4Bf0H029509; Mon, 24 Feb 2003 23:11:41 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Mon, 24 Feb 2003 23:11:40 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: NEWSYSLOG changes Cc: Wes Peters Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-Spam-Score: 0.2 () SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I sent this message about two hours ago, but it seems to have just disappeared. I'll send it again, but this time I'll include a URL to the patch instead of including the whole patch in the message... At 11:35 PM -0500 2/20/03, Garance A Drosihn wrote: >What follows is part #1 of what I plan to do. This adds the >notion of a "default rotation action" to newsyslog. This >action will *only* be significant when newsyslog is run with >a specific list of filenames. The patch from the earlier message has been committed to -current. No man page yet, but I'll do that before MFC'ing any of this. >I'll soon have a second update, which will implement "-R requestor", >which Wes could then take advantage of with his syslog changes. Here is the second patch. This implements a -R option, where -R requires a name of the requestor, and it also requires that a list of filenames to rotate was given on the newsyslog command. Right now the "requestor" is only used in the message added to (non-binary) log files. The idea of -R is that newsyslog should always rotate the given list of files, whether or not *it* thinks they need to be rotated. It is only being used to govern how each of the files are rotated (such as gzip vs bzip2, and how many backup copies to keep). For now it is assumed that the caller is the same process which usually writes to the file, and thus it does NOT use the pid_file to signal that process. The whole idea of this is to let Wes change syslogd to use this, and it would be silly for newsyslog to HUP syslogd when it's syslogd that is requesting the rotate. It may be that we should handle the pid-file signalling a different way. This is meant to be the "minimal change that gets the job done". I expect to make additional changes to newsyslog which will clean this up a bit more (while cleaning up some other things too). Let me know if there are any better ideas for this. I'll probably commit this on Thursday night unless there's some objections, or if someone wants some more time to think about it. I have only tested this a little bit, so I may also delay until Sunday if I haven't had time to do testing between now and Thursday. The patch is available at: http://people.freebsd.org/~gad/newsyslog/option-R.diff -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 20:51:52 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 952B437B401 for ; Mon, 24 Feb 2003 20:51:51 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B582F43FBD for ; Mon, 24 Feb 2003 20:51:50 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1P4ph1o045732; Mon, 24 Feb 2003 20:51:43 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1P4phWk002318; Mon, 24 Feb 2003 20:51:43 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1P4phhY002317; Mon, 24 Feb 2003 20:51:43 -0800 (PST) (envelope-from marcel) Date: Mon, 24 Feb 2003 20:51:43 -0800 From: Marcel Moolenaar To: Garance A Drosihn Cc: "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Fw: Proposed new sysctl MIB nodes Message-ID: <20030225045143.GB2290@athlon.pn.xcllnt.net> References: <20030224.174742.21056478.imp@bsdimp.com> <20030225005912.GA1583@athlon.pn.xcllnt.net> <20030225021234.GA1835@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 24, 2003 at 10:50:49PM -0500, Garance A Drosihn wrote: > > Jason is asking on the bsd-api-discuss@wasabisystems.com > mailing list. I assume people could get onto it by sending > "subscribe bsd-api-discuss" to majordomo@wasabisystems.com Thanks for the pointer. Subscribing now... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 21:36: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B839437B401 for ; Mon, 24 Feb 2003 21:35:58 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78CD943F93 for ; Mon, 24 Feb 2003 21:35:57 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA15427; Tue, 25 Feb 2003 16:35:46 +1100 Date: Tue, 25 Feb 2003 16:37:05 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar Cc: "M. Warner Losh" , Subject: Re: Fw: Proposed new sysctl MIB nodes In-Reply-To: <20030225005912.GA1583@athlon.pn.xcllnt.net> Message-ID: <20030225160527.W9462-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Feb 2003, Marcel Moolenaar wrote: > On Mon, Feb 24, 2003 at 05:47:42PM -0700, M. Warner Losh wrote: > > > > From: Jason R Thorpe > > > > I'd like to propose new HW_PHYSPAGES and HW_USERPAGES MIB nodes that > > return the same information, but in a 32-bit page count, instead. The > > implementation is left as an exercise to the reader. I just want to get > > consensus on the names, so that I can tell the GCC people about it, and > > have it work on all the BSD platforms (as their current sysctl code does). > > What's the reason to not use a 64-bit entity whether it represents > bytes or pages? Under FreeBSD, the sysctl return an unsigned long, so they already return a 64-bit entity on machines which happen to have 64-bit longs. Under NetBSD, the sysctls return a 32-bit signed int, so they only already return 64 non-overflowing bits on machines which happen to have 65-bit ints. This gives the following pedantic wrongness for always using a 64-bit entity for bytes: On machines with 32-bit longs: Returning a 64-bit entity would mainly be a micropessimization. On machines with 64-bit longs: A 64-bit entity is already returned under FreeBSD. This is already incompatible with NetBSD, but correctly-written applications shouldn't notice -- they should read scalar values into a union or something (yes, this is messy to code; there is no portable way to convert the size returned by sysctl to a type, and the correct type is not even documented in sysctl(3) (it says that HW.PHYSMEM returns an "integer" and doesn't say that an "integer" can have almost any size). On machines with >64-bit longs: Returning a 64-bit entity would be a regression on machines with more than 2^64 bytes of memory :-). > Or to be more presice, an integral entity that can be used to cast > to from a pointer without data loss? That would be more bogus than returning a plain u_long, since u_long was the largest scalar type, but the size needed to count main memory is unrelated to the number of bits in a pointer. In practice, u_long is the same as uintptr_t on most machines, but that doesn't make it right for counting main memory since all of main memory might not be mappable (e.g., on i386's with PAE support). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 21:55: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A5FC37B401; Mon, 24 Feb 2003 21:55:00 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id E13C143F3F; Mon, 24 Feb 2003 21:54:59 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.6/8.12.6) id h1P5ss5E015032; Mon, 24 Feb 2003 23:54:54 -0600 (CST) (envelope-from dan) Date: Mon, 24 Feb 2003 23:54:54 -0600 From: Dan Nelson To: Mike Barcroft Cc: Marcel Moolenaar , Garance A Drosihn , "M. Warner Losh" , arch@FreeBSD.ORG Subject: Re: Proposed new sysctl MIB nodes Message-ID: <20030225055454.GC20064@dan.emsphone.com> References: <20030224.174742.21056478.imp@bsdimp.com> <20030225005912.GA1583@athlon.pn.xcllnt.net> <20030225021234.GA1835@athlon.pn.xcllnt.net> <20030224224154.F61907@espresso.bsdmike.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224224154.F61907@espresso.bsdmike.org> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Feb 24), Mike Barcroft said: > Marcel Moolenaar writes: > > Also, why a sysctl to get the total amount of memory in the box. > > Isn't getrlimit a much better approach to tune process behaviour? > > Good point, a process may also have resource limits, so the system > memory is almost irrelevant. Too bad we don't support the > standardized RLIMIT_AS option for getrlimit(). Anyone know the difference between our RLIMIT_VMEM and SUSv3's RLIMIT_AS? Unfortunately, RLIMIT_VMEM went into 4.7, so we can't just rename it to RLIMIT_AS... -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Feb 24 22:19:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78D0F37B401 for ; Mon, 24 Feb 2003 22:19:25 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9447643FBF for ; Mon, 24 Feb 2003 22:19:12 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1P6J1Ev012095; Tue, 25 Feb 2003 07:19:07 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: "M. Warner Losh" Cc: arch@FreeBSD.ORG Subject: Re: Fw: Proposed new sysctl MIB nodes From: phk@phk.freebsd.dk In-Reply-To: Your message of "Mon, 24 Feb 2003 17:47:42 MST." <20030224.174742.21056478.imp@bsdimp.com> Date: Tue, 25 Feb 2003 07:19:01 +0100 Message-ID: <12094.1046153941@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20030224.174742.21056478.imp@bsdimp.com>, "M. Warner Losh" writes: >The GCC folks have recently started using the HW_PHYSMEM and HW_USERMEM >sysctl MIB nodes to tune the behavior of the garbage collecting memory >allocator in GCC. It was pointed out there that these totally fall over >with >=4G of RAM, since it's a 32-bit quantity that returns the number >of bytes. > >I'd like to propose new HW_PHYSPAGES and HW_USERPAGES MIB nodes that >return the same information, but in a 32-bit page count, instead. The >implementation is left as an exercise to the reader. I just want to get >consensus on the names, so that I can tell the GCC people about it, and >have it work on all the BSD platforms (as their current sysctl code does). Makes sense I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 25 6:33:45 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 181C437B401; Tue, 25 Feb 2003 06:33:44 -0800 (PST) Received: from freebsd.org (TN218-187-123-89.2-3.pl.apol.com.tw [218.187.123.89]) by mx1.FreeBSD.org (Postfix) with SMTP id 1CCA143FD7; Tue, 25 Feb 2003 06:33:17 -0800 (PST) (envelope-from 223833@freebsd.org) From: =?Big5?B?p9qmYrRNp+QuLi4uLi4u?= Subject: =?Big5?B?p0G3UcX9rmGkSLlMp/Ombqq6pc2sobbcPw==?= Content-Type: text/html Date: Tue, 25 Feb 2003 22:22:08 +0800 X-Priority: 3 X-Library: Indy 9.0.3-B Message-Id: <20030225143317.1CCA143FD7@mx1.FreeBSD.org> To: undisclosed-recipients: ; Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG І`©]1ВI¤F

І`©]1ВI¤F

Ѕц¦b§Й¤WЄє§Ъ¤ЈВ_Єє«дЇБ...µLЄk¤JєО

ёЈ¤¤ҐXІ{Єє¬O¤чҐАїЛЇhѕОЄєЁ­Ей...

§ЪєО¤ЈµЫ...єО¤ЈµЫ.......

ґїёg...§ЪёШ¤U®ь¤f­nЕэҐL­М№L¦n¤й¤l

Ґi¬O·LБЎБ~¤ф«oµLЄkЕэ§Ъјi¦ж©УїХ

ґX­У¤л«e...§Ъ±µДІЁм¤F¤@¤щҐъєР...

µuµuЄє40ґX¤АДБ...§Ъ¬ЭЁм¤F§Ж±ж

§Ъ¤@ЁB¤@ЁBЄє¦b№пЄє¦a¤и¬°®a§V¤O

¦У§ЪЄє©УїХ¤]±N§IІ{

¦pЄG§A¤]·QЕэ®a¤H№L§у¦nЄєҐН¬Ў

ЅРЇd¤Uёк®Ж,§Ъ±N§віo¤щҐъєР±Hµ№§A

§Ъ«OГТ,Ґu­n§A¬ЭАґ¤F,¤@©w·|¬°§A¶}±Т«GДRЄє¤HҐН

©m¦W
©m§O
¦~ДЦ
®a¤¤№qёЬ
¦ж°К№qёЬ
¶l±H¦a§}
¶l»ј°Пё№
ЅР±HЁмpop99917@yahoo.com.tw

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 25 8:10: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 968D637B401 for ; Tue, 25 Feb 2003 08:09:59 -0800 (PST) Received: from espresso.bsdmike.org (espresso.bsdmike.org [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87D0E43FB1 for ; Tue, 25 Feb 2003 08:09:58 -0800 (PST) (envelope-from mike@espresso.bsdmike.org) Received: by espresso.bsdmike.org (Postfix, from userid 1002) id C1D209C5F; Tue, 25 Feb 2003 10:57:22 -0500 (EST) Date: Tue, 25 Feb 2003 10:57:22 -0500 From: Mike Barcroft To: freebsd-arch@freebsd.org Subject: Re: [RFC] Merging NOTES (was: Re: [RFC] splitting of conf/NOTES) Message-ID: <20030225105722.I61907@espresso.bsdmike.org> References: <20030224001644.GA67255@dragon.nuxi.com> <20030224112323.A61907@espresso.bsdmike.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224112323.A61907@espresso.bsdmike.org>; from mike@FreeBSD.org on Mon, Feb 24, 2003 at 11:23:23AM -0500 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Barcroft writes: > David O'Brien writes: > > I can now create a sparc64 LINT kernel with the patches at > > http://people.freebsd.org/~obrien/sp64notes.diff. The essence of this > > patch is to split sys/conf/NOTES into NOTES, NOTES.bt, NOTES.ext2fs, > > NOTES.ps2, NOTES.raid, and NOTES.syscons. Each /sys//conf/Makefile > > now looks like: > > Counter-proposal: > Merge all sys/*/conf/NOTES and sys/conf/NOTES into one file, and add > CPP parsing. Okay, I guess there's very little interest in my idea. David, please proceed with the nodevice keyword. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 25 9:53:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29E6D37B401 for ; Tue, 25 Feb 2003 09:53:43 -0800 (PST) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DED343F93 for ; Tue, 25 Feb 2003 09:53:41 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 4208 invoked from network); 25 Feb 2003 17:53:44 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Feb 2003 17:53:44 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h1PHqNhT020296; Tue, 25 Feb 2003 12:52:25 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030224.114405.41526431.imp@bsdimp.com> Date: Tue, 25 Feb 2003 12:53:49 -0500 (EST) From: John Baldwin To: "M. Warner Losh" Subject: Re: [RFC] splitting of conf/NOTES Cc: obrien@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 24-Feb-2003 M. Warner Losh wrote: > In message: <20030224172818.GA47872@dragon.nuxi.com> > "David O'Brien" writes: >: On Mon, Feb 24, 2003 at 06:03:15AM -0700, M. Warner Losh wrote: >: > I'd agree with this. All PCI devices are available for all platforms >: > that support PCI, as a general rule (exception to this rule will >: > likely be rare). Those exceptions can just be left out of the >: > NOTES.pci file. The exceptions are very likely to be MACHINE >: > dependent (some of the pc98 built-in chips are this way). >: >: I agree with this sentiment, and knowing nothing about the PC98 I don't >: understand why nyan took a lot of PCI cards (mostly RAID) out of the PC98 >: LINT. Do know why? > > No. The pc98 specific pci devices that I'm aware of tend not to have > drivers yet (some do, however). Maybe he didn't have the cards for > testing? Doesn't hurt to just make sure they compile. Look, folks, it doesn't hurt to compile all PCI drivers on all machines that support PCI. Yes, it might not be tested yet, but it should at least compile and link ok. LINT is about testing compiles. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 25 9:53:55 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1229B37B401 for ; Tue, 25 Feb 2003 09:53:54 -0800 (PST) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1C4C43FBD for ; Tue, 25 Feb 2003 09:53:52 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 20832 invoked from network); 25 Feb 2003 17:53:56 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Feb 2003 17:53:56 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h1PHqUhT020300; Tue, 25 Feb 2003 12:52:32 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030225160527.W9462-100000@gamplex.bde.org> Date: Tue, 25 Feb 2003 12:53:56 -0500 (EST) From: John Baldwin To: Bruce Evans Subject: Re: Fw: Proposed new sysctl MIB nodes Cc: arch@FreeBSD.ORG, "M. Warner Losh" , Marcel Moolenaar Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 25-Feb-2003 Bruce Evans wrote: > On Mon, 24 Feb 2003, Marcel Moolenaar wrote: > >> On Mon, Feb 24, 2003 at 05:47:42PM -0700, M. Warner Losh wrote: >> > >> > From: Jason R Thorpe >> > >> > I'd like to propose new HW_PHYSPAGES and HW_USERPAGES MIB nodes that >> > return the same information, but in a 32-bit page count, instead. The >> > implementation is left as an exercise to the reader. I just want to get >> > consensus on the names, so that I can tell the GCC people about it, and >> > have it work on all the BSD platforms (as their current sysctl code does). >> >> What's the reason to not use a 64-bit entity whether it represents >> bytes or pages? > > Under FreeBSD, the sysctl return an unsigned long, so they already > return a 64-bit entity on machines which happen to have 64-bit longs. > Under NetBSD, the sysctls return a 32-bit signed int, so they only > already return 64 non-overflowing bits on machines which happen to > have 65-bit ints. This gives the following pedantic wrongness for > always using a 64-bit entity for bytes: So the sysctl should be returning size_t's then? :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 25 12:55:57 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AFC337B405 for ; Tue, 25 Feb 2003 12:55:55 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id F01B243F75 for ; Tue, 25 Feb 2003 12:55:53 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id EE3E542FC3; Tue, 25 Feb 2003 12:55:51 -0800 (PST) From: Wes Peters Organization: Softweyr.com To: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes Date: Tue, 25 Feb 2003 12:55:48 -0800 User-Agent: KMail/1.5 References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302251255.48219.wes@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday 24 February 2003 18:08, Garance A Drosihn wrote: > At 11:35 PM -0500 2/20/03, Garance A Drosihn wrote: > > >I'll soon have a second update, which will implement "-R requestor", > >which Wes could then take advantage of with his syslog changes. > > Here is the second patch. This implements a -R option, where > -R requires a name of the requestor, and it also requires that > a list of filenames to rotate was given on the newsyslog command. > Right now the "requestor" is only used in the message added to > (non-binary) log files. > > The idea of -R is that newsyslog should always rotate the given > list of files, whether or not *it* thinks they need to be rotated. > It is only being used to govern how each of the files are rotated > (such as gzip vs bzip2, and how many backup copies to keep). Ah, good idea. We have the ability to "backup" a running system into a file that can be used to restore it later on. We'd like to essentially terminate all the log files in this backup and start the system with fresh logs. This change will help us do that as well. > For now it is assumed that the caller is the same process which > usually writes to the file, and thus it does NOT use the pid_file > to signal that process. The whole idea of this is to let Wes > change syslogd to use this, and it would be silly for newsyslog > to HUP syslogd when it's syslogd that is requesting the rotate. > It may be that we should handle the pid-file signalling a > different way. Uh, actually, syslogd needs the HUP to re-open the file. ;^) I can change that iff I run newsyslog -F, waiting for the "new" log file to appear. Let me think about how to best do that... Come to think of it, my current code doesn't do a very good job of reaping the child newsyslog processes. That's going to need some work anyhow, so I can probably do it there. I do like the idea of not needing a HUP signal between the two since syslogd started the newsyslog anyhow. I'll get this hacked up ASAP, then get some of these patches out for review. > This is meant to be the "minimal change that gets the job done". > I expect to make additional changes to newsyslog which will clean > this up a bit more (while cleaning up some other things too). > > Let me know if there are any better ideas for this. I'll probably > commit this on Thursday night unless there's some objections, or > if someone wants some more time to think about it. It sounds good to me. I'll review your patch, then dump it into my newsyslog for testing, so I can make sure I run newsyslog correctly. Thanks for the collaboration. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 25 16:18:15 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3386137B401 for ; Tue, 25 Feb 2003 16:18:14 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3604B43FA3 for ; Tue, 25 Feb 2003 16:18:13 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.7/8.12.7) with ESMTP id h1Q0I93q031964; Tue, 25 Feb 2003 19:18:09 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200302251255.48219.wes@softweyr.com> References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302251255.48219.wes@softweyr.com> Date: Tue, 25 Feb 2003 19:18:08 -0500 To: Wes Peters , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: NEWSYSLOG changes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-Spam-Score: -1.6 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:55 PM -0800 2/25/03, Wes Peters wrote: >On Monday 24 February 2003 18:08, Garance A Drosihn wrote: > > The idea of -R is that newsyslog should always rotate the given > > list of files, whether or not *it* thinks they need to be rotated. > > For now it is assumed that the caller is the same process which >> usually writes to the file, and thus it does NOT use the pid_file >> to signal that process. The whole idea of this is to let Wes >> change syslogd to use this, and it would be silly for newsyslog >> to HUP syslogd when it's syslogd that is requesting the rotate. >> It may be that we should handle the pid-file signalling a >> different way. > >Uh, actually, syslogd needs the HUP to re-open the file. ;^) > >I can change that iff I run newsyslog -F, waiting for the "new" >log file to appear. Let me think about how to best do that... Well, I'm seriously thinking of redoing the -R update a little, and have a separate option to say "do not signal". So, -R will still send the signal by default. Still, I'd think that syslogd would: close the logfile exec newsyslog -NR syslogd somefile wait for that to finish re-open the log file. If newsyslog does the HUP, then it is also going to sleep for something like 5 seconds, because it wants to be sure that the signaled-process has done all the processing it needs to do. >... I do like the idea of not needing a HUP signal between the >two since syslogd started the newsyslog anyhow. Also, wouldn't a HUP will cause all config-files to be re-read, and all log files to be closed and opened? That seems like a lot of unnecessary work. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 25 20:58: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD43937B401 for ; Tue, 25 Feb 2003 20:58:06 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id F308E43F3F for ; Tue, 25 Feb 2003 20:58:05 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.7/8.12.7) with ESMTP id h1Q4w40H017742; Tue, 25 Feb 2003 23:58:04 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302251255.48219.wes@softweyr.com> Date: Tue, 25 Feb 2003 23:58:02 -0500 To: Wes Peters , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: NEWSYSLOG changes, nosignal & -Rotate Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-Spam-Score: -0.8 () IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:18 PM -0500 2/25/03, Garance A Drosihn wrote: >Well, I'm seriously thinking of redoing the -R update a little, >and have a separate option to say "do not signal". I have two different updates now, to replace the one I previously posted. To avoid the problem where my messages sometimes disappear when I include the patch in them, here's the location of the two patches: http://people.freebsd.org/~gad/newsyslog/1-nosig.diff http://people.freebsd.org/~gad/newsyslog/2-rotate.diff The first one adds a '-s' option to the newsyslog command, which indicates that newsyslog should NOT send signals to any processes if it has to rotate some log files. It also adds the 'N' or 'n' option to the flags-field of entries in /etc/newsyslog.conf, which indicates that the specific entry has no process which needs to be signalled. For instance, right now the distributed newsyslog.conf file has entries for files like /var/log/daily.log, and I doubt that syslogd needs to be HUP'ed whenever that file is rotated. Both -s and the 'N' flag are based on options in NetBSD's version of newsyslog. I am tempted to pick some other option, say '-Q' plus 'Q' or 'q' for flags, so that the same letter will be used in the config file or when specified on the command. I would keep the netbsd letters, but only document the new letter. It would be very easy to talk me into doing this... The nosig patch includes a little cleanup in areas I was touching anway, which are done with an eye towards future updates (such as the -R update...). The second update is basically the same as my previous posting of the -R option, except that the newer implementation *does* send a signal by default. Callers of newsyslog who do not want the signal would add the '-s' (or '-Q'?) option. These updates have not been tested much. I intend to commit them next Sunday, assuming they work in my testing and no one has any additional feedback on them. They assume you're running the up-to-the-minute version of newsyslog in -current. newsyslog itself has a number of subtle and not-so-subtle bugs in it, so I expect to be writing up more updates after these. One bug which was cleaned up as part of the nosig patch is that it currently accepts either capital-G or lowercase-c (instead of lowercase-g) as the flags to indicate the entry is a glob-pattern. I still accept 'c', but warn about it. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 0:50:56 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E4E737B401 for ; Wed, 26 Feb 2003 00:50:55 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86F3443F93 for ; Wed, 26 Feb 2003 00:50:54 -0800 (PST) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <20030226085053003007dmtge>; Wed, 26 Feb 2003 08:50:53 +0000 Date: Wed, 26 Feb 2003 00:50:52 -0800 (PST) From: Doug Barton To: Marcel Moolenaar Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: Indiscriminately installing all .h files in /usr/include/* In-Reply-To: <20030211073011.GA576@dhcp01.pn.xcllnt.net> Message-ID: <20030226005003.O903@znfgre.tberna.bet> References: <143501c2d154$9c3c70e0$52557f42@errno.com> <20030211041721.B3AEE2A8B4@canning.wemm.org> <20030211073011.GA576@dhcp01.pn.xcllnt.net> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Feb 2003, Marcel Moolenaar wrote: > On Mon, Feb 10, 2003 at 08:17:21PM -0800, Peter Wemm wrote: > > > > Part of the reason why its done like it is right now is that nobody really > > got around to figuring out what was needed and doing the Makefile lists > > and testing that it didn't break stuff. > > Testing is really the hard part. It would be nice to have a way to > have the whole ports collection built with a particular change before > the change is committed. Ie, use the ports collection for regression > testing. Talk to kris. He fits changes to test into bento builds fairly regularly. Doug -- "The last time France wanted more evidence, it rolled right through Paris with a German flag." - David Letterman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 5:55: 7 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E613F37B401 for ; Wed, 26 Feb 2003 05:55:05 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2087243F75 for ; Wed, 26 Feb 2003 05:55:05 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1QDt23Y004096; Wed, 26 Feb 2003 06:55:03 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 26 Feb 2003 06:54:14 -0700 (MST) Message-Id: <20030226.065414.31318249.imp@bsdimp.com> To: marcel@xcllnt.net Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [RFC] splitting of conf/NOTES From: "M. Warner Losh" In-Reply-To: <20030224222205.GA1032@athlon.pn.xcllnt.net> References: <20030224204113.GC661@athlon.pn.xcllnt.net> <20030224.143957.17279856.imp@bsdimp.com> <20030224222205.GA1032@athlon.pn.xcllnt.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20030224222205.GA1032@athlon.pn.xcllnt.net> Marcel Moolenaar writes: : What I'm getting at is: will this only be i386 ROMs (ie with : i386 code) or is it possible that when a machine has ISA : emulation, one should be able to scan for ROMs in the ISA hole : and find something that can actually be used. I'm inclined to : assume that ROMs found in the ISA hole are i386 specific and : ISA emulation is limited to I/O ports and registers only. Typically, the ROMs that are found are used to create a map of resources that are decoded by the bus but otherwise not used by other drivers. : Thus: even if ISA (sec) is not i386 specific, there may be ISA : drivers that depend on ROM, BIOS and/or BIOS data (see sys/fb/vga.c) : and consequently are not pure ISA drivers. They are PC drivers. : This is the driver part I was referring to in my previous mail. There are very few drivers in the tree that do this. However, the whole console goo stuff is far too dependent on the PC architecture. : On the ia64 branch I fiddled with sys/conf/files.* to make PC/ISA : device drivers actually depend on the existence of "device isa", : so that I could create an ISA-less kernel (needed for pluto{1|2}). This should be a good thing. However, the purity of some of the older files in the tree leaves something to be desired. : This triggered some interesting bugs, such as the fact that the : high-level syscons code (ie sc(4) itself) has been attached to : the ISA bus and is identified/probed as an ISA device. I had to : break the artificial dependency to get syscons working (with the : supprt of a PCI VGA wannabe driver). Yes. These are bugs in the tree. Let's also not forget sio, which is mostly kinda sorta MI, but lacks support for memory mapping and a number of other desirable things (but marcel-sio seems to have fixed them :-). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 13:33:52 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B993837B401 for ; Wed, 26 Feb 2003 13:33:50 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E69C443FA3 for ; Wed, 26 Feb 2003 13:33:49 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1QLXmEv028751 for ; Wed, 26 Feb 2003 22:33:49 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org Subject: (almost) Ready to ditch device major numbers. From: Poul-Henning Kamp Date: Wed, 26 Feb 2003 22:33:48 +0100 Message-ID: <28750.1046295228@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG We are now (almost) ready to ditch device major numbers if we want to. For POSIXMISTAKE like reasons we cannot abolish major-minor numbers entirely, but at least we can automate them enough to make them a non-pain. There are some things we can _not_ do, the main one being assign the same major-minor tupple to two devices at the same time. Since the minor is under control of the device driver, this more or less means that we cannot automagically share major numbers between two or more different cdevsw structurs. We will therefore still have a limit of <256 device drivers until we also tackle minor-number assignment (something which is much harder and much more intrusive and therefore maybe not even feasible) but at least the limit will be "256 loaded drivers" and not "256 drivers for which we have assigned minor numbers. Here is a suggested sequence of events, not a timeline by any strech of the imagination, merely things we can do and the order we can do them in: 1) Build a bitmap of registered majors (from conf/majors) at kernel-compile so the kernel can know which majors we can risk KLD's to use. 2) Introduce "MAJOR_AUTO" or similar for use in cdevsw structures. This should autoallocate the highest free major number for that cdevsw without people having to go to the trouble of registering a number from sys/conf/majors. The major number will be non-persistent and will vary from boot to boot. Tools like tripwire will hate us for it, but such tools need to learn about DEVFS anyway. 3) Stop allocating major numbers from conf/majors, unless very special requirements mandate they have to be static across boots and systems. 4) Start actively revoking registrations from conf/majors for in-our-tree drivers which works just great with MAJOR_AUTO. 5) Remove the d_maj field from struct cdevsw entirely and make dynamic allocation the default. Comments welcome. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 14:55:40 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A5D437B401 for ; Wed, 26 Feb 2003 14:55:39 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id E558D43FDF for ; Wed, 26 Feb 2003 14:55:37 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <2003022622553705200947o6e>; Wed, 26 Feb 2003 22:55:37 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA99329; Wed, 26 Feb 2003 14:55:36 -0800 (PST) Date: Wed, 26 Feb 2003 14:55:34 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: (almost) Ready to ditch device major numbers. In-Reply-To: <28750.1046295228@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 26 Feb 2003, Poul-Henning Kamp wrote: > > We are now (almost) ready to ditch device major numbers if we want to. > > > 5) Remove the d_maj field from struct cdevsw entirely and make > dynamic allocation the default. > > Comments welcome. Sounds right to me.. (I assume there are no NFS related gotchas) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 15:41:32 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92D0637B401 for ; Wed, 26 Feb 2003 15:41:31 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 423B543F85 for ; Wed, 26 Feb 2003 15:41:30 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 137E75308; Thu, 27 Feb 2003 00:41:27 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: (almost) Ready to ditch device major numbers. From: Dag-Erling Smorgrav Date: Thu, 27 Feb 2003 00:41:27 +0100 In-Reply-To: <28750.1046295228@critter.freebsd.dk> (Poul-Henning Kamp's message of "Wed, 26 Feb 2003 22:33:48 +0100") Message-ID: User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386--freebsd) References: <28750.1046295228@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > We are now (almost) ready to ditch device major numbers if we want to. Sounds like a step in the right direction. > 1) Build a bitmap of registered majors (from conf/majors) at > kernel-compile so the kernel can know which majors we can risk > KLD's to use. We already have a fairly large reserved range that we can draw from (200-252), so this might not be necessary. We also have a range reserved for lkms (32-38) which is unused, AFAIK. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 19: 4:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3D8137B401; Wed, 26 Feb 2003 19:02:33 -0800 (PST) Received: from notes-relay.monroe.edu (notes-relay.monroe.edu [199.190.222.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDFCA43FAF; Wed, 26 Feb 2003 19:02:30 -0800 (PST) (envelope-from vortex_nismo@mail.ru) Received: from mail.greece.k12.ny.us (greece-notes1.greece.k12.ny.us [207.10.14.202]) by notes-relay.monroe.edu (8.12.1/8.12.1) with ESMTP id h1R2wgB8085308; Wed, 26 Feb 2003 21:58:43 -0500 (EST) Received: from hotmail.com ([64.2.84.131]) by mail.greece.k12.ny.us (Lotus Domino Release 5.0.10) with SMTP id 2003022622004652:3595 ; Wed, 26 Feb 2003 22:00:46 -0500 Reply-To: vortex_nismo@mail.ru From: П*О*Л*И*Г*Р*А*Ф*И*Я Subject: -=Оперативная полиграфия по отличным ценам!=- Date: Thu, 27 Feb 2003 04:59:03 +0200 MIME-Version: 1.0 X-Priority: 1 (High) X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on Greece-Notes1/Greece(Release 5.0.10 |March 22, 2002) at 02/26/2003 10:00:58 PM, Serialize by Router on Greece-Notes1/Greece(Release 5.0.10 |March 22, 2002) at 02/26/2003 10:02:21 PM, Serialize complete at 02/26/2003 10:02:21 PM Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="Windows-1251" To: undisclosed-recipients: ; Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG
 
Наша типография предлагаем Вам услуги оперативной полиграфии по передовой технологии цифровой полноцветной печати (разрешение до 1200dpi) на самом современном оборудовании по ОТЛИЧНЫМ ценам! Цветные и черно-белые визитные карточки, бланки, рекламные листовки, календари, плакаты - любые виды печатной продукции в самые кратчайшие сроки. В офисе работает профессиональный дизайнер, который поможет Вам создать неповторимый стиль и оригинальный дизайн-макет будущей продукции в период Вашего присутствия (от 15 мин до 1,5 часов). Дизайн и изготовление макета - бесплатно!


Прайс-лист на услуги:

Визитные карточки !!!полноцвет!!! (цифровая цветная печать):

 

Тираж

Стоимость тиража ($)

50

7,5

100

9

200

19

500

40

1000

75

* бумага плотностью до 300 г/м2

Визитные карточки (цифровая черно-белая печать):

 

Тираж

Стоимость тиража ($)

50

5

100

7

200

15

500

25

1000

40

* бумага плотностью до 300 г/м2

Плакаты А3:

 

Тираж

Стоимость тиража ($)

1

5

5

20

10

35

50

150


Двусторонние календари:

 

Тираж

Стоимость тиража ($)

50

20

100

35

300

80

 

Цифровая печать любых файлов:

 

По договоренности

 

Изготовление упаковки любых форматов :

По договоренности 

   

Дисконтные карты:

 

Тираж

Стоимость тиража ($)

50

30

100

38

200

50,7

500

110

1000

195

 


Доставка продукции, а также выезд курьера - 100 рублей в пределах МКАД!

Надеемся на дальнейшее долгосрочное сотрудничество!

По всем возникающим вопросам и предложениям о сотрудничестве Вы можете обратиться по телефону:
(095) 275-24-50 (многоканальный).

 

JVBTOWNFXFGPGSJIQCRXPSDMWBJBDNCPBKRKLC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 19:39: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A49C237B405 for ; Wed, 26 Feb 2003 19:39:00 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-52.dsl.lsan03.pacbell.net [63.207.60.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 810A443FA3 for ; Wed, 26 Feb 2003 19:38:59 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 06556679DA; Wed, 26 Feb 2003 19:38:55 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 267BC124A; Wed, 26 Feb 2003 19:38:55 -0800 (PST) Date: Wed, 26 Feb 2003 19:38:55 -0800 From: Kris Kennaway To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: (almost) Ready to ditch device major numbers. Message-ID: <20030227033854.GA87187@rot13.obsecurity.org> References: <28750.1046295228@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <28750.1046295228@critter.freebsd.dk> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 26, 2003 at 10:33:48PM +0100, Poul-Henning Kamp wrote: >=20 > We are now (almost) ready to ditch device major numbers if we want to. There are a number of ports that create device nodes in the package tarball (e.g. the linux_base ports which create a shadow /dev). How will this be affected under your plans? Kris --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+XYhNWry0BWjoQKURAhqiAJ0SO5B5aR8QpEjOys4jYkUgcG88WQCg3/iT AMLSIt4FSP8nJNK2aJf+mBA= =+tjl -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 20: 1:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D117E37B401 for ; Wed, 26 Feb 2003 20:01:46 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 327B843FCB for ; Wed, 26 Feb 2003 20:01:46 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.6/8.12.6) id h1R41jwi077960; Wed, 26 Feb 2003 22:01:45 -0600 (CST) (envelope-from dan) Date: Wed, 26 Feb 2003 22:01:45 -0600 From: Dan Nelson To: Kris Kennaway Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: (almost) Ready to ditch device major numbers. Message-ID: <20030227040145.GA25640@dan.emsphone.com> References: <28750.1046295228@critter.freebsd.dk> <20030227033854.GA87187@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030227033854.GA87187@rot13.obsecurity.org> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Feb 26), Kris Kennaway said: > On Wed, Feb 26, 2003 at 10:33:48PM +0100, Poul-Henning Kamp wrote: > > We are now (almost) ready to ditch device major numbers if we want > > to. > > There are a number of ports that create device nodes in the package > tarball (e.g. the linux_base ports which create a shadow /dev). How > will this be affected under your plans? linux_base-7.1_2 doesn't put anything in /compat/linx/dev, and I don't see anything in linux_base-6's plist that indicates it does, either. Anything that tries to generate a device node in /dev from userland should already fail anyway, right? devfs won't let you do anything except make symlinks. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 21:45: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC83837B401 for ; Wed, 26 Feb 2003 21:45:04 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 387C043F93 for ; Wed, 26 Feb 2003 21:45:04 -0800 (PST) (envelope-from wes@softweyr.com) Received: from 204.68.178.4 (66-75-151-22.san.rr.com [66.75.151.22]) by smtp-relay.omnis.com (Postfix) with ESMTP id A92564354A; Wed, 26 Feb 2003 21:41:47 -0800 (PST) From: Wes Peters Organization: Softweyr LLC To: Terry Lambert , Garance A Drosihn Subject: Re: NEWSYSLOG changes Date: Wed, 26 Feb 2003 21:50:34 -0800 User-Agent: KMail/1.5 Cc: arch@FreeBSD.ORG References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <3E59B3C9.650144CC@mindspring.com> In-Reply-To: <3E59B3C9.650144CC@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302262150.34760.wes@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday 23 February 2003 09:55 pm, Terry Lambert wrote: > Garance A Drosihn wrote: > > Yes, I have an idea of what I want to do for that, but it will be > > done as a separate patch. I have several different changes in > > mind, and I'm trying to figure out the best order to make them. > > I'm pretty happy with what Garance has said he intends to do in > this area. > > > Note that the problem isn't the first roll (where the 40-meg file > > turns into /var/log/somelog.0), it's that later checking may see > > that /var/log/somelog is 0 bytes (particularly if /var/log is out > > of disk space), and thus the 40-meg logfile is *never* rotated > > after that first shot. > > Actually, the problem in the case of the InterJet was that in the > case of an out-of-space, the space was not available, not that > there would not be subsequent log rolls, as you imply here. > > Specifically, there are a lot of things that go on /var besides > log files. One of these is the pid files for various programs, > which fail to start if they cannot be created, and many of which > do not necessarily run as root. Another is temporary files, for > things like mail queue entries, which may occur on /var/tmp, if > it is the designated /tmp directory. This is a common case, > when /var is the only writeable FS in the system (for example). Oh, hell, that's easy, you solve that with a /log filesystem. > > Once I add the -R option, and once you add the improvements to > > syslogd itself, then the situation that Terry describes is less > > likely to happen. I do want to do something about it, though. > > As long as it's possible to set *some* option up to drain the FS > down to a less than full state, I'm mostly agnostic on the method > used to specifically do it. I've stated my preferences, from a > product design and remote support perspective (rewrite history > and save only the last XXX of the last log file); I think that's > the most reasonable approach, but there's also something to be said > about saving the events around the time the failure started that > ended up leaving me with a full disk. So... I'm mostly agnostic. Being smart about sensing that something has gone bonkers and is babbling into the logs would be an excellent step forward. The "last line repeated XXX times" cache is perhaps a few entries too short... > I never fixed this at Whistle because it was Archie's code, and > the best way to piss off your coworkers is to rewrite their code > out from under them. 8-) 8-). Really? We used to have races to see who could fix each others bugs quickest at DoBox. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 22:12: 1 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B4AB37B401 for ; Wed, 26 Feb 2003 22:12:00 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2815E43FBD for ; Wed, 26 Feb 2003 22:11:59 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1R6Bwaa002847; Thu, 27 Feb 2003 07:11:58 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: (almost) Ready to ditch device major numbers. From: phk@phk.freebsd.dk In-Reply-To: Your message of "Thu, 27 Feb 2003 00:41:27 +0100." Date: Thu, 27 Feb 2003 07:11:58 +0100 Message-ID: <2846.1046326318@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >Poul-Henning Kamp writes: >> We are now (almost) ready to ditch device major numbers if we want to. > >Sounds like a step in the right direction. > >> 1) Build a bitmap of registered majors (from conf/majors) at >> kernel-compile so the kernel can know which majors we can risk >> KLD's to use. > >We already have a fairly large reserved range that we can draw from >(200-252), so this might not be necessary. We also have a range >reserved for lkms (32-38) which is unused, AFAIK. I know, but as we make more and more driver use MAJOR_AUTO, we will need larger ranges, so creating the bitmap with a script from conf/majors would save some manual work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 22:21:41 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0710937B401 for ; Wed, 26 Feb 2003 22:21:40 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19A6E43FA3 for ; Wed, 26 Feb 2003 22:21:39 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1R6LWaa002967; Thu, 27 Feb 2003 07:21:37 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: (almost) Ready to ditch device major numbers. From: phk@phk.freebsd.dk In-Reply-To: Your message of "Wed, 26 Feb 2003 19:38:55 PST." <20030227033854.GA87187@rot13.obsecurity.org> Date: Thu, 27 Feb 2003 07:21:32 +0100 Message-ID: <2966.1046326892@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20030227033854.GA87187@rot13.obsecurity.org>, Kris Kennaway writes: > >--DocE+STaALJfprDB >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Wed, Feb 26, 2003 at 10:33:48PM +0100, Poul-Henning Kamp wrote: >>=20 >> We are now (almost) ready to ditch device major numbers if we want to. > >There are a number of ports that create device nodes in the package >tarball (e.g. the linux_base ports which create a shadow /dev). How >will this be affected under your plans? Depends what the shadow /dev contains and how it is used. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 22:30:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC16037B401 for ; Wed, 26 Feb 2003 22:30:42 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-63-207-60-52.dsl.lsan03.pacbell.net [63.207.60.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 313E343FAF for ; Wed, 26 Feb 2003 22:30:41 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 45B7B679DA; Wed, 26 Feb 2003 22:30:40 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 3080A1248; Wed, 26 Feb 2003 22:30:40 -0800 (PST) Date: Wed, 26 Feb 2003 22:30:40 -0800 From: Kris Kennaway To: Dan Nelson Cc: Kris Kennaway , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: (almost) Ready to ditch device major numbers. Message-ID: <20030227063039.GA88321@rot13.obsecurity.org> References: <28750.1046295228@critter.freebsd.dk> <20030227033854.GA87187@rot13.obsecurity.org> <20030227040145.GA25640@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20030227040145.GA25640@dan.emsphone.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 26, 2003 at 10:01:45PM -0600, Dan Nelson wrote: > In the last episode (Feb 26), Kris Kennaway said: > > On Wed, Feb 26, 2003 at 10:33:48PM +0100, Poul-Henning Kamp wrote: > > > We are now (almost) ready to ditch device major numbers if we want > > > to. > >=20 > > There are a number of ports that create device nodes in the package > > tarball (e.g. the linux_base ports which create a shadow /dev). How > > will this be affected under your plans? >=20 > linux_base-7.1_2 doesn't put anything in /compat/linx/dev, and I don't > see anything in linux_base-6's plist that indicates it does, either. >=20 > Anything that tries to generate a device node in /dev from userland > should already fail anyway, right? devfs won't let you do anything > except make symlinks. No, it definitely does. I noticed this because I recently made a change to the bento package builds so they build packages in a jail instead of a chroot. A number of packages (3-4) failed because they try and mknod at install-time, which is disallowed within a jail. See e.g. http://bento.freebsd.org/errorlogs/i386-4-exp-latest/linux_base-7.1_2.log Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+XbCPWry0BWjoQKURAhu3AJ4ldM/ax0qaovIAmCp+wF5O/U2N6QCg4sFg /FMF2erHr5H9sz4/ngE09F8= =zNZI -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 23:12:55 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 929AE37B401 for ; Wed, 26 Feb 2003 23:12:53 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 500D443FBD for ; Wed, 26 Feb 2003 23:12:48 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1R7Cc1o058035; Wed, 26 Feb 2003 23:12:38 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1R7CcqV002675; Wed, 26 Feb 2003 23:12:38 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1R7CTRU002674; Wed, 26 Feb 2003 23:12:29 -0800 (PST) Date: Wed, 26 Feb 2003 23:12:29 -0800 From: Marcel Moolenaar To: Kris Kennaway Cc: Dan Nelson , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: (almost) Ready to ditch device major numbers. Message-ID: <20030227071229.GB2442@dhcp01.pn.xcllnt.net> References: <28750.1046295228@critter.freebsd.dk> <20030227033854.GA87187@rot13.obsecurity.org> <20030227040145.GA25640@dan.emsphone.com> <20030227063039.GA88321@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030227063039.GA88321@rot13.obsecurity.org> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Feb 26, 2003 at 10:30:40PM -0800, Kris Kennaway wrote: > On Wed, Feb 26, 2003 at 10:01:45PM -0600, Dan Nelson wrote: > > In the last episode (Feb 26), Kris Kennaway said: > > > On Wed, Feb 26, 2003 at 10:33:48PM +0100, Poul-Henning Kamp wrote: > > > > We are now (almost) ready to ditch device major numbers if we want > > > > to. > > > > > > There are a number of ports that create device nodes in the package > > > tarball (e.g. the linux_base ports which create a shadow /dev). How > > > will this be affected under your plans? > > > > linux_base-7.1_2 doesn't put anything in /compat/linx/dev, and I don't > > see anything in linux_base-6's plist that indicates it does, either. > > > > Anything that tries to generate a device node in /dev from userland > > should already fail anyway, right? devfs won't let you do anything > > except make symlinks. > > No, it definitely does. I noticed this because I recently made a > change to the bento package builds so they build packages in a jail > instead of a chroot. A number of packages (3-4) failed because they > try and mknod at install-time, which is disallowed within a jail. > > See e.g. > > http://bento.freebsd.org/errorlogs/i386-4-exp-latest/linux_base-7.1_2.log In this case it's the ports makefile that creates the device file. The reason it does that is that rpm is run with --root ${LINUXBASE} so that the RPM database is located in /compat/linux, even though the rpm binary itself is a FreeBSD native one (and thus likes to put its bits under /var). The --root command line option results in a chroot(2) and thus causes some nasty problems. One of which is the dependency on /dev/null, which has to be created under /compat/linux for that case. I think (but I'm not sure) that it should be safe to remove the major/minor numbers, because we could probably do some trickery with devfs and symbolic links. I seem to recall however that iBCS has a stronger dependency. Also, VMWare probably needs a quick audit. It might also be a good idea to look at osf1 emulation because it's needed for Linux emulation on alpha. While we're at it, we might as well look at SysV emulation too :-) Overall: I think there might be some weird cases we need to deal with. But since we don't have any major/minor number mappings in the various emulation layers, I expect that the weird cases are mostly special cases and that we don't have a fundamental problem. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 23:14:10 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEB4637B401 for ; Wed, 26 Feb 2003 23:14:08 -0800 (PST) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 3D68043F93 for ; Wed, 26 Feb 2003 23:14:07 -0800 (PST) (envelope-from roam@ringlet.net) Received: (qmail 4661 invoked from network); 27 Feb 2003 07:10:02 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 27 Feb 2003 07:10:02 -0000 Received: (qmail 82419 invoked by uid 1000); 27 Feb 2003 07:12:47 -0000 Date: Thu, 27 Feb 2003 09:12:47 +0200 From: Peter Pentchev To: Julian Elischer Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: (almost) Ready to ditch device major numbers. Message-ID: <20030227071247.GJ487@straylight.oblivion.bg> Mail-Followup-To: Julian Elischer , Poul-Henning Kamp , arch@freebsd.org References: <28750.1046295228@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pgaa2uWPnPrfixyx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Pgaa2uWPnPrfixyx Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 26, 2003 at 02:55:34PM -0800, Julian Elischer wrote: > On Wed, 26 Feb 2003, Poul-Henning Kamp wrote: >=20 > >=20 > > We are now (almost) ready to ditch device major numbers if we want to. > >=20 > >=20 > > 5) Remove the d_maj field from struct cdevsw entirely and make > > dynamic allocation the default. > >=20 > > Comments welcome. >=20 > Sounds right to me.. > (I assume there are no NFS related gotchas) What happens to a FreeBSD NFS server, or rather, to its clients, if the server is rebooted and the client remounts the NFS share? Could some programs at the client side be confused by the suddenly changed device major numbers? G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. --Pgaa2uWPnPrfixyx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+Xbpv7Ri2jRYZRVMRApcBAJwKysX30K1UABHhu38kzL53h9O8LQCdHw6O VQHfj41OA4Fi44E5aTL2PJg= =vfHa -----END PGP SIGNATURE----- --Pgaa2uWPnPrfixyx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 26 23:20:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FC9537B401 for ; Wed, 26 Feb 2003 23:20:41 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90A2043F75 for ; Wed, 26 Feb 2003 23:20:40 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1R7KTaa003610; Thu, 27 Feb 2003 08:20:35 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Peter Pentchev Cc: Julian Elischer , arch@freebsd.org Subject: Re: (almost) Ready to ditch device major numbers. From: phk@phk.freebsd.dk In-Reply-To: Your message of "Thu, 27 Feb 2003 09:12:47 +0200." <20030227071247.GJ487@straylight.oblivion.bg> Date: Thu, 27 Feb 2003 08:20:29 +0100 Message-ID: <3609.1046330429@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20030227071247.GJ487@straylight.oblivion.bg>, Peter Pentchev writes : >What happens to a FreeBSD NFS server, or rather, to its clients, if the >server is rebooted and the client remounts the NFS share? Could some >programs at the client side be confused by the suddenly changed device >major numbers? We should not use major/minor in filehandles, and I don't think we do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 0:51:10 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EDAE37B401 for ; Thu, 27 Feb 2003 00:51:09 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4792D43FDD for ; Thu, 27 Feb 2003 00:51:08 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1R8p1aa004337; Thu, 27 Feb 2003 09:51:02 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar Cc: Kris Kennaway , Dan Nelson , arch@FreeBSD.ORG Subject: Re: (almost) Ready to ditch device major numbers. From: phk@phk.freebsd.dk In-Reply-To: Your message of "Wed, 26 Feb 2003 23:12:29 PST." <20030227071229.GB2442@dhcp01.pn.xcllnt.net> Date: Thu, 27 Feb 2003 09:51:01 +0100 Message-ID: <4336.1046335861@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG For now the focus is to make sure we don't run out of major numbers, and for that I don't see why we should not recognize some devices as sufficiently magic that we will not touch their majors. /dev/null, and /dev/zero are at the top of my list. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 6:48:19 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7711737B405 for ; Thu, 27 Feb 2003 06:48:18 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91C3D44028 for ; Thu, 27 Feb 2003 06:48:15 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0140.cvx40-bradley.dialup.earthlink.net ([216.244.42.140] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18oPKQ-00016W-00; Thu, 27 Feb 2003 06:48:07 -0800 Message-ID: <3E5E24D2.D4CE8F4F@mindspring.com> Date: Thu, 27 Feb 2003 06:46:42 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: (almost) Ready to ditch device major numbers. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d372d43fb3e9066969f86d769d092a63350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > On Wed, 26 Feb 2003, Poul-Henning Kamp wrote: > > We are now (almost) ready to ditch device major numbers if we want to. > > > > > > 5) Remove the d_maj field from struct cdevsw entirely and make > > dynamic allocation the default. > > > > Comments welcome. > > Sounds right to me.. > (I assume there are no NFS related gotchas) Will it still be possible to manually create device nodes, such that you will be able to NFS boot OS's other than FreeBSD, hosted by a FreeBSD NFS server (e.g. Darwin, NetBSD, OpenBSD, Tru64)? Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 8:29:22 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 313DA37B401 for ; Thu, 27 Feb 2003 08:29:21 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FE4143FAF for ; Thu, 27 Feb 2003 08:29:20 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.6/8.12.6) with ESMTP id h1RGTITp012054; Thu, 27 Feb 2003 16:29:18 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost) by storm.FreeBSD.org.uk (8.12.6/8.12.6/Submit) with UUCP id h1RGTHht012053; Thu, 27 Feb 2003 16:29:17 GMT X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.7/8.12.7) with ESMTP id h1RGHso6040341; Thu, 27 Feb 2003 16:17:55 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200302271617.h1RGHso6040341@grimreaper.grondar.org> To: phk@phk.freebsd.dk Cc: arch@FreeBSD.ORG Subject: Re: (almost) Ready to ditch device major numbers. In-Reply-To: Your message of "Thu, 27 Feb 2003 09:51:01 +0100." <4336.1046335861@critter.freebsd.dk> Date: Thu, 27 Feb 2003 16:17:54 +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG phk@phk.freebsd.dk writes: > > For now the focus is to make sure we don't run out of major numbers, > and for that I don't see why we should not recognize some devices as > sufficiently magic that we will not touch their majors. /dev/null, > and /dev/zero are at the top of my list. You are welcome to add /dev/random. Please ditch the compatability symlink while you are there :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 11:11:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77DAD37B405 for ; Thu, 27 Feb 2003 11:11:47 -0800 (PST) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id D864943FAF for ; Thu, 27 Feb 2003 11:11:45 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 13232 invoked from network); 27 Feb 2003 19:11:51 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Feb 2003 19:11:51 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h1RJAAhT027301; Thu, 27 Feb 2003 14:10:10 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030227071247.GJ487@straylight.oblivion.bg> Date: Thu, 27 Feb 2003 14:11:58 -0500 (EST) From: John Baldwin To: Peter Pentchev Subject: Re: (almost) Ready to ditch device major numbers. Cc: arch@freebsd.org, Poul-Henning Kamp , Julian Elischer Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 27-Feb-2003 Peter Pentchev wrote: > On Wed, Feb 26, 2003 at 02:55:34PM -0800, Julian Elischer wrote: >> On Wed, 26 Feb 2003, Poul-Henning Kamp wrote: >> >> > >> > We are now (almost) ready to ditch device major numbers if we want to. >> > >> > >> > 5) Remove the d_maj field from struct cdevsw entirely and make >> > dynamic allocation the default. >> > >> > Comments welcome. >> >> Sounds right to me.. >> (I assume there are no NFS related gotchas) > > What happens to a FreeBSD NFS server, or rather, to its clients, if the > server is rebooted and the client remounts the NFS share? Could some > programs at the client side be confused by the suddenly changed device > major numbers? devices are local to the machine. If you open a cdev from an NFS mount, it will try to open it as a device on the local machine, not on the remote machine. Exporting devfs over NFS seems rather pointless. Exporting devices over NFS is only really useful for diskless boots on systems w/o devfs (i.e. 4.x). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 11:19:29 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A875437B401; Thu, 27 Feb 2003 11:19:27 -0800 (PST) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5704043FA3; Thu, 27 Feb 2003 11:19:26 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.7/8.12.7) with ESMTP id h1RJJKT0001304; Thu, 27 Feb 2003 20:19:20 +0100 (CET) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.7/8.12.7/Submit) id h1RJJKAQ001303; Thu, 27 Feb 2003 20:19:20 +0100 (CET) Date: Thu, 27 Feb 2003 20:19:20 +0100 From: Wilko Bulte To: John Baldwin Cc: Peter Pentchev , arch@FreeBSD.ORG, Poul-Henning Kamp , Julian Elischer Subject: Re: (almost) Ready to ditch device major numbers. Message-ID: <20030227201920.A1280@freebie.xs4all.nl> References: <20030227071247.GJ487@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Thu, Feb 27, 2003 at 02:11:58PM -0500 X-OS: FreeBSD 4.8-PRERELEASE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Feb 27, 2003 at 02:11:58PM -0500, John Baldwin wrote: > > On 27-Feb-2003 Peter Pentchev wrote: > > On Wed, Feb 26, 2003 at 02:55:34PM -0800, Julian Elischer wrote: > >> On Wed, 26 Feb 2003, Poul-Henning Kamp wrote: > >> > >> > > >> > We are now (almost) ready to ditch device major numbers if we want to. > >> > > >> > > >> > 5) Remove the d_maj field from struct cdevsw entirely and make > >> > dynamic allocation the default. > >> > > >> > Comments welcome. > >> > >> Sounds right to me.. > >> (I assume there are no NFS related gotchas) > > > > What happens to a FreeBSD NFS server, or rather, to its clients, if the > > server is rebooted and the client remounts the NFS share? Could some > > programs at the client side be confused by the suddenly changed device > > major numbers? > > devices are local to the machine. If you open a cdev from an NFS mount, > it will try to open it as a device on the local machine, not on the remote > machine. Exporting devfs over NFS seems rather pointless. Exporting > devices over NFS is only really useful for diskless boots on systems w/o > devfs (i.e. 4.x). Remembers me of RFS on SysV. There you could have device access on RFS mounted fs. IIRC that is, it's been a while.. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 11:23:59 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C256237B401; Thu, 27 Feb 2003 11:23:58 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA04943F3F; Thu, 27 Feb 2003 11:23:57 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h1RJNkaa009566; Thu, 27 Feb 2003 20:23:46 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Wilko Bulte Cc: John Baldwin , Peter Pentchev , arch@FreeBSD.ORG, Julian Elischer Subject: Re: (almost) Ready to ditch device major numbers. From: phk@phk.freebsd.dk In-Reply-To: Your message of "Thu, 27 Feb 2003 20:19:20 +0100." <20030227201920.A1280@freebie.xs4all.nl> Date: Thu, 27 Feb 2003 20:23:46 +0100 Message-ID: <9565.1046373826@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20030227201920.A1280@freebie.xs4all.nl>, Wilko Bulte writes: >Remembers me of RFS on SysV. There you could have device access on RFS >mounted fs. IIRC that is, it's been a while.. Ahh yes, and who hasn't gridlocked a set of sysV machines with RFS cross-mounts, but it was neat to be able to use remote tape drives and stuff. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 14:22:32 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5740A37B401 for ; Thu, 27 Feb 2003 14:22:31 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0D9E43FA3 for ; Thu, 27 Feb 2003 14:22:29 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.7/8.12.7) with ESMTP id h1RMLr3q026077; Thu, 27 Feb 2003 17:21:54 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302251255.48219.wes@softweyr.com> Date: Thu, 27 Feb 2003 17:21:52 -0500 To: Wes Peters , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: NEWSYSLOG changes, nosignal & -Rotate Cc: Julian Elischer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:58 PM -0500 2/25/03, Garance A Drosihn wrote: >I have two different updates now, to replace the one I >previously posted. Here's the location of the two patches: > >http://people.freebsd.org/~gad/newsyslog/1-nosig.diff >http://people.freebsd.org/~gad/newsyslog/2-rotate.diff The first patch adds the -s "nosignal" option and "Nn" flags. The second patch adds the -R "request rotate" option. And now here is a third patch: http://people.freebsd.org/~gad/newsyslog/3-fixglob.diff The main purpose of this update is to rework the way newsyslog handles filenames which are specified on the command line. This is mainly to fix bugs with how those files were matched when the config file includes entries that specify filename-patterns (globs). It is also probably obvious by looking at it that I expect to write a future update so newsyslog can read information from multiple config files, say: /etc/defaults/newsyslog.conf and /etc/newsyslog.conf and maybe even /usr/local/etc/newsyslog.d/*.conf But I don't want to open that debate just yet. For now I just wanted to get glob's working correctly, because I think the bugs in the present glob-handling might bite more people once syslogd starts taking advantage of -R. This update has not been extensively tested, although it does seem to do the right thing for the config files I've tried. Assuming there are no major bugs, I'd like to commit this at about the same time as the other two. I'm still claiming that should be this Sunday, but it might be a few days later. Let me know if you see any problems with these updates. I also plan to do more testing of these before committing them. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 20:37:35 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8231837B401 for ; Thu, 27 Feb 2003 20:37:33 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0422743FB1 for ; Thu, 27 Feb 2003 20:37:33 -0800 (PST) (envelope-from wes@softweyr.com) Received: from 204.68.178.4 (66-75-151-22.san.rr.com [66.75.151.22]) by smtp-relay.omnis.com (Postfix) with ESMTP id C774042F99; Thu, 27 Feb 2003 20:36:29 -0800 (PST) From: Wes Peters Organization: Softweyr LLC To: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes Date: Thu, 27 Feb 2003 20:45:24 -0800 User-Agent: KMail/1.5 References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> <200302251255.48219.wes@softweyr.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302272045.24640.wes@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 25 February 2003 04:18 pm, Garance A Drosihn wrote: > At 12:55 PM -0800 2/25/03, Wes Peters wrote: > >On Monday 24 February 2003 18:08, Garance A Drosihn wrote: > > > The idea of -R is that newsyslog should always rotate the given > > > list of files, whether or not *it* thinks they need to be > > > rotated. > > > > > > > > > For now it is assumed that the caller is the same process which > >> > >> usually writes to the file, and thus it does NOT use the pid_file > >> to signal that process. The whole idea of this is to let Wes > >> change syslogd to use this, and it would be silly for newsyslog > >> to HUP syslogd when it's syslogd that is requesting the rotate. > >> It may be that we should handle the pid-file signalling a > >> different way. > > > >Uh, actually, syslogd needs the HUP to re-open the file. ;^) > > > >I can change that iff I run newsyslog -F, waiting for the "new" > >log file to appear. Let me think about how to best do that... > > Well, I'm seriously thinking of redoing the -R update a little, > and have a separate option to say "do not signal". So, -R will > still send the signal by default. OK. I think I'll use the "do not signal" option, cause syslogd essentially restarts itself on SIGHUP, which is a little overboard for just rolling one file. > Still, I'd think that syslogd would: > close the logfile > exec newsyslog -NR syslogd somefile > wait for that to finish > re-open the log file. Yup, that's what I came up with when I was hacking on it yesterday. The code looks astonishingly like what you have above. > If newsyslog does the HUP, then it is also going to sleep for > something like 5 seconds, because it wants to be sure that the > signaled-process has done all the processing it needs to do. Yeah, ugh. And syslogd needs to pause to allow newsyslog to start, and etc. Nah. > >... I do like the idea of not needing a HUP signal between the > >two since syslogd started the newsyslog anyhow. > > Also, wouldn't a HUP will cause all config-files to be re-read, and > all log files to be closed and opened? That seems like a lot of > unnecessary work. Yup, exactly. Let me know if you put in a separate option for "don't signal" so I can use it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 27 20:39:47 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E86B37B401 for ; Thu, 27 Feb 2003 20:39:45 -0800 (PST) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF8E443FAF for ; Thu, 27 Feb 2003 20:39:44 -0800 (PST) (envelope-from wes@softweyr.com) Received: from 204.68.178.4 (66-75-151-22.san.rr.com [66.75.151.22]) by smtp-relay.omnis.com (Postfix) with ESMTP id B029B42D03; Thu, 27 Feb 2003 20:39:43 -0800 (PST) From: Wes Peters Organization: Softweyr LLC To: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: NEWSYSLOG changes, nosignal & -Rotate Date: Thu, 27 Feb 2003 20:48:38 -0800 User-Agent: KMail/1.5 References: <20030210114930.GB90800@melusine.cuivre.fr.eu.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200302272048.38443.wes@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 25 February 2003 08:58 pm, Garance A Drosihn wrote: > At 7:18 PM -0500 2/25/03, Garance A Drosihn wrote: > >Well, I'm seriously thinking of redoing the -R update a little, > >and have a separate option to say "do not signal". > > I have two different updates now, to replace the one I previously > posted. To avoid the problem where my messages sometimes disappear > when I include the patch in them, here's the location of the two > patches: > > http://people.freebsd.org/~gad/newsyslog/1-nosig.diff > http://people.freebsd.org/~gad/newsyslog/2-rotate.diff > > The first one adds a '-s' option to the newsyslog command, which > indicates that newsyslog should NOT send signals to any processes > if it has to rotate some log files. It also adds the 'N' or 'n' > option to the flags-field of entries in /etc/newsyslog.conf, which > indicates that the specific entry has no process which needs to be > signalled. For instance, right now the distributed newsyslog.conf > file has entries for files like /var/log/daily.log, and I doubt > that syslogd needs to be HUP'ed whenever that file is rotated. > > Both -s and the 'N' flag are based on options in NetBSD's version > of newsyslog. I am tempted to pick some other option, say '-Q' > plus 'Q' or 'q' for flags, so that the same letter will be used in > the config file or when specified on the command. I would keep > the netbsd letters, but only document the new letter. It would > be very easy to talk me into doing this... > > The nosig patch includes a little cleanup in areas I was touching > anway, which are done with an eye towards future updates (such > as the -R update...). > > The second update is basically the same as my previous posting > of the -R option, except that the newer implementation *does* > send a signal by default. Callers of newsyslog who do not want > the signal would add the '-s' (or '-Q'?) option. > > These updates have not been tested much. I intend to commit > them next Sunday, assuming they work in my testing and no one > has any additional feedback on them. They assume you're running > the up-to-the-minute version of newsyslog in -current. > > newsyslog itself has a number of subtle and not-so-subtle bugs > in it, so I expect to be writing up more updates after these. > One bug which was cleaned up as part of the nosig patch is that > it currently accepts either capital-G or lowercase-c (instead of > lowercase-g) as the flags to indicate the entry is a glob-pattern. > I still accept 'c', but warn about it. Sounds good to me. It takes me a while to test your patches because I have to back-port them to 4.4, but I'll get them hacked in. I'm going to try to get my -current box up this weekend and get the syslogd changes hacked into -current ready for testing and committing also. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 28 19:39: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAC7137B401; Fri, 28 Feb 2003 19:38:44 -0800 (PST) Received: from mel-rto2.wanadoo.fr (smtp-out-2.wanadoo.fr [193.252.19.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id E71C043FA3; Fri, 28 Feb 2003 19:38:42 -0800 (PST) (envelope-from pmiioijhi@list.ru) Received: from mel-rta6.wanadoo.fr (193.252.19.26) by mel-rto2.wanadoo.fr (6.7.015) id 3E0C3370028C6CBC; Sat, 1 Mar 2003 04:23:33 +0100 Received: from billsrv (217.128.212.103) by mel-rta6.wanadoo.fr (6.7.015) id 3E26CE21018F73F6; Sat, 1 Mar 2003 04:23:33 +0100 Message-ID: <3E26CE21018F73F6@mel-rta6.wanadoo.fr> (added by postmaster@wanadoo.fr) Received: from ALagny-101-1-4-107.abo.wanadoo.fr ([217.128.203.107]) by billsrv (602Pro LAN SUITE v. 2002) id 2e5b6895; Sat, 1 Mar 2003 4:26:26 +0100 Reply-To: pmiioijhi@list.ru From: ***Клиника Альтра-Вита*** Subject: Бесплодие женское и мужское Date: Sat, 1 Mar 2003 05:23:24 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1081 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 To: undisclosed-recipients: ; Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG

БЕСПЛОДИЕ – ЭТО НЕ ПРИГОВОР

СОВРЕМЕННЫЕ РЕПРОДУКТИВНЫЕ ТЕХНОЛОГИИ МОГУТ ПОМОЧЬ ДАЖЕ В САМЫХ СЛОЖНЫХ СЛУЧАЯХ

 

Суперсовременная специализированная клиника по лечению бесплодия проводит точную диагностику и эффективное лечение всех форм мужского и женского бесплодия.

 

Новейшее американское оборудование, опытные специалисты – репродуктологи, прошедшие стажировку за рубежом, высочайший уровень комфорта и теплое отношение персонала – все это вы найдете в нашей клинике.

 

Мы применяем новейшие методы лечения бесплодия включая ЭКО, ИКСИ, ТЕСА и др.

 

Подробную информацию вы можете получить по телефону : 127-39-36









SFSRRZUWUVCXBKXORSCYHJNZDWKJOZSGJVTMXE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 1 21:48:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 349CD37B401 for ; Sat, 1 Mar 2003 21:48:37 -0800 (PST) Received: from mail26a.sbc-webhosting.com (mail26a.sbc-webhosting.com [216.173.237.36]) by mx1.FreeBSD.org (Postfix) with SMTP id 46E0F44025 for ; Sat, 1 Mar 2003 21:48:36 -0800 (PST) (envelope-from alc@imimic.com) Received: from www.imimic.com (64.143.12.21) by mail26a.sbc-webhosting.com (RS ver 1.0.63s) with SMTP id 078149 for ; Sun, 2 Mar 2003 00:48:13 -0500 (EST) Message-ID: <3E619B26.DF1E4FC7@imimic.com> Date: Sat, 01 Mar 2003 23:48:22 -0600 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Removal of ENABLE_VFS_IOOPT Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Before I begin work on vm_object locking, I'd like to remove ENABLE_VFS_IOOPT from the kernel sources. ENABLE_VFS_IOOPT was a work-in-progress by John Dyson to perform zero-copy file system I/O. Unfortunately, it still has some unresolved issues, and no one has taken an active interest in fixing them. For the record, both Matt Dillon and Tor Egge have stated in public or private e-mail that they favor removing it. Unless I hear an objection, I intend to remove it in a few days. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 1 22: 1:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D34237B401 for ; Sat, 1 Mar 2003 22:01:34 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31DD643FCB for ; Sat, 1 Mar 2003 22:01:33 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h2261VI86700; Sun, 2 Mar 2003 01:01:31 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sun, 2 Mar 2003 01:01:31 -0500 (EST) From: Jeff Roberson To: "Alan L. Cox" Cc: arch@FreeBSD.ORG Subject: Re: Removal of ENABLE_VFS_IOOPT In-Reply-To: <3E619B26.DF1E4FC7@imimic.com> Message-ID: <20030302010032.Y57876-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 1 Mar 2003, Alan L. Cox wrote: > For the record, both Matt Dillon and Tor Egge have stated in public or > private e-mail that they favor removing it. > Unless I hear an objection, I intend to remove it in a few days. > I'm all for it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message