From owner-freebsd-current Sun Feb 19 18:05:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA23537 for current-outgoing; Sun, 19 Feb 1995 18:05:11 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA23525 for ; Sun, 19 Feb 1995 18:04:57 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id JAA00524 for ; Sun, 19 Feb 1995 09:08:59 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id JAA01612 for ; Sun, 19 Feb 1995 09:08:59 -0800 Message-Id: <199502191708.JAA01612@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: current@FreeBSD.org Subject: testing... From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 19 Feb 1995 09:08:57 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk Testing.... From owner-freebsd-current Sun Feb 19 18:16:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA23915 for current-outgoing; Sun, 19 Feb 1995 18:16:46 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA23904 for ; Sun, 19 Feb 1995 18:16:37 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id SAA29159 for current@freefall.cdrom.com; Sun, 19 Feb 1995 18:35:40 -0700 Date: Sun, 19 Feb 1995 18:35:40 -0700 From: Nate Williams Message-Id: <199502200135.SAA29159@trout.sri.MT.net> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current@freefall.cdrom.com Subject: libcompat and shlib conflict Sender: current-owner@FreeBSD.org Precedence: bulk Umm, forgive me if this sounds silly, but does the old shared library loader NOT complain about multiply defined symbols when it tries to build libcompat? The reason I'm asking is that I'm attempting to bring in the newest ld (once more) to hopefully finish off the shilb code merge. However, the newest ld is giving me errors trying to build libcompat (correctly so) with multiple definitions of the function regerror(), which is defined in both libcompat/4.3/regex.c and libcompat/regexp regerror.c. I suspect the older ld does not have problems, but as I'm a ways into the test phase, I'd rather not back out the changes I've made to make sure, but rather move forward and figure out how to resolve this conflict. Any hints or suggestions are welcome, Nate From owner-freebsd-current Sun Feb 19 20:00:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA28059 for current-outgoing; Sun, 19 Feb 1995 20:00:21 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA28050 for ; Sun, 19 Feb 1995 20:00:14 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id TAA18198; Sun, 19 Feb 1995 19:59:21 -0800 From: "Rodney W. Grimes" Message-Id: <199502200359.TAA18198@gndrsh.aac.dev.com> Subject: Re: libcompat and shlib conflict To: nate@trout.sri.MT.net (Nate Williams) Date: Sun, 19 Feb 1995 19:59:21 -0800 (PST) Cc: current@freefall.cdrom.com In-Reply-To: <199502200135.SAA29159@trout.sri.MT.net> from "Nate Williams" at Feb 19, 95 06:35:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1100 Sender: current-owner@FreeBSD.org Precedence: bulk > > Umm, forgive me if this sounds silly, but does the old shared library > loader NOT complain about multiply defined symbols when it tries to > build libcompat? The reason I'm asking is that I'm attempting to bring > in the newest ld (once more) to hopefully finish off the shilb code > merge. However, the newest ld is giving me errors trying to build > libcompat (correctly so) with multiple definitions of the function > regerror(), which is defined in both libcompat/4.3/regex.c and > libcompat/regexp regerror.c. > > I suspect the older ld does not have problems, but as I'm a ways into > the test phase, I'd rather not back out the changes I've made to make > sure, but rather move forward and figure out how to resolve this > conflict. I just rebuilt it and see no errors or no warnings from the build of libcompat :-(, this is on 2.0 current as of 4:00 this afternoon :-(. > > Any hints or suggestions are welcome, Sorry :-( -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sun Feb 19 20:27:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA28437 for current-outgoing; Sun, 19 Feb 1995 20:27:49 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA28431 for ; Sun, 19 Feb 1995 20:27:47 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id UAA16820 for current@freebsd.org; Sun, 19 Feb 1995 20:27:34 -0800 From: Poul-Henning Kamp Message-Id: <199502200427.UAA16820@ref.tfs.com> Subject: CTM To: current@FreeBSD.org Date: Sun, 19 Feb 1995 20:27:33 -0800 (PST) Content-Type: text Content-Length: 644 Sender: current-owner@FreeBSD.org Precedence: bulk Let it be known... CTM has moved to freefall. If you access the "cvs-cur" tree, you need to pick up the deltas in /home/ctm/CTM-priv/cvs-cur If you access the "src-cur" or "ports-cur", you will be able to pick up the deltas in freefall's anon-ftp area as ftp://freefall.cdrom.com/pub/CTM When we get it working. Until then find them in /home/ctm/CTM-pub. Email is open now too, subscribe to "cvs-src-cur" by sending email to majordomo@freefall.cdrom.com Send me email if you have problems. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Sun Feb 19 21:30:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id VAA29333 for current-outgoing; Sun, 19 Feb 1995 21:30:35 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id VAA29327 for ; Sun, 19 Feb 1995 21:30:30 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id WAA01333; Sun, 19 Feb 1995 22:34:04 -0700 Date: Sun, 19 Feb 1995 22:34:04 -0700 From: Nate Williams Message-Id: <199502200534.WAA01333@trout.sri.MT.net> In-Reply-To: "Rodney W. Grimes" "Re: libcompat and shlib conflict" (Feb 19, 7:59pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Rodney W. Grimes" Subject: Re: libcompat and shlib conflict Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk [ Multiple definitions of regerror() in libcompat ] > > However, the newest ld is giving me errors trying to build > > libcompat (correctly so) with multiple definitions of the function > > regerror(), which is defined in both libcompat/4.3/regex.c and > > libcompat/regexp/regerror.c. Does anyone know what should be done here? NetBSD just ignores the problem by not making a shared library. The problem still exists though since at link time I'm not sure which version of regerror() will get used, and a quick perusal of the code makes it obvious that they can't be combined into one function. I'm sure the function that is first found would be the first function linked in, but that could change depending on the other functions in the library and tsort. We either need to completely remove one of the functions, or ignore the problem and only build a static library which avoids the error at the cost of later problems in code. (But, I suppose folks shouldn't be using the compat libraries anyway, right. :( ) What say you? Nate From owner-freebsd-current Sun Feb 19 22:47:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id WAA00294 for current-outgoing; Sun, 19 Feb 1995 22:47:23 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id WAA00288 for ; Sun, 19 Feb 1995 22:47:21 -0800 Received: from masi.ibp.fr (root@masi.ibp.fr [132.227.60.23]) by ibp.ibp.fr (8.6.8/jtpda-5.0) with ESMTP id HAA09854 for ; Mon, 20 Feb 1995 07:49:06 +0100 Received: from hebe.ibp.fr (card@hebe.ibp.fr [132.227.64.34]) by masi.ibp.fr (8.6.9/jtpda-5.0) with ESMTP id HAA03767 for ; Mon, 20 Feb 1995 07:47:07 +0100 From: Remy.Card@masi.ibp.fr (Remy CARD) Received: by hebe.ibp.fr (8.6.9/jtpda-5.0) id HAA08576 for freebsd-current@freebsd.org; Mon, 20 Feb 1995 07:43:58 +0100 Message-Id: <199502200643.HAA08576@hebe.ibp.fr> Subject: Bad file retrieved in latest sup To: freebsd-current@FreeBSD.org Date: Mon, 20 Feb 1995 07:43:58 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 587 Sender: current-owner@FreeBSD.org Precedence: bulk Hi, It seems that a bad file is stored in the CVS repository: pascal>sup -d -v freebsd.supfile usrsbin SUP 8.26 (4.3 BSD) for file freebsd.supfile at Feb 20 07:49:34 SUP: supfilesrv/tcp: unknown service: using port 871 SUP Upgrade of usrsbin at Mon Feb 20 07:49:35 1995 SUP Fileserver 8.13 (4.3 BSD) 260 on freefall.cdrom.com at 07:49:35 SUP Requesting changes since Feb 20 04:44:40 1995 SUP Using compressed file transfer SUP Receiving file usr.sbin/config/.#mkswapconf.c.1.4 SUP Upgrade of usrsbin completed at Feb 20 07:49:58 1995 Can someone please remove it? Thanks Remy From owner-freebsd-current Sun Feb 19 23:12:58 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA00514 for current-outgoing; Sun, 19 Feb 1995 23:12:58 -0800 Received: from dns.netvision.net.il (root@dns.NetVision.net.il [194.90.1.5]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id XAA00507 for ; Sun, 19 Feb 1995 23:12:54 -0800 Received: from Burka.NetVision.net.il (root@Burka.NetVision.net.il [194.90.1.15]) by dns.netvision.net.il (8.6.9/8.6.9) with ESMTP id JAA02403 for ; Mon, 20 Feb 1995 09:12:13 +0200 Received: from localhost (gena@localhost [127.0.0.1]) by Burka.NetVision.net.il (8.6.9/8.6.6) with SMTP id JAA22789 for ; Mon, 20 Feb 1995 09:14:44 +0200 Message-Id: <199502200714.JAA22789@Burka.NetVision.net.il> X-Authentication-Warning: Burka.NetVision.net.il: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.5.3 12/28/94 To: current@FreeBSD.org Subject: tkined/scotty Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Feb 1995 09:14:44 +0200 From: Gennady Sorokopud Sender: current-owner@FreeBSD.org Precedence: bulk Hello! I uploaded tkined & scotty ports/packages for -current to freebsd.cdrom.com /pub/FreeBSD/incoming . scotty-1.2.0.tgz - scotty package tkined-1.2.0.tgz - tkined package scotty.tar.gz - scotty port tkined.tar.gz - tkined port Regards. OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO O Gennady Sorokopud O O O O System programmer at NetVision Israel O O Home of Israeli Internet O O O O E-Mail: gena@netvision.net.il O O O O http: http://www.netvision.net.il/~gena/ O O Tel: home: 972-4-9931-594 Address: Sharet st. 11/13 O O work: 972-4-440-330 K. Tivon , Israel O OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQBNAi43i2YAAAECANV6d3p8bQLR6Hr2tyd9f4FEUakUIbF0YOtsiil3hR/ebGRe y4EC2Y45ZS7VPiP8Pp8zyAinWEtJ/tBKBYoHdPEABRG0LEdlbm5hZHkgQi4gU29y b2tvcHVkIDxnZW5hQG5ldHZpc2lvbi5uZXQuaWw+ =bvR+ -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-current Sun Feb 19 23:44:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA01070 for current-outgoing; Sun, 19 Feb 1995 23:44:27 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id XAA01061 for ; Sun, 19 Feb 1995 23:44:23 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id XAA18530; Sun, 19 Feb 1995 23:43:31 -0800 From: "Rodney W. Grimes" Message-Id: <199502200743.XAA18530@gndrsh.aac.dev.com> Subject: Re: libcompat and shlib conflict To: nate@trout.sri.MT.net (Nate Williams) Date: Sun, 19 Feb 1995 23:43:31 -0800 (PST) Cc: current@freefall.cdrom.com In-Reply-To: <199502200534.WAA01333@trout.sri.MT.net> from "Nate Williams" at Feb 19, 95 10:34:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1716 Sender: current-owner@FreeBSD.org Precedence: bulk > > [ Multiple definitions of regerror() in libcompat ] > > > > However, the newest ld is giving me errors trying to build > > > libcompat (correctly so) with multiple definitions of the function > > > regerror(), which is defined in both libcompat/4.3/regex.c and > > > libcompat/regexp/regerror.c. > > Does anyone know what should be done here? NetBSD just ignores the > problem by not making a shared library. The problem still exists though > since at link time I'm not sure which version of regerror() will get > used, and a quick perusal of the code makes it obvious that they can't > be combined into one function. I'm sure the function that is first > found would be the first function linked in, but that could change > depending on the other functions in the library and tsort. > > We either need to completely remove one of the functions, or ignore the > problem and only build a static library which avoids the error at the > cost of later problems in code. (But, I suppose folks shouldn't be > using the compat libraries anyway, right. :( ) > > What say you? I am not much of an export on this issue, but we defanitly need to do something about cleaning it up. Another anomoly caused by this is: hookturn# man -k regerr regcomp(3), regexec(3), regerror(3), regfree(3) - regular-expression library regcomp(3), regexec(3), regsub(3), regerror(3) - regular expression handlers I can get the first man page for sure with `man regfree' and the second one with `man regsub' but I am not sure where the links for the other ones point :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Sun Feb 19 23:45:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA01092 for current-outgoing; Sun, 19 Feb 1995 23:45:23 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id XAA01085; Sun, 19 Feb 1995 23:45:22 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Poul-Henning Kamp cc: current@FreeBSD.org Subject: Re: CTM In-reply-to: Your message of "Sun, 19 Feb 95 20:27:33 PST." <199502200427.UAA16820@ref.tfs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Feb 1995 23:45:22 -0800 Message-ID: <1084.793266322@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > > Let it be known... CTM has moved to freefall. > > If you access the "cvs-cur" tree, you need to pick up the deltas in > > /home/ctm/CTM-priv/cvs-cur Is there documentation on how to use all this? We need a step-by-step guide on "going -current with CTM." Otherwise they're going to ask -questions and everyone still on that list will hate you! :-) Jordan From owner-freebsd-current Mon Feb 20 00:22:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id AAA01588 for current-outgoing; Mon, 20 Feb 1995 00:22:48 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id AAA01582 for ; Mon, 20 Feb 1995 00:22:44 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id AAA18613; Mon, 20 Feb 1995 00:21:57 -0800 From: "Rodney W. Grimes" Message-Id: <199502200821.AAA18613@gndrsh.aac.dev.com> Subject: Re: Bad file retrieved in latest sup To: Remy.Card@masi.ibp.fr (Remy CARD) Date: Mon, 20 Feb 1995 00:21:57 -0800 (PST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199502200643.HAA08576@hebe.ibp.fr> from "Remy CARD" at Feb 20, 95 07:43:58 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 986 Sender: current-owner@FreeBSD.org Precedence: bulk > > > Hi, > > It seems that a bad file is stored in the CVS repository: > pascal>sup -d -v freebsd.supfile usrsbin > SUP 8.26 (4.3 BSD) for file freebsd.supfile at Feb 20 07:49:34 > SUP: supfilesrv/tcp: unknown service: using port 871 > SUP Upgrade of usrsbin at Mon Feb 20 07:49:35 1995 > SUP Fileserver 8.13 (4.3 BSD) 260 on freefall.cdrom.com at 07:49:35 > SUP Requesting changes since Feb 20 04:44:40 1995 > SUP Using compressed file transfer > SUP Receiving file usr.sbin/config/.#mkswapconf.c.1.4 > SUP Upgrade of usrsbin completed at Feb 20 07:49:58 1995 > > Can someone please remove it? This was caused by a cvs update merge conflict on Freefall, some one had been playing in /usr/src. I cleared the conflict but forget to remove cvs's droppings. Thanks for bringing this to my attention, it has been corrected. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Mon Feb 20 02:29:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA04053 for current-outgoing; Mon, 20 Feb 1995 02:29:34 -0800 Received: from dns.netvision.net.il (root@dns.NetVision.net.il [194.90.1.5]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA04042; Mon, 20 Feb 1995 02:29:19 -0800 Received: from ugen.NetManage.co.il (ugen.netmanage.co.il [192.114.78.165]) by dns.netvision.net.il (8.6.9/8.6.9) with SMTP id MAA17053; Mon, 20 Feb 1995 12:27:56 +0200 Date: Mon, 20 Feb 95 12:30:27 IST From: "Ugen J.S.Antsilevich" Subject: Re: CTM To: Poul-Henning Kamp , "Jordan K. Hubbard" Cc: current@FreeBSD.org X-Mailer: Chameleon 4.00-Arm-25, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: current-owner@FreeBSD.org Precedence: bulk >> >> Let it be known... CTM has moved to freefall. >> >> If you access the "cvs-cur" tree, you need to pick up the deltas in >> >> /home/ctm/CTM-priv/cvs-cur > >Is there documentation on how to use all this? We need a step-by-step >guide on "going -current with CTM." Otherwise they're going to ask >-questions and everyone still on that list will hate you! :-) Yeh..what is CTM???How does it works??Should i use it instead of cvs or something??? > > Jordan > -- -=Ugen J.S.Antsilevich=- NetVision - Israeli Commercial Internet | Learning E-mail: ugen@NetVision.net.il | To Fly. [c] Phone : +972-4-550330 | From owner-freebsd-current Mon Feb 20 02:34:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA04243 for current-outgoing; Mon, 20 Feb 1995 02:34:20 -0800 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA04235 for ; Mon, 20 Feb 1995 02:34:16 -0800 Received: from gilberto.physik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HN9RLA0BRK000R1K@mail.rwth-aachen.de>; Mon, 20 Feb 1995 11:34:56 +0100 Received: by gilberto.physik.rwth-aachen.de (LAA25930); Mon, 20 Feb 1995 11:40:42 +0100 Date: Mon, 20 Feb 1995 11:40:42 +0100 From: "Christoph P. Kukulies" Subject: setconf (autoconf) in kernel build undef'd To: freebsd-current@freefall.cdrom.com Message-id: <199502201040.LAA25930@gilberto.physik.rwth-aachen.de> Content-transfer-encoding: 7BIT Sender: current-owner@FreeBSD.org Precedence: bulk Don't know if this is a late consequence of the freefall outage but my most recent kernel build failed by this: -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 -c vers.c loading kernel autoconf.o: Undefined symbol `_setconf' referenced from text segment *** Error code 1 Stop. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Mon Feb 20 03:01:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA06717 for current-outgoing; Mon, 20 Feb 1995 03:01:06 -0800 Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id DAA06620 for ; Mon, 20 Feb 1995 03:00:41 -0800 Received: from g386bsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1) id AA15490; Mon, 20 Feb 95 11:59:23 +0100 Received: by g386bsd.first.gmd.de (MAA27926); Mon, 20 Feb 1995 12:01:31 +0100 From: Andreas Schulz Message-Id: <199502201101.MAA27926@g386bsd.first.gmd.de> Subject: Re: setconf (autoconf) in kernel build undef'd To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Date: Mon, 20 Feb 1995 12:01:30 +0059 (MET) Cc: freebsd-current@freefall.cdrom.com In-Reply-To: <199502201040.LAA25930@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Feb 20, 95 11:40:42 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 558 Sender: current-owner@FreeBSD.org Precedence: bulk > Don't know if this is a late consequence of the freefall outage > but my most recent kernel build failed by this: > > -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 -c vers.c > loading kernel > autoconf.o: Undefined symbol `_setconf' referenced from text segment > *** Error code 1 rebuilt config. ATS ( ats@first.gmd.de or ats@cs.tu-berlin.de ) Andreas Schulz GMD-FIRST 12489 Berlin-Adlershof Rudower Chaussee 5 Gebaeude 13.7 Tel: +49-30-6392-1856/+49-177-2134745 Germany/Europe From owner-freebsd-current Mon Feb 20 03:12:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA08469 for current-outgoing; Mon, 20 Feb 1995 03:12:02 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id DAA08455 for ; Mon, 20 Feb 1995 03:11:49 -0800 Received: by sequent.kiae.su id AA09565 (5.65.kiae-2 ); Mon, 20 Feb 1995 14:05:02 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 20 Feb 95 14:05:01 +0300 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id OAA00650; Mon, 20 Feb 1995 14:02:25 +0300 To: current@freefall.cdrom.com, Nate Williams References: <199502200135.SAA29159@trout.sri.MT.net> In-Reply-To: <199502200135.SAA29159@trout.sri.MT.net>; from Nate Williams at Sun, 19 Feb 1995 18:35:40 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 20 Feb 1995 14:02:25 +0300 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: libcompat and shlib conflict Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 992 Sender: current-owner@FreeBSD.org Precedence: bulk In message <199502200135.SAA29159@trout.sri.MT.net> Nate Williams writes: >Umm, forgive me if this sounds silly, but does the old shared library >loader NOT complain about multiply defined symbols when it tries to >build libcompat? The reason I'm asking is that I'm attempting to bring >in the newest ld (once more) to hopefully finish off the shilb code >merge. However, the newest ld is giving me errors trying to build >libcompat (correctly so) with multiple definitions of the function >regerror(), which is defined in both libcompat/4.3/regex.c and >libcompat/regexp regerror.c. Only one of those modules normally picked, not both. So, conflict never happens. It is error in newest ld. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Feb 20 03:30:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA11231 for current-outgoing; Mon, 20 Feb 1995 03:30:10 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id DAA11193 for ; Mon, 20 Feb 1995 03:29:59 -0800 Received: by sequent.kiae.su id AA14105 (5.65.kiae-2 ); Mon, 20 Feb 1995 14:20:16 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 20 Feb 95 14:20:12 +0300 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id OAA00772; Mon, 20 Feb 1995 14:21:36 +0300 To: Nate Williams , "Rodney W. Grimes" Cc: current@freefall.cdrom.com References: <199502200534.WAA01333@trout.sri.MT.net> In-Reply-To: <199502200534.WAA01333@trout.sri.MT.net>; from Nate Williams at Sun, 19 Feb 1995 22:34:04 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 20 Feb 1995 14:21:36 +0300 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: libcompat and shlib conflict Lines: 43 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2017 Sender: current-owner@FreeBSD.org Precedence: bulk In message <199502200534.WAA01333@trout.sri.MT.net> Nate Williams writes: >[ Multiple definitions of regerror() in libcompat ] >> > However, the newest ld is giving me errors trying to build >> > libcompat (correctly so) with multiple definitions of the function >> > regerror(), which is defined in both libcompat/4.3/regex.c and >> > libcompat/regexp/regerror.c. >Does anyone know what should be done here? NetBSD just ignores the >problem by not making a shared library. The problem still exists though >since at link time I'm not sure which version of regerror() will get >used, and a quick perusal of the code makes it obvious that they can't >be combined into one function. I'm sure the function that is first >found would be the first function linked in, but that could change >depending on the other functions in the library and tsort. >We either need to completely remove one of the functions, or ignore the >problem and only build a static library which avoids the error at the >cost of later problems in code. (But, I suppose folks shouldn't be >using the compat libraries anyway, right. :( ) >What say you? There is historically two regex interfaces: regexp & regex. _Both_ have regerror(), it is right. Only _one_ interface can be picked. If you pick regex module, you pick regerror() too from same file. Be shure that your regerror() call not first call in pgm in this case. If you pick regexp module, regerror() from there must be first in library. Current tsort does just right thing placing it first. I just build libcompat without any problems. Maybe better variant will be to merge both regerror() function into one function which is ruled by setting global variables into regex & regexp. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Feb 20 03:54:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA13897 for current-outgoing; Mon, 20 Feb 1995 03:54:47 -0800 Received: from zibbi.mikom.csir.co.za (some.schmuck.lame.delegated.to.RAIN.PSG.COM [146.64.24.58]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id DAA13870 for ; Mon, 20 Feb 1995 03:54:31 -0800 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.9/8.6.6) id NAA11973; Mon, 20 Feb 1995 13:47:02 +0200 From: John Hay Message-Id: <199502201147.NAA11973@zibbi.mikom.csir.co.za> Subject: Re: setconf (autoconf) in kernel build undef'd To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Date: Mon, 20 Feb 1995 13:47:01 +0200 (SAT) Cc: freebsd-current@freefall.cdrom.com In-Reply-To: <199502201040.LAA25930@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Feb 20, 95 11:40:42 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 445 Sender: current-owner@FreeBSD.org Precedence: bulk > Don't know if this is a late consequence of the freefall outage > but my most recent kernel build failed by this: > > -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 -c vers.c > loading kernel > autoconf.o: Undefined symbol `_setconf' referenced from text segment > *** Error code 1 > > Stop. > Just recompile config and config your kernel again. -- John Hay -- jhay@mikom.csir.co.za From owner-freebsd-current Mon Feb 20 04:35:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id EAA19842 for current-outgoing; Mon, 20 Feb 1995 04:35:27 -0800 Received: from amcell2.caisr.cwru.edu (amcell2.CAISR.CWRU.Edu [129.22.24.2]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id EAA19833 for ; Mon, 20 Feb 1995 04:35:25 -0800 Received: (from ljo@localhost) by amcell2.caisr.cwru.edu (8.6.9/8.6.6) id HAA01665; Mon, 20 Feb 1995 07:33:36 -0500 Date: Mon, 20 Feb 1995 07:33:36 -0500 From: L Jonas Olsson Message-Id: <199502201233.HAA01665@amcell2.caisr.cwru.edu> To: nate@trout.sri.MT.net CC: rgrimes@gndrsh.aac.dev.com, current@freefall.cdrom.com In-reply-to: <199502200534.WAA01333@trout.sri.MT.net> (message from Nate Williams on Sun, 19 Feb 1995 22:34:04 -0700) Subject: Re: libcompat and shlib conflict Reply-to: ljo@po.CWRU.Edu Sender: current-owner@FreeBSD.org Precedence: bulk Isn't the idea not to have a shared libcompat? This library is supposed to disappear (at least some functions in it) and we don't want binaries to depend on having these functions in new releases. This also gives an extra incentive to fix programs that use it as their binaries will be larger :) Jonas From owner-freebsd-current Mon Feb 20 05:11:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id FAA21351 for current-outgoing; Mon, 20 Feb 1995 05:11:19 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id FAA21337 for ; Mon, 20 Feb 1995 05:11:14 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA24395; Tue, 21 Feb 1995 00:05:15 +1100 Date: Tue, 21 Feb 1995 00:05:15 +1100 From: Bruce Evans Message-Id: <199502201305.AAA24395@godzilla.zeta.org.au> To: freebsd-current@freefall.cdrom.com, kuku@gilberto.physik.rwth-aachen.de Subject: Re: mcrt0.o Sender: current-owner@FreeBSD.org Precedence: bulk >This is the second post from my site that didn't appear in the list. >Anyway, I'm repeating: >in proflibs of 0202SNAP mcrt0.o isn't included. I wanted >to profile a program and ld claims that mcrt0.o is missing. >I can't locate mcrt0.o in the -current tree either. >Is it missing or gone? Or am I missing something? FreeBSD doesn't support profiling by `prof' (cc -p ...), so don't attempt to use it. FreeBSD supports profiling by `gprof' (cc -pg ...). Bruce From owner-freebsd-current Mon Feb 20 06:59:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id GAA23432 for current-outgoing; Mon, 20 Feb 1995 06:59:08 -0800 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id GAA23426 for ; Mon, 20 Feb 1995 06:59:01 -0800 Received: from gilberto.physik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HNA0UHXXM8000YMA@mail.rwth-aachen.de>; Mon, 20 Feb 1995 15:59:41 +0100 Received: by gilberto.physik.rwth-aachen.de (QAA26393); Mon, 20 Feb 1995 16:05:34 +0100 Date: Mon, 20 Feb 1995 16:05:34 +0100 From: "Christoph P. Kukulies" Subject: kernel build still fails (snic.h) To: freebsd-current@freefall.cdrom.com Message-id: <199502201505.QAA26393@gilberto.physik.rwth-aachen.de> Content-transfer-encoding: 7BIT Sender: current-owner@FreeBSD.org Precedence: bulk blues# make cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -I. -I../.. -I../../sys ../../i386/i386/conf.c:861: snic.h: No such file or dctory *** Error code 1 Stop. I did a make includes, I rebuilt config. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Mon Feb 20 08:49:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA27983 for current-outgoing; Mon, 20 Feb 1995 08:49:30 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id IAA27977 for ; Mon, 20 Feb 1995 08:49:29 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03124; Mon, 20 Feb 95 09:42:53 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502201642.AA03124@cs.weber.edu> Subject: Re: libcompat and shlib conflict To: ljo@po.CWRU.Edu Date: Mon, 20 Feb 95 9:42:52 MST Cc: nate@trout.sri.MT.net, rgrimes@gndrsh.aac.dev.com, current@freefall.cdrom.com In-Reply-To: <199502201233.HAA01665@amcell2.caisr.cwru.edu> from "L Jonas Olsson" at Feb 20, 95 07:33:36 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > Isn't the idea not to have a shared libcompat? This library is > supposed to disappear (at least some functions in it) and we don't > want binaries to depend on having these functions in new releases. > This also gives an extra incentive to fix programs that use it as > their binaries will be larger :) A program compiled with a static libcompat as opposed to a dynamic libcompat is more likely to correctly match another platforms ABI in any case. Not only are we not guaranteed that the external globals linked into your program and referenced by the libcompat routines will be the same on another platform (causing their shared libcompat to fail), but the cruft in libcompat is likely as not going to be different from vendor to vendor anyway. Specifically, the libcompat is cruft to act as glue between an old program that everyone is too lazy to rewrite, and new interfaces for which specifications are available. The cost of the cruft should be bourne by the crufty program. As someone else noted, think of it as incentive to do what should have been done instead of using libcompat in the first place. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Feb 20 09:49:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA29047 for current-outgoing; Mon, 20 Feb 1995 09:49:43 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA29041 for ; Mon, 20 Feb 1995 09:49:39 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA28927; Tue, 21 Feb 1995 04:45:26 +1100 Date: Tue, 21 Feb 1995 04:45:26 +1100 From: Bruce Evans Message-Id: <199502201745.EAA28927@godzilla.zeta.org.au> To: roberto@blaise.ibp.fr Subject: Re: Fix for libc/gen/errlst.c warning Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Here is a fix for the warning one get when compiling libc's gen/errlst.c : >Index: stdio.h >-extern int sys_nerr; /* perror(3) external variables */ >+extern __const int sys_nerr; /* perror(3) external variables */ > extern __const char *__const sys_errlist[]; I've made this change too, but I expect it to break a few ports when it is applied (I've only compiled about 5 ports here). Bruce From owner-freebsd-current Mon Feb 20 09:56:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA29159 for current-outgoing; Mon, 20 Feb 1995 09:56:18 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA29153 for ; Mon, 20 Feb 1995 09:56:13 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id KAA06118; Mon, 20 Feb 1995 10:59:44 -0700 Date: Mon, 20 Feb 1995 10:59:44 -0700 From: Nate Williams Message-Id: <199502201759.KAA06118@trout.sri.MT.net> In-Reply-To: "Andrey A. Chernov, Black Mage" "Re: libcompat and shlib conflict" (Feb 20, 2:02pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Andrey A. Chernov, Black Mage" , current@freefall.cdrom.com Subject: Re: libcompat and shlib conflict Sender: current-owner@FreeBSD.org Precedence: bulk [ Two modules defining regerror ] > Only one of those modules normally picked, not both. So, conflict > never happens. It is error in newest ld. Umm, which modules gets picked? What if I want one module, and not the other? There *is* a conflict in that two modules in the same library are defining the same function. Nate From owner-freebsd-current Mon Feb 20 10:56:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA01543 for current-outgoing; Mon, 20 Feb 1995 10:56:00 -0800 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA01533 for ; Mon, 20 Feb 1995 10:55:58 -0800 Received: from gilberto.physik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HNA949QK680011FW@mail.rwth-aachen.de>; Mon, 20 Feb 1995 19:56:37 +0100 Received: by gilberto.physik.rwth-aachen.de (UAA26821); Mon, 20 Feb 1995 20:02:24 +0100 Date: Mon, 20 Feb 1995 20:02:24 +0100 (MET) From: Christoph Kukulies Subject: Re: kernel build still fails (snic.h) In-reply-to: <199502201505.QAA26393@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Feb 20, 95 04:05:34 pm To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Cc: freebsd-current@freefall.cdrom.com (user alias) Reply-to: Christoph Kukulies Message-id: <199502201902.UAA26821@gilberto.physik.rwth-aachen.de> X-Mailer: ELM [version 2.4 PL23] Content-type: text Content-transfer-encoding: 7BIT Content-length: 604 Sender: current-owner@FreeBSD.org Precedence: bulk I wrote: > > blues# make > cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -I. -I../.. -I../../sys > ../../i386/i386/conf.c:861: snic.h: No such file or dctory > *** Error code 1 > > Stop. > > I did a make includes, I rebuilt config. > > I'm afraid my sup tree has somehow got out of sync (due to the accident on freefall) and it will take some time to be in sync again. So please discard. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Mon Feb 20 11:16:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA03244 for current-outgoing; Mon, 20 Feb 1995 11:16:11 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id LAA03041 for ; Mon, 20 Feb 1995 11:13:39 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA11001; Mon, 20 Feb 1995 19:54:15 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id TAA27867 for freebsd-current@FreeBSD.org; Mon, 20 Feb 1995 19:54:14 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id SAA05968 for freebsd-current@FreeBSD.org; Mon, 20 Feb 1995 18:18:50 +0100 From: J Wunsch Message-Id: <199502201718.SAA05968@uriah.heep.sax.de> Subject: Re: libcompat and shlib conflict To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 20 Feb 1995 18:18:49 +0100 (MET) In-Reply-To: from "Andrey A. Chernov, Black Mage" at Feb 20, 95 02:21:36 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 540 Sender: current-owner@FreeBSD.org Precedence: bulk As Andrey A. Chernov, Black Mage wrote: > > There is historically two regex interfaces: regexp & regex. > _Both_ have regerror(), it is right. ... > Maybe better variant will be to merge both regerror() function > into one function which is ruled by setting global variables > into regex & regexp. Or maybe one of them should make it into a different libregex (with a pointer in the man page)? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Feb 20 11:45:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA04984 for current-outgoing; Mon, 20 Feb 1995 11:45:37 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id LAA04978 for ; Mon, 20 Feb 1995 11:45:33 -0800 Received: by sequent.kiae.su id AA02348 (5.65.kiae-2 ); Mon, 20 Feb 1995 22:39:17 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 20 Feb 95 22:39:16 +0300 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id WAA01054; Mon, 20 Feb 1995 22:32:56 +0300 To: current@freefall.cdrom.com, Nate Williams References: <199502201759.KAA06118@trout.sri.MT.net> In-Reply-To: <199502201759.KAA06118@trout.sri.MT.net>; from Nate Williams at Mon, 20 Feb 1995 10:59:44 -0700 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 20 Feb 1995 22:32:56 +0300 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: libcompat and shlib conflict Lines: 26 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1038 Sender: current-owner@FreeBSD.org Precedence: bulk In message <199502201759.KAA06118@trout.sri.MT.net> Nate Williams writes: >[ Two modules defining regerror ] >> Only one of those modules normally picked, not both. So, conflict >> never happens. It is error in newest ld. >Umm, which modules gets picked? What if I want one module, and not the >other? There *is* a conflict in that two modules in the same library >are defining the same function. As I already say in previous letter, you can got conflict only in one _very-very_rare_ case: 1) You use regex module. 2) You use regerror() before any regex functions. All other cases handled correctly. Because this case is almost impossible, we don't need to make libcompat static-only, so I stronly recommend to back out your change. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Feb 20 11:46:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA05008 for current-outgoing; Mon, 20 Feb 1995 11:46:08 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id LAA05002 for ; Mon, 20 Feb 1995 11:46:05 -0800 Received: by sequent.kiae.su id AA02368 (5.65.kiae-2 ); Mon, 20 Feb 1995 22:39:20 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 20 Feb 95 22:39:19 +0300 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id WAA01072; Mon, 20 Feb 1995 22:37:44 +0300 To: ljo@po.CWRU.Edu, Terry Lambert Cc: current@freefall.cdrom.com, nate@trout.sri.MT.net, rgrimes@gndrsh.aac.dev.com References: <9502201642.AA03124@cs.weber.edu> In-Reply-To: <9502201642.AA03124@cs.weber.edu>; from Terry Lambert at Mon, 20 Feb 95 9:42:52 MST Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 20 Feb 1995 22:37:44 +0300 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: libcompat and shlib conflict Lines: 24 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1178 Sender: current-owner@FreeBSD.org Precedence: bulk In message <9502201642.AA03124@cs.weber.edu> Terry Lambert writes: >A program compiled with a static libcompat as opposed to a dynamic >libcompat is more likely to correctly match another platforms ABI >in any case. Not only are we not guaranteed that the external >globals linked into your program and referenced by the libcompat >routines will be the same on another platform (causing their shared >libcompat to fail), but the cruft in libcompat is likely as not >going to be different from vendor to vendor anyway. If you look in, you can see, that other platforms do just the same thing, only one condition needs to be present: regerror module itself must be placed before regex module, as already done. >The cost of the cruft should be bourne by the crufty program. Too many crufty pgms in the world. You don't have enough power to teach whole world which functions to use. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Feb 20 11:54:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA05132 for current-outgoing; Mon, 20 Feb 1995 11:54:41 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id LAA05126 for ; Mon, 20 Feb 1995 11:54:36 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id MAA07136; Mon, 20 Feb 1995 12:58:09 -0700 Date: Mon, 20 Feb 1995 12:58:09 -0700 From: Nate Williams Message-Id: <199502201958.MAA07136@trout.sri.MT.net> In-Reply-To: "Andrey A. Chernov, Black Mage" "Re: libcompat and shlib conflict" (Feb 20, 10:32pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Andrey A. Chernov, Black Mage" , current@freefall.cdrom.com Subject: Re: libcompat and shlib conflict Sender: current-owner@FreeBSD.org Precedence: bulk > >[ Two modules defining regerror ] > > >> Only one of those modules normally picked, not both. So, conflict > >> never happens. It is error in newest ld. > > >Umm, which modules gets picked? What if I want one module, and not the > >other? There *is* a conflict in that two modules in the same library > >are defining the same function. > > As I already say in previous letter, you can got conflict only > in one _very-very_rare_ case: > 1) You use regex module. > 2) You use regerror() before any regex functions. > All other cases handled correctly. It is *possible* that order of the library will change, and conflicts will occur if a new module is added, or an old one is removed. This is unacceptable behavior. We can not depend on the current ordering of the library being the same as it is now. Nate From owner-freebsd-current Mon Feb 20 11:56:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA05148 for current-outgoing; Mon, 20 Feb 1995 11:56:41 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id LAA05142 for ; Mon, 20 Feb 1995 11:56:36 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id NAA07147; Mon, 20 Feb 1995 13:00:10 -0700 Date: Mon, 20 Feb 1995 13:00:10 -0700 From: Nate Williams Message-Id: <199502202000.NAA07147@trout.sri.MT.net> In-Reply-To: "Andrey A. Chernov, Black Mage" "Re: libcompat and shlib conflict" (Feb 20, 10:37pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Andrey A. Chernov, Black Mage" Subject: Re: libcompat and shlib conflict Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > >A program compiled with a static libcompat as opposed to a dynamic > >libcompat is more likely to correctly match another platforms ABI > >in any case. Not only are we not guaranteed that the external > >globals linked into your program and referenced by the libcompat > >routines will be the same on another platform (causing their shared > >libcompat to fail), but the cruft in libcompat is likely as not > >going to be different from vendor to vendor anyway. > > If you look in, you can see, that other platforms do just the same thing, > only one condition needs to be present: regerror module itself > must be placed before regex module, as already done. You didn't understand what Terry was saying. There is no guarantee that the same modules exist in a different vendor's libcompat. > >The cost of the cruft should be bourne by the crufty program. > > Too many crufty pgms in the world. You don't have enough power > to teach whole world which functions to use. So, does that mean we shouldn't at least try? We continue to provide libcompat, just not a shared version. This means that binaries compiled with -lcompat will be *more* portable across multiple vendors and releases than version relying on the shlib providing the old interfaces. Nate From owner-freebsd-current Mon Feb 20 12:02:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA05567 for current-outgoing; Mon, 20 Feb 1995 12:02:51 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id MAA05561 for ; Mon, 20 Feb 1995 12:02:48 -0800 Received: by sequent.kiae.su id AA04360 (5.65.kiae-2 for freebsd-current@freefall.cdrom.com); Mon, 20 Feb 1995 22:49:27 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 20 Feb 95 22:49:26 +0300 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id WAA01193 for freebsd-current@freefall.cdrom.com; Mon, 20 Feb 1995 22:50:58 +0300 To: freebsd-current@freefall.cdrom.com Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 20 Feb 1995 22:50:58 +0300 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Alternate solution for libcompat Lines: 9 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 508 Sender: current-owner@FreeBSD.org Precedence: bulk Look at libcompat structure, it is well separated, maybe it will be nice to make several libcompats from tree, i.e. libcompat4.3, libcompat4.4, libregexp, etc. We easily avoid conflict pointed by nate in this case. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Feb 20 12:28:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA06343 for current-outgoing; Mon, 20 Feb 1995 12:28:04 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA06337 for ; Mon, 20 Feb 1995 12:27:59 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id NAA07242; Mon, 20 Feb 1995 13:31:32 -0700 Date: Mon, 20 Feb 1995 13:31:32 -0700 From: Nate Williams Message-Id: <199502202031.NAA07242@trout.sri.MT.net> In-Reply-To: "Andrey A. Chernov, Black Mage" "Alternate solution for libcompat" (Feb 20, 10:50pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Andrey A. Chernov, Black Mage" , freebsd-current@freefall.cdrom.com Subject: Re: Alternate solution for libcompat Sender: current-owner@FreeBSD.org Precedence: bulk > Look at libcompat structure, it is well separated, > maybe it will be nice to make several libcompats from tree, > i.e. libcompat4.3, libcompat4.4, libregexp, etc. > We easily avoid conflict pointed by nate in this case. Yuck! The purpose of libcompat is to provide *old* interfaces to programs that haven't yet been updated. We are making this *way* more complicated than it needs to be. The current setup w/out the shlib will work, and it's easy to program for and understand. By adding lots of 'compat' libraries it gets very complicated. Also, the programs that need -lcompat *should* be updated to use the newer functions, and by leaving libcompat as the junk library, it let's the programmer who uses them know that those interfaces will go away in the next major revision of the OS. (Ex: FreeBSD 3.0 *grin*) Nate From owner-freebsd-current Mon Feb 20 13:12:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA08126 for current-outgoing; Mon, 20 Feb 1995 13:12:33 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id NAA08098 for ; Mon, 20 Feb 1995 13:12:24 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id NAA20022; Mon, 20 Feb 1995 13:11:17 -0800 From: "Rodney W. Grimes" Message-Id: <199502202111.NAA20022@gndrsh.aac.dev.com> Subject: Re: Alternate solution for libcompat To: nate@trout.sri.MT.net (Nate Williams) Date: Mon, 20 Feb 1995 13:11:17 -0800 (PST) Cc: ache@astral.msk.su, freebsd-current@freefall.cdrom.com In-Reply-To: <199502202031.NAA07242@trout.sri.MT.net> from "Nate Williams" at Feb 20, 95 01:31:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2904 Sender: current-owner@FreeBSD.org Precedence: bulk > > > Look at libcompat structure, it is well separated, > > maybe it will be nice to make several libcompats from tree, > > i.e. libcompat4.3, libcompat4.4, libregexp, etc. > > We easily avoid conflict pointed by nate in this case. > > Yuck! The purpose of libcompat is to provide *old* interfaces to > programs that haven't yet been updated. We are making this *way* more > complicated than it needs to be. The current setup w/out the shlib will > work, and it's easy to program for and understand. By adding lots of > 'compat' libraries it gets very complicated. > > Also, the programs that need -lcompat *should* be updated to use the > newer functions, and by leaving libcompat as the junk library, it let's > the programmer who uses them know that those interfaces will go away in > the next major revision of the OS. (Ex: FreeBSD 3.0 *grin*) Some one had better get to work on some of the code then: hookturn:rgrimes {156} find . -name Makefile | xargs grep lcompat ./games/atc/Makefile:LDADD= -ll -lm -lcurses -ltermcap -lcompat ./games/backgammon/backgammon/Makefile:LDADD= -ltermcap -lcompat ./games/backgammon/teachgammon/Makefile:LDADD= -ltermcap -lcompat ./games/battlestar/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/canfield/canfield/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/cribbage/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/fortune/fortune/Makefile:LDADD= -lcompat ./games/hack/Makefile:LDADD= -ltermcap -lcompat ./games/hangman/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/larn/Makefile:LDADD= -ltermcap -lcompat ./games/mille/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/phantasia/Makefile:LDADD= -lm -lcurses -ltermcap -lcompat ./games/rain/Makefile:LDADD= -ltermcap -lcompat ./games/robots/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/rogue/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/sail/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/snake/snake/Makefile:LDADD= -lm -ltermcap -lcompat ./games/trek/Makefile:LDADD= -lm -lcompat ./games/worm/Makefile:LDADD= -lcurses -ltermcap -lcompat ./games/worms/Makefile:LDADD= -lcurses -ltermcap -lcompat ./gnu/lib/libg++/Makefile:LDADD+= -lcurses -lcompat ./gnu/usr.bin/gdb/gdb/Makefile:LDADD+= -lcompat ./sbin/mount_portal/Makefile:LDADD= -lcompat ./usr.bin/more/Makefile:LDADD= -ltermcap -lcompat ./usr.bin/msgs/Makefile:LDADD= -ltermcap -lcompat ./usr.bin/rdist/Makefile:LDADD= -lcompat ./usr.bin/talk/Makefile:LDADD= -lcurses -ltermcap -lcompat ./usr.sbin/XNSrouted/Makefile:LDADD= -lcompat ./usr.sbin/routed/Makefile:LDADD= -lcompat hookturn:rgrimes {157} Hummmm.. mount_portal, what where them there programmers thinking :-( -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Mon Feb 20 13:21:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA08828 for current-outgoing; Mon, 20 Feb 1995 13:21:46 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id NAA08812 for ; Mon, 20 Feb 1995 13:21:39 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id OAA07397; Mon, 20 Feb 1995 14:24:50 -0700 Date: Mon, 20 Feb 1995 14:24:50 -0700 From: Nate Williams Message-Id: <199502202124.OAA07397@trout.sri.MT.net> In-Reply-To: "Rodney W. Grimes" "Re: Alternate solution for libcompat" (Feb 20, 1:11pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Rodney W. Grimes" Subject: Re: Alternate solution for libcompat Cc: ache@astral.msk.su, freebsd-current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > > Also, the programs that need -lcompat *should* be updated to use the > > newer functions, and by leaving libcompat as the junk library, it let's > > the programmer who uses them know that those interfaces will go away in > > the next major revision of the OS. (Ex: FreeBSD 3.0 *grin*) > > Some one had better get to work on some of the code then: Yep, someone better. :-) .... [ list of programs in -current tree deleted ] > Hummmm.. mount_portal, what where them there programmers thinking :-( Sigh, the games I can understand, but some of the newer ones I don't get. Nate From owner-freebsd-current Mon Feb 20 13:50:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA12386 for current-outgoing; Mon, 20 Feb 1995 13:50:23 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id NAA12376 for ; Mon, 20 Feb 1995 13:50:17 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA04487; Mon, 20 Feb 1995 16:49:54 -0500 Date: Mon, 20 Feb 1995 16:49:54 -0500 From: Garrett Wollman Message-Id: <9502202149.AA04487@halloran-eldar.lcs.mit.edu> To: terry@cs.weber.edu (Terry Lambert) Cc: current@freefall.cdrom.com Subject: Re: libcompat and shlib conflict In-Reply-To: <9502201642.AA03124@cs.weber.edu> References: <199502201233.HAA01665@amcell2.caisr.cwru.edu> <9502201642.AA03124@cs.weber.edu> Sender: current-owner@FreeBSD.org Precedence: bulk < The cost of the cruft should be bourne by the crufty program. ^^^^^^ Freudian slip here, Terry? -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Mon Feb 20 14:14:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA13581 for current-outgoing; Mon, 20 Feb 1995 14:14:01 -0800 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA13568 for ; Mon, 20 Feb 1995 14:13:49 -0800 Received: by sequent.kiae.su id AA15443 (5.65.kiae-2 ); Tue, 21 Feb 1995 01:10:25 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 21 Feb 95 01:10:25 +0300 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id BAA01690; Tue, 21 Feb 1995 01:11:33 +0300 To: Nate Williams , "Rodney W. Grimes" Cc: freebsd-current@freefall.cdrom.com References: <199502202111.NAA20022@gndrsh.aac.dev.com> In-Reply-To: <199502202111.NAA20022@gndrsh.aac.dev.com>; from "Rodney W. Grimes" at Mon, 20 Feb 1995 13:11:17 -0800 (PST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 21 Feb 1995 01:11:33 +0300 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: Alternate solution for libcompat Lines: 21 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 725 Sender: current-owner@FreeBSD.org Precedence: bulk In message <199502202111.NAA20022@gndrsh.aac.dev.com> Rodney W. Grimes writes: >Some one had better get to work on some of the code then: >hookturn:rgrimes {156} find . -name Makefile | xargs grep lcompat >./games/atc/Makefile:LDADD= -ll -lm -lcurses -ltermcap -lcompat [skipped] And many ports use it too... Maybe split it into two parts? 1) regexp code into libregexp library 2) other stuff into libcompat library -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-current Mon Feb 20 14:31:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA14823 for current-outgoing; Mon, 20 Feb 1995 14:31:57 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA14799 for ; Mon, 20 Feb 1995 14:31:47 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA04916; Mon, 20 Feb 95 15:24:47 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502202224.AA04916@cs.weber.edu> Subject: Re: libcompat and shlib conflict To: ache@astral.msk.su (Andrey A. Chernov, Black Mage) Date: Mon, 20 Feb 95 15:24:47 MST Cc: ljo@po.CWRU.Edu, current@freefall.cdrom.com, nate@trout.sri.MT.net, rgrimes@gndrsh.aac.dev.com In-Reply-To: from "Andrey A. Chernov, Black Mage" at Feb 20, 95 10:37:44 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > >The cost of the cruft should be bourne by the crufty program. > > Too many crufty pgms in the world. You don't have enough power > to teach whole world which functions to use. You can make teaching them the default if you are willing to further obfuscate or even kill libcompat, IMO. The programs people really want will end up fixed because they have no other choice. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Feb 20 14:35:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA15234 for current-outgoing; Mon, 20 Feb 1995 14:35:19 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA15213 for ; Mon, 20 Feb 1995 14:35:14 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA04952; Mon, 20 Feb 95 15:28:55 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502202228.AA04952@cs.weber.edu> Subject: Re: libcompat and shlib conflict To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Mon, 20 Feb 95 15:28:54 MST Cc: current@freefall.cdrom.com In-Reply-To: <9502202149.AA04487@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Feb 20, 95 04:49:54 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > The cost of the cruft should be bourne by the crufty program. > ^^^^^^ > Freudian slip here, Terry? Subliminal advertising for csh. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Feb 20 14:48:44 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA17406 for current-outgoing; Mon, 20 Feb 1995 14:48:44 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA17372 for ; Mon, 20 Feb 1995 14:48:35 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.8/jtpda-5.0) with SMTP id XAA23244 for ; Mon, 20 Feb 1995 23:50:12 +0100 Received: by blaise.ibp.fr (4.1/SMI-4.1) id AA20112; Mon, 20 Feb 95 23:47:52 +0100 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.6.9/keltia-uucp-1.21) id XAA08885 for freebsd-current@FreeBSD.ORG; Mon, 20 Feb 1995 23:44:39 +0100 From: Ollivier Robert Message-Id: <199502202244.XAA08885@keltia.frmug.fr.net> Subject: Unknown structures in sysctl To: freebsd-current@FreeBSD.org (FreeBSD Current Users' list) Date: Mon, 20 Feb 1995 23:44:33 +0100 (MET) Reply-To: roberto@blaise.ibp.fr (Ollivier Robert) X-Operating-System: FreeBSD 2.1.0-Development ctm#373 X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 449 Sender: current-owner@FreeBSD.org Precedence: bulk Is it expected or am I missing something ? net.inet.icmp.stats: unknown structure returned net.inet.igmp.stats: unknown structure returned net.inet.tcp.stats: unknown structure returned net.inet.udp.stats: unknown structure returned I've recompiled sysctl(8) and am running a saturday kernel. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.1.0-Development #9: Sat Feb 18 19:21:00 MET 1995 From owner-freebsd-current Mon Feb 20 15:05:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA20068 for current-outgoing; Mon, 20 Feb 1995 15:05:00 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA19889; Mon, 20 Feb 1995 15:04:24 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.8/jtpda-5.0) with SMTP id AAA23364 ; Tue, 21 Feb 1995 00:06:07 +0100 Received: by blaise.ibp.fr (4.1/SMI-4.1) id AA20156; Tue, 21 Feb 95 00:03:47 +0100 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.6.9/keltia-uucp-1.21) id AAA09544; Tue, 21 Feb 1995 00:00:41 +0100 From: Ollivier Robert Message-Id: <199502202300.AAA09544@keltia.frmug.fr.net> Subject: Symbol undefined in vm_page.c : ACT_MAX To: freebsd-bugs@FreeBSD.org (FreeBSD Bugs' list), freebsd-current@FreeBSD.org (FreeBSD Current Users' list) Date: Tue, 21 Feb 1995 00:00:39 +0100 (MET) Reply-To: roberto@hsc.fr.net X-Operating-System: FreeBSD 2.1.0-Development ctm#373 X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1419 Sender: current-owner@FreeBSD.org Precedence: bulk Last ctm patch from today, CTM_BEGIN 2.0 cvs-cur 377 19950220154143Z . cc -c -O -m486 -pipe -W -Wreturn-type -Wcomment -Wredundant-decls -I. -I../.. -I../../sys -DKELTIA -DI486_CPU -DEXCLUDE_PRO_MIDI -DEXCLUDE_PAS -DEXCLUDE_PSS -DEXCLUDE_MSS -DEXCLUDE_GUS16 -DEXCLUDE_GUSMAX -DEXCLUDE_GUS_IODETECT -DEXCLUDE_GUS -DKTRACE -DDODUMP -DGATEWAY -DSHMMAXPGS=64 -DSYSVMSG -DSYSVSEM -DSYSVSHM -DDUMMY_NOPS -DAUTO_EOI_2 -DAUTO_EOI_1 -DUCONSOLE -DSCSI_2_DEF -DCOMPAT_43 -DPROCFS -DLFS -DMFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../vm/vm_page.c ../../vm/vm_page.c: In function `vm_page_activate': ../../vm/vm_page.c:1005: `ACT_MAX' undeclared (first use this function) ../../vm/vm_page.c:1005: (Each undeclared identifier is reported only once ../../vm/vm_page.c:1005: for each function it appears in.) *** Error code 1 Stop. ACT_MAX is only defined in vm_pageout.c. I guess it's time to move it to /sys/i386/include/param.h (or elsewhere) I suppose : /usr/include/vm/vm_pageout.c:#define ACT_MAX 100 /usr/include/vm/vm_pageout.c: if (p->act_count < ACT_MAX) /usr/include/vm/vm_pageout.c: if (m->act_count < ACT_MAX) /usr/include/vm/vm_pageout.c: if (m->act_count < ACT_MAX) { -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.1.0-Development #9: Sat Feb 18 19:21:00 MET 1995 From owner-freebsd-current Mon Feb 20 15:13:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA21897 for current-outgoing; Mon, 20 Feb 1995 15:13:56 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id PAA21889 for ; Mon, 20 Feb 1995 15:13:53 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA04700; Mon, 20 Feb 1995 18:13:29 -0500 Date: Mon, 20 Feb 1995 18:13:29 -0500 From: Garrett Wollman Message-Id: <9502202313.AA04700@halloran-eldar.lcs.mit.edu> To: roberto@blaise.ibp.fr (Ollivier Robert) Cc: freebsd-current@FreeBSD.org (FreeBSD Current Users' list) Subject: Unknown structures in sysctl In-Reply-To: <199502202244.XAA08885@keltia.frmug.fr.net> References: <199502202244.XAA08885@keltia.frmug.fr.net> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > Is it expected or am I missing something ? > net.inet.icmp.stats: unknown structure returned > net.inet.igmp.stats: unknown structure returned > net.inet.tcp.stats: unknown structure returned > net.inet.udp.stats: unknown structure returned No, you are not missing anything. `sysctl' is tell you that these variables are not of a type that it knows how to deal with, so it's not going to print them. (This is another effort in my crusade to eliminate use of /dev/kmem wherever there is a better interface.) I fiddled with `sysctl' for about an hour, but no satisfactory solution came about. You're welcome to try if it bothers you that much, -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Mon Feb 20 15:19:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA23053 for current-outgoing; Mon, 20 Feb 1995 15:19:50 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [192.48.107.36]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA22933 for ; Mon, 20 Feb 1995 15:19:24 -0800 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.9/8.6.9) id MAA12218; Sun, 19 Feb 1995 12:58:57 +0100 Date: Sun, 19 Feb 1995 12:58:57 +0100 From: Julian Howard Stacey Message-Id: <199502191158.MAA12218@vector.eikon.e-technik.tu-muenchen.de> To: current@FreeBSD.org Subject: Possible kern.maxproc fatal bug Reply-To: jhs@regent.e-technik.tu-muenchen.de Sender: current-owner@FreeBSD.org Precedence: bulk I report this in case it points a finger towards inadequate limit checking in the kernel: (how i managed to induce the bug, with my mangled ports make set up, doesn't worry me, it's the kernel reaction that is of interest ) As last line in my /etc/rc.local I used to have sysctl -w kern.maxproc=300 An innocent cd /usr/ports ; make -i would then always crash the system (even when compiled as normal user, & with everything in ports having been changed to owner jhs (thus no suid 0 stuff lurking in /usr/ports)). Without the sysctl -w kern.maxproc=300 I would merely get on console: Feb 19 11:38:32 vector kernel.nu: proc: table is full (The system was forking a series of nominal ncftp's & makes recursively) BTW I have: NCFTP=abort /usr/vsl/bin/abort & my abort generates Signal 6 (SIGABRT) I do this as a crude way of forcing make to blunder on & compile most ports, without constantly needing my pay-as-you-use modem slip link. --- Julian Stacey From owner-freebsd-current Mon Feb 20 15:20:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA23217 for current-outgoing; Mon, 20 Feb 1995 15:20:45 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [192.48.107.36]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA23114 for ; Mon, 20 Feb 1995 15:20:04 -0800 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.9/8.6.9) id VAA00372; Sun, 19 Feb 1995 21:45:23 +0100 Date: Sun, 19 Feb 1995 21:45:23 +0100 From: Julian Howard Stacey Message-Id: <199502192045.VAA00372@vector.eikon.e-technik.tu-muenchen.de> To: current@FreeBSD.org Subject: newfs: sectors per cylinder (4096) disagrees with disk label (36) Reply-To: jhs@regent.e-technik.tu-muenchen.de Sender: current-owner@FreeBSD.org Precedence: bulk With system after a make world from current (of Fri 18th Feb), While doing a: cd /usr/src/etc make floppies it blew up with disklabel -w -r -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd fd0 fd1440 newfs -b 4096 -c 80 -f 512 -i 8192 -m 0 -o space rfd0 fd1440 Warning: calculated sectors per cylinder (4096) disagrees with disk label (36) Block size and bytes per inode restrict cylinders per group to 6. I recompiled & installed sbin & disklabel, to no avail, The disklabel command confirms floppy is set to 36 (I'm using a 1.4M flop, so OK) I'm using an old newfs binary for now. Perhaps I have an inconsistent mirror collection, or worse, maybe freebsd has bad newfs sources ? Anyone else see this problem ? --- Julian Stacey , ( is a dial up ) From owner-freebsd-current Mon Feb 20 15:29:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA23935 for current-outgoing; Mon, 20 Feb 1995 15:29:30 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA23910 for ; Mon, 20 Feb 1995 15:29:25 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id PAA05870; Mon, 20 Feb 1995 15:29:05 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id PAA00296; Mon, 20 Feb 1995 15:29:05 -0800 Message-Id: <199502202329.PAA00296@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: roberto@hsc.fr.net cc: freebsd-current@FreeBSD.org (FreeBSD Current Users' list) Subject: Re: Symbol undefined in vm_page.c : ACT_MAX In-reply-to: Your message of "Tue, 21 Feb 95 00:00:39 +0100." <199502202300.AAA09544@keltia.frmug.fr.net> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 20 Feb 1995 15:29:03 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >Last ctm patch from today, > >CTM_BEGIN 2.0 cvs-cur 377 19950220154143Z . > >cc -c -O -m486 -pipe -W -Wreturn-type -Wcomment -Wredundant-decls -I. -I../.. -I../../sys -DKELTIA -DI486_CPU -DEXCLUDE_PRO_MIDI -DEXCLUDE_PAS -DEXCLUDE_PSS -DEXCLUDE_MSS -DEXCLUDE_GUS16 -DEXCLUDE_GUSMAX -DEXCLUDE_GUS_IODETECT -DEXCLUDE_GUS -DKTRACE -DDODUMP -DGATEWAY -DSHMMAXPGS=64 -DSYSVMSG -DSYSVSEM -DSYSVSHM -DDUMMY_NOPS -DAUTO_EOI_2 -DAUTO_EOI_1 -DUCONSOLE -DSCSI_2_DEF -DCOMPAT_43 -DPROCFS -DLFS -DMFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../vm/vm_page.c >../../vm/vm_page.c: In function `vm_page_activate': >../../vm/vm_page.c:1005: `ACT_MAX' undeclared (first use this function) >../../vm/vm_page.c:1005: (Each undeclared identifier is reported only once >../../vm/vm_page.c:1005: for each function it appears in.) >*** Error code 1 > >Stop. > >ACT_MAX is only defined in vm_pageout.c. I guess it's time to move it to >/sys/i386/include/param.h (or elsewhere) I suppose : No, it belongs in vm_page.h. I just forgot to commit that change. -DG From owner-freebsd-current Mon Feb 20 15:34:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA24651 for current-outgoing; Mon, 20 Feb 1995 15:34:36 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA24641 for ; Mon, 20 Feb 1995 15:34:33 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id PAA05882; Mon, 20 Feb 1995 15:32:44 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id PAA00309; Mon, 20 Feb 1995 15:32:43 -0800 Message-Id: <199502202332.PAA00309@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: jhs@regent.e-technik.tu-muenchen.de cc: current@FreeBSD.org Subject: Re: Possible kern.maxproc fatal bug In-reply-to: Your message of "Sun, 19 Feb 95 12:58:57 +0100." <199502191158.MAA12218@vector.eikon.e-technik.tu-muenchen.de> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 20 Feb 1995 15:32:35 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >I report this in case it points a finger towards inadequate limit checking in >the kernel: > (how i managed to induce the bug, with my mangled ports make set up, > doesn't worry me, it's the kernel reaction that is of interest ) > >As last line in my /etc/rc.local I used to have > sysctl -w kern.maxproc=300 >An innocent > cd /usr/ports ; make -i >would then always crash the system (even when compiled as normal user, >& with everything in ports having been changed to owner jhs (thus no suid 0 >stuff lurking in /usr/ports)). Probably because the proc table is not dynamically sized. Basically, you can't change maxproc - it probably should not by managed by sysctl. >I would merely get on console: > Feb 19 11:38:32 vector kernel.nu: proc: table is full >(The system was forking a series of nominal ncftp's & makes recursively) Increase the maxusers parameter in your kernel config file. -DG From owner-freebsd-current Mon Feb 20 15:59:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA01125 for current-outgoing; Mon, 20 Feb 1995 15:59:00 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA01113 for ; Mon, 20 Feb 1995 15:58:59 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.8/jtpda-5.0) with SMTP id BAA23877 ; Tue, 21 Feb 1995 01:00:42 +0100 Received: by blaise.ibp.fr (4.1/SMI-4.1) id AA20364; Tue, 21 Feb 95 00:58:23 +0100 From: roberto@blaise.ibp.fr (Ollivier ROBERT) Message-Id: <9502202358.AA20364@blaise.ibp.fr> Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) To: jhs@regent.e-technik.tu-muenchen.de Date: Tue, 21 Feb 1995 00:58:22 +0100 (MET) Cc: current@FreeBSD.org In-Reply-To: <199502192045.VAA00372@vector.eikon.e-technik.tu-muenchen.de> from "Julian Howard Stacey" at Feb 19, 95 09:45:23 pm X-Operating-System: FreeBSD 2.1.0-Development ctm#375 X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 411 Sender: current-owner@FreeBSD.org Precedence: bulk > Warning: calculated sectors per cylinder (4096) disagrees with disk label (36) > or worse, maybe freebsd has bad newfs sources ? > Anyone else see this problem ? You can get the same message by mounting an mfs in the swap on /tmp. Weel, I get it at each boot... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.1.0-Development #9: Sat Feb 18 19:21:00 MET 1995 From owner-freebsd-current Mon Feb 20 17:26:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA27197 for current-outgoing; Mon, 20 Feb 1995 17:26:53 -0800 Received: (from dima@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA27162; Mon, 20 Feb 1995 17:26:52 -0800 Message-Id: <199502210126.RAA27162@freefall.cdrom.com> Subject: Re: setconf (autoconf) in kernel build undef'd To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Date: Mon, 20 Feb 1995 17:26:52 -0800 (PST) Cc: freebsd-current@freefall.cdrom.com In-Reply-To: <199502201040.LAA25930@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Feb 20, 95 11:40:42 am From: dima@FreeBSD.org (Dima Ruban) X-Class: Fast Organization: HackerDome X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 654 Sender: current-owner@FreeBSD.org Precedence: bulk Christoph P. Kukulies writes: > > > Don't know if this is a late consequence of the freefall outage > but my most recent kernel build failed by this: > > -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 -c vers.c > loading kernel > autoconf.o: Undefined symbol `_setconf' referenced from text segment > *** Error code 1 you should recompile /usr/sbin/config first > > Stop. > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 > 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 > -- dima From owner-freebsd-current Mon Feb 20 17:27:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA27803 for current-outgoing; Mon, 20 Feb 1995 17:27:22 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA27680 for ; Mon, 20 Feb 1995 17:27:15 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id RAA20482; Mon, 20 Feb 1995 17:25:30 -0800 From: "Rodney W. Grimes" Message-Id: <199502210125.RAA20482@gndrsh.aac.dev.com> Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) To: jhs@regent.e-technik.tu-muenchen.de Date: Mon, 20 Feb 1995 17:25:29 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: <199502192045.VAA00372@vector.eikon.e-technik.tu-muenchen.de> from "Julian Howard Stacey" at Feb 19, 95 09:45:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1348 Sender: current-owner@FreeBSD.org Precedence: bulk > > With system after a make world from current (of Fri 18th Feb), > While doing a: > cd /usr/src/etc > make floppies > it blew up with > disklabel -w -r -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd fd0 fd1440 > newfs -b 4096 -c 80 -f 512 -i 8192 -m 0 -o space rfd0 fd1440 > Warning: calculated sectors per cylinder (4096) disagrees with disk label (36) > Block size and bytes per inode restrict cylinders per group to 6. > I recompiled & installed sbin & disklabel, to no avail, > The disklabel command confirms floppy is set to 36 > (I'm using a 1.4M flop, so OK) > I'm using an old newfs binary for now. > Perhaps I have an inconsistent mirror collection, > or worse, maybe freebsd has bad newfs sources ? > Anyone else see this problem ? This is caused by phk's changes to the behavior of newfs, it now uses 1 head/cylinder, 4096 sectors/track by default. This was an attempt to increase performace. I have found that it does nothing for any disks I use and just leads to problems while newfsing several of them. You can revert to the old behavior my adding -t 0 -u 0 to the newfs commands, which causes newfs to use the head/cylinder and sectors/track from the disklabel. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Mon Feb 20 17:37:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA01499 for current-outgoing; Mon, 20 Feb 1995 17:37:49 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA01476 for ; Mon, 20 Feb 1995 17:37:44 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id RAA20889; Mon, 20 Feb 1995 17:37:25 -0800 From: Poul-Henning Kamp Message-Id: <199502210137.RAA20889@ref.tfs.com> Subject: Re: Lock file in cvs tree To: roberto@blaise.ibp.fr Date: Mon, 20 Feb 1995 17:37:24 -0800 (PST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199502202222.XAA07167@keltia.frmug.fr.net> from "Ollivier Robert" at Feb 20, 95 11:22:30 pm Content-Type: text Content-Length: 402 Sender: current-owner@FreeBSD.org Precedence: bulk > There is a stale lock file in sys/miscfs/procfs in the CVS tree : > > extract from cvs-cur.0377 : > > CTM_BEGIN 2.0 cvs-cur 377 19950220154143Z . > ... > > FM src/sys/miscfs/procfs/#cvs.wfl.25214 > ... ctm-cvs-cur users will have to zap this one themselves. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Mon Feb 20 17:54:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA07424 for current-outgoing; Mon, 20 Feb 1995 17:54:53 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA07416 for ; Mon, 20 Feb 1995 17:54:52 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id RAA20970; Mon, 20 Feb 1995 17:54:15 -0800 From: Poul-Henning Kamp Message-Id: <199502210154.RAA20970@ref.tfs.com> Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 20 Feb 1995 17:54:14 -0800 (PST) Cc: jhs@regent.e-technik.tu-muenchen.de, current@FreeBSD.org In-Reply-To: <199502210125.RAA20482@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Feb 20, 95 05:25:29 pm Content-Type: text Content-Length: 455 Sender: current-owner@FreeBSD.org Precedence: bulk > This is caused by phk's changes to the behavior of newfs, it now > uses 1 head/cylinder, 4096 sectors/track by default. This was an > attempt to increase performace. I have found that it does nothing > for any disks I use and just leads to problems while newfsing several > of them. How did you measure this ? -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Mon Feb 20 18:23:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA17745 for current-outgoing; Mon, 20 Feb 1995 18:23:28 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA17723 for ; Mon, 20 Feb 1995 18:23:24 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id SAA20630; Mon, 20 Feb 1995 18:22:33 -0800 From: "Rodney W. Grimes" Message-Id: <199502210222.SAA20630@gndrsh.aac.dev.com> Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Mon, 20 Feb 1995 18:22:32 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: <199502210154.RAA20970@ref.tfs.com> from "Poul-Henning Kamp" at Feb 20, 95 05:54:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 641 Sender: current-owner@FreeBSD.org Precedence: bulk > > > This is caused by phk's changes to the behavior of newfs, it now > > uses 1 head/cylinder, 4096 sectors/track by default. This was an > > attempt to increase performace. I have found that it does nothing > > for any disks I use and just leads to problems while newfsing several > > of them. > How did you measure this ? Iozone using auto and 128 8192 and dd to/from /dev/{null,zero}. Note that the newfs code already defeats the rotational delay stuff by -n 1 -d 0 defaults. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Mon Feb 20 18:26:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA18841 for current-outgoing; Mon, 20 Feb 1995 18:26:43 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA18833 for ; Mon, 20 Feb 1995 18:26:42 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id SAA21140; Mon, 20 Feb 1995 18:26:18 -0800 From: Poul-Henning Kamp Message-Id: <199502210226.SAA21140@ref.tfs.com> Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 20 Feb 1995 18:26:18 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: <199502210222.SAA20630@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Feb 20, 95 06:22:32 pm Content-Type: text Content-Length: 788 Sender: current-owner@FreeBSD.org Precedence: bulk > > > This is caused by phk's changes to the behavior of newfs, it now > > > uses 1 head/cylinder, 4096 sectors/track by default. This was an > > > attempt to increase performace. I have found that it does nothing > > > for any disks I use and just leads to problems while newfsing several > > > of them. > > How did you measure this ? > > Iozone using auto and 128 8192 and dd to/from /dev/{null,zero}. > Note that the newfs code already defeats the rotational delay stuff > by -n 1 -d 0 defaults. > Try this: newfs /dev/rsdXy mount /dev/sdXy /mnt (cd /usr/src ; find . -print | cpio -dumpV /mnt) time tar cf /dev/null /mnt umount /mnt -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Mon Feb 20 23:00:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA09675 for current-outgoing; Mon, 20 Feb 1995 23:00:10 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id WAA09665 for ; Mon, 20 Feb 1995 22:59:49 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA08777; Tue, 21 Feb 1995 17:55:53 +1100 Date: Tue, 21 Feb 1995 17:55:53 +1100 From: Bruce Evans Message-Id: <199502210655.RAA08777@godzilla.zeta.org.au> To: obiwan!bob@uudell.us.dell.com, roberto@blaise.ibp.fr Subject: Re: ATTENTION Cc: current@FreeBSD.org, phk@ref.tfs.com Sender: current-owner@FreeBSD.org Precedence: bulk >>[slices] >1. what will it change ? Mainly sd.c and wd.c. The specialness of the 'd' partition will go away and you will have to use (e.g.) /dev/sd0 instead of /dev/sd0d. Almost nothing used /dev/sd0d (fdisk, sysinstall and benchmarks are the only things that should have used it), so you won't notice in normal operation. >2. how do we convert from the old system ? Simply compiling the new version should be enough to get ordinary ufs partitions working. The bootstrap will probably complain about 'd' partitions and may complain about MSDOS partitions and delete them from the in-core disklabel (partitions not within the BSD slice are not allowed). You can delete the bogus partitions to get rid of the warnings. I keep them for testing. To get at (primary) MSDOS slices that are no longer in the label, you have to edit /etc/fstab to give the new name of the slice, e.g., /dev/sd0s1 (DOSpartition 1). If you want new features such as more than one BSD slices, then you have to edit /etc/fstab some more and /dev/MAKEDEV to create the new devices (there are too many possible devices to create by default and I haven't added nonstandard cases yet). If the second BSD slice is /dev/sd0s3, then you would need devices /dev/[r]sd0s3[a-h]. Booting from BSD slices after the first is currently not supported. >3. if someone wants to stay as is it now, will it be possible or > will slices be mandatory ? The slice code will be mandatory but you won't see much evidence of it. However, there is a lot of compatibility cruft to make the old devices work transparently. I'd like this to go away soon. Devices would have to be named differently in /etc/fstab and in config files, e.g., /dev/sd0s2a instead of /dev/sd0a if /dev/sd0s2 is the first BSD slice. (The partitions on the first BSD slice in the DOSpartition table are aliased to /dev/[r]sd0[a-h]. This requires confusing minor numbering: name slice bits in minor DOSpartition number [r]sd0[a-h] 0 << 21 aliased [r]sd0[c] 1 << 21 none [r]sd0s1[a-h] 2 << 21 1 .... [r]sd0s4[a-h] 5 << 21 4). >4. will it require to have a DOS partition or not. ? Not necessary. The case BSD on the whole disk hasn't been tested much. I think it works with a correct DOSpartition table (covering the whole disk) or no DOSpartition table (no 0xAA55 signature). Unfortunately, the standard bootstrap creates an incorrect DOSpartition table. This case will probably work too, by throwing out the table. Bruce From owner-freebsd-current Mon Feb 20 23:45:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id XAA10549 for current-outgoing; Mon, 20 Feb 1995 23:45:10 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id XAA10536 for ; Mon, 20 Feb 1995 23:44:57 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA09650; Tue, 21 Feb 1995 18:39:49 +1100 Date: Tue, 21 Feb 1995 18:39:49 +1100 From: Bruce Evans Message-Id: <199502210739.SAA09650@godzilla.zeta.org.au> To: phk@ref.tfs.com, roberto@blaise.ibp.fr Subject: Re: Lock file in cvs tree Cc: freebsd-current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> There is a stale lock file in sys/miscfs/procfs in the CVS tree : >> >> extract from cvs-cur.0377 : >> >> CTM_BEGIN 2.0 cvs-cur 377 19950220154143Z . >> ... >> > FM src/sys/miscfs/procfs/#cvs.wfl.25214 >> ... >ctm-cvs-cur users will have to zap this one themselves. Won't ctm get around to zapping it? Zapping junk imported by ctm usually breaks the ctm update that deletes it. Bruce From owner-freebsd-current Tue Feb 21 00:20:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id AAA11199 for current-outgoing; Tue, 21 Feb 1995 00:20:46 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id AAA11192 for ; Tue, 21 Feb 1995 00:20:21 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA10312; Tue, 21 Feb 1995 19:18:14 +1100 Date: Tue, 21 Feb 1995 19:18:14 +1100 From: Bruce Evans Message-Id: <199502210818.TAA10312@godzilla.zeta.org.au> To: davidg@Root.COM, jhs@regent.e-technik.tu-muenchen.de Subject: Re: Possible kern.maxproc fatal bug Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >>As last line in my /etc/rc.local I used to have >> sysctl -w kern.maxproc=300 >>An innocent >> cd /usr/ports ; make -i >>would then always crash the system (even when compiled as normal user, >>& with everything in ports having been changed to owner jhs (thus no suid 0 >>stuff lurking in /usr/ports)). > Probably because the proc table is not dynamically sized. Basically, you >can't change maxproc - it probably should not by managed by sysctl. But it is dynamically sized. I can't see any problems that would cause a panic. Old rlimits for RLIMIT_NPROC become bogus when maxproc is changed but this probably won't cause a panic. Bruce From owner-freebsd-current Tue Feb 21 01:12:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id BAA12409 for current-outgoing; Tue, 21 Feb 1995 01:12:43 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id BAA12401; Tue, 21 Feb 1995 01:12:40 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: obiwan!bob@uudell.us.dell.com, roberto@blaise.ibp.fr, current@FreeBSD.org, phk@ref.tfs.com Subject: Re: ATTENTION In-reply-to: Your message of "Tue, 21 Feb 95 17:55:53 +1100." <199502210655.RAA08777@godzilla.zeta.org.au> Date: Tue, 21 Feb 1995 01:12:35 -0800 Message-ID: <12396.793357955@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > The slice code will be mandatory but you won't see much evidence of > it. However, there is a lot of compatibility cruft to make the old > devices work transparently. I'd like this to go away soon. Devices > would have to be named differently in /etc/fstab and in config files, > e.g., /dev/sd0s2a instead of /dev/sd0a if /dev/sd0s2 is the first BSD > slice. (The partitions on the first BSD slice in the DOSpartition > table are aliased to /dev/[r]sd0[a-h]. This requires confusing Well, as far as I'm concerned the flag day has already been called and we can just do this in one jump. Slow transitions can be just as bad or worse than jumps, in my experience, and I'm keen to see this go forward so that we can start relying on the slice code for the new installation code. Jordan From owner-freebsd-current Tue Feb 21 01:16:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id BAA12646 for current-outgoing; Tue, 21 Feb 1995 01:16:30 -0800 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id BAA12634 for ; Tue, 21 Feb 1995 01:16:10 -0800 Received: from gilberto.physik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HNB35MFM680012UG@mail.rwth-aachen.de>; Tue, 21 Feb 1995 10:16:42 +0100 Received: by gilberto.physik.rwth-aachen.de (KAA10599); Tue, 21 Feb 1995 10:22:26 +0100 Date: Tue, 21 Feb 1995 10:22:26 +0100 From: "Christoph P. Kukulies" Subject: snic.h (conf.c) To: freebsd-current@freefall.cdrom.com Message-id: <199502210922.KAA10599@gilberto.physik.rwth-aachen.de> Content-transfer-encoding: 7BIT Sender: current-owner@FreeBSD.org Precedence: bulk First I thought of a sup problem but now it looks like a problem to me  . From owner-freebsd-current Tue Feb 21 01:19:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id BAA12804 for current-outgoing; Tue, 21 Feb 1995 01:19:54 -0800 Received: from zibbi.mikom.csir.co.za (some.schmuck.lame.delegated.to.RAIN.PSG.COM [146.64.24.58]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id BAA12781 for ; Tue, 21 Feb 1995 01:19:33 -0800 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.9/8.6.6) id KAA02454; Tue, 21 Feb 1995 10:46:48 +0200 From: John Hay Message-Id: <199502210846.KAA02454@zibbi.mikom.csir.co.za> Subject: Re: Lock file in cvs tree To: bde@zeta.org.au (Bruce Evans) Date: Tue, 21 Feb 1995 10:46:48 +0200 (SAT) Cc: phk@ref.tfs.com, roberto@blaise.ibp.fr, freebsd-current@FreeBSD.org In-Reply-To: <199502210739.SAA09650@godzilla.zeta.org.au> from "Bruce Evans" at Feb 21, 95 06:39:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 705 Sender: current-owner@FreeBSD.org Precedence: bulk > >> There is a stale lock file in sys/miscfs/procfs in the CVS tree : > >> > >> extract from cvs-cur.0377 : > >> > >> CTM_BEGIN 2.0 cvs-cur 377 19950220154143Z . > >> ... > >> > FM src/sys/miscfs/procfs/#cvs.wfl.25214 > >> ... > >ctm-cvs-cur users will have to zap this one themselves. > > Won't ctm get around to zapping it? Zapping junk imported by ctm > usually breaks the ctm update that deletes it. > > Bruce > While you have that file, cvs won't check that directory out because it thinks that another cvs is busy in that directory. It wiil just wait for that file to disappear. So I won't be able to do a checkout until a ctm arrive that deletes it:( -- John Hay -- jhay@mikom.csir.co.za From owner-freebsd-current Tue Feb 21 02:05:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA16070 for current-outgoing; Tue, 21 Feb 1995 02:05:30 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA16022; Tue, 21 Feb 1995 02:05:02 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA12502; Tue, 21 Feb 1995 21:02:13 +1100 Date: Tue, 21 Feb 1995 21:02:13 +1100 From: Bruce Evans Message-Id: <199502211002.VAA12502@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@freefall.cdrom.com Subject: Re: ATTENTION Cc: current@FreeBSD.org, obiwan!bob@uudell.us.dell.com, phk@ref.tfs.com, roberto@blaise.ibp.fr Sender: current-owner@FreeBSD.org Precedence: bulk >> The slice code will be mandatory but you won't see much evidence of >> it. However, there is a lot of compatibility cruft to make the old >> devices work transparently. I'd like this to go away soon. Devices >Well, as far as I'm concerned the flag day has already been called >and we can just do this in one jump. Slow transitions can be just >as bad or worse than jumps, in my experience, and I'm keen to see this >go forward so that we can start relying on the slice code for the new >installation code. Removing the compatibility cruft would cause the following problems: - almost all disk labels would have to be changed. Old versions of FreeBSD wouldn't be able to read new labels and vice versa. (Even with the compatibility cruft, other BSD's will have problems reading FreeBSD labels if more than one FreeBSD partition is used.) - all disk devices in /dev would have to be removed and rebuilt. - almost all disk devices in fstab and config would have to be renamed - the device name changes aren't backwards compatibile either. They are easier to back out than the label changes iff you can find a compatible kernel to boot from. - all backups of /dev would have to fixed to not use a crufty program/ format such as tar, pax or the default cpio. I forgot to say that they will need to be fixed anyway. The following backup programs/ formats work right: dump, `cpio -newdc'. I think making all these changes together is too much. It would be too hard to install them automatically without a complete reinstall. The compatibility cruft hides most of the interface changes so there is little to worry about except bugs (bugs are most likely in the compatibility cruft since it was written last :-). Bruce From owner-freebsd-current Tue Feb 21 02:08:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA16346 for current-outgoing; Tue, 21 Feb 1995 02:08:52 -0800 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA16333 for ; Tue, 21 Feb 1995 02:08:40 -0800 Received: from gilberto.physik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HNB4Z742O00012TW@mail.rwth-aachen.de>; Tue, 21 Feb 1995 11:08:47 +0100 Received: by gilberto.physik.rwth-aachen.de (LAA10761); Tue, 21 Feb 1995 11:14:39 +0100 Date: Tue, 21 Feb 1995 11:14:38 +0100 (MET) From: Christoph Kukulies Subject: Re: snic.h (conf.c) In-reply-to: <199502210922.KAA10599@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Feb 21, 95 10:22:26 am To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Cc: freebsd-current@freefall.cdrom.com (user alias) Reply-to: Christoph Kukulies Message-id: <199502211014.LAA10761@gilberto.physik.rwth-aachen.de> X-Mailer: ELM [version 2.4 PL23] Content-type: text Content-transfer-encoding: 7BIT Content-length: 407 Sender: current-owner@FreeBSD.org Precedence: bulk > > First I thought of a sup problem but now it looks like a problem to > me >  > > > . Sorry, that was an unwanted mail launching. I wanted to say that snic.h is not being generated by config. > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Tue Feb 21 02:41:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA21131 for current-outgoing; Tue, 21 Feb 1995 02:41:48 -0800 Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id CAA21102 for ; Tue, 21 Feb 1995 02:41:33 -0800 Received: from rks32.pcs.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA09284; Tue, 21 Feb 95 02:39:39 -0800 Received: by rks32.pcs.dec.com (Smail3.1.27.1 #16) id m0rgryf-0005PMC; Tue, 21 Feb 95 11:37 MEZ Message-Id: To: current%freebsd.org@inet-gw-1.pa.dec.com In-Reply-To: Message from Bruce Evans of Tue, 21 Feb 95 21:02:13 X. Reply-To: gj@FreeBSD.org Subject: Re: ATTENTION Date: Tue, 21 Feb 95 10:37:57 GMT From: "gj%pcs.dec.com@inet-gw-1.pa.dec.com" Sender: current-owner@FreeBSD.org Precedence: bulk Bruce Evans gives several good reasons why the compatibility cruft is needed [deleted] I have to agree with Bruce, it's very important in my eyes to make a slow transition to the new slice code until the kernel is 100% stable. If a user makes the full transition running an older kernel and then moves to a new one only to discover that there's some bug which prevents a successful boot, he's pretty much up the creek. His old backup kernel won't understand the new slice stuff in fstab and /dev. If, on the other hand, he uses a new kernel (with the old stuff in fstab and /dev at boot) to do the transition and then somehow the slice code doesn't work, he's just as far up the creek. Of course, there's no reason why the old and new devices can't co-exist in /dev until everything's been shaken out. But this still leaves the fstab problem. A new install using the slice stuff shouldn't be a problem, since everything get's installed from scratch (assuming the new slice code has really been wrung out). I realize this is sort of a chicken and egg problem, since somebody has to test the new code. Since I have two systems I'm more than willing to act as guinea pig. Not to imply that Bruce hasn't thorughly tested the new code. Gary J. From owner-freebsd-current Tue Feb 21 02:49:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA22370 for current-outgoing; Tue, 21 Feb 1995 02:49:43 -0800 Received: from dns.netvision.net.il (root@dns.NetVision.net.il [194.90.1.5]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA22316 for ; Tue, 21 Feb 1995 02:49:26 -0800 Received: from ugen.NetManage.co.il (ugen.netmanage.co.il [192.114.78.165]) by dns.netvision.net.il (8.6.9/8.6.9) with SMTP id MAA26233 for ; Tue, 21 Feb 1995 12:48:30 +0200 Date: Tue, 21 Feb 95 12:51:25 IST From: "Ugen J.S.Antsilevich" Subject: Hardware list???? To: freebsd-current@freefall.cdrom.com X-Mailer: Chameleon 4.00-Arm-25, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Do we have a full supported hardware list for FreeBSD-current or at least for 2.0RELEASE??? We definitely should have one.... -- -=Ugen J.S.Antsilevich=- NetVision - Israeli Commercial Internet | Learning E-mail: ugen@NetVision.net.il | To Fly. [c] Phone : +972-4-550330 | From owner-freebsd-current Tue Feb 21 03:17:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA26660 for current-outgoing; Tue, 21 Feb 1995 03:17:07 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id DAA26596; Tue, 21 Feb 1995 03:16:44 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA13910; Tue, 21 Feb 1995 22:10:36 +1100 Date: Tue, 21 Feb 1995 22:10:36 +1100 From: Bruce Evans Message-Id: <199502211110.WAA13910@godzilla.zeta.org.au> To: jkh@freefall.cdrom.com, rgrimes@gndrsh.aac.dev.com Subject: Re: pax and gzip botch.. Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk >> ld: Unexpected multiple definitions of symbol `_warn', type 0x1 >This was caused by the changes to src/lib/libc/locale, the local startup >stuff now calls err/warn/..., this causes err.o to be loaded in all programs >from libc. I think the opposite is the case. collate.c was changed to _not_ call err/warn. The change isn't quite right. err() writes to stdout while __collate_err() writes to STDERR_FILENO. There is a difference if stderr is buffer. stdio uses special code to avoid this bug for perror(). It should use and export a general function __write_stderr(). I'm running the library from a couple of days ago and have some locale changes but don't have the linkage problems. >Is warn/err/... in the POSIX name space or not? This may simply be namespace >pollution from libc that needs fixed, or namespace pollution in all the >other sources :-(. They are in the user namespace, like about 90% of the names in libc. Bruce From owner-freebsd-current Tue Feb 21 03:52:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA04132 for current-outgoing; Tue, 21 Feb 1995 03:52:35 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id DAA04101 for ; Tue, 21 Feb 1995 03:52:27 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id DAA07072; Tue, 21 Feb 1995 03:52:04 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id DAA00893; Tue, 21 Feb 1995 03:52:03 -0800 Message-Id: <199502211152.DAA00893@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: Bruce Evans cc: jhs@regent.e-technik.tu-muenchen.de, current@FreeBSD.org Subject: Re: Possible kern.maxproc fatal bug In-reply-to: Your message of "Tue, 21 Feb 95 19:18:14 +1100." <199502210818.TAA10312@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 21 Feb 1995 03:51:57 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >>>As last line in my /etc/rc.local I used to have >>> sysctl -w kern.maxproc=300 >>>An innocent >>> cd /usr/ports ; make -i >>>would then always crash the system (even when compiled as normal user, >>>& with everything in ports having been changed to owner jhs (thus no suid 0 >>>stuff lurking in /usr/ports)). > >> Probably because the proc table is not dynamically sized. Basically, you >>can't change maxproc - it probably should not by managed by sysctl. > >But it is dynamically sized. I can't see any problems that would cause >a panic. Not completely. The problem is that the upages must be mapped in kernel memory. There used to be a problem with allocation failures caused by map fragmentation...until I created a seperate map to contain the upages (kernel stack and 'u' info). The size of this map is calculated at startup time and effectively sets the upper maximum on the total number of processes to whatever "maxproc" was at startup time. Other than creating a "balance set", there really isn't any way of working around this problem other than making the map much large than maxproc (and thus allow maxproc to grow much larger). Perhaps making the map accomodate 2 or 3 times maxproc might be a compromise. -DG From owner-freebsd-current Tue Feb 21 07:04:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA02586 for current-outgoing; Tue, 21 Feb 1995 07:04:11 -0800 Received: from ParC03.MI.Uni-Koeln.DE (ParC03.MI.Uni-Koeln.DE [134.95.212.43]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id HAA02536 for ; Tue, 21 Feb 1995 07:04:01 -0800 Received: by ParC03.MI.Uni-Koeln.DE id AA14424 (5.67b/IDA-1.5 for current@freebsd.org); Tue, 21 Feb 1995 16:03:36 +0100 Message-Id: <199502211503.AA14424@ParC03.MI.Uni-Koeln.DE> From: se@MI.Uni-Koeln.DE (Stefan Esser) Date: Tue, 21 Feb 1995 16:03:36 +0100 In-Reply-To: "Rodney W. Grimes" "Re: newfs: sectors per cylinder (4096) disagrees with disk label (36)" (Feb 20, 17:25) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current@FreeBSD.org Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) Sender: current-owner@FreeBSD.org Precedence: bulk On Feb 20, 17:25, "Rodney W. Grimes" wrote: } Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label } This is caused by phk's changes to the behavior of newfs, it now } uses 1 head/cylinder, 4096 sectors/track by default. This was an } attempt to increase performace. I have found that it does nothing } for any disks I use and just leads to problems while newfsing several } of them. Not surprising. There has been some changes to the default file system parameters, but no change to the block allocation code to reflect this. Since there is only one rotational position now by default (a GOOD thing !), the code that ought to choose a rotational near block, in fact returns a RANDOM block on the (virtual) cylinder (i.e. in a 2MB range with current parameters). This means, a random block within a range of a few (up to 10) cylinders is chosen, if the block succeeding the last one of a file is not free when a file is grown. This can easily be circumvented by a slight modification of the alloc code: Index: ffs_alloc.c =================================================================== RCS file: /usr/cvs/src/sys/ufs/ffs/ffs_alloc.c,v retrieving revision 1.7 diff -C2 -r1.7 ffs_alloc.c *** 1.7 1995/02/14 06:14:28 --- ffs_alloc.c 1995/02/21 14:49:18 *************** *** 913,920 **** * check for a block available on the same cylinder */ ! cylno = cbtocylno(fs, bpref); ! if (cg_blktot(cgp)[cylno] == 0) ! goto norot; ! if (fs->fs_cpc == 0) { /* * Block layout information is not available. --- 913,917 ---- * check for a block available on the same cylinder */ ! if (fs->fs_nrpos <= 1 || fs->fs_cpc == 0) { /* * Block layout information is not available. *************** *** 927,930 **** --- 924,930 ---- goto norot; } + cylno = cbtocylno(fs, bpref); + if (cg_blktot(cgp)[cylno] == 0) + goto norot; /* * check the summary information to see if a block is If there is only one rotational position, then the best strategy is to use the next free logical block succeeding "bpref". (In fact, I've put "#ifdef USE_ROTPOS" around this line and the "#endif" just above the "norot:" label. It's extremely unlikely, that I'll ever connect a device that would use the rot. optimisation code. This results in a slight reduction in code size and avoids an unnecessary test and jump ...) I'd like to apply the above patch (or the "#ifdef" version) to FreeBSD-current. (A similar patch was applied to NetBSD some time ago as a reaction to me pointing the above out in a news group article.) Regards, STefan -- Stefan Esser Internet: Zentrum fuer Paralleles Rechnen Tel: +49 221 4706019 Universitaet zu Koeln FAX: +49 221 4705160 Weyertal 80 50931 Koeln From owner-freebsd-current Tue Feb 21 07:09:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA04386 for current-outgoing; Tue, 21 Feb 1995 07:09:22 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id HAA03501 for ; Tue, 21 Feb 1995 07:06:54 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA12418; Tue, 21 Feb 1995 15:51:15 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id PAA05239; Tue, 21 Feb 1995 15:51:14 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id PAA10150; Tue, 21 Feb 1995 15:38:07 +0100 From: J Wunsch Message-Id: <199502211438.PAA10150@uriah.heep.sax.de> Subject: pcvt in -current To: freebsd-current@FreeBSD.org (FreeBSD-current users), hm@hcs.de (Hellmuth Michaelis), lim@gate.sinica.edu.tw (Carmay Lim) Date: Tue, 21 Feb 1995 15:38:06 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1163 Sender: current-owner@FreeBSD.org Precedence: bulk Wow, i've finally tracked down why pcvt panics a -current kernel. Thanks to the guy who used to be called Carny Lim here (i know it's not your real name, but forgive me: i've forgot it), who provided me with an account on a machine in Taiwan to analyze a kernel core dump for this. The problem is that pcvt used to be a replacement driver for syscons and pccons. Hence it always used the same calling interface as its replacees, so all external entry points are named pc*. Recently, Søren decided to rename the syscons entry points to their new names though, and since we don't have pccons any longer, pcvt dissapeared from the cdevsw[] table. :-( Hellmuth, we need to test for this condition in pccnprobe() instead of falling off the end of cdevsw[] and filling the console structure with bogus values. (panic() is all we can do there, but much better pointing to the source of the evil.) Now i dunno how to handle this at best. IMHO, creating an own cdevsw[] entry is the best solution. Any other opinions? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Feb 21 08:22:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA06512 for current-outgoing; Tue, 21 Feb 1995 08:22:15 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id IAA06505; Tue, 21 Feb 1995 08:22:14 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: current@FreeBSD.org, obiwan!bob@uudell.us.dell.com, phk@ref.tfs.com, roberto@blaise.ibp.fr Subject: Re: ATTENTION In-reply-to: Your message of "Tue, 21 Feb 95 21:02:13 +1100." <199502211002.VAA12502@godzilla.zeta.org.au> Date: Tue, 21 Feb 1995 08:22:13 -0800 Message-ID: <6503.793383733@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I think making all these changes together is too much. It would be > too hard to install them automatically without a complete reinstall. > The compatibility cruft hides most of the interface changes so there > is little to worry about except bugs (bugs are most likely in the > compatibility cruft since it was written last :-). Well, when you put it that way, I agree! :-) Jordan From owner-freebsd-current Tue Feb 21 08:24:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA06542 for current-outgoing; Tue, 21 Feb 1995 08:24:27 -0800 Received: from cybernetics.net (jeffh@server0.cybernetics.net [198.80.48.52]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id IAA06536 for ; Tue, 21 Feb 1995 08:24:25 -0800 Received: by cybernetics.net (4.1/SMI-4.1) id AA05988; Tue, 21 Feb 95 11:24:02 EST Date: Tue, 21 Feb 1995 11:23:59 -0500 (EST) From: Jeff Hoffman To: current@FreeBSD.org Subject: 2.0R, floppy problem Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk I recently posted this question on the Questions mailing list and got no response. I am posting it here in hopes that someone on this list can find the problem and fix it before v2.1. I will do anything I can to help diagnose the problem, and if any of you hackers have any suggestions I am open to anything at this point. As some of you know, when I tried to install 2.0 from my Walnut Creek CD-ROM, I got a hard error when it went to make fd0c root. I got it installed, finally, after using the floppies in the 'newer' directory on freefall. Now I can boot the machine fine, but cannot install anything from floppy (my X server from X Inside.) --- begin forwarded message --- Ok, by downloading the newer 2.0R floppies from freefall, I got FreeBSD to install off of my WC 2.0R CD. Now, for some reason, whenever I try to read a floppy disk (or mount one, or...), I get an error. Here is an example: nexus# mount_msdos /dev/fd0 /mnt fd0c: hard error reading fsbn 0 (ST0 40 ST1 1 ST2 0 cyl 0 hd 0 sec 1) mount_msdos: mount: Input/output error nexus# This is with a DOS-formatted floppy in the drive. When I try to install my X server (AcceleratedX from X Inside, Inc.), I get the following: nexus# tar -xvzf /dev/rfd0 fd0c: hard error reading fsbn 0 of 0-19 (ST0 40 ST1 1 ST2 0 cyl 0 hd 0 sec 1) tar (child): read error on /dev/rfd0 : Input/output error gzip: stdin: unexpected end of file tar: child status returned 1 nexus# does anyone have any idea what is wrong? I re-made my kernel from the srcdist and the whole 9 yards, yet nothing seems to fix the problem. Is there any hope? Jeff -- Jeff Hoffman -- jeffh@cybernetics.net ------------------------------------- "A man facing the light looks not into sorrow, but to to the future...always." WWW: http://www.cybernetics.net/users/jeffh ------------------------------------------------------------------------------ PGP Public Key available on request. From owner-freebsd-current Tue Feb 21 09:04:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA07410 for current-outgoing; Tue, 21 Feb 1995 09:04:46 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA07404 for ; Tue, 21 Feb 1995 09:04:45 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id JAA23539; Tue, 21 Feb 1995 09:04:01 -0800 From: Poul-Henning Kamp Message-Id: <199502211704.JAA23539@ref.tfs.com> Subject: Re: Lock file in cvs tree To: bde@zeta.org.au (Bruce Evans) Date: Tue, 21 Feb 1995 09:04:00 -0800 (PST) Cc: roberto@blaise.ibp.fr, freebsd-current@FreeBSD.org In-Reply-To: <199502210739.SAA09650@godzilla.zeta.org.au> from "Bruce Evans" at Feb 21, 95 06:39:49 pm Content-Type: text Content-Length: 600 Sender: current-owner@FreeBSD.org Precedence: bulk > >> There is a stale lock file in sys/miscfs/procfs in the CVS tree : > >> > >> extract from cvs-cur.0377 : > >> > >> CTM_BEGIN 2.0 cvs-cur 377 19950220154143Z . > >> ... > >> > FM src/sys/miscfs/procfs/#cvs.wfl.25214 > >> ... > >ctm-cvs-cur users will have to zap this one themselves. > > Won't ctm get around to zapping it? Zapping junk imported by ctm > usually breaks the ctm update that deletes it. no ctm will no longer deal with ctm-locks I hope. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Tue Feb 21 09:11:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA08047 for current-outgoing; Tue, 21 Feb 1995 09:11:15 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA08030 for ; Tue, 21 Feb 1995 09:11:11 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id JAA23571; Tue, 21 Feb 1995 09:09:18 -0800 From: Poul-Henning Kamp Message-Id: <199502211709.JAA23571@ref.tfs.com> Subject: Re: Lock file in cvs tree To: jhay@mikom.csir.co.za (John Hay) Date: Tue, 21 Feb 1995 09:09:18 -0800 (PST) Cc: bde@zeta.org.au, roberto@blaise.ibp.fr, freebsd-current@FreeBSD.org In-Reply-To: <199502210846.KAA02454@zibbi.mikom.csir.co.za> from "John Hay" at Feb 21, 95 10:46:48 am Content-Type: text Content-Length: 480 Sender: current-owner@FreeBSD.org Precedence: bulk > While you have that file, cvs won't check that directory out because it thinks > that another cvs is busy in that directory. It wiil just wait for that file > to disappear. > > So I won't be able to do a checkout until a ctm arrive that deletes it:( just delete it by hand. ctm will (hopefully) never again see a cvs-lock of any kind. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Tue Feb 21 10:08:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA03609 for current-outgoing; Tue, 21 Feb 1995 10:08:18 -0800 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA03538 for ; Tue, 21 Feb 1995 10:08:12 -0800 Received: from gilberto.physik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HNBL9N9PZK0014TW@mail.rwth-aachen.de>; Tue, 21 Feb 1995 18:55:21 +0100 Received: by gilberto.physik.rwth-aachen.de (TAA11529); Tue, 21 Feb 1995 19:01:11 +0100 Date: Tue, 21 Feb 1995 19:01:11 +0100 (MET) From: Christoph Kukulies Subject: world build on blues Tue Feb 21 18:35:26 1995 (fwd) To: freebsd-current@freefall.cdrom.com (user alias) Reply-to: Christoph Kukulies Message-id: <199502211801.TAA11529@gilberto.physik.rwth-aachen.de> X-Mailer: ELM [version 2.4 PL23] Content-type: text Content-transfer-encoding: 7BIT Content-length: 1367 Sender: current-owner@FreeBSD.org Precedence: bulk Forwarded message: > From root@blues.physik.rwth-aachen.de Tue Feb 21 18:38:34 1995 > Date: Tue, 21 Feb 1995 18:35:28 GMT > From: Charlie Root > Message-Id: <199502211835.SAA19415@blues.physik.rwth-aachen.de> > To: kuku@blues.physik.rwth-aachen.de > Subject: world build on blues Tue Feb 21 18:35:26 1995 > > compressing in /usr/share/man/man8: quotaon.8 -> quotaon.8.gz > /usr/share/man/man8/quotaoff.8.gz -> /usr/share/man/man8/quotaon.8.gz > ===> usr.sbin/repquota > install -c -s -o bin -g bin -m 555 repquota /usr/sbin > (cd /usr/src/usr.sbin/repquota; install -c -o bin -g bin -m 444 repquota.8 /usr/share/man/man8) > compressing in /usr/share/man/man8: repquota.8 -> repquota.8.gz > ===> usr.sbin/routed > install -c -s -o bin -g bin -m 555 routed /usr/sbin > (cd /usr/src/usr.sbin/routed; install -c -o bin -g bin -m 444 routed.8 /usr/share/man/man8) > compressing in /usr/share/man/man8: routed.8 -> routed.8.gz > ===> usr.sbin/rmt > ln -s /usr/sbin/rmt /etc/rmt > ln: /etc/rmt: File exists > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Tue Feb 21 10:35:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA15718 for current-outgoing; Tue, 21 Feb 1995 10:35:52 -0800 Received: from ionews.io.org (root@ionews.io.org [198.133.36.6]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA15706 for ; Tue, 21 Feb 1995 10:35:51 -0800 Received: from localhost (taob@localhost) by ionews.io.org (8.6.5/8.6.9) id NAA04085; Tue, 21 Feb 1995 13:27:49 -0500 Date: Tue, 21 Feb 1995 13:27:46 -0500 (EST) From: Brian Tao To: Joerg Wunsch cc: FreeBSD-current users , Hellmuth Michaelis Subject: Re: pcvt in -current In-Reply-To: <199502211438.PAA10150@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Tue, 21 Feb 1995, J Wunsch wrote: > > Wow, > > i've finally tracked down why pcvt panics a -current kernel. Thanks > to the guy who used to be called Carny Lim here (i know it's not your > real name, but forgive me: i've forgot it), who provided me with an > account on a machine in Taiwan to analyze a kernel core dump for this. That's me, posting from my account back in Toronto. I'm also the one with the NCR SCSI-2 PCI card that the 940210 snapshot boot kernel doesn't like. ;-) Hope I can get the new 486 up and running soon. Thanks for the excellent support, Joerg. -- Brian Tao:: taob@io.org (Internex Online, 416-363-4151, 150 lines, v.32ter) ::::::::::: - - --===+ Home page URL = http://www.io.org/~taob/ +===-- - - From owner-freebsd-current Tue Feb 21 11:47:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA11157 for current-outgoing; Tue, 21 Feb 1995 11:47:31 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id LAA11127; Tue, 21 Feb 1995 11:47:26 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id aa05611; 21 Feb 95 19:36 GMT Received: (from gary@localhost) by palmer.demon.co.uk (8.6.9/8.6.9) id TAA00158; Tue, 21 Feb 1995 19:29:02 GMT From: Gary Palmer Message-Id: <199502211929.TAA00158@palmer.demon.co.uk> Subject: Adaptec problems To: freebsd-hardware@FreeBSD.org Date: Tue, 21 Feb 1995 19:29:01 +0000 (WET) Cc: FreeBSD-Current , Nathan Bradshaw X-OS: FreeBSD 2.1.0-Development X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2701 Sender: current-owner@FreeBSD.org Precedence: bulk Hi A friend has been asking me for hints on a problem he has been seeing for a few weeks, and it's bitten me now (I've just fitted a new SCSI drive) We both have Adaptec 1542(something) cards (mine is a CF AFAIK) in the machines providing primary storage. For some unknown reason the kernel will thrash the disk happily for a while, then the card (and presumably the SCSI bus) locks tight. Of course the kernel then vanishes into unspeakable places as it can't do any I/O. (the console messages just complain of bus timeouts AFAIR - then the VM pagers starts griping. I don't have DDB compiled in so it just prints `Debugger(aha1542) called'). Next time someone remind me to get a pen and paper out... The access light on the drive stays on (constantly) when this happens, as does the light on the controller. My setup looks like : External SCSI CD <-> card <-> internal drive Both the CDROM & the hard disk are terminated. My friend just has the disk on it's own. Not another piece of hardware or dust exists on his bus. The boot messages from my machine are appended. Can anyone help? Thanks Gary P.S. My friend says Linux doesn't do this on his hardware. I'm not mad enough to try... :-) -- SNIP -- FreeBSD 2.1.0-Development #0: Tue Feb 21 16:56:36 GMT 1995 root@palmer.demon.co.uk:/usr/src/sys/compile/WESTHILL CPU: i486DX (486-class CPU) real memory = 8257536 (2016 pages) avail memory = 7135232 (1742 pages) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed2 at 0x300-0x31f irq 10 maddr 0xcc000 msize 16384 on isa ed2: address 00:00:c0:5c:46:8e, type WD8013EPC (16 bit) bpf: ed2 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16450 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16450 lpt0 at 0x278-0x27f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: (NEC 72065B) [0: fd0: 1.44MB 3.5in] wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): <94354-230> wd0: 201MB (412128 total sec), 1272 cyl, 9 head, 36 sec, bytes/sec 512 aha0 is a 154xCF-2.01-VB.0: enabling mailbox and residuals aha0: reading board settings, dma=5 int=11 (bus speed defaulted) aha0 at 0x330-0x333 irq 11 drq 5 on isa aha0 waiting for scsi devices to settle aha0 targ 0 lun 0: type 0(direct) fixed SCSI2 aha0 targ 0 lun 0: sd0: 1013MB (2074880 total sec), 2756 cyl, 8 head, 94 sec, bytes/sec 512 aha0 targ 6 lun 0: type 5(readonly) removable SCSI2 aha0 targ 6 lun 0: cd0: cd present.[208702 x 2048 byte records] npx0 on motherboard npx0: INT 16 interface bpf: lo0 attached bpf: sl0 attached From owner-freebsd-current Tue Feb 21 11:54:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA14138 for current-outgoing; Tue, 21 Feb 1995 11:54:31 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id LAA14120 for ; Tue, 21 Feb 1995 11:54:29 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA06021; Tue, 21 Feb 1995 14:53:55 -0500 Date: Tue, 21 Feb 1995 14:53:55 -0500 From: Garrett Wollman Message-Id: <9502211953.AA06021@halloran-eldar.lcs.mit.edu> To: davidg@Root.COM Cc: current@FreeBSD.org Subject: Re: Possible kern.maxproc fatal bug In-Reply-To: <199502211152.DAA00893@corbin.Root.COM> References: <199502210818.TAA10312@godzilla.zeta.org.au> <199502211152.DAA00893@corbin.Root.COM> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > whatever "maxproc" was at startup time. Other than creating a "balance set", > there really isn't any way of working around this problem other than making > the map much large than maxproc (and thus allow maxproc to grow much larger). > Perhaps making the map accomodate 2 or 3 times maxproc might be a compromise. This sounds like a good idea. Of course, sysctl should be modified as well to understand that there actually is a hard upper limit to the hard upper limit :-) . -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Tue Feb 21 14:44:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA17901 for current-outgoing; Tue, 21 Feb 1995 14:44:10 -0800 Received: from glueserv1.umd.edu (glueserv1.umd.edu [129.2.70.69]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA17895; Tue, 21 Feb 1995 14:44:07 -0800 Received: from latte.eng.umd.edu (latte.eng.umd.edu [129.2.98.15]) by glueserv1.umd.edu (8.6.9/8.6.4) with ESMTP id RAA05361; Tue, 21 Feb 1995 17:43:14 -0500 Received: (chuckr@localhost) by latte.eng.umd.edu (8.6.9/8.6.4) id RAA15071; Tue, 21 Feb 1995 17:43:14 -0500 Date: Tue, 21 Feb 1995 17:43:13 -0500 (EST) From: Chuck Robey To: Gary Palmer cc: freebsd-hardware@FreeBSD.org, FreeBSD-Current , Nathan Bradshaw Subject: Re: Adaptec problems In-Reply-To: <199502211929.TAA00158@palmer.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Tue, 21 Feb 1995, Gary Palmer wrote: > Hi > > A friend has been asking me for hints on a problem he has been seeing for > a few weeks, and it's bitten me now (I've just fitted a new SCSI drive) > > We both have Adaptec 1542(something) cards (mine is a CF AFAIK) in the > machines providing primary storage. For some unknown reason the kernel will > thrash the disk happily for a while, then the card (and presumably the SCSI > bus) locks tight. Of course the kernel then vanishes into unspeakable places > as it can't do any I/O. (the console messages just complain of bus timeouts > AFAIR - then the VM pagers starts griping. I don't have DDB compiled in > so it just prints `Debugger(aha1542) called'). Next time someone remind me > to get a pen and paper out... > > The access light on the drive stays on (constantly) when this happens, as > does the light on the controller. > > My setup looks like : > > External SCSI CD <-> card <-> internal drive > > Both the CDROM & the hard disk are terminated. My friend just has the > disk on it's own. Not another piece of hardware or dust exists on his bus. > > The boot messages from my machine are appended. Can anyone help? > > Thanks > > Gary > > P.S. My friend says Linux doesn't do this on his hardware. I'm not mad > enough to try... :-) > > -- SNIP -- > FreeBSD 2.1.0-Development #0: Tue Feb 21 16:56:36 GMT 1995 > root@palmer.demon.co.uk:/usr/src/sys/compile/WESTHILL > CPU: i486DX (486-class CPU) > real memory = 8257536 (2016 pages) > avail memory = 7135232 (1742 pages) > Probing for devices on the ISA bus: > sc0 at 0x60-0x6f irq 1 on motherboard > sc0: VGA color <16 virtual consoles, flags=0x0> > ed2 at 0x300-0x31f irq 10 maddr 0xcc000 msize 16384 on isa ^^^^^^^^^^^ Isn't this the same ioaddr as your 1542CF ? > ed2: address 00:00:c0:5c:46:8e, type WD8013EPC (16 bit) > bpf: ed2 attached > sio0 at 0x3f8-0x3ff irq 4 on isa > sio0: type 16450 > sio1 at 0x2f8-0x2ff irq 3 on isa > sio1: type 16450 > lpt0 at 0x278-0x27f irq 7 on isa > lpt0: Interrupt-driven port > lp0: TCP/IP capable interface > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: (NEC 72065B) [0: fd0: 1.44MB 3.5in] > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): <94354-230> > wd0: 201MB (412128 total sec), 1272 cyl, 9 head, 36 sec, bytes/sec 512 > aha0 is a 154xCF-2.01-VB.0: enabling mailbox and residuals > aha0: reading board settings, dma=5 int=11 (bus speed defaulted) > aha0 at 0x330-0x333 irq 11 drq 5 on isa > aha0 waiting for scsi devices to settle > aha0 targ 0 lun 0: type 0(direct) fixed SCSI2 > aha0 targ 0 lun 0: > sd0: 1013MB (2074880 total sec), 2756 cyl, 8 head, 94 sec, bytes/sec 512 > aha0 targ 6 lun 0: type 5(readonly) removable SCSI2 > aha0 targ 6 lun 0: > cd0: cd present.[208702 x 2048 byte records] > npx0 on motherboard > npx0: INT 16 interface > bpf: lo0 attached > bpf: sl0 attached > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 7608 Topton St. | New Carrollton, MD 20784 | I run Journey2 (Freebsd 2.0) and n3lxx (301) 459-2316 | (FreeBSD 1.1.5.1) and am I happy! ----------------------------+----------------------------------------------- From owner-freebsd-current Tue Feb 21 15:12:17 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA18475 for current-outgoing; Tue, 21 Feb 1995 15:12:17 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id PAA18467; Tue, 21 Feb 1995 15:12:14 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id ab03575; 21 Feb 95 23:05 GMT Received: (from gary@localhost) by palmer.demon.co.uk (8.6.9/8.6.9) id WAA00556; Tue, 21 Feb 1995 22:56:04 GMT From: Gary Palmer Message-Id: <199502212256.WAA00556@palmer.demon.co.uk> Subject: Re: Adaptec problems To: Chuck Robey Date: Tue, 21 Feb 1995 22:56:03 +0000 (WET) Cc: freebsd-hardware@FreeBSD.org, current@FreeBSD.org, nb@xap.com In-Reply-To: from "Chuck Robey" at Feb 21, 95 05:43:13 pm X-OS: FreeBSD 2.1.0-Development X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 431 Sender: current-owner@FreeBSD.org Precedence: bulk > > ed2 at 0x300-0x31f irq 10 maddr 0xcc000 msize 16384 on isa > ^^^^^^^^^^^ > Isn't this the same ioaddr as your 1542CF ? [SNIPPED] > > aha0 is a 154xCF-2.01-VB.0: enabling mailbox and residuals > > aha0: reading board settings, dma=5 int=11 (bus speed defaulted) > > aha0 at 0x330-0x333 irq 11 drq 5 on isa ^^^^^ Nope... ed2 0x300 aha 0x330 If nothing else the kernel should gripe if it had... Gary From owner-freebsd-current Tue Feb 21 17:42:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA21685 for current-outgoing; Tue, 21 Feb 1995 17:42:13 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id RAA21667 for ; Tue, 21 Feb 1995 17:41:51 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA25242; Wed, 22 Feb 1995 02:21:31 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id CAA08941; Wed, 22 Feb 1995 02:21:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id CAA00872; Wed, 22 Feb 1995 02:19:19 +0100 From: J Wunsch Message-Id: <199502220119.CAA00872@uriah.heep.sax.de> Subject: Re: 2.0R, floppy problem To: jeffh@cybernetics.net (Jeff Hoffman) Date: Wed, 22 Feb 1995 02:19:19 +0100 (MET) Cc: current@FreeBSD.org In-Reply-To: from "Jeff Hoffman" at Feb 21, 95 11:23:59 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 812 Sender: current-owner@FreeBSD.org Precedence: bulk As Jeff Hoffman wrote: > > nexus# mount_msdos /dev/fd0 /mnt > fd0c: hard error reading fsbn 0 (ST0 40 ST1 1 ST2 0 cyl > 0 hd 0 sec 1) > mount_msdos: mount: Input/output error > nexus# ... > does anyone have any idea what is wrong? I re-made my kernel from the > srcdist and the whole 9 yards, yet nothing seems to fix the problem. Is > there any hope? >From the 2.0 srcdist? Well, so you've finally trashed the (newer) kernel from the newer boot floppies again. The 2.0 kernel is known to have problems with (at least) NEC 72065B controllers. You need to build the kernel from recent sources. Best would be installing a recent SNAP release. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Feb 21 17:54:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA21988 for current-outgoing; Tue, 21 Feb 1995 17:54:11 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id RAA21975 for ; Tue, 21 Feb 1995 17:53:51 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA25849; Wed, 22 Feb 1995 02:52:19 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id CAA09103 for freebsd-current@FreeBSD.org; Wed, 22 Feb 1995 02:52:18 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id CAA01052 for freebsd-current@FreeBSD.org; Wed, 22 Feb 1995 02:34:00 +0100 From: J Wunsch Message-Id: <199502220134.CAA01052@uriah.heep.sax.de> Subject: Re: world build on blues Tue Feb 21 18:35:26 1995 (fwd) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 22 Feb 1995 02:34:00 +0100 (MET) In-Reply-To: <199502211801.TAA11529@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Feb 21, 95 07:01:11 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 373 Sender: current-owner@FreeBSD.org Precedence: bulk As Christoph Kukulies wrote: > > > ===> usr.sbin/rmt > > ln -s /usr/sbin/rmt /etc/rmt > > ln: /etc/rmt: File exists Hmm, Jordan: make this rm -f /etc/rmt ln -s /usr/sbin/rmt /etc/rmt or just -ln -s /usr/sbin/rmt /etc/rmt -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Feb 21 18:50:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA22706 for current-outgoing; Tue, 21 Feb 1995 18:50:53 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA22698 for ; Tue, 21 Feb 1995 18:50:49 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id SAA23225; Tue, 21 Feb 1995 18:47:08 -0800 From: "Rodney W. Grimes" Message-Id: <199502220247.SAA23225@gndrsh.aac.dev.com> Subject: Re: world build on blues Tue Feb 21 18:35:26 1995 (fwd) To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 21 Feb 1995 18:47:08 -0800 (PST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199502220134.CAA01052@uriah.heep.sax.de> from "J Wunsch" at Feb 22, 95 02:34:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1112 Sender: current-owner@FreeBSD.org Precedence: bulk > > As Christoph Kukulies wrote: > > > > > ===> usr.sbin/rmt > > > ln -s /usr/sbin/rmt /etc/rmt > > > ln: /etc/rmt: File exists > > Hmm, Jordan: make this > > rm -f /etc/rmt > ln -s /usr/sbin/rmt /etc/rmt > > or just > > -ln -s /usr/sbin/rmt /etc/rmt Or correctly make it: ln -sf /usr/sbin/rmt ${DESTDIR}/etc/rmt and move this command to /usr/src/etc/Makefile distribution: target. Actually I am thinking along the lines that we should possible add the target install_etc: to the various Makefile's that want to drop stuff in /etc and have /usr/src/etc/Makefile do call backs to the other Makefiles with something like this: ETC_MAKEFILES= share/termcap usr.sbin/rmt ... distribution: ... for i in ${ETC_MAKEFILES}; do \ cd ${.CURDIR}/../$i; \ ${MAKE} install_etc; \ done ... With this in place we could almost empty /usr/src/etc., config files would be back with the sources that use them (more likely to keep up to date that way). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Tue Feb 21 19:53:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA23809 for current-outgoing; Tue, 21 Feb 1995 19:53:21 -0800 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA23802 for ; Tue, 21 Feb 1995 19:53:17 -0800 Received: from starkhome.UUCP (root@localhost) by sbstark.cs.sunysb.edu (8.6.9/8.6.9) with UUCP id WAA28677 for current@freebsd.org; Tue, 21 Feb 1995 22:49:58 -0500 Received: by starkhome.cs.sunysb.edu (8.6.9/1.34) id HAA07946; Tue, 21 Feb 1995 07:28:10 -0500 Date: Tue, 21 Feb 1995 07:28:10 -0500 From: starkhome!gene@sbstark.cs.sunysb.edu (Gene Stark) Message-Id: <199502211228.HAA07946@starkhome.cs.sunysb.edu> To: regent.e-technik.tu-muenchen.de!jhs@sbstark.cs.sunysb.edu Cc: current@FreeBSD.org In-reply-to: Julian Howard Stacey's message of Sun, 19 Feb 1995 21:45:23 +0100 Subject: newfs: sectors per cylinder (4096) disagrees with disk label (36) Sender: current-owner@FreeBSD.org Precedence: bulk >With system after a make world from current (of Fri 18th Feb), >While doing a: > cd /usr/src/etc > make floppies >it blew up with > disklabel -w -r -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd fd0 fd1440 > newfs -b 4096 -c 80 -f 512 -i 8192 -m 0 -o space rfd0 fd1440 > Warning: calculated sectors per cylinder (4096) disagrees with disk label (36) Newfs now ignores the disklabel and uses defaults of 1 track/cyl and 4096 sectors/track. You can override by giving explicit arguments. However, the way the changes have been made strikes me as somewhat kludgy. Would it be possible for newfs to do the following: (1) Check /etc/disktab for info on the partition. Use these parameters if available. (Put the 4096/1 stuff in here.) (2) If /etc/disktab has no info, look at the disklabel. Pay attention to these parameters if available. (3) If neither (1), nor (2), use the hard-coded defaults (4096/1). - Gene Stark From owner-freebsd-current Wed Feb 22 01:03:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id BAA01564 for current-outgoing; Wed, 22 Feb 1995 01:03:45 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id BAA01556 for ; Wed, 22 Feb 1995 01:03:29 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA02348; Wed, 22 Feb 1995 19:57:50 +1100 Date: Wed, 22 Feb 1995 19:57:50 +1100 From: Bruce Evans Message-Id: <199502220857.TAA02348@godzilla.zeta.org.au> To: regent.e-technik.tu-muenchen.de!jhs@sbstark.cs.sunysb.edu, starkhome!gene@sbstark.cs.sunysb.edu Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Newfs now ignores the disklabel and uses defaults of 1 track/cyl and 4096 >sectors/track. You can override by giving explicit arguments. >However, the way the changes have been made strikes me as somewhat kludgy. >Would it be possible for newfs to do the following: > (1) Check /etc/disktab for info on the partition. Use these > parameters if available. > (Put the 4096/1 stuff in here.) > (2) If /etc/disktab has no info, look at the disklabel. > Pay attention to these parameters if available. It already looks at /etc/disktab (if a disktab entry is specified) and at the label. I wouldn't want it replacing values in the label with values in the disktab entry for the disk type givel in the label when a disktab entry is not specified. The point is that the values given in disktab entries and labels are often BAD. They are supposed to be blown away. Poul actually only intended the values in disklabels to be ignored, but the same problem occurs for disktab entries. However, there are some disktab and label entries that give the physical geometry (floppies and old drives). Newfs should use these geometries unless the old ufs support for fixed geometries doesn't actually work (I don't think it can unless all the seek times are known). I think the correct solution is to put the geometry that you want newfs to use in the label. The geometry in the label isn't used for many things other than newfs. It is used for booting and by fdisk. Disk slicing will provide separate labels for the whole disk and the BSD slice (even when the BSD slice is the whole disk) so it will be possible to have separate geometries for booting/fdisk and newfs. Bruce From owner-freebsd-current Wed Feb 22 03:49:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA06791 for current-outgoing; Wed, 22 Feb 1995 03:49:42 -0800 Received: from rz-wb.fh-sw.de (rz-wb.fh-sw.de [192.129.23.111]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id DAA06764 for ; Wed, 22 Feb 1995 03:49:29 -0800 Received: (from root@localhost) by rz-wb.fh-sw.de (8.6.9/8.6.9) id MAA19519; Wed, 22 Feb 1995 12:47:11 +0100 Date: Wed, 22 Feb 1995 12:47:10 +0100 (MET) From: Michael Reifenberger To: Joerg Wunsch cc: FreeBSD-current users Subject: Re: world build on blues Tue Feb 21 18:35:26 1995 (fwd) In-Reply-To: <199502220134.CAA01052@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Wed, 22 Feb 1995, J Wunsch wrote: > Date: Wed, 22 Feb 1995 02:34:00 +0100 (MET) > From: J Wunsch > To: FreeBSD-current users > Subject: Re: world build on blues Tue Feb 21 18:35:26 1995 (fwd) > > As Christoph Kukulies wrote: > > > > > ===> usr.sbin/rmt > > > ln -s /usr/sbin/rmt /etc/rmt > > > ln: /etc/rmt: File exists > > Hmm, Jordan: make this > > rm -f /etc/rmt > ln -s /usr/sbin/rmt /etc/rmt > > or just > > -ln -s /usr/sbin/rmt /etc/rmt or "ln -fs /usr/sbin/rmt /etc/rmt" Bye! ---- Michael Reifenberger From owner-freebsd-current Wed Feb 22 03:50:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id DAA06828 for current-outgoing; Wed, 22 Feb 1995 03:50:02 -0800 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id DAA06820 for ; Wed, 22 Feb 1995 03:50:01 -0800 Received: from starkhome.UUCP (root@localhost) by sbstark.cs.sunysb.edu (8.6.9/8.6.9) with UUCP id GAA29289 for current@FreeBSD.org; Wed, 22 Feb 1995 06:46:41 -0500 Received: by starkhome.cs.sunysb.edu (8.6.9/1.34) id GAA12743; Wed, 22 Feb 1995 06:48:53 -0500 Date: Wed, 22 Feb 1995 06:48:53 -0500 From: starkhome!gene@sbstark.cs.sunysb.edu (Gene Stark) Message-Id: <199502221148.GAA12743@starkhome.cs.sunysb.edu> To: bde@zeta.org.au CC: regent.e-technik.tu-muenchen.de!jhs@sbstark.cs.sunysb.edu, current@FreeBSD.org In-reply-to: Bruce Evans's message of Wed, 22 Feb 1995 19:57:50 +1100 <199502220857.TAA02348@godzilla.zeta.org.au> Subject: newfs: sectors per cylinder (4096) disagrees with disk label (36) Sender: current-owner@FreeBSD.org Precedence: bulk >It already looks at /etc/disktab (if a disktab entry is specified) and at >the label. I wouldn't want it replacing values in the label with values >in the disktab entry for the disk type givel in the label when a disktab >entry is not specified. When I first saw the "parameters don't match those in disk label" errors, I looked at the newfs code briefly. It looked to me like what had been done is that some parameters that normally were zeroes had been #define'd to 4096, etc. The normal behavior of newfs was to look in the disklabel or in the disktab entry for stuff only if these parameters were zero (indicating they had not been overridden by command line arguments). #define'ing them to nonzero values seemed to break the normal searching that newfs does, and this is what I was referring to as kludgy. >I think the correct solution is to put the geometry that you want newfs >to use in the label. The geometry in the label isn't used for many >things other than newfs. It is used for booting and by fdisk. Disk No, this won't work for IDE drives, which in my experience seem to be very particular about what geometry is stuffed into the controller. If you put some geometry in the disklabel that has nothing to do with the geometry reported by the controller, then when that geometry is stuffed into the controller when the disk is first opened, it will likely hose things badly. >slicing will provide separate labels for the whole disk and the BSD >slice (even when the BSD slice is the whole disk) so it will be possible >to have separate geometries for booting/fdisk and newfs. If this scheme uses the "native" geometry to initialize the controller, and the BSD geometry for "soft" operations (like newfs) only, then it should work. - Gene From owner-freebsd-current Wed Feb 22 04:06:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id EAA08104 for current-outgoing; Wed, 22 Feb 1995 04:06:49 -0800 Received: from dns.netvision.net.il (root@dns.NetVision.net.il [194.90.1.5]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id EAA08087; Wed, 22 Feb 1995 04:06:44 -0800 Received: from ugen.NetManage.co.il (ugen.netmanage.co.il [192.114.78.165]) by dns.netvision.net.il (8.6.9/8.6.9) with SMTP id OAA03804; Wed, 22 Feb 1995 14:05:51 +0200 Date: Wed, 22 Feb 95 13:51:47 IST From: "Ugen J.S.Antsilevich" Subject: HARDWARE LIST??!!! To: freebsd-current@freefall.cdrom.com, core@FreeBSD.org X-Mailer: Chameleon 4.00-Arm-25, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Sorry guys to bother but how can i get it? -- -=Ugen J.S.Antsilevich=- NetVision - Israeli Commercial Internet | Learning E-mail: ugen@NetVision.net.il | To Fly. [c] Phone : +972-4-550330 | From owner-freebsd-current Wed Feb 22 05:54:58 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id FAA12472 for current-outgoing; Wed, 22 Feb 1995 05:54:58 -0800 Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id FAA12461 for ; Wed, 22 Feb 1995 05:54:44 -0800 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id NAA08420; Wed, 22 Feb 1995 13:40:35 GMT Date: Wed, 22 Feb 1995 13:40:32 +0000 (GMT) From: Doug Rabson To: current@FreeBSD.org Subject: mountd changes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk I have some changes here for mountd which do two things: (1) Stop it from moaning when more than one mountpoint in a given filesystem is exported. (2) Allow mounts of directories which have an exported initial segment. I am wondering whether to commit these. (1) is probably safe but (2) might be a security risk. Comments? -- Doug Rabson, RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 71 251 4411 FAX: +44 71 251 0939 From owner-freebsd-current Wed Feb 22 06:02:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id GAA12713 for current-outgoing; Wed, 22 Feb 1995 06:02:18 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id GAA12705; Wed, 22 Feb 1995 06:02:16 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Doug Rabson cc: current@FreeBSD.org Subject: Re: mountd changes In-reply-to: Your message of "Wed, 22 Feb 95 13:40:32 GMT." Date: Wed, 22 Feb 1995 06:02:12 -0800 Message-ID: <12690.793461732@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > (1) Stop it from moaning when more than one mountpoint in a given > filesystem is exported. Does it actually work though? :-) > (2) Allow mounts of directories which have an exported initial > segment. -alldirs? My biggest bug-a-boo is that it lets you mount the same filesystem more than once! :) Jordan From owner-freebsd-current Wed Feb 22 06:05:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id GAA12897 for current-outgoing; Wed, 22 Feb 1995 06:05:30 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id GAA12867 for ; Wed, 22 Feb 1995 06:05:17 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id GAA09419; Wed, 22 Feb 1995 06:04:38 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id GAA04430; Wed, 22 Feb 1995 06:04:38 -0800 Message-Id: <199502221404.GAA04430@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: Doug Rabson cc: current@FreeBSD.org Subject: Re: mountd changes In-reply-to: Your message of "Wed, 22 Feb 95 13:40:32 GMT." From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 22 Feb 1995 06:04:29 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >I have some changes here for mountd which do two things: > >(1) Stop it from moaning when more than one mountpoint in a given >filesystem is exported. > >(2) Allow mounts of directories which have an exported initial >segment. I thought (1) happens because of the screwy way that the system applies protections - the first listed is the one that applies to the rest (i.e. only one set of protections/options per filesystem). I thought (2) was already supported via -alldirs ? -DG From owner-freebsd-current Wed Feb 22 06:54:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id GAA14812 for current-outgoing; Wed, 22 Feb 1995 06:54:06 -0800 Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id GAA14804 for ; Wed, 22 Feb 1995 06:54:03 -0800 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id OAA08853; Wed, 22 Feb 1995 14:55:27 GMT Date: Wed, 22 Feb 1995 14:55:24 +0000 (GMT) From: Doug Rabson To: David Greenman cc: current@FreeBSD.org Subject: Re: mountd changes In-Reply-To: <199502221404.GAA04430@corbin.Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Wed, 22 Feb 1995, David Greenman wrote: > >I have some changes here for mountd which do two things: > > > >(1) Stop it from moaning when more than one mountpoint in a given > >filesystem is exported. > > > >(2) Allow mounts of directories which have an exported initial > >segment. > > I thought (1) happens because of the screwy way that the system applies > protections - the first listed is the one that applies to the rest (i.e. only > one set of protections/options per filesystem). This is true. The problem is that vfs_export() returns EPERM when mountd attempts to export the mount point for a second time, and mountd does not add it to its exports list. As a workaround, I interpret EPERM as success. Probably bogus, I know but it was easier that changing vfs_export(). > I thought (2) was already supported via -alldirs ? Blimey. That'll teach me to RTFM before I start hacking :-) > > -DG > -- Doug Rabson, RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 71 251 4411 FAX: +44 71 251 0939 From owner-freebsd-current Wed Feb 22 07:34:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA17764 for current-outgoing; Wed, 22 Feb 1995 07:34:08 -0800 Received: (from jkh@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA17757 for current; Wed, 22 Feb 1995 07:34:07 -0800 Date: Wed, 22 Feb 1995 07:34:07 -0800 From: "Jordan K. Hubbard" Message-Id: <199502221534.HAA17757@freefall.cdrom.com> To: current Subject: TRUE and FALSE Sender: current-owner@FreeBSD.org Precedence: bulk These have always been traditionally defined in , yet I see that we don't do it there. Are these now in violation of POSIX namespace or something? Should I be including something else to get them? So far, I see definitions in: And that seems a little silly (so is exporting the entire NFS tree into /usr/include, while we're talking about silly, but that's another diatribe entirely). Comments? Jordan From owner-freebsd-current Wed Feb 22 09:16:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA22317 for current-outgoing; Wed, 22 Feb 1995 09:16:18 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.223.46]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA22311; Wed, 22 Feb 1995 09:16:18 -0800 Received: (from jkh@localhost) by time.cdrom.com (8.6.9/8.6.9) id JAA06992; Wed, 22 Feb 1995 09:15:54 -0800 Date: Wed, 22 Feb 1995 09:15:54 -0800 From: "Jordan K. Hubbard" Message-Id: <199502221715.JAA06992@time.cdrom.com> To: current@FreeBSD.org, julian@FreeBSD.org Subject: st.c - is this right?? Sender: current-owner@FreeBSD.org Precedence: bulk Line 1043 of /sys/scsi/st.c: /* * Correctly set the buf to indicate a completed xfer */ iodone(bp); ^^^^^^ Shouldn't this be a biodone? Jordan From owner-freebsd-current Wed Feb 22 10:02:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA23972 for current-outgoing; Wed, 22 Feb 1995 10:02:54 -0800 Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.97.216]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA23966 for ; Wed, 22 Feb 1995 10:02:53 -0800 Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.6.9/8.6.9) id JAA10255 for freebsd-current@freefall.cdrom.com; Wed, 22 Feb 1995 09:59:51 -0800 From: Steven G Kargl Message-Id: <199502221759.JAA10255@troutmask.apl.washington.edu> Subject: kernel build dies To: freebsd-current@freefall.cdrom.com (FreeBSD Current) Date: Wed, 22 Feb 1995 09:59:50 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 803 Sender: current-owner@FreeBSD.org Precedence: bulk troutmask[25] make cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -I. -I../.. -I../../sys -DTROUTMASK -DI486_CPU -DSCSI_DELAY=10 -DMAXCONS=4 -DHARDFONTS -DAUTO_EOI_1 -DPROCFS -DMSDOSFS -DMFS -DFFS -DINET -DUCONSOLE -DKTRACE -DDODUMP -DDDB -DCOMPAT_43 -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../vm/vm_page.c ../../vm/vm_page.c: In function `vm_page_alloc': ../../vm/vm_page.c:658: structure has no member named `v_interrupt_free_min' *** Error code 1 Stop. This error occurs with sources supped this morning (0945 PST 950222). -- Steven G. Kargl | Phone: 206-685-4677 | Applied Physics Laboratory | Fax: 206-543-6785 | University of Washington |---------------------| 1013 NE 40th St | FreeBSD 2.0-current | Seattle, WA 98105 |---------------------| From owner-freebsd-current Wed Feb 22 10:11:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA24192 for current-outgoing; Wed, 22 Feb 1995 10:11:06 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA24183; Wed, 22 Feb 1995 10:11:02 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id KAA09895; Wed, 22 Feb 1995 10:10:35 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id KAA00251; Wed, 22 Feb 1995 10:10:34 -0800 Message-Id: <199502221810.KAA00251@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" cc: current@FreeBSD.org, julian@FreeBSD.org Subject: Re: st.c - is this right?? In-reply-to: Your message of "Wed, 22 Feb 95 09:15:54 PST." <199502221715.JAA06992@time.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 22 Feb 1995 10:10:32 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >Line 1043 of /sys/scsi/st.c: > > /* > * Correctly set the buf to indicate a completed xfer > */ > iodone(bp); > ^^^^^^ > >Shouldn't this be a biodone? Yes, but it doesn't matter: ./sys/buf.h:#define iodone biodone /* Old name for biodone. */ -DG From owner-freebsd-current Wed Feb 22 10:12:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA24211 for current-outgoing; Wed, 22 Feb 1995 10:12:08 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id KAA24205 for ; Wed, 22 Feb 1995 10:11:59 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA24450; Wed, 22 Feb 95 11:05:17 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502221805.AA24450@cs.weber.edu> Subject: Re: mountd changes To: dfr@render.com (Doug Rabson) Date: Wed, 22 Feb 95 11:05:16 MST Cc: current@FreeBSD.org In-Reply-To: from "Doug Rabson" at Feb 22, 95 01:40:32 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > I have some changes here for mountd which do two things: > > (1) Stop it from moaning when more than one mountpoint in a given > filesystem is exported. > > (2) Allow mounts of directories which have an exported initial > segment. > > I am wondering whether to commit these. (1) is probably safe but (2) > might be a security risk. Comments? The reason for #1 is that server caching (not in the server's FS, but in the server code itself) could result in a bad interaction where bogus data got blown to disk as a result of write requests to the same file for multiple clients. This is because cache coherency is not maintained between exported mount points, and this is mostly because the NFS server isn't a multithreaded instead of a multiprocess implementation using only kernel threads (which we don't have any of). So it's a design limitation for *BSD, not a protocol limitation for NFS. #2 is a security problem because mount requests are made as root. I believe it was SunOS 4.1.3_U2 that addressed this by disallowing it in the Sun NFS implementation. The exact failure is that unless you allow a hosts root in, it will not allow an iteration of the descending directories to be made as "nobody". I agree that this is disasterous for AMD based dataless workstations. The correct response is to allow their root user in as root. The reason for the change was that NFS cookies can be manufactured from an insecure host inside the secure zone and not have to traverse intermediate security restrictions to get at terminal file system objects. Basically, this means that you can hack on file that you would not be able to get to and which live in protected directories if you know their names -- and you can get the names from snooping the wire traffic of authorized users. I believe there was a CERT advisory recommending this lockdown. There is a difference in implementation, which could be considered bad. The security update as shipped by Sun added a debug statement to set a kernel flag into the rc files. Unlike the *BSD soloution, this is administrator switchable. The *BSD soloution ought to be switchable as well. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Feb 22 10:15:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA24335 for current-outgoing; Wed, 22 Feb 1995 10:15:11 -0800 Received: from bigdipper.umd.edu (bigdipper.umd.edu [128.8.220.139]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA24320; Wed, 22 Feb 1995 10:14:59 -0800 Received: (from adhir@localhost) by bigdipper.umd.edu (8.6.8/8.6.6) id NAA08341; Wed, 22 Feb 1995 13:14:24 -0500 Date: Wed, 22 Feb 1995 13:14:23 -0500 (EST) From: "Alok K. Dhir" To: Poul-Henning Kamp cc: "Jordan K. Hubbard" , current@FreeBSD.org Subject: Re: ATTENTION In-Reply-To: <199502170412.UAA04330@ref.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Thu, 16 Feb 1995, Poul-Henning Kamp wrote: > > > > > Expect the FreeBSD to be seriously broken for some time now. > > > We will be integrating the new disk-slice stuff now. > > > > Can you clarify this a little? The FreeBSD.... What? All of FreeBSD? > > I've never heard FreeBSD referred to as "the FreeBSD" before..! :-) > > "FreeBSD the one and only" of course! :-) > > Sorry, I meant FreeBSD-current... So you're saying that supping/make-worlding will result in an unusable system? What can I expect to be broken (I've had a make world going for about 6 hours now and it will be complete in a couple more. I supped right before that (Early morning Feb 22)... Please tell me I'm safe :-0! BTW - the box has two SCSI disks, all FreeBSD, no other OSs. Could this mean that I won't be afected by the slice changes (please say yes)!? -------------------------------------___--------------------------------- | Al Dhir, Programmer Analyst /___\ UMCP Ag-Engineering Dept | | Internet: adhir@bigdipper.umd.edu (o o) (301) 405-1197 | ---------------------------------ooO-(_)-Ooo----------------------------- From owner-freebsd-current Wed Feb 22 10:15:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA24353 for current-outgoing; Wed, 22 Feb 1995 10:15:46 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id KAA24346 for ; Wed, 22 Feb 1995 10:15:41 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA24483; Wed, 22 Feb 95 11:09:00 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502221809.AA24483@cs.weber.edu> Subject: Re: mountd changes To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 22 Feb 95 11:09:00 MST Cc: dfr@render.com, current@FreeBSD.org In-Reply-To: <12690.793461732@freefall.cdrom.com> from "Jordan K. Hubbard" at Feb 22, 95 06:02:12 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > (2) Allow mounts of directories which have an exported initial > > segment. > > -alldirs? This is insufficient for security reasons unless you also implement netgroups (a royal pain). > My biggest bug-a-boo is that it lets you mount the same filesystem > more than once! :) Client problem; an almost totally independent set of code. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Feb 22 10:21:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA24515 for current-outgoing; Wed, 22 Feb 1995 10:21:30 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA24509; Wed, 22 Feb 1995 10:21:28 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id KAA04099; Wed, 22 Feb 1995 10:20:57 -0800 From: Poul-Henning Kamp Message-Id: <199502221820.KAA04099@ref.tfs.com> Subject: Re: ATTENTION To: adhir@bigdipper.umd.edu (Alok K. Dhir) Date: Wed, 22 Feb 1995 10:20:57 -0800 (PST) Cc: jkh@freefall.cdrom.com, current@FreeBSD.org In-Reply-To: from "Alok K. Dhir" at Feb 22, 95 01:14:23 pm Content-Type: text Content-Length: 738 Sender: current-owner@FreeBSD.org Precedence: bulk > > Sorry, I meant FreeBSD-current... > > So you're saying that supping/make-worlding will result in an unusable > system? What can I expect to be broken (I've had a make world going for > about 6 hours now and it will be complete in a couple more. I supped > right before that (Early morning Feb 22)... > > Please tell me I'm safe :-0! BTW - the box has two SCSI disks, all > FreeBSD, no other OSs. Could this mean that I won't be afected by the > slice changes (please say yes)!? Frankly: I don't know. Bruce has done a lot to avoid killing people, but I cannot give any guarantees. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 10:29:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA24730 for current-outgoing; Wed, 22 Feb 1995 10:29:28 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA24724; Wed, 22 Feb 1995 10:29:20 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.9/8.6.9) with SMTP id UAA17039; Wed, 22 Feb 1995 20:28:44 +0200 Message-Id: <199502221828.UAA17039@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: bugs@FreeBSD.org, current@FreeBSD.org Subject: Lots of crud... Date: Wed, 22 Feb 1995 20:28:43 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk Hi There are a BUNCH of files in src/etc/etc.i386 that _REALLY_ should be nuked: (Look at the dates on some of these!) - 21508 Feb 17 17:05 MAKEDEV Does this have to be here? (Better in src/RELEASE with its baby brother ../MAKEDEV.Local?) - 6474 Jun 28 1994 README.1ST - 36633 Jun 28 1994 README.INSTALL These README's are for 1.1.5.1 - 28831 Sep 15 06:46 cdinst1.install - 2199 Apr 18 1994 cdinst1.profile - 367 Feb 21 1994 cpio.install* - 9135 Jun 29 1994 cpio.magic - 3111 Sep 15 06:46 cpio.rc AFAICSee, these are all for the 1.1.5.1 install floppies. - 5178 Feb 20 1994 disktab This, I believe, could comfortably live in src/etc - 80 Jun 20 1993 fstab.wd WTF is this? - 30179 Oct 17 04:32 inst1.install* - 159 Feb 21 1994 inst1.profile - 10680 Sep 15 06:46 inst2.rc - 1744 Sep 15 06:46 kc.profile More 1.1.5.1 crud... Also the Makefile in src/etc (which has been worked on recently) seems mainly concerned with making 1.1*-style install floppies. Can we not chuck it out? Whenever I do a build world, I resort to a hand checking of the files in src/etc directory to see what has changed. What about some way of automating this, so a make install will install the (hopefully) non- customisable files (like rc, services etc) and leave alone the ones that users are supposed to mess with (like netstart and hosts)? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Wed Feb 22 11:50:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA02020 for current-outgoing; Wed, 22 Feb 1995 11:50:21 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id LAA02014; Wed, 22 Feb 1995 11:50:16 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id LAA24920; Wed, 22 Feb 1995 11:48:58 -0800 From: "Rodney W. Grimes" Message-Id: <199502221948.LAA24920@gndrsh.aac.dev.com> Subject: Re: Lots of crud... To: mark@grondar.za (Mark Murray) Date: Wed, 22 Feb 1995 11:48:58 -0800 (PST) Cc: bugs@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199502221828.UAA17039@grunt.grondar.za> from "Mark Murray" at Feb 22, 95 08:28:43 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2467 Sender: current-owner@FreeBSD.org Precedence: bulk > > Hi > > There are a BUNCH of files in src/etc/etc.i386 that _REALLY_ should > be nuked: (Look at the dates on some of these!) > > - 21508 Feb 17 17:05 MAKEDEV > Does this have to be here? (Better in src/RELEASE with its baby brother > ../MAKEDEV.Local?) I see no MAKEDEV.Local in src/release, MAKEDEV files are machine depenedent, so they need to be in the etc.i386 directory. MAKEDEV.local is machine independent so it belongs where it is. > - 6474 Jun 28 1994 README.1ST > - 36633 Jun 28 1994 README.INSTALL > These README's are for 1.1.5.1 These are the instructions for the other scripts, see below. > - 28831 Sep 15 06:46 cdinst1.install > - 2199 Apr 18 1994 cdinst1.profile > - 367 Feb 21 1994 cpio.install* > - 9135 Jun 29 1994 cpio.magic > - 3111 Sep 15 06:46 cpio.rc > AFAICSee, these are all for the 1.1.5.1 install floppies. And are still in use by some folks who prefer the 1.x method of installing things. I am still using these, expect a revamp some time real soon now. > - 5178 Feb 20 1994 disktab > This, I believe, could comfortably live in src/etc Think multiplatform, but maybe this could safely be moved. This is the traditional BSD location for this source file. > - 80 Jun 20 1993 fstab.wd > WTF is this? A sample /etc/fstab, specifically cruft, should probably install as /usr/share/examples/etc/fstab > - 30179 Oct 17 04:32 inst1.install* > - 159 Feb 21 1994 inst1.profile > - 10680 Sep 15 06:46 inst2.rc > - 1744 Sep 15 06:46 kc.profile > More 1.1.5.1 crud... And stuff that still works 99% of the way. > Also the Makefile in src/etc (which has been worked on recently) seems > mainly concerned with making 1.1*-style install floppies. Can we not > chuck it out? Lots of it is still extensivly used by make release in src/release. > Whenever I do a build world, I resort to a hand checking of the files in > src/etc directory to see what has changed. What about some way of > automating this, so a make install will install the (hopefully) non- > customisable files (like rc, services etc) and leave alone the ones > that users are supposed to mess with (like netstart and hosts)? There is no such thing as a non-customizable file in /etc :-(. > Mark Murray > 46 Harvey Rd, Claremont, Cape Town 7700, South Africa > +27 21 61-3768 GMT+0200 -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Wed Feb 22 12:11:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA02411 for current-outgoing; Wed, 22 Feb 1995 12:11:13 -0800 Received: from mail2.netcom.com (root@mail2.netcom.com [192.100.81.122]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA02352; Wed, 22 Feb 1995 12:09:40 -0800 From: patl@asimov.lashley.slip.netcom.com Received: from lashley.slip.netcom.com by mail2.netcom.com (8.6.9/Netcom) id MAA02860; Wed, 22 Feb 1995 12:08:29 -0800 Received: by lashley.slip.netcom.com (5.x/SMI-SVR4) id AA03245; Wed, 22 Feb 1995 12:11:25 -0800 Date: Wed, 22 Feb 1995 12:11:25 -0800 Message-Id: <9502222011.AA03245@lashley.slip.netcom.com> To: mark@grondar.za, rgrimes@gndrsh.aac.dev.com Subject: Re: Lots of crud... Cc: bugs@FreeBSD.org, current@FreeBSD.org Reply-To: lashley@netcom.com X-Sun-Charset: US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk |> > Whenever I do a build world, I resort to a hand checking of the files in |> > src/etc directory to see what has changed. What about some way of |> > automating this, so a make install will install the (hopefully) non- |> > customisable files (like rc, services etc) and leave alone the ones |> > that users are supposed to mess with (like netstart and hosts)? |> |> There is no such thing as a non-customizable file in /etc :-(. I'm -very- new to the *BSD world, and probably don't properly understand the issues well enough to comment; but I'll risk it... One of the things I liked about the Solaris2(*) installation packages is that the package maintainer can specify what is to happen if one of the target files has been modified since the previous installation of the package. The choices are: 1. Rename the existing file and install the new file. 2. Install the new file, but under a modified name. 3. Run a script that will attempt to Do The Right Thing in some package and file-dependant manner. In all cases a message is emited to syserr and the log file. Would it be posible (and reasonable) to provide some similar type of facility here? (*) This update facility didn't completely work until Solaris 2.4. -Pat My opinions are my own. For a small royalty, they can be yours as well... Pat Lashley, Senior Software Engineer, Henry Davis Consulting 1098 Lynn, Sunnyvale, CA 94087 || 408/720-9039 || lashley@netcom.com From owner-freebsd-current Wed Feb 22 12:12:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA02446 for current-outgoing; Wed, 22 Feb 1995 12:12:15 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id MAA02437; Wed, 22 Feb 1995 12:12:09 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA08273; Wed, 22 Feb 1995 15:11:39 -0500 Date: Wed, 22 Feb 1995 15:11:39 -0500 From: Garrett Wollman Message-Id: <9502222011.AA08273@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: current@freefall.cdrom.com Subject: TRUE and FALSE In-Reply-To: <199502221534.HAA17757@freefall.cdrom.com> References: <199502221534.HAA17757@freefall.cdrom.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > These have always been traditionally defined in , yet I see > that we don't do it there. Are these now in violation of POSIX namespace > or something? Should I be including something else to get them? No, they are in violation of ANSI namespace, and an idiotic idea in the first place. Think: what happens if someone decides to define enum bool { TRUE, FALSE }; ? (A somewhat less idiotic idea, but still bogus.) > And that seems a little silly (so is exporting the entire NFS tree into > /usr/include, while we're talking about silly, but that's another diatribe > entirely). Hello, Jordan? Wake up! wollman@khavrinen(11)$ ls -l /usr/include/nfs lrwxr-xr-x 1 bin bin 8 Feb 21 15:03 /usr/include/nfs@ -> /sys/nfs wollman@khavrinen(12)$ ls -l /usr/include/sys lrwxr-xr-x 1 bin bin 8 Feb 21 15:03 /usr/include/sys@ -> /sys/sys -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 12:26:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA02721 for current-outgoing; Wed, 22 Feb 1995 12:26:33 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA02712; Wed, 22 Feb 1995 12:26:23 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.9/8.6.9) with SMTP id WAA22507; Wed, 22 Feb 1995 22:25:15 +0200 Message-Id: <199502222025.WAA22507@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: bugs@FreeBSD.org, current@FreeBSD.org Subject: Re: Lots of crud... Date: Wed, 22 Feb 1995 22:25:15 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk > I see no MAKEDEV.Local in src/release, MAKEDEV files are machine depenedent, > so they need to be in the etc.i386 directory. MAKEDEV.local is machine > independent so it belongs where it is. I meant move MAKEDEV _with_ MAKEDEV.local. MAKEDEV is in etc.i386, and MAKEDEV.local is in etc. Should they at least not be together? > These are the instructions for the other scripts, see below. Then they need a _small_ bit of updating. > > AFAICSee, these are all for the 1.1.5.1 install floppies. > > And are still in use by some folks who prefer the 1.x method of installing > things. I am still using these, expect a revamp some time real soon now. OK - I'll buy that. Why would anyone still want the 1.x method ;-) > > - 5178 Feb 20 1994 disktab > > This, I believe, could comfortably live in src/etc > > Think multiplatform, but maybe this could safely be moved. This is the > traditional BSD location for this source file. I'll go for tradition. It needs some updating tho'. There are a few hard disks out there... > > More 1.1.5.1 crud... > > And stuff that still works 99% of the way. Ok. > There is no such thing as a non-customizable file in /etc :-(. Bummer. It is much better, now that most of the customising can be done _without_ messing with rc*. This idea should be taken as far as possible with other /etc files, leaving as clear as possible a distinction between files that one _should_ modify, _may_ modify and should preferably _not_ modify. I was Helping someone upgrade his production 1.1 box to 1.1.5.1 today, and the /etc area was a nightmare to do. -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Wed Feb 22 12:36:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA02939 for current-outgoing; Wed, 22 Feb 1995 12:36:20 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id MAA02928 for ; Wed, 22 Feb 1995 12:36:14 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA08329; Wed, 22 Feb 1995 15:35:31 -0500 Date: Wed, 22 Feb 1995 15:35:31 -0500 From: Garrett Wollman Message-Id: <9502222035.AA08329@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: current@FreeBSD.org Subject: Re: mountd changes In-Reply-To: <12690.793461732@freefall.cdrom.com> References: <12690.793461732@freefall.cdrom.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > My biggest bug-a-boo is that it lets you mount the same filesystem > more than once! :) And what on earth is wrong with that? All a `mount' does is cover one directory vnode with another; it seems rather pointless to have such restrictions on it. (For that matter, I would like to see the directory restriction lifted, too.) The only reason why UFS doesn't let you mount the same device more than once is because it doesn't have the necessary internal locking and serialization code to make it work. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 12:38:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA02990 for current-outgoing; Wed, 22 Feb 1995 12:38:48 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id MAA02983 for ; Wed, 22 Feb 1995 12:38:44 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA08339; Wed, 22 Feb 1995 15:37:56 -0500 Date: Wed, 22 Feb 1995 15:37:56 -0500 From: Garrett Wollman Message-Id: <9502222037.AA08339@halloran-eldar.lcs.mit.edu> To: Doug Rabson Cc: current@FreeBSD.org Subject: mountd changes In-Reply-To: References: Sender: current-owner@FreeBSD.org Precedence: bulk < said: > I have some changes here for mountd which do two things: > (1) Stop it from moaning when more than one mountpoint in a given > filesystem is exported. > I am wondering whether to commit these. (1) is probably safe but (2) > might be a security risk. Comments? `mountd' is right to moan, since NFS access control is not supported except on a per-mount-point basis, so allowing access to any other directory under a mount point is tantamount to allowing access to all of them. You might as well just use `-alldirs'. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 12:44:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA03125 for current-outgoing; Wed, 22 Feb 1995 12:44:56 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA03116; Wed, 22 Feb 1995 12:44:50 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id MAA25124; Wed, 22 Feb 1995 12:43:16 -0800 From: "Rodney W. Grimes" Message-Id: <199502222043.MAA25124@gndrsh.aac.dev.com> Subject: Re: Lots of crud... To: mark@grondar.za (Mark Murray) Date: Wed, 22 Feb 1995 12:43:16 -0800 (PST) Cc: bugs@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199502222025.WAA22507@grunt.grondar.za> from "Mark Murray" at Feb 22, 95 10:25:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2926 Sender: current-owner@FreeBSD.org Precedence: bulk > > > I see no MAKEDEV.Local in src/release, MAKEDEV files are machine depenedent, > > so they need to be in the etc.i386 directory. MAKEDEV.local is machine > > independent so it belongs where it is. > > I meant move MAKEDEV _with_ MAKEDEV.local. MAKEDEV is in etc.i386, and > MAKEDEV.local is in etc. Should they at least not be together? Please read again what I said ``MAKEDEV is machine dependent, MAKEDEV.local is machine INdependent''. No, they should not be togeather. ... > > > AFAICSee, these are all for the 1.1.5.1 install floppies. > > > > And are still in use by some folks who prefer the 1.x method of installing > > things. I am still using these, expect a revamp some time real soon now. > > OK - I'll buy that. Why would anyone still want the 1.x method ;-) Fixit functionality, running a system from cdrom and floppy, etc... there are things that can be done with these tools that can not be done with the new ones. :-( > > > - 5178 Feb 20 1994 disktab > > > This, I believe, could comfortably live in src/etc > > > > Think multiplatform, but maybe this could safely be moved. This is the > > traditional BSD location for this source file. > > I'll go for tradition. It needs some updating tho'. There are a few hard disks > out there... And with the new or old install tools we create entries for the disk that is installed to, no need to really create a huge /etc/disktab file. Perhaps the parts of the scripts that create /etc/disktab entries could be pulled out and made a seperate script and installed as /usr/sbin/mkdisktab for those that want an easier way to create one. The things that really need to stay in this file are the floppy disks, as far as I can see we could nuke the rest of the file. ... > > There is no such thing as a non-customizable file in /etc :-(. > > Bummer. It is much better, now that most of the customising can be > done _without_ messing with rc*. This idea should be taken as far as > possible with other /etc files, leaving as clear as possible a distinction > between files that one _should_ modify, _may_ modify and should preferably > _not_ modify. I was Helping someone upgrade his production 1.1 box to > 1.1.5.1 today, and the /etc area was a nightmare to do. Having been installing and upgrading unix systems for 15 years I have never seen a clean way to handle /etc, atleast now all the files in /etc are text files, and diff can be used to see what was customized (if you keep the original files around). I don't think your classing of ``should, may, and may not'' would work, I can label every file in /etc as ``should''. Can you point to one that a user under some circumstances would not modify. If you can I will make the argument that the file no longer belongs in /etc. :-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Wed Feb 22 13:02:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA03623 for current-outgoing; Wed, 22 Feb 1995 13:02:13 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id NAA03615 for ; Wed, 22 Feb 1995 13:02:07 -0800 Received: by brasil.moneng.mei.com (4.1/SMI-4.1) id AA08816; Wed, 22 Feb 95 14:58:46 CST From: Joe Greco Message-Id: <9502222058.AA08816@brasil.moneng.mei.com> Subject: Re: Lots of crud... To: lashley@netcom.com Date: Wed, 22 Feb 1995 14:58:45 -0600 (CST) Cc: current@FreeBSD.org In-Reply-To: <9502222011.AA03245@lashley.slip.netcom.com> from "patl@asimov.lashley.slip.netcom.com" at Feb 22, 95 12:11:25 pm X-Mailer: ELM [version 2.4beta PL9] Content-Type: text Content-Length: 466 Sender: current-owner@FreeBSD.org Precedence: bulk > (*) This update facility didn't completely work until Solaris 2.4. > > -Pat (**) This update facility still doesn't completely work under Solaris 2.4. It just doesn't make as many blatantly stupid mistakes. ... Joe ------------------------------------------------------------------------------- Joe Greco - The Data Capture Fellow (and UNIX/Network Hacker) 414/362-3617 Marquette Electronics, Inc. - Milwaukee, WI jgreco@brasil.moneng.mei.com From owner-freebsd-current Wed Feb 22 13:27:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA04454 for current-outgoing; Wed, 22 Feb 1995 13:27:25 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id NAA04444; Wed, 22 Feb 1995 13:27:06 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.9/8.6.9) with SMTP id XAA24936; Wed, 22 Feb 1995 23:26:08 +0200 Message-Id: <199502222126.XAA24936@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: bugs@FreeBSD.org, current@FreeBSD.org Subject: Re: Lots of crud... Date: Wed, 22 Feb 1995 23:26:08 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk > Please read again what I said ``MAKEDEV is machine dependent, MAKEDEV.local > is machine INdependent''. No, they should not be togeather. OOps.. > Fixit functionality, running a system from cdrom and floppy, etc... there > are things that can be done with these tools that can not be done with the > new ones. :-( Ok - makes sense. I can see that they will become Really Difficult (tm) to maintain as FBSD evolves. Already, look at the makefiles. They are TERRIBLE to try to understand, let alone modify. > And with the new or old install tools we create entries for the disk that > is installed to, no need to really create a huge /etc/disktab file. Perhaps > the parts of the scripts that create /etc/disktab entries could be pulled > out and made a seperate script and installed as /usr/sbin/mkdisktab for > those that want an easier way to create one. Cool... > The things that really need to stay in this file are the floppy disks, as > far as I can see we could nuke the rest of the file. AHA! Now you're talking. > Having been installing and upgrading unix systems for 15 years I have never > seen a clean way to handle /etc, atleast now all the files in /etc are > text files, and diff can be used to see what was customized (if you keep > the original files around). Yeah. Nasty manual method, though. I was using my 4 years, not all of it that involved in that many systems, and thinking (in dream mode) "but..." > I don't think your classing of ``should, may, and may not'' would work, > I can label every file in /etc as ``should''. Can you point to one that > a user under some circumstances would not modify. If you can I will make > the argument that the file no longer belongs in /etc. :-) There are some that many users can get away with _not_ modifying for quite a while. The way rc is headed, most of the mucking about is done in netstart. I'm not saying now that rc is somehow holy and not to be messed with, but what the average joe does (start named/routed, name his machine, configure internet interfaces etc) is _not_ done in rc, so I tend to class it as a "should not", not a "must not". Obviously if you know WTF you are doing, its yours for the having, at the expense of having more work at the next SUP. Others, like hosts and netstart are "musts". Not many users will have cause to modify services, but more (particularly the security aware) will want to touch inetd.conf and syslog.conf. These are "may"s. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 From owner-freebsd-current Wed Feb 22 14:00:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA05425 for current-outgoing; Wed, 22 Feb 1995 14:00:38 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA05416; Wed, 22 Feb 1995 14:00:30 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Garrett Wollman cc: current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 15:11:39 EST." <9502222011.AA08273@halloran-eldar.lcs.mit.edu> Date: Wed, 22 Feb 1995 14:00:29 -0800 Message-ID: <5415.793490429@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > > And that seems a little silly (so is exporting the entire NFS tree into > > /usr/include, while we're talking about silly, but that's another diatribe > > entirely). > > Hello, Jordan? Wake up! > > wollman@khavrinen(11)$ ls -l /usr/include/nfs > lrwxr-xr-x 1 bin bin 8 Feb 21 15:03 /usr/include/nfs@ -> /sys/nfs Thank you, Garrett. However, you complelely and utterly missed my point. When I said "exported" I meant exactly that: One way or another we have now /usr/include/nfs/* containing the full NFS sources rather than just the relevant header files. If you're any kind of purist at all, this is immediately obvious as being rather evil. If I wanted to move my header files from one place to another I could easily be forgiven for wanting to simply tar up the contents of /usr/include and get ONLY the header files (rather than a pastiche' of links, files, sources and god-only-knows-what). To put it another way, the /usr/include directory follows NO consistent paradigm - some things are links, others are copies of stuff, still others are just pointers into the sources. If you make with SHARED=copies then this unifies some of it by copying stuff across, but it could then be argued that the "non-copies" case should see /usr/include as *only* a link farm, with no actual files in there. Am I the only one who sees this as somewhat inconsistent? Jordan From owner-freebsd-current Wed Feb 22 14:10:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA05697 for current-outgoing; Wed, 22 Feb 1995 14:10:07 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA05684; Wed, 22 Feb 1995 14:10:00 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id OAA05455; Wed, 22 Feb 1995 14:09:32 -0800 From: Poul-Henning Kamp Message-Id: <199502222209.OAA05455@ref.tfs.com> Subject: Re: TRUE and FALSE To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 22 Feb 1995 14:09:32 -0800 (PST) Cc: wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com In-Reply-To: <5415.793490429@freefall.cdrom.com> from "Jordan K. Hubbard" at Feb 22, 95 02:00:29 pm Content-Type: text Content-Length: 802 Sender: current-owner@FreeBSD.org Precedence: bulk > To put it another way, the /usr/include directory follows NO > consistent paradigm - some things are links, others are copies of > stuff, still others are just pointers into the sources. If you make > with SHARED=copies then this unifies some of it by copying stuff > across, but it could then be argued that the "non-copies" case should > see /usr/include as *only* a link farm, with no actual files in there. I belive this can be dealt with in one stroke. Since we want (as a medium term goal) to have our source compile without reference to /usr/include, then we will not need the links, and we can safely and decisively remove the SHARED!=copies case. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 14:11:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA05755 for current-outgoing; Wed, 22 Feb 1995 14:11:35 -0800 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA05745; Wed, 22 Feb 1995 14:11:23 -0800 Received: (dufault@localhost) by hda.com (8.6.9/8.3) id RAA22363; Wed, 22 Feb 1995 17:08:33 -0500 From: Peter Dufault Message-Id: <199502222208.RAA22363@hda.com> Subject: Re: Adaptec problems To: gary@palmer.demon.co.uk (Gary Palmer) Date: Wed, 22 Feb 1995 17:08:32 -0500 (EST) Cc: freebsd-hardware@FreeBSD.org, current@FreeBSD.org, nb@xap.com In-Reply-To: <199502211929.TAA00158@palmer.demon.co.uk> from "Gary Palmer" at Feb 21, 95 07:29:01 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 697 Sender: current-owner@FreeBSD.org Precedence: bulk Gary Palmer writes: > > Hi > > A friend has been asking me for hints on a problem he has been seeing for > a few weeks, and it's bitten me now (I've just fitted a new SCSI drive) > > We both have Adaptec 1542(something) cards (mine is a CF AFAIK) in the > machines providing primary storage. (...) > My setup looks like : > > External SCSI CD <-> card <-> internal drive > You've disabled termination on the card? On the non-C you have to remove the termination resistors. On the C it is under software control. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-current Wed Feb 22 14:19:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA06083 for current-outgoing; Wed, 22 Feb 1995 14:19:15 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA06071 for ; Wed, 22 Feb 1995 14:19:01 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA08650; Wed, 22 Feb 1995 17:18:30 -0500 Date: Wed, 22 Feb 1995 17:18:30 -0500 From: Garrett Wollman Message-Id: <9502222218.AA08650@halloran-eldar.lcs.mit.edu> To: Poul-Henning Kamp Cc: current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-Reply-To: <199502222209.OAA05455@ref.tfs.com> References: <5415.793490429@freefall.cdrom.com> <199502222209.OAA05455@ref.tfs.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > Since we want (as a medium term goal) to have our source compile > without reference to /usr/include, then we will not need the > links, and we can safely and decisively remove the SHARED!=copies > case. This loses badly for people who develop kernel-dependent software which is not part of FreeBSD. (Like me.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 14:24:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA06271 for current-outgoing; Wed, 22 Feb 1995 14:24:45 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA06259 for ; Wed, 22 Feb 1995 14:24:37 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id OAA05589; Wed, 22 Feb 1995 14:24:00 -0800 From: Poul-Henning Kamp Message-Id: <199502222224.OAA05589@ref.tfs.com> Subject: Re: TRUE and FALSE To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Wed, 22 Feb 1995 14:23:59 -0800 (PST) Cc: current@freefall.cdrom.com In-Reply-To: <9502222218.AA08650@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Feb 22, 95 05:18:30 pm Content-Type: text Content-Length: 730 Sender: current-owner@FreeBSD.org Precedence: bulk > > Since we want (as a medium term goal) to have our source compile > > without reference to /usr/include, then we will not need the > > links, and we can safely and decisively remove the SHARED!=copies > > case. > > This loses badly for people who develop kernel-dependent software > which is not part of FreeBSD. (Like me.) No it doesn't. If you develop kernel-dependent sw, you had better make sure that your development env is aligned with your kernel, ie something like: cd /usr/src/include ; make all install cd /usr/src/sys ; make all install or whatever the trick will be. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 14:28:05 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA06577 for current-outgoing; Wed, 22 Feb 1995 14:28:05 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA06568 for ; Wed, 22 Feb 1995 14:27:56 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA08707; Wed, 22 Feb 1995 17:27:14 -0500 Date: Wed, 22 Feb 1995 17:27:14 -0500 From: Garrett Wollman Message-Id: <9502222227.AA08707@halloran-eldar.lcs.mit.edu> To: Poul-Henning Kamp Cc: current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-Reply-To: <199502222224.OAA05589@ref.tfs.com> References: <9502222218.AA08650@halloran-eldar.lcs.mit.edu> <199502222224.OAA05589@ref.tfs.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > If you develop kernel-dependent sw, you had better make sure that your > development env is aligned with your kernel, ie something like: > cd /usr/src/include ; make all install > cd /usr/src/sys ; make all install > or whatever the trick will be. And I'm saying that it's an incredible imposition to force such developers to do this every time they make a change to a kernel header file. I won't stand for it. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 14:48:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA07936 for current-outgoing; Wed, 22 Feb 1995 14:48:35 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA07929; Wed, 22 Feb 1995 14:48:32 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Garrett Wollman cc: current@FreeBSD.org Subject: Re: mountd changes In-reply-to: Your message of "Wed, 22 Feb 95 15:35:31 EST." <9502222035.AA08329@halloran-eldar.lcs.mit.edu> Date: Wed, 22 Feb 1995 14:48:31 -0800 Message-ID: <7928.793493311@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > And what on earth is wrong with that? All a `mount' does is cover one > directory vnode with another; it seems rather pointless to have such > restrictions on it. (For that matter, I would like to see the > directory restriction lifted, too.) Sigh.. You can't tell me that this makes sense: $ mount freefall:/a /mnt $ mount freefall:/a /mnt $ mount freefall:/a /mnt $ mount freefall:/a /mnt $ df ... freefall:/a 1668222 569434 1015376 36% /mnt freefall:/a 1668222 569434 1015376 36% /mnt freefall:/a 1668222 569434 1015376 36% /mnt freefall:/a 1668222 569434 1015376 36% /mnt Jordan From owner-freebsd-current Wed Feb 22 14:58:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA08433 for current-outgoing; Wed, 22 Feb 1995 14:58:14 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA08151 for ; Wed, 22 Feb 1995 14:55:06 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA21650; Wed, 22 Feb 1995 23:52:43 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id XAA15645 for freebsd-current@FreeBSD.org; Wed, 22 Feb 1995 23:52:43 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id XAA05162 for freebsd-current@FreeBSD.org; Wed, 22 Feb 1995 23:47:13 +0100 From: J Wunsch Message-Id: <199502222247.XAA05162@uriah.heep.sax.de> Subject: xmkmf & imake @ freefall To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 22 Feb 1995 23:47:13 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 337 Sender: current-owner@FreeBSD.org Precedence: bulk While porting the most recent xlockmore to -current (have a look at the daemon :-), finally i can't test-compile it there since freefall happens to have an xmkmf, but no imake. Strange, eh'... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Feb 22 14:59:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA08522 for current-outgoing; Wed, 22 Feb 1995 14:59:53 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA08510 for ; Wed, 22 Feb 1995 14:59:48 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA08835; Wed, 22 Feb 1995 17:59:11 -0500 Date: Wed, 22 Feb 1995 17:59:11 -0500 From: Garrett Wollman Message-Id: <9502222259.AA08835@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: Garrett Wollman , current@FreeBSD.org Subject: Re: mountd changes In-Reply-To: <7928.793493311@freefall.cdrom.com> References: <9502222035.AA08329@halloran-eldar.lcs.mit.edu> <7928.793493311@freefall.cdrom.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: >> And what on earth is wrong with that? All a `mount' does is cover one >> directory vnode with another; it seems rather pointless to have such >> restrictions on it. (For that matter, I would like to see the >> directory restriction lifted, too.) > Sigh.. You can't tell me that this makes sense: > $ mount freefall:/a /mnt > $ mount freefall:/a /mnt > $ mount freefall:/a /mnt > $ mount freefall:/a /mnt > $ df > ... > freefall:/a 1668222 569434 1015376 36% /mnt > freefall:/a 1668222 569434 1015376 36% /mnt > freefall:/a 1668222 569434 1015376 36% /mnt > freefall:/a 1668222 569434 1015376 36% /mnt Sure, makes perfect sense. Just as if I said: root@khavrinen$ mount -t null /usr/local/X11R6 /mnt root@khavrinen$ df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd0h 127143 64985 55800 54% /usr/local /usr/local/X11R6 127143 64985 55800 54% /mnt -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 15:09:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA09217 for current-outgoing; Wed, 22 Feb 1995 15:09:42 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA09211 for ; Wed, 22 Feb 1995 15:09:32 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id QAA15832; Wed, 22 Feb 1995 16:12:35 -0700 Date: Wed, 22 Feb 1995 16:12:35 -0700 From: Nate Williams Message-Id: <199502222312.QAA15832@trout.sri.MT.net> In-Reply-To: Garrett Wollman "Re: TRUE and FALSE" (Feb 22, 5:27pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Garrett Wollman , Poul-Henning Kamp Subject: Re: TRUE and FALSE Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > > If you develop kernel-dependent sw, you had better make sure that your > > development env is aligned with your kernel, ie something like: > > > cd /usr/src/include ; make all install > > cd /usr/src/sys ; make all install > > > or whatever the trick will be. > > And I'm saying that it's an incredible imposition to force such > developers to do this every time they make a change to a kernel header > file. I won't stand for it. I agree with Garrett here. It's silly to do this, and this will cause no end of problems when people forget to do this after they upgrade their kernel sources. Forcing a 'make world' every update is much too anal. People keep current with the kernel, and very often the kernel-specific utils needs updates. It's simple to do that now. Build and install new kernel re-build and re-install libkvm re-build ps By forcing the user to re-install the include files every time, he *may* be forcing things to break that are non-kernel specific. The LOCALE changes come to mind. I completely ignored them when they were being done but I was able to continue to do kernel testing. This would no longer be the case with your proposal. Nate From owner-freebsd-current Wed Feb 22 15:11:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA09250 for current-outgoing; Wed, 22 Feb 1995 15:11:01 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA09244; Wed, 22 Feb 1995 15:10:53 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id QAA15850; Wed, 22 Feb 1995 16:14:10 -0700 Date: Wed, 22 Feb 1995 16:14:10 -0700 From: Nate Williams Message-Id: <199502222314.QAA15850@trout.sri.MT.net> In-Reply-To: Garrett Wollman "Re: mountd changes" (Feb 22, 5:59pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Garrett Wollman , "Jordan K. Hubbard" Subject: Re: mountd changes Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > > Sigh.. You can't tell me that this makes sense: > > > $ mount freefall:/a /mnt > > $ mount freefall:/a /mnt > > $ mount freefall:/a /mnt > > $ mount freefall:/a /mnt > > $ df > > ... > > freefall:/a 1668222 569434 1015376 36% /mnt > > freefall:/a 1668222 569434 1015376 36% /mnt > > freefall:/a 1668222 569434 1015376 36% /mnt > > freefall:/a 1668222 569434 1015376 36% /mnt > > Sure, makes perfect sense. Just as if I said: > > root@khavrinen$ mount -t null /usr/local/X11R6 /mnt > root@khavrinen$ df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/wd0h 127143 64985 55800 54% /usr/local > /usr/local/X11R6 127143 64985 55800 54% /mnt No, it *doesn't* make sense at all. Having multiple mounts is confusing at best, and down-right dangerous at other times. (Single-user mode comes to mind) Nate From owner-freebsd-current Wed Feb 22 15:20:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA09502 for current-outgoing; Wed, 22 Feb 1995 15:20:10 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA09481 for ; Wed, 22 Feb 1995 15:19:51 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA08767; Thu, 23 Feb 1995 10:16:14 +1100 Date: Thu, 23 Feb 1995 10:16:14 +1100 From: Bruce Evans Message-Id: <199502222316.KAA08767@godzilla.zeta.org.au> To: julian@TFS.COM Subject: Re: cvs commit: src/sys/dev/vn vn.c Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> Please test the slice/label features: >> cd /dev; sh MAKEDEV svn0 >> cd /var/tmp; dd if=/dev/zero of=vnfile bs=8192 count=1024 >> vnconfig -c /dev/rvn0 /var/tmp/vnfile >> fdisk /dev/rvn0 # invent a geometry, create one BSD partition >> disklabel -r -w vn0 floppy # a convenient (bogus) label >> disklabel -e vn0 # edit label to match device >> newfs /dev/rvn0a >> mount /dev/vn0a /mnt >> ... >This is a good example of it's use.. >it'd be nice if it were stuck in the FAQ or somewhere.... A good example of how to use vn or slices? :-) I'm going to copy and modify it for real disk devices. I forgot to say: o Use option TEST_LABELLING to enable slices and labels in vn. o Expect a lot of kernel printfs for botched and old labels. o You can put BSD partitions on slices vn0s[1-4]. MAKEDEV has to be changed a little to create [r]vn0s[2-4][a-h]. It doesn't create all the partitions by default because there would be too many. Bruce From owner-freebsd-current Wed Feb 22 15:22:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA09601 for current-outgoing; Wed, 22 Feb 1995 15:22:34 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA09593 for ; Wed, 22 Feb 1995 15:22:31 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id PAA05931; Wed, 22 Feb 1995 15:21:35 -0800 From: Poul-Henning Kamp Message-Id: <199502222321.PAA05931@ref.tfs.com> Subject: Re: TRUE and FALSE To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Wed, 22 Feb 1995 15:21:35 -0800 (PST) Cc: current@freefall.cdrom.com In-Reply-To: <9502222227.AA08707@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Feb 22, 95 05:27:14 pm Content-Type: text Content-Length: 648 Sender: current-owner@FreeBSD.org Precedence: bulk > > If you develop kernel-dependent sw, you had better make sure that your > > development env is aligned with your kernel, ie something like: > > > cd /usr/src/include ; make all install > > cd /usr/src/sys ; make all install > > > or whatever the trick will be. > > And I'm saying that it's an incredible imposition to force such > developers to do this every time they make a change to a kernel header > file. I won't stand for it. They can use -I/sys/sys if they want. Then sit down instead. :-) -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 15:28:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA09804 for current-outgoing; Wed, 22 Feb 1995 15:28:47 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA09795 for ; Wed, 22 Feb 1995 15:28:44 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id PAA05987; Wed, 22 Feb 1995 15:28:01 -0800 From: Poul-Henning Kamp Message-Id: <199502222328.PAA05987@ref.tfs.com> Subject: Re: TRUE and FALSE To: nate@trout.sri.MT.net (Nate Williams) Date: Wed, 22 Feb 1995 15:28:01 -0800 (PST) Cc: wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com In-Reply-To: <199502222312.QAA15832@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 04:12:35 pm Content-Type: text Content-Length: 1041 Sender: current-owner@FreeBSD.org Precedence: bulk > > > If you develop kernel-dependent sw, you had better make sure that your > > > development env is aligned with your kernel, ie something like: > > > > > cd /usr/src/include ; make all install > > > cd /usr/src/sys ; make all install > > > > > or whatever the trick will be. > > > > And I'm saying that it's an incredible imposition to force such > > developers to do this every time they make a change to a kernel header > > file. I won't stand for it. > > I agree with Garrett here. It's silly to do this, and this will cause > no end of problems when people forget to do this after they upgrade > their kernel sources. Forcing a 'make world' every update is much too > anal. Hang on, you lost an important point here: Anything in the FreeBSD source will reference the "internal includes", that is relative paths to the include dirs. Only things like $HOME/hello.c will be at risk... -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 15:43:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA10082 for current-outgoing; Wed, 22 Feb 1995 15:43:04 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA10076 for ; Wed, 22 Feb 1995 15:42:56 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id QAA15987; Wed, 22 Feb 1995 16:45:52 -0700 Date: Wed, 22 Feb 1995 16:45:52 -0700 From: Nate Williams Message-Id: <199502222345.QAA15987@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: TRUE and FALSE" (Feb 22, 3:28pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp Subject: Re: TRUE and FALSE Cc: wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk [ Bring back in the reason that we're doing this ] [ /usr/include/nfs contains .c as well as .h files ] Poul writes: > Since we want (as a medium term goal) to have our source compile > without reference to /usr/include, then we will not need the > links, and we can safely and decisively remove the SHARED!=copies > case. > If you develop kernel-dependent sw, you had better make sure that your > development env is aligned with your kernel, ie something like: > > cd /usr/src/include ; make all install > cd /usr/src/sys ; make all install Garrett responds with: > And I'm saying that it's an incredible imposition to force such > developers to do this every time they make a change to a kernel header > file. I won't stand for it. Nate sez: > I agree with Garrett here. It's silly to do this, and this will cause > no end of problems when people forget to do this after they upgrade > their kernel sources. Forcing a 'make world' every update is much too > anal. Poul answers: > Hang on, you lost an important point here: Anything in the FreeBSD > source will reference the "internal includes", that is relative paths > to the include dirs. Only things like $HOME/hello.c will be at risk... At what gain are we doing this? I believe it's a noble gain to have the source tree compile w/out reference to /usr/include, but what does it gain us? The only thing I can see where it's a big deal is building a brand-new $(DESTDIR) tree. Other than that, most of the time I *want* to use the files in /usr/include and NOT those in /usr/src (speaking as a user-land kind of guy). Also, by no-longer symlinking in the stuff from the current kernel, we add a lot of complexity by requiring a new 'fill in the /usr/include' tree with lots of varying files from /usr/src/sys. Keeping this up to date will be a pain in the butt! Wouldn't it be just easier to separate the include files from the sources files in the kernel? Nate From owner-freebsd-current Wed Feb 22 15:47:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA10180 for current-outgoing; Wed, 22 Feb 1995 15:47:33 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id PAA10173; Wed, 22 Feb 1995 15:47:31 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Garrett Wollman cc: Poul-Henning Kamp , current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 17:18:30 EST." <9502222218.AA08650@halloran-eldar.lcs.mit.edu> Date: Wed, 22 Feb 1995 15:47:29 -0800 Message-ID: <10172.793496849@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > < said: > > > Since we want (as a medium term goal) to have our source compile > > without reference to /usr/include, then we will not need the > > links, and we can safely and decisively remove the SHARED!=copies > > case. > > This loses badly for people who develop kernel-dependent software > which is not part of FreeBSD. (Like me.) What?? Surely you're not arguing for our sources continuing to assume an outside hierarchy for compilation? This is just bogus, it's always been bogus (to say nothing of error-prone) and continuing to promulgate it just to favor a very small minority of folks is something I'll fight tooth and nail. Hopefully, this is not what you're arguing for! :-) Jordan From owner-freebsd-current Wed Feb 22 15:48:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA10233 for current-outgoing; Wed, 22 Feb 1995 15:48:42 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA10226 for ; Wed, 22 Feb 1995 15:48:39 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id PAA06084; Wed, 22 Feb 1995 15:47:50 -0800 From: Poul-Henning Kamp Message-Id: <199502222347.PAA06084@ref.tfs.com> Subject: Re: TRUE and FALSE To: nate@trout.sri.MT.net (Nate Williams) Date: Wed, 22 Feb 1995 15:47:50 -0800 (PST) Cc: wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com In-Reply-To: <199502222345.QAA15987@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 04:45:52 pm Content-Type: text Content-Length: 619 Sender: current-owner@FreeBSD.org Precedence: bulk > At what gain are we doing this? I believe it's a noble gain to have the > source tree compile w/out reference to /usr/include, but what does it > gain us? The only thing I can see where it's a big deal is building a > brand-new $(DESTDIR) tree. Other than that, most of the time I *want* > to use the files in /usr/include and NOT those in /usr/src (speaking as > a user-land kind of guy). "The only thing..." You are elected to release eng for 2.2 if you want to ... :-) -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 15:56:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA10391 for current-outgoing; Wed, 22 Feb 1995 15:56:28 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id PAA10382; Wed, 22 Feb 1995 15:56:24 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Garrett Wollman cc: Poul-Henning Kamp , current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 17:27:14 EST." <9502222227.AA08707@halloran-eldar.lcs.mit.edu> Date: Wed, 22 Feb 1995 15:56:23 -0800 Message-ID: <10381.793497383@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > And I'm saying that it's an incredible imposition to force such > developers to do this every time they make a change to a kernel header > file. I won't stand for it. Garrett, I strongly suggest you go home and get some sleep or vitamins whatever it is you're lacking today. Such confrontationalism does none of us any good and so far all I've seen from you is a lot of snide comments and gleeful balloon popping. The "imposition" in this case is so incredibly minor that I can only assume that something else is bothering you and I'm not entirely enthusiastic at the prospect of going another 10 rounds with you in the mailing lists until we all figure out just exactly what that is and deal with it directly. Try and be just a little more constructive, eh? It won't hurt you, I promise. Jordan From owner-freebsd-current Wed Feb 22 16:00:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA10564 for current-outgoing; Wed, 22 Feb 1995 16:00:50 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA10548; Wed, 22 Feb 1995 16:00:46 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Garrett Wollman cc: current@FreeBSD.org Subject: Re: mountd changes In-reply-to: Your message of "Wed, 22 Feb 95 17:59:11 EST." <9502222259.AA08835@halloran-eldar.lcs.mit.edu> Date: Wed, 22 Feb 1995 16:00:45 -0800 Message-ID: <10546.793497645@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > Sure, makes perfect sense. Just as if I said: > > root@khavrinen$ mount -t null /usr/local/X11R6 /mnt > root@khavrinen$ df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/wd0h 127143 64985 55800 54% /usr/local > /usr/local/X11R6 127143 64985 55800 54% /mnt Hmmmm. I guess it just seems wrong to me that you should be able to overlay a mountpoint to no good effect, but then again I suppose you're also right in that the "layering" paradigm (e.g. last mounted fs wins) is at least preserved in the same way that it would be for, say, a union mount. Ok, upon further reflection, I stand corrected. I guess I'll go close that PR! :-) Jordan From owner-freebsd-current Wed Feb 22 16:05:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA10790 for current-outgoing; Wed, 22 Feb 1995 16:05:07 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA10780 for ; Wed, 22 Feb 1995 16:04:52 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA16127; Wed, 22 Feb 1995 17:08:06 -0700 Date: Wed, 22 Feb 1995 17:08:06 -0700 From: Nate Williams Message-Id: <199502230008.RAA16127@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: TRUE and FALSE" (Feb 22, 3:47pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp Subject: Re: TRUE and FALSE Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > > At what gain are we doing this? I believe it's a noble gain to have the > > source tree compile w/out reference to /usr/include, but what does it > > gain us? The only thing I can see where it's a big deal is building a > > brand-new $(DESTDIR) tree. Other than that, most of the time I *want* > > to use the files in /usr/include and NOT those in /usr/src (speaking as > > a user-land kind of guy). > > "The only thing..." > > You are elected to release eng for 2.2 if you want to ... :-) chroot is your friend. ;) I did a bit of this when FreeBSD was barely alive at MSU, and I wouldn't want to do it again, but with CVS and a chroot tree I was able to build a DESTDIR tree pretty well which only relied on the stuff inside that tree. If you are *really* interesteed in how I did it, send me private email and we'll talk. Note, this was only part of the release engr. task, but a significant one. Nate From owner-freebsd-current Wed Feb 22 16:06:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA10810 for current-outgoing; Wed, 22 Feb 1995 16:06:25 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA10804 for ; Wed, 22 Feb 1995 16:06:22 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA27316; Wed, 22 Feb 95 16:59:47 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502222359.AA27316@cs.weber.edu> Subject: Re: TRUE and FALSE To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Wed, 22 Feb 95 16:59:47 MST Cc: phk@ref.tfs.com, current@freefall.cdrom.com In-Reply-To: <9502222218.AA08650@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Feb 22, 95 05:18:30 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > Since we want (as a medium term goal) to have our source compile > > without reference to /usr/include, then we will not need the > > links, and we can safely and decisively remove the SHARED!=copies > > case. > > This loses badly for people who develop kernel-dependent software > which is not part of FreeBSD. (Like me.) Gotta spend some packets agreeing with this one. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Feb 22 16:07:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA10831 for current-outgoing; Wed, 22 Feb 1995 16:07:43 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA10823; Wed, 22 Feb 1995 16:07:28 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA16145; Wed, 22 Feb 1995 17:10:54 -0700 Date: Wed, 22 Feb 1995 17:10:54 -0700 From: Nate Williams Message-Id: <199502230010.RAA16145@trout.sri.MT.net> In-Reply-To: "Jordan K. Hubbard" "Re: mountd changes" (Feb 22, 4:00pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Jordan K. Hubbard" , Garrett Wollman Subject: Re: mountd changes Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > > Sure, makes perfect sense. Just as if I said: > > > > root@khavrinen$ mount -t null /usr/local/X11R6 /mnt > > root@khavrinen$ df > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/wd0h 127143 64985 55800 54% /usr/local > > /usr/local/X11R6 127143 64985 55800 54% /mnt > > Hmmmm. I guess it just seems wrong to me that you should be able to > overlay a mountpoint to no good effect, but then again I suppose > you're also right in that the "layering" paradigm (e.g. last mounted > fs wins) is at least preserved in the same way that it would be for, > say, a union mount. If that is the case, (and we don't have 'multiple' copies of /usr/local mounted each time), then shouldn't it be up to mount/umount to do the right thing with respect to df and friends? If something is already in the tree already, then why repeat it? It muddies up the output when we have 10 version of: /usr/local/X11R6 127143 64985 55800 54% /mnt /usr/local/X11R6 127143 64985 55800 54% /mnt /usr/local/X11R6 127143 64985 55800 54% /mnt /usr/local/X11R6 127143 64985 55800 54% /mnt /usr/local/X11R6 127143 64985 55800 54% /mnt in df's output. Nate From owner-freebsd-current Wed Feb 22 16:09:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA10886 for current-outgoing; Wed, 22 Feb 1995 16:09:35 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA10880 for ; Wed, 22 Feb 1995 16:09:33 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id QAA06222; Wed, 22 Feb 1995 16:08:46 -0800 From: Poul-Henning Kamp Message-Id: <199502230008.QAA06222@ref.tfs.com> Subject: Re: TRUE and FALSE To: nate@trout.sri.MT.net (Nate Williams) Date: Wed, 22 Feb 1995 16:08:46 -0800 (PST) Cc: current@freefall.cdrom.com In-Reply-To: <199502230008.RAA16127@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 05:08:06 pm Content-Type: text Content-Length: 924 Sender: current-owner@FreeBSD.org Precedence: bulk > > > At what gain are we doing this? I believe it's a noble gain to have the > > > source tree compile w/out reference to /usr/include, but what does it > > > gain us? The only thing I can see where it's a big deal is building a > > > brand-new $(DESTDIR) tree. Other than that, most of the time I *want* > > > to use the files in /usr/include and NOT those in /usr/src (speaking as > > > a user-land kind of guy). > > > > "The only thing..." > > > > You are elected to release eng for 2.2 if you want to ... :-) > > chroot is your friend. ;) Yes, sure, but it's only a workaround. The fundamental problem is that the source-tree should be self-contained. Just think about the benefit of a "make world" which will not hose your c-compiler if the c-compiler source is sick... -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 16:13:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA11029 for current-outgoing; Wed, 22 Feb 1995 16:13:55 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA11021 for ; Wed, 22 Feb 1995 16:13:43 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA09145; Wed, 22 Feb 1995 19:12:46 -0500 Date: Wed, 22 Feb 1995 19:12:46 -0500 From: Garrett Wollman Message-Id: <9502230012.AA09145@halloran-eldar.lcs.mit.edu> To: Nate Williams Cc: "Jordan K. Hubbard" , Garrett Wollman , current@FreeBSD.org Subject: Re: mountd changes In-Reply-To: <199502230010.RAA16145@trout.sri.MT.net> References: <199502230010.RAA16145@trout.sri.MT.net> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > If that is the case, (and we don't have 'multiple' copies of /usr/local > mounted each time), then shouldn't it be up to mount/umount to do the > right thing with respect to df and friends? If something is already in > the tree already, then why repeat it? It muddies up the output when we > have 10 version of: > /usr/local/X11R6 127143 64985 55800 54% /mnt Well, there are two points here: 1) In the specific case of the null filesystem, `df' has no way of knowing that the fsstat information for `/mnt' was faked up by nullfs from the information provided by `/usr/local'. 2) In general, all `df' does is iterate through the mount list and get the stats for each one. I don't think you can make it smart enough to do what you want without also making it stupid enough to mistakenly omit two filesystems that look the same but really aren't. It just doesn't have enough information, and arguably it shouldn't. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 16:20:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA11482 for current-outgoing; Wed, 22 Feb 1995 16:20:18 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA11469 for ; Wed, 22 Feb 1995 16:20:06 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id RAA16248; Wed, 22 Feb 1995 17:23:23 -0700 Date: Wed, 22 Feb 1995 17:23:23 -0700 From: Nate Williams Message-Id: <199502230023.RAA16248@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: TRUE and FALSE" (Feb 22, 4:08pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp Subject: Re: TRUE and FALSE Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > The fundamental problem is that the source-tree should be self-contained. > > Just think about the benefit of a "make world" which will not hose your > c-compiler if the c-compiler source is sick... And just where am I going to install the new tools? This assumes that I have room for 2 completely independant 'systems' on the same box. This is very rarely the case for most folks. And for those that do have the room for both, an chroot tree works *almost* as good as doesn't cause a lot of un-ncessary headache for the common case. Nate From owner-freebsd-current Wed Feb 22 16:21:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA11597 for current-outgoing; Wed, 22 Feb 1995 16:21:36 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA11583; Wed, 22 Feb 1995 16:21:30 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Nate Williams cc: Garrett Wollman , Poul-Henning Kamp , current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 16:12:35 MST." <199502222312.QAA15832@trout.sri.MT.net> Date: Wed, 22 Feb 1995 16:21:28 -0800 Message-ID: <11582.793498888@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > I agree with Garrett here. It's silly to do this, and this will cause > no end of problems when people forget to do this after they upgrade > their kernel sources. Forcing a 'make world' every update is much too > anal. But.. but.. We *need* the source tree to be decoupled from /usr/include or we'll never achieve our goal of being able to make all the dependencies work properly when doing a `make all' (the current world target is just evil and needs to DIE!) in a tree that's just been blapped onto some machine with old headers and libraries! :-( Jordan From owner-freebsd-current Wed Feb 22 16:28:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA12017 for current-outgoing; Wed, 22 Feb 1995 16:28:31 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA12011 for ; Wed, 22 Feb 1995 16:28:25 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id QAA06370; Wed, 22 Feb 1995 16:27:45 -0800 From: Poul-Henning Kamp Message-Id: <199502230027.QAA06370@ref.tfs.com> Subject: Re: TRUE and FALSE To: nate@trout.sri.MT.net (Nate Williams) Date: Wed, 22 Feb 1995 16:27:44 -0800 (PST) Cc: current@freefall.cdrom.com In-Reply-To: <199502230023.RAA16248@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 05:23:23 pm Content-Type: text Content-Length: 822 Sender: current-owner@FreeBSD.org Precedence: bulk > > The fundamental problem is that the source-tree should be self-contained. > > > > Just think about the benefit of a "make world" which will not hose your > > c-compiler if the c-compiler source is sick... > > And just where am I going to install the new tools? This assumes that I > have room for 2 completely independant 'systems' on the same box. This > is very rarely the case for most folks. And for those that do have the > room for both, an chroot tree works *almost* as good as doesn't cause a > lot of un-ncessary headache for the common case. Nate, a chroot tree has exactly the same size as one made using proper application of the $DESTDIR. Thinks about it... -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 16:29:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA12066 for current-outgoing; Wed, 22 Feb 1995 16:29:47 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA12056; Wed, 22 Feb 1995 16:29:18 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA09224; Wed, 22 Feb 1995 19:28:40 -0500 Date: Wed, 22 Feb 1995 19:28:40 -0500 From: Garrett Wollman Message-Id: <9502230028.AA09224@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: Nate Williams , Garrett Wollman , Poul-Henning Kamp , current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-Reply-To: <11582.793498888@freefall.cdrom.com> References: <199502222312.QAA15832@trout.sri.MT.net> <11582.793498888@freefall.cdrom.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > But.. but.. We *need* the source tree to be decoupled from > /usr/include or we'll never achieve our goal of being able to make all > the dependencies work properly when doing a `make all' (the current > world target is just evil and needs to DIE!) in a tree that's just > been blapped onto some machine with old headers and libraries! :-( But we should not (cannot) force developers of other software that just happens to run on FreeBSD to make substantial modifications to their build model just because we want to make our makefiles cleaner. Otherwise what you end up with is a mess like a certain program I was working on last month: unable to depend on being able to access the correct headers for the kernel in question (this was in SunOS), the developers just included local copies of the header files that you had to add to the kernel to get it to work anyway. This is evil, and not something I want to see perpetrated in FreeBSD. We need to remember that not all programs compiled under FreeBSD use the FreeBSD build system, no matter how convenient it might be. (And whatever that system evolves into had better still be useful for compiling non-source-tree programs, or a number of different users will get screwed over.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 16:37:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA12200 for current-outgoing; Wed, 22 Feb 1995 16:37:19 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA12192; Wed, 22 Feb 1995 16:37:11 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id QAA06439; Wed, 22 Feb 1995 16:36:42 -0800 From: Poul-Henning Kamp Message-Id: <199502230036.QAA06439@ref.tfs.com> Subject: Re: TRUE and FALSE To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Wed, 22 Feb 1995 16:36:42 -0800 (PST) Cc: jkh@freefall.cdrom.com, nate@trout.sri.mt.net, wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com In-Reply-To: <9502230028.AA09224@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Feb 22, 95 07:28:40 pm Content-Type: text Content-Length: 1261 Sender: current-owner@FreeBSD.org Precedence: bulk > This is evil, and not something I want to see perpetrated in FreeBSD. > We need to remember that not all programs compiled under FreeBSD use > the FreeBSD build system, no matter how convenient it might be. (And > whatever that system evolves into had better still be useful for > compiling non-source-tree programs, or a number of different users > will get screwed over.) Just a sec here. 1) Programs which are part of the FreeBSD source tree should compile cleanly, and use $DESTDIR/usr/include, $DESTDIR/usr/lib and $DESTDIR/anything_else for their needs. This means that a "make world" will be: make includes into $DESTDIR/usr/include make tools using /usr/bin install into $DESTDIR/usr/bin make libs using $DESTDIR into $DESTDIR/usr/lib if the "paranoia" option is set make includes into $DESTDIR/usr/include make tools using $DESTDIR into $DESTDIR/usr/bin make libs using $DESTDIR into $DESTDIR/usr/lib endif make all into $DESTDIR 2) Programs which are not part of FreeBSD can use just what they feel like, it's entirely their own problem. Can anybody explain what the problem is with this ? -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 16:37:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA12215 for current-outgoing; Wed, 22 Feb 1995 16:37:33 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA12206; Wed, 22 Feb 1995 16:37:31 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Nate Williams cc: Poul-Henning Kamp , wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 16:45:52 MST." <199502222345.QAA15987@trout.sri.MT.net> Date: Wed, 22 Feb 1995 16:37:30 -0800 Message-ID: <12205.793499850@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > At what gain are we doing this? I believe it's a noble gain to have the > source tree compile w/out reference to /usr/include, but what does it > gain us? The only thing I can see where it's a big deal is building a Oh geeze! I can't believe we need to explain *that*! Look, right now we have an intolerable situation where we have this mutant world target from hell that requires updating each and every time some weird bogon in the tree requires that it be updated in a specific sequence before anything else will work. It's already tripled in size since we first created it and it's not at all inconceivable that (if things keep going this way) the world target will be 3 pages long by the time 2.2 comes out! That or we'll finally run into a case we can't solve with one pass and we'll end up with multiple sub-makes from the darkest reaches of Hades! That and the simple fact that depending on includes and libraries from outside of /usr/src is incredibly *error prone*. If you and Garrett feel so strongly about this, then I have a suggestion: YOU BE THE RELEASE ENGINEERS FOR 2.1! Otherwise, and with all due respect, kindly put a plug in it.. It is incredibly irksome to be one of the ones bitten by this and then be corrected by the two people here who have NEVER done a release and have always run rapidly in the other direction every time the hat was passed around for a volunteer to actually do this grueling task! Do you know that the 950210-SNAP release has a bogus ps and several other binaries for which the fixes are in /usr/src? How did that happen, you ask? Well, I made the release on time and time had slightly older contents of /usr/lib. Since I was technically making and installing into a sub-tree it didn't occur to me that the various utilities would link themselves with the includes and libraries in /usr rather than in ${DESTDIR}/usr, and I got binaries that were out of sync with the actual sources. Now you can argue that I should have gone through the arduous process of doing a make world first, or perhaps a make install then a chroot then another make all and ... but I didn't have a full 24 hours to tie up my machine with this at the time, so I took what looked like a reasonably short cut and it bit my ass. This should NOT HAVE HAPPENED and if we had a properly designed source tree it WOULD NOT HAVE. Now Poul-Henning is proposing a final solution to this mess and you guys, who have never done a release and have very little grasp of the issues involved (and I won't be convinced otherwise until you guys have actually DONE a release and have truly walked the steps), are picking it to death on the basis of having to type TWO INCREDIBLY SIMPLE COMMANDS for what is also an exceptional case - hacking on kernel dependent sources that aren't in /usr/src. Excuse me while I go scream into a pillow or something. Jordan From owner-freebsd-current Wed Feb 22 16:52:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA12688 for current-outgoing; Wed, 22 Feb 1995 16:52:33 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA12679; Wed, 22 Feb 1995 16:52:21 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA09330; Wed, 22 Feb 1995 19:51:26 -0500 Date: Wed, 22 Feb 1995 19:51:26 -0500 From: Garrett Wollman Message-Id: <9502230051.AA09330@halloran-eldar.lcs.mit.edu> To: Poul-Henning Kamp Cc: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman), jkh@freefall.cdrom.com, nate@trout.sri.mt.net, current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-Reply-To: <199502230036.QAA06439@ref.tfs.com> References: <9502230028.AA09224@halloran-eldar.lcs.mit.edu> <199502230036.QAA06439@ref.tfs.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > 2) Programs which are not part of FreeBSD can use just what they feel like, > it's entirely their own problem. > Can anybody explain what the problem is with this ? There are four sets of interesting programs: 1) Programs which are not a part of FreeBSD and do not use bsd.*.mk. When compiling, they should use the header files in /usr/include, and /usr/include/{sys,netinet,net,nfs,netiso,netccitt,machine} should point to the appropriate directories in the kernel source tree. 2) Programs which are not a part of FreeBSD and DO use bsd.*.mk. When compiling, they should use exactly the same header files and libraries as programs in set (1). 3) Programs which are a part of FreeBSD, but are being compiled outside of the source tree (perhaps the user doesn't have all the sources). When compiling, they should use exactly the same header files and libraries as programs in set (1). 4) Programs which are a part of FreeBSD, and are being compiled as a part of `make all' from the top level. When compiling, they should use the previously-built header files and libraries. Note that this means it is no longer acceptable to put SUBDIRs in alphabetical order; instead, they must be topologically sorted. There are probably loops which will need to be broken (that's what the `tools' target does). -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Wed Feb 22 16:59:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA12872 for current-outgoing; Wed, 22 Feb 1995 16:59:15 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA12862; Wed, 22 Feb 1995 16:59:11 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id QAA06598; Wed, 22 Feb 1995 16:58:43 -0800 From: Poul-Henning Kamp Message-Id: <199502230058.QAA06598@ref.tfs.com> Subject: Re: TRUE and FALSE To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Date: Wed, 22 Feb 1995 16:58:42 -0800 (PST) Cc: wollman@halloran-eldar.lcs.mit.edu, jkh@freefall.cdrom.com, nate@trout.sri.mt.net, current@freefall.cdrom.com In-Reply-To: <9502230051.AA09330@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Feb 22, 95 07:51:26 pm Content-Type: text Content-Length: 1737 Sender: current-owner@FreeBSD.org Precedence: bulk > > 2) Programs which are not part of FreeBSD can use just what they feel like, > > it's entirely their own problem. > > > Can anybody explain what the problem is with this ? > > There are four sets of interesting programs: > > 1) Programs which are not a part of FreeBSD and do not use bsd.*.mk. > When compiling, they should use the header files in /usr/include, and > /usr/include/{sys,netinet,net,nfs,netiso,netccitt,machine} should > point to the appropriate directories in the kernel source tree. Correction: which will be copies of the ... from the last time the kernel and utilities was installed. Otherwise use -I > 2) Programs which are not a part of FreeBSD and DO use bsd.*.mk. When > compiling, they should use exactly the same header files and libraries > as programs in set (1). yes. with the correction. > 3) Programs which are a part of FreeBSD, but are being compiled > outside of the source tree (perhaps the user doesn't have all the > sources). When compiling, they should use exactly the same header > files and libraries as programs in set (1). yes. With the correction. > 4) Programs which are a part of FreeBSD, and are being compiled as a > part of `make all' from the top level. When compiling, they should > use the previously-built header files and libraries. Note that this > means it is no longer acceptable to put SUBDIRs in alphabetical order; > instead, they must be topologically sorted. There are probably loops > which will need to be broken (that's what the `tools' target does). yes. So all it comes down to is that you have to use -I qed. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 17:07:47 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA13120 for current-outgoing; Wed, 22 Feb 1995 17:07:47 -0800 Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA13114 for ; Wed, 22 Feb 1995 17:07:45 -0800 Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.9/8.6.9) with SMTP id TAA20791 for ; Wed, 22 Feb 1995 19:07:15 -0600 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Feb 1995 19:07:17 -0600 To: current@freefall.cdrom.com From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: TRUE and FALSE Sender: current-owner@FreeBSD.org Precedence: bulk Poul-Henning Kamp writes: >Hang on, you lost an important point here: Anything in the FreeBSD >source will reference the "internal includes", that is relative paths >to the include dirs. Only things like $HOME/hello.c will be at risk... I think that this is an important point. NOTHING in a system build should depend on the installed system on which it is running. If a user wants to compile code to run on her local machine, she should get /usr/include by default. But we MUST eliminate that from our code. There are three separate env's. The HOST which is running. The cross-compiler TOOLS which run on the HOST and generate TARGET code. The TARGET is the new kernel and all the programs that go with it. All packed up in distribution tarballs, etc. I should be able to compile the code for FreeBSD 2.1 on my MacII running MacBSD. And if it were not for the Makefile problems, I could do it under MPW. In general, we are working in the simple case HOST === TARGET, but that is not the general case for which we should be configured. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Wed Feb 22 17:21:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA13466 for current-outgoing; Wed, 22 Feb 1995 17:21:50 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA13454; Wed, 22 Feb 1995 17:21:40 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id SAA16677; Wed, 22 Feb 1995 18:24:48 -0700 Date: Wed, 22 Feb 1995 18:24:48 -0700 From: Nate Williams Message-Id: <199502230124.SAA16677@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: TRUE and FALSE" (Feb 22, 4:36pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp , wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Subject: Re: TRUE and FALSE Cc: jkh@freefall.cdrom.com, current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > 1) Programs which are part of the FreeBSD source tree should compile cleanly, > and use $DESTDIR/usr/include, $DESTDIR/usr/lib and $DESTDIR/anything_else > for their needs. This means that a "make world" will be: > > make includes into $DESTDIR/usr/include > make tools using /usr/bin install into $DESTDIR/usr/bin > make libs using $DESTDIR into $DESTDIR/usr/lib > if the "paranoia" option is set > make includes into $DESTDIR/usr/include > make tools using $DESTDIR into $DESTDIR/usr/bin > make libs using $DESTDIR into $DESTDIR/usr/lib > endif > make all into $DESTDIR ^^^^^^^^^^^^^^^^^^^^^^ > > 2) Programs which are not part of FreeBSD can use just what they feel like, > it's entirely their own problem. > > Can anybody explain what the problem is with this ? Can you explain to me *HOW* you are going to build the new tools using the tools in $DESTDIR? I can see how the includes file will get down, but are you proposing that each and every Makefile that uses *any* utility will be required to 'register' that utility in the global Makefiles. All these registrations will be .if defined($DESTDIR) CC = $(DESTDIR)/usr/bin/cc -nostdlib -L$(DESTDIR)/usr/lib \ -I$(DESTDIR)/usr/include \ -find-my-other-binaries-in $(DESTDIR)/usr/libexec .else CC = cc .endif for every utility. This means that if any utility moves, the changes will have to be reflected in the modules file, the Makefile, the scripts, the system make files, and any other file that happens to reference that utility. And they call this progress? Nate From owner-freebsd-current Wed Feb 22 17:33:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA13762 for current-outgoing; Wed, 22 Feb 1995 17:33:21 -0800 Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA13753 for ; Wed, 22 Feb 1995 17:33:19 -0800 Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.9/8.6.9) with SMTP id TAA20844 for ; Wed, 22 Feb 1995 19:32:49 -0600 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Feb 1995 19:32:51 -0600 To: current@FreeBSD.org From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: TRUE and FALSE Sender: current-owner@FreeBSD.org Precedence: bulk >1) Programs which are part of the FreeBSD source tree should compile cleanly, >and use $DESTDIR/usr/include, $DESTDIR/usr/lib and $DESTDIR/anything_else >for their needs. This means that a "make world" will be: > > make includes into $DESTDIR/usr/include > make tools using /usr/bin install into $DESTDIR/usr/bin > make libs using $DESTDIR into $DESTDIR/usr/lib > if the "paranoia" option is set > make includes into $DESTDIR/usr/include > make tools using $DESTDIR into $DESTDIR/usr/bin > make libs using $DESTDIR into $DESTDIR/usr/lib > endif > make all into $DESTDIR > > >Can anybody explain what the problem is with this ? A minor point ... The TOOLS are a third level. They are compiled for the host machine and linked with its libraries. they are NOT the same as the $DESTDIR/usr/bin that "all" will make in the final step. Therefore, they must reside in their own tree. Having said that, I advocate tree folding whenever possible. When the host machine and the target are the same, or sufficiently similar, you can simply move the target back into the host tree (after appropriate testing). ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Wed Feb 22 17:33:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA13777 for current-outgoing; Wed, 22 Feb 1995 17:33:35 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA13764; Wed, 22 Feb 1995 17:33:23 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id SAA16736; Wed, 22 Feb 1995 18:36:56 -0700 Date: Wed, 22 Feb 1995 18:36:56 -0700 From: Nate Williams Message-Id: <199502230136.SAA16736@trout.sri.MT.net> In-Reply-To: "Jordan K. Hubbard" "Re: TRUE and FALSE" (Feb 22, 4:37pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Jordan K. Hubbard" Subject: Re: TRUE and FALSE Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > Look, right now we have an intolerable situation where we have this > mutant world target from hell that requires updating each and every > time some weird bogon in the tree requires that it be updated in a > specific sequence before anything else will work. Yes, and that will not change with the solution proposed. There will *always* be tool dependencies in the tree. That's why GCC still has a bootstrap target. The only thing a self-hosting tree will buy you is one less iteration to build things. Dependency will always exist, since you can't build libraries until you upgrade the library build-tools, and you can't build utilities w/out the libraries, so you may need to do a couple iterations to get things up to snuff, hence the 'world' target. > It's already > tripled in size since we first created it and it's not at all > inconceivable that (if things keep going this way) the world target > will be 3 pages long by the time 2.2 comes out! That or we'll finally > run into a case we can't solve with one pass and we'll end up with > multiple sub-makes from the darkest reaches of Hades! Welcome to tool dependencies and changing source trees. That's life. > That and the simple fact that depending on includes and libraries > from outside of /usr/src is incredibly *error prone*. If you and > Garrett feel so strongly about this, then I have a suggestion: > > YOU BE THE RELEASE ENGINEERS FOR 2.1! Get off of it. This always comes up, and all it does is ruffle feathers. You don't have to be release engineer to understand some of the issues required to do it. Heck, all of us do (our at least should do) our own little 'release' engineering work before we integrate patches into the tree. It's not as large as the main work, but it does mean we have a clue on doing releases. I *couldn't* be the release engineer even if you paid me $100K to do it. > incredibly irksome to be one of the ones bitten by this and then be > corrected by the two people here who have NEVER done a release and > have always run rapidly in the other direction every time the hat was > passed around for a volunteer to actually do this grueling task! Trust me, I've done release engineering, and you have also. Remember the patchkit. Do't give me this 'NEVER done a release' crap. > you know that the 950210-SNAP release has a bogus ps ... > Now you can argue that I should have gone through the arduous process > of doing a make world first, or perhaps a make install then a chroot > then another make all and ... but I didn't have a full 24 hours to tie > up my machine with this at the time, so I took what looked like a > reasonably short cut and it bit my ass. This should NOT HAVE HAPPENED > and if we had a properly designed source tree it WOULD NOT HAVE. Sheesh. If you don't have 24 hours to make a completely public release of the software, then maybe it's time for you to quit making them. Before I even commit patches to the tree I run them for over 48 hours in make world regression tests. To not take the extra 24 hours to make sure it's up to date seems rather silly. Starting from a running system, you are guaranteed to get everything working with 2 make worlds, and a 3rd certainly shouldn't hurt. > Now Poul-Henning is proposing a final solution to this mess and you There is no solution proposed. What was proposed was filling up /usr/include from files in /sys, instead of using symlinks as it is now. Nothing else was proposed. Don't get all huffy and mighty. Nate From owner-freebsd-current Wed Feb 22 17:39:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA13890 for current-outgoing; Wed, 22 Feb 1995 17:39:12 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA13883 for ; Wed, 22 Feb 1995 17:39:05 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id SAA16814; Wed, 22 Feb 1995 18:42:26 -0700 Date: Wed, 22 Feb 1995 18:42:26 -0700 From: Nate Williams Message-Id: <199502230142.SAA16814@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: TRUE and FALSE" (Feb 22, 4:27pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp Subject: Re: TRUE and FALSE Cc: current@freefall.cdrom.com Sender: current-owner@FreeBSD.org Precedence: bulk > > > The fundamental problem is that the source-tree should be self-contained. > > > > > > Just think about the benefit of a "make world" which will not hose your > > > c-compiler if the c-compiler source is sick... > > > > And just where am I going to install the new tools? This assumes that I > > have room for 2 completely independant 'systems' on the same box. This > > is very rarely the case for most folks. And for those that do have the > > room for both, an chroot tree works *almost* as good as doesn't cause a > > lot of un-ncessary headache for the common case. > > Nate, a chroot tree has exactly the same size as one made using proper > application of the $DESTDIR. Thinks about it... Read what I wrote. I *know* that, but all of a sudden we've made the release only target the default. That implies that everyone should have 2 trees on their machines. How else would a 'normal' user not hose himself if his compiler is sick? Nate From owner-freebsd-current Wed Feb 22 17:48:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA14106 for current-outgoing; Wed, 22 Feb 1995 17:48:26 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id RAA14089; Wed, 22 Feb 1995 17:47:59 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id aa05112; 22 Feb 95 20:20 GMT Received: from localhost (gary@localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.9/8.6.9) with SMTP id UAA01745; Wed, 22 Feb 1995 20:19:47 GMT To: bugs@FreeBSD.org, Current@FreeBSD.org Subject: sendmail dying MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1741.793484385.1@palmer.demon.co.uk> Date: Wed, 22 Feb 1995 20:19:45 +0000 Message-ID: <1742.793484385@palmer.demon.co.uk> From: Gary Palmer Sender: current-owner@FreeBSD.org Precedence: bulk Anyone seen this: Feb 22 18:55:43 palmer sendmail[87]: daemon process doesn't have $j in $=w; see syslog ? (That's from /var/log/maillog) /var/log/messages says: Feb 22 18:55:43 palmer sendmail[87]: daemon process doesn't have $j in $=w; see syslog Feb 22 18:55:43 palmer kernel: pid 87: sendmail: uid 0: exited on signal 6 Anyone got any ideas? Thanks Gary From owner-freebsd-current Wed Feb 22 17:50:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA14136 for current-outgoing; Wed, 22 Feb 1995 17:50:25 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA14121 for ; Wed, 22 Feb 1995 17:50:16 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id SAA16901 for current@FreeBSD.org; Wed, 22 Feb 1995 18:53:40 -0700 Date: Wed, 22 Feb 1995 18:53:40 -0700 From: Nate Williams Message-Id: <199502230153.SAA16901@trout.sri.MT.net> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current@FreeBSD.org Subject: Include files and 'release' engineering Sender: current-owner@FreeBSD.org Precedence: bulk I'm sure there is a way to have your cake and eat it too w/regards to the include files. Poul wants to be able do: 'cc -I$(DESTDIR)/usr/include -L$(DESTDIR) ....' and it will 'Do The Right Thing' Garrett and I want to be able to keep in sync with the kernel w/out daily runs of 'cd /usr/src/include; make all install'. The problem: Currently, the stuff install in /usr/include/{sys|net|...} use the symlink /usr/include sys -> /sys/sys, which still resolves to /sys/sys even when $(DESTDIR) is set. What we need is some Apollo-Domain hacking, but since we don't have that, what else can we do? Solution: When $(DESTDIR) is set completely populate $(DESTDIR)/usr/include as it is done now when COPIES != SHARED. Then, $(DESTDIR)/usr/include is completely valid, AND we can still allow shared /usr/include for the 'developers' case? The other problems with building the release with the tools in $(DESTDIR) are orthogonal to this, and are much more complicated than some people would like them to sound. What other problems exist with making the tree self-hosting? (not including the above two problems) Nate From owner-freebsd-current Wed Feb 22 18:12:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA14439 for current-outgoing; Wed, 22 Feb 1995 18:12:49 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA14432; Wed, 22 Feb 1995 18:12:43 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.9/8.6.9) with SMTP id SAA15059; Wed, 22 Feb 1995 18:11:36 -0800 Message-Id: <199502230211.SAA15059@precipice.Shockwave.COM> To: ugen@FreeBSD.org cc: current@FreeBSD.org Subject: snp(4)/watch(8) code review comments Date: Wed, 22 Feb 1995 18:11:30 -0800 From: Paul Traina Sender: current-owner@FreeBSD.org Precedence: bulk I did a preliminary run through the snp device code that you added and had some comments to make. No insult intended, but I see room for improvement here: (a) we should document that this device is a BIG security hole and people should only compile it into their kernels if they're willing to take that risk (b) It seems to me that having to specify the type of tty that you're looking at is brain-dead. I see that you've got knowledge of the tty structures for the ptys, sios, and vtys. All of this information is already in the cdevsw table and you should be accessing it via those vectors, not through your own back-door interface. The information passed down to the snp device should simply be the major and minor number of the tty you wish to attach to, at which point you can just look up the point to the structure and verify that it's a tty class device and you're off and running. The current scheme seems rather i386 dependant (vty/pty/sio). If you change it to major/minors, you get new devices for free without having to update the snoop code, and you can do a major clean-up on watch(8) because you don't do name to device class conversion (which is a really icky thing, since it's perfectly reasonable for someone to name ptys as /dev/ttyvXX). Would you consider making these changes before 2.1 ships? If not, would you mind if I changed the interface and watch and fixed it? Paul From owner-freebsd-current Wed Feb 22 18:22:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA14722 for current-outgoing; Wed, 22 Feb 1995 18:22:19 -0800 Received: from wiley.csusb.edu (wiley.csusb.edu [139.182.2.2]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id SAA14707 for ; Wed, 22 Feb 1995 18:22:11 -0800 Received: by wiley.csusb.edu (5.67a/1.34) id AA01350; Wed, 22 Feb 1995 18:25:37 -0800 From: rmallory@wiley.csusb.edu (Rob Mallory) Message-Id: <199502230225.AA01350@wiley.csusb.edu> Subject: Re: TRUE and FALSE To: current@freefall.cdrom.com Date: Wed, 22 Feb 1995 18:25:37 -0800 (PST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 816 Sender: current-owner@FreeBSD.org Precedence: bulk ...many interesting things have been said, many more things ought to be thought about before taking a big step like this. stardate:1996.2.28 FreeBSD Release Version: 2.4 (isn't this where Solaris collapsed their tree?) Platforms Supported: Sparc, Alpha, PowerPC, x86 (including VLIW 786) question: When I put the cdrom in to install, what the hell am I going to do with all this VME-bus crap in my /sys tree? I dont think I will ever be compiling something with VLIW's on my 386! Point being, yes, FreeBSD just might have 5 or 6 Arch-specific param.h files sometime in the future. What about the people who want only an arch-specific /sys tree? What if I want the whole enchilada so I can compile a new kernel for my lonely 486 on my 250Mhz Alpha? ___ Rob Mallory [rmallory@csusb.edu] From owner-freebsd-current Wed Feb 22 18:22:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA14755 for current-outgoing; Wed, 22 Feb 1995 18:22:50 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA14746; Wed, 22 Feb 1995 18:22:38 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id SAA26107; Wed, 22 Feb 1995 18:21:40 -0800 From: "Rodney W. Grimes" Message-Id: <199502230221.SAA26107@gndrsh.aac.dev.com> Subject: Re: TRUE and FALSE To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 22 Feb 1995 18:21:39 -0800 (PST) Cc: current@freefall.cdrom.com In-Reply-To: <5415.793490429@freefall.cdrom.com> from "Jordan K. Hubbard" at Feb 22, 95 02:00:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2269 Sender: current-owner@FreeBSD.org Precedence: bulk > > > > And that seems a little silly (so is exporting the entire NFS tree into > > > /usr/include, while we're talking about silly, but that's another diatribe > > > entirely). > > > > Hello, Jordan? Wake up! > > > > wollman@khavrinen(11)$ ls -l /usr/include/nfs > > lrwxr-xr-x 1 bin bin 8 Feb 21 15:03 /usr/include/nfs@ -> /sys/nfs > > Thank you, Garrett. However, you complelely and utterly missed my point. > > When I said "exported" I meant exactly that: One way or another we > have now /usr/include/nfs/* containing the full NFS sources rather > than just the relevant header files. If you're any kind of purist at > all, this is immediately obvious as being rather evil. If I wanted to > move my header files from one place to another I could easily be > forgiven for wanting to simply tar up the contents of /usr/include and > get ONLY the header files (rather than a pastiche' of links, files, > sources and god-only-knows-what). > > To put it another way, the /usr/include directory follows NO > consistent paradigm - some things are links, others are copies of > stuff, still others are just pointers into the sources. If you make > with SHARED=copies then this unifies some of it by copying stuff > across, but it could then be argued that the "non-copies" case should > see /usr/include as *only* a link farm, with no actual files in there. > > Am I the only one who sees this as somewhat inconsistent? This will be fixed some time around 2.2, the current SHARED=copies only has these links: test:rgrimes {111} find . -type l ./errno.h ./fcntl.h ./syslog.h ./termios.h ./float.h ./floatingpoint.h ./stdarg.h ./varargs.h ./nterm.h And all of those links resolve to files within /usr/include, all of them pointing into /usr/include/machine/ and /usr/include/sys. These links will remain forever as far as I can see. My revamped .mk stuff that is sitting on hold for quite some time has mechanisms in it to fix the SHARED=symlink case by making ALL of /usr/include symbolic links. I do not see me getting back to this stuff for 2.1, but should get back to it for 2.2. > Jordan -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Wed Feb 22 18:42:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA15372 for current-outgoing; Wed, 22 Feb 1995 18:42:31 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id SAA15360; Wed, 22 Feb 1995 18:42:27 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Garrett Wollman cc: Poul-Henning Kamp , nate@trout.sri.mt.net, current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 19:51:26 EST." <9502230051.AA09330@halloran-eldar.lcs.mit.edu> Date: Wed, 22 Feb 1995 18:42:27 -0800 Message-ID: <15359.793507347@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > 1) Programs which are not a part of FreeBSD and do not use bsd.*.mk. > When compiling, they should use the header files in /usr/include, and > /usr/include/{sys,netinet,net,nfs,netiso,netccitt,machine} should > point to the appropriate directories in the kernel source tree. Fine. We're not talking about eliminating /usr/include here, Garrett, we're talking about making our *own* sources use relative paths. On a system that has been installed from a scratch distribution, the user is going to have a perfectly reasonable /usr/include to depend on. If they start making changes to their /usr/src/blah/foo/bar.h files then they can damn well install them if they like. > 2) Programs which are not a part of FreeBSD and DO use bsd.*.mk. When > compiling, they should use exactly the same header files and libraries > as programs in set (1). Fine. See above. > 3) Programs which are a part of FreeBSD, but are being compiled > outside of the source tree (perhaps the user doesn't have all the > sources). When compiling, they should use exactly the same header > files and libraries as programs in set (1). Any program which is "part" of FreeBSD should be compiled "inside" the source tree, period. Sure, it may work for some things to be compiled in any old location but certainly not everything, and if it's not guaranteed to be deterministic then it should be discouraged. Period. > 4) Programs which are a part of FreeBSD, and are being compiled as a > part of `make all' from the top level. When compiling, they should > use the previously-built header files and libraries. Note that this Yes and no. I think they should depend first on the libraries in /usr/src/lib/*/{obj,}/*.a and then go look in /usr/lib only if no libraries exist there. Clearly, the generated include files and libraries will still need to be made first in a top-down make, but this is a lot less complex of a "world" target than we have now! Jordan From owner-freebsd-current Wed Feb 22 18:51:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA15466 for current-outgoing; Wed, 22 Feb 1995 18:51:27 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA15460; Wed, 22 Feb 1995 18:51:24 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id SAA07112; Wed, 22 Feb 1995 18:50:43 -0800 From: Poul-Henning Kamp Message-Id: <199502230250.SAA07112@ref.tfs.com> Subject: Re: TRUE and FALSE To: nate@trout.sri.MT.net (Nate Williams) Date: Wed, 22 Feb 1995 18:50:42 -0800 (PST) Cc: wollman@halloran-eldar.lcs.mit.edu, jkh@freefall.cdrom.com, current@freefall.cdrom.com In-Reply-To: <199502230124.SAA16677@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 06:24:48 pm Content-Type: text Content-Length: 516 Sender: current-owner@FreeBSD.org Precedence: bulk > All these registrations will be > > for every utility. This means that if any utility moves, the changes will > have to be reflected in the modules file, the Makefile, the scripts, the > system make files, and any other file that happens to reference that utility. > > And they call this progress? Nate, let me just say that I have a slightly simpler schema in mind :-) -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 18:55:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA15562 for current-outgoing; Wed, 22 Feb 1995 18:55:39 -0800 Received: from shell1.best.com (root@shell1.best.com [204.156.128.10]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA15555 for ; Wed, 22 Feb 1995 18:55:35 -0800 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by shell1.best.com (8.6.9/8.6.5) with ESMTP id SAA11701 for ; Wed, 22 Feb 1995 18:53:12 -0800 Received: (from rcarter@localhost) by geli.clusternet (8.6.9/8.6.9) id SAA28726 for current@freebsd.org; Wed, 22 Feb 1995 18:52:00 -0800 Date: Wed, 22 Feb 1995 18:52:00 -0800 From: "Russell L. Carter" Message-Id: <199502230252.SAA28726@geli.clusternet> To: current@FreeBSD.org Subject: Re: TRUE and FALSE -> is this true? Sender: current-owner@FreeBSD.org Precedence: bulk |Date: Wed, 22 Feb 1995 18:36:56 -0700 |From: Nate Williams |In-Reply-To: "Jordan K. Hubbard" | "Re: TRUE and FALSE" (Feb 22, 4:37pm) |X-Mailer: Mail User's Shell (7.2.5 10/14/92) |To: "Jordan K. Hubbard" |Subject: Re: TRUE and FALSE |Cc: current@freefall.cdrom.com |Sender: current-owner@FreeBSD.org |Precedence: bulk [ We interrupt this dispute for a small question ] Sorry guys for jumping in, but this little tidbit is very interesting: | |Starting from a running system, you are guaranteed to get everything working |with 2 make worlds, and a 3rd certainly shouldn't hurt. For those of us suping current regularly, and having the make world occasionally fail, does this imply that it might work to try make world twice? (Or three times?) Russell [ Now back to the action... ] From owner-freebsd-current Wed Feb 22 18:57:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA15584 for current-outgoing; Wed, 22 Feb 1995 18:57:00 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA15578 for ; Wed, 22 Feb 1995 18:56:58 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id SAA07124; Wed, 22 Feb 1995 18:56:21 -0800 From: Poul-Henning Kamp Message-Id: <199502230256.SAA07124@ref.tfs.com> Subject: Re: Include files and 'release' engineering To: nate@trout.sri.MT.net (Nate Williams) Date: Wed, 22 Feb 1995 18:56:21 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: <199502230153.SAA16901@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 06:53:40 pm Content-Type: text Content-Length: 357 Sender: current-owner@FreeBSD.org Precedence: bulk > I'm sure there is a way to have your cake and eat it too w/regards to the > include files. There is. I'm dropping of this discussion here. Everybody log out, get a life and don't come back until you smile again. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 19:01:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA15715 for current-outgoing; Wed, 22 Feb 1995 19:01:36 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id TAA15708; Wed, 22 Feb 1995 19:01:31 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Nate Williams cc: current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 18:36:56 MST." <199502230136.SAA16736@trout.sri.MT.net> Date: Wed, 22 Feb 1995 19:01:30 -0800 Message-ID: <15707.793508490@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > Get off of it. This always comes up, and all it does is ruffle > feathers. You don't have to be release engineer to understand some of > the issues required to do it. Heck, all of us do (our at least should Some of the issues, perhaps. Significant grasp of enough of them to argue this with me? No. Sorry, but no. You can change my mind by doing one thing and one thing ONLY, and that is to do a release or even a snapshot of your own and then come back to me with a description of what you did and how you did it. Otherwise I simply am not going to debate this any further with you. You don't have the qualifications, just as I lack the qualifications to debate the intricacies of the VM system with David and John or the internals of the network code with Garrett. I know my limitations. And I know your limitations. This argument is over. You want to argue it further? Do the work first then come back, otherwise don't waste my time. Jordan From owner-freebsd-current Wed Feb 22 19:09:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA15877 for current-outgoing; Wed, 22 Feb 1995 19:09:20 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA15870; Wed, 22 Feb 1995 19:09:15 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id TAA07194; Wed, 22 Feb 1995 19:08:48 -0800 From: Poul-Henning Kamp Message-Id: <199502230308.TAA07194@ref.tfs.com> Subject: Re: TRUE and FALSE To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 22 Feb 1995 19:08:48 -0800 (PST) Cc: nate@trout.sri.mt.net, current@freefall.cdrom.com In-Reply-To: <15707.793508490@freefall.cdrom.com> from "Jordan K. Hubbard" at Feb 22, 95 07:01:30 pm Content-Type: text Content-Length: 867 Sender: current-owner@FreeBSD.org Precedence: bulk > > Get off of it. This always comes up, and all it does is ruffle > > feathers. You don't have to be release engineer to understand some of > > the issues required to do it. Heck, all of us do (our at least should > > Some of the issues, perhaps. Significant grasp of enough of them to > argue this with me? No. Sorry, but no. You can change my mind by > doing one thing and one thing ONLY, and that is to do a release or > even a snapshot of your own and then come back to me with a > description of what you did and how you did it. Otherwise I simply am I tend to agree here, and I belive Rod will agree. We have to cut the effort to make a sterilized release from the present level to something more managerable. -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 19:17:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA16098 for current-outgoing; Wed, 22 Feb 1995 19:17:33 -0800 Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA16076 for ; Wed, 22 Feb 1995 19:16:50 -0800 Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.9/8.6.9) with SMTP id VAA21040 for ; Wed, 22 Feb 1995 21:16:09 -0600 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Feb 1995 21:16:11 -0600 To: current@FreeBSD.org From: Richard Wackerbarth (by way of rkw@dataplex.net (Richard Wackerbarth)) Subject: Why are these still here? Sender: current-owner@FreeBSD.org Precedence: bulk I've ask this before. If someone out there would PLEASE forward this to someone with the "authority" to fix it. Please clean things up! These items should either be readable or they should be removed. Mirrored FreeBSD-ports (ftp.FreeBSD.org:/pub/FreeBSD/ports-2.0/ -> /pub/FreeBSD/ports-2.0/) FreeBSD Ports @ Wed Feb 22 20:09:24 CST 1995 Failed to get x11/tk/patches/patch-ab: 550 x11/tk/patches/patch-ab: Permission denied. Failed to get lang/tcl/patches/patch-aa: 550 lang/tcl/patches/patch-aa: Permission denied. Failed to get games/xrisk/Makefile: 550 games/xrisk/Makefile: Permission denied. Failed to get games/xrisk/patches/patch-e: 550 games/xrisk/patches/patch-e: Permission denied. Failed to get games/xrisk/patches/patch-d: 550 games/xrisk/patches/patch-d: Permission denied. Failed to get games/xrisk/patches/patch-c: 550 games/xrisk/patches/patch-c: Permission denied. Failed to get games/xrisk/patches/patch-a: 550 games/xrisk/patches/patch-a: Permission denied. Failed to get games/xrisk/patches/patch-b: 550 games/xrisk/patches/patch-b: Permission denied. Failed to get games/xrisk/pkg/COMMENT: 550 games/xrisk/pkg/COMMENT: Permission denied. Failed to get games/xrisk/pkg/DESCR: 550 games/xrisk/pkg/DESCR: Permission denied. Failed to get games/xrisk/pkg/PLIST: 550 games/xrisk/pkg/PLIST: Permission denied. Failed to get games/xmine/pkg/COMMENT: 550 games/xmine/pkg/COMMENT: Permission denied. Failed to get games/xmine/pkg/DESCR: 550 games/xmine/pkg/DESCR: Permission denied. Failed to get games/xmine/pkg/PLIST: 550 games/xmine/pkg/PLIST: Permission denied. From owner-freebsd-current Wed Feb 22 19:19:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA16162 for current-outgoing; Wed, 22 Feb 1995 19:19:45 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA16155 for ; Wed, 22 Feb 1995 19:19:28 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id TAA26297; Wed, 22 Feb 1995 19:18:06 -0800 From: "Rodney W. Grimes" Message-Id: <199502230318.TAA26297@gndrsh.aac.dev.com> Subject: Re: TRUE and FALSE To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Wed, 22 Feb 1995 19:18:06 -0800 (PST) Cc: nate@trout.sri.MT.net, current@freefall.cdrom.com In-Reply-To: <199502230008.QAA06222@ref.tfs.com> from "Poul-Henning Kamp" at Feb 22, 95 04:08:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1524 Sender: current-owner@FreeBSD.org Precedence: bulk > > > > > At what gain are we doing this? I believe it's a noble gain to have the > > > > source tree compile w/out reference to /usr/include, but what does it > > > > gain us? The only thing I can see where it's a big deal is building a > > > > brand-new $(DESTDIR) tree. Other than that, most of the time I *want* > > > > to use the files in /usr/include and NOT those in /usr/src (speaking as > > > > a user-land kind of guy). > > > > > > "The only thing..." > > > > > > You are elected to release eng for 2.2 if you want to ... :-) > > > > chroot is your friend. ;) > > Yes, sure, but it's only a workaround. > The fundamental problem is that the source-tree should be self-contained. > > Just think about the benefit of a "make world" which will not hose your > c-compiler if the c-compiler source is sick... Again.. serious .mk file munging use of what I called $TOOL_ROOT and $EXPORT_ROOT solves this. Kinda like the way osf/1 builds. $TOOL_ROOT and $EXPORT_ROOT default to $DESTDIR, they are they for seperated for doing cross compiling. It means changing all the things like ``MAKE= make'' to ``MAKE = ${TOOL_ROOT}/usr/bin/make''. I just wish I had more time to go work on this again right now, but it will have to wait, or someone else will have to do it. If someone else wants to start looking at doing this I can give you *lots* of pointers. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Wed Feb 22 19:22:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA16220 for current-outgoing; Wed, 22 Feb 1995 19:22:26 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA16213 for ; Wed, 22 Feb 1995 19:22:07 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id UAA17345; Wed, 22 Feb 1995 20:24:55 -0700 Date: Wed, 22 Feb 1995 20:24:55 -0700 From: Nate Williams Message-Id: <199502230324.UAA17345@trout.sri.MT.net> In-Reply-To: "Russell L. Carter" "Re: TRUE and FALSE -> is this true?" (Feb 22, 6:52pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Russell L. Carter" , current@FreeBSD.org Subject: Re: TRUE and FALSE -> is this true? Sender: current-owner@FreeBSD.org Precedence: bulk > |Starting from a running system, you are guaranteed to get everything working > |with 2 make worlds, and a 3rd certainly shouldn't hurt. > > For those of us suping current regularly, and having the make world > occasionally fail, does this imply that it might work to try make world > twice? (Or three times?) No, it implies that if a release is to be done, then make world should work. If make world doesn't work, then the release isn't ready. So, assuming a make world works, then it should work multiple times. Nate From owner-freebsd-current Wed Feb 22 19:23:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA16242 for current-outgoing; Wed, 22 Feb 1995 19:23:29 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA16234 for ; Wed, 22 Feb 1995 19:23:15 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id UAA17362; Wed, 22 Feb 1995 20:26:29 -0700 Date: Wed, 22 Feb 1995 20:26:29 -0700 From: Nate Williams Message-Id: <199502230326.UAA17362@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: Include files and 'release' engineering" (Feb 22, 6:56pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp Subject: Re: Include files and 'release' engineering Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > > I'm sure there is a way to have your cake and eat it too w/regards to the > > include files. > > There is. > > I'm dropping of this discussion here. > > Everybody log out, get a life and don't come back until you smile again. Actually, my intent with that message was to lose the arguementative spirit the previous articles had and bring the discussion back to the issues. I'm *very* interested in hearing your ideas on the self-hosting build tree. Nate From owner-freebsd-current Wed Feb 22 19:33:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA16513 for current-outgoing; Wed, 22 Feb 1995 19:33:11 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA16507 for ; Wed, 22 Feb 1995 19:33:08 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id TAA07293; Wed, 22 Feb 1995 19:32:30 -0800 From: Poul-Henning Kamp Message-Id: <199502230332.TAA07293@ref.tfs.com> Subject: Re: Include files and 'release' engineering To: nate@trout.sri.MT.net (Nate Williams) Date: Wed, 22 Feb 1995 19:32:28 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: <199502230326.UAA17362@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 08:26:29 pm Content-Type: text Content-Length: 1100 Sender: current-owner@FreeBSD.org Precedence: bulk > > Everybody log out, get a life and don't come back until you smile again. > > Actually, my intent with that message was to lose the arguementative spirit > the previous articles had and bring the discussion back to the issues. > > I'm *very* interested in hearing your ideas on the self-hosting build > tree. And I don't mind sharing them with you or anybody else. I just think Garrett needs to understand that I don't give a shit what's in this /usr/include, but I do care about what includes are used by /usr/src. I had hoped to have this bagged before 2.1 (with a lot of help from Rod :) but that appears to not make it. So I will have to play it safe to make the quality of the release certain. Which again means that it will take a lot of time on my part to roll this stuff. :-( My personal reason for being grumpy is that my trusty Gateway 2000 Handbook has had a disk-crash and GW said that it will take around 3 weeks to swap the disk :-( -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Wed Feb 22 19:40:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA16741 for current-outgoing; Wed, 22 Feb 1995 19:40:04 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA16727 for ; Wed, 22 Feb 1995 19:39:58 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id UAA17475; Wed, 22 Feb 1995 20:43:13 -0700 Date: Wed, 22 Feb 1995 20:43:13 -0700 From: Nate Williams Message-Id: <199502230343.UAA17475@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp "Re: Include files and 'release' engineering" (Feb 22, 7:32pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Poul-Henning Kamp Subject: Re: Include files and 'release' engineering Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > > I'm *very* interested in hearing your ideas on the self-hosting build > > tree. > > And I don't mind sharing them with you or anybody else. > > I just think Garrett needs to understand that I don't give a shit what's > in this /usr/include, but I do care about what includes are used by /usr/src. If we can keep them both in sync with little or no effort I think both of us will be much happier. > My personal reason for being grumpy is that my trusty Gateway 2000 Handbook > has had a disk-crash and GW said that it will take around 3 weeks to swap > the disk :-( Sigh.... Nate From owner-freebsd-current Wed Feb 22 19:47:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA17139 for current-outgoing; Wed, 22 Feb 1995 19:47:21 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id TAA17129 for ; Wed, 22 Feb 1995 19:47:14 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id TAA26362; Wed, 22 Feb 1995 19:46:05 -0800 From: "Rodney W. Grimes" Message-Id: <199502230346.TAA26362@gndrsh.aac.dev.com> Subject: Re: Why are these still here? To: wacky@eel.dataplex.net (Richard Wackerbarth ) Date: Wed, 22 Feb 1995 19:46:05 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth " at Feb 22, 95 09:16:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1995 Sender: current-owner@FreeBSD.org Precedence: bulk > > I've ask this before. If someone out there would PLEASE forward this to > someone with the "authority" to fix it. > > Please clean things up! These items should either be readable or they > should be removed. > > > Mirrored FreeBSD-ports (ftp.FreeBSD.org:/pub/FreeBSD/ports-2.0/ -> > /pub/FreeBSD/ports-2.0/) FreeBSD Ports @ Wed Feb 22 20:09:24 CST 1995 > Failed to get x11/tk/patches/patch-ab: 550 x11/tk/patches/patch-ab: > Permission denied. ... Please check the permissions on your end, every thing looks find on freefall... and on ftp.cdrom.com. It could be you can not write into the directory on your system. > Failed to get lang/tcl/patches/patch-aa: 550 lang/tcl/patches/patch-aa: > Permission denied. > Failed to get games/xrisk/Makefile: 550 games/xrisk/Makefile: Permission denied. > Failed to get games/xrisk/patches/patch-e: 550 games/xrisk/patches/patch-e: > Permission denied. > Failed to get games/xrisk/patches/patch-d: 550 games/xrisk/patches/patch-d: > Permission denied. > Failed to get games/xrisk/patches/patch-c: 550 games/xrisk/patches/patch-c: > Permission denied. > Failed to get games/xrisk/patches/patch-a: 550 games/xrisk/patches/patch-a: > Permission denied. > Failed to get games/xrisk/patches/patch-b: 550 games/xrisk/patches/patch-b: > Permission denied. > Failed to get games/xrisk/pkg/COMMENT: 550 games/xrisk/pkg/COMMENT: > Permission denied. > Failed to get games/xrisk/pkg/DESCR: 550 games/xrisk/pkg/DESCR: Permission > denied. > Failed to get games/xrisk/pkg/PLIST: 550 games/xrisk/pkg/PLIST: Permission > denied. > Failed to get games/xmine/pkg/COMMENT: 550 games/xmine/pkg/COMMENT: > Permission denied. > Failed to get games/xmine/pkg/DESCR: 550 games/xmine/pkg/DESCR: Permission > denied. > Failed to get games/xmine/pkg/PLIST: 550 games/xmine/pkg/PLIST: Permission > denied. > > > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Wed Feb 22 20:38:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA19810 for current-outgoing; Wed, 22 Feb 1995 20:38:02 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA19796 for ; Wed, 22 Feb 1995 20:37:56 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id VAA17717; Wed, 22 Feb 1995 21:41:10 -0700 Date: Wed, 22 Feb 1995 21:41:10 -0700 From: Nate Williams Message-Id: <199502230441.VAA17717@trout.sri.MT.net> In-Reply-To: rmallory@wiley.csusb.edu (Rob Mallory) "Re: TRUE and FALSE" (Feb 22, 6:25pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rmallory@wiley.csusb.edu (Rob Mallory), current@freefall.cdrom.com Subject: Re: TRUE and FALSE Sender: current-owner@FreeBSD.org Precedence: bulk > FreeBSD Release Version: 2.4 (isn't this where Solaris collapsed their tree?) > Platforms Supported: Sparc, Alpha, PowerPC, x86 (including VLIW 786) > > question: When I put the cdrom in to install, what the hell am I going to > do with all this VME-bus crap in my /sys tree? I dont think I will > ever be compiling something with VLIW's on my 386! Then don't install anything but the x86 specific code. (But, I suspect we'll all want 900Mhz Alpha boxes by then. :-) > Point being, yes, FreeBSD just might have 5 or 6 Arch-specific param.h files > sometime in the future. > > What about the people who want only an arch-specific /sys tree? > What if I want the whole enchilada so I can compile a new kernel for > my lonely 486 on my 250Mhz Alpha? [ This is my opinion, and not necessarily the opinions of the FreeBSD project ] Setting up cross-compilation environment if very difficult to do, and making it work while not affecting normal compilation would be more work than it would be worth. However, if you are willing to present us with the patches necessary for this to work, I'm sure you'd find someone to champion the work and make it work right. Nate From owner-freebsd-current Wed Feb 22 20:48:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA20495 for current-outgoing; Wed, 22 Feb 1995 20:48:50 -0800 Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA20489; Wed, 22 Feb 1995 20:48:47 -0800 Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.9/8.6.9) with SMTP id WAA21292; Wed, 22 Feb 1995 22:48:16 -0600 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Feb 1995 22:48:17 -0600 To: "Jordan K. Hubbard" From: rkw@dataplex.net (Richard Wackerbarth) Subject: Building World from Read-Only Media Cc: current@FreeBSD.org, phk@ref.tfs.com, rgrimes@gndrsh.aac.dev.com Sender: current-owner@FreeBSD.org Precedence: bulk OK, guys! I have some new mk files that are much "cleaner" for our make world. I have identified 4 strategies for the placement of object files. If one of these will not please you, SPEAK NOW, or hold your peace. Assume that we are compiling /home/my/src/prog/cfile.c Case 1. Just put the object next to its source /home/my/src/prog/cfile.o Case 2. Put the objects in a directory /home/my/src/prog/obj/cfile.o Case 3. Global object store /usr/obj/home/my/src/prog/cfile.o Case 4. Local object tree /home/my/obj/prog/cfile.o Right now, the "world" uses links to make case 3 look like case 2. My inclination is to go to case 4 instead. To build my own object tree from read-only media mkdir /home/my ln -s /cdrom/some.version/Makefile /home/my ln -s /cdrom/some.version/src /home/my cd /home/my make I am presently finishing up to procedures necessary to allow links in a source tree to point to directory trees rather than each file. It is easy unless you want to cd down in the tree and "make" some subtree rather than making the whole tree. However, I think I can do it provided you supply a DESTDIR in advance. Can I write a makefile rule that can export an env variable. What I would like to do is cd /top/of/tree make plant-my-root cd down/the/tree and have DESTDIR=/top/of/tree ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Wed Feb 22 21:13:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id VAA22031 for current-outgoing; Wed, 22 Feb 1995 21:13:13 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id VAA22006 for ; Wed, 22 Feb 1995 21:13:06 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id VAA11498; Wed, 22 Feb 1995 21:12:25 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id VAA00806; Wed, 22 Feb 1995 21:12:25 -0800 Message-Id: <199502230512.VAA00806@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: Garrett Wollman cc: Poul-Henning Kamp , current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 17:27:14 EST." <9502222227.AA08707@halloran-eldar.lcs.mit.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 22 Feb 1995 21:12:22 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >< said: > >> If you develop kernel-dependent sw, you had better make sure that your >> development env is aligned with your kernel, ie something like: > >> cd /usr/src/include ; make all install >> cd /usr/src/sys ; make all install > >> or whatever the trick will be. > >And I'm saying that it's an incredible imposition to force such >developers to do this every time they make a change to a kernel header >file. I won't stand for it. Neither will I. It's a recipe for new and interesting bugs. If the problem with the symlinks should be fixed at all, it should be made so that each header has it's own symlink in /usr/include/sys/*. These can still indirect through /sys to make it easy to reassign the whole thing (/usr/include/sys becomes a directory with symlinks to the headers in /sys/*). -DG From owner-freebsd-current Wed Feb 22 21:15:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id VAA22190 for current-outgoing; Wed, 22 Feb 1995 21:15:19 -0800 Received: from cybernetics.net (jeffh@server0.cybernetics.net [198.80.48.52]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id VAA22050; Wed, 22 Feb 1995 21:13:27 -0800 Received: by cybernetics.net (4.1/SMI-4.1) id AA11638; Thu, 23 Feb 95 00:12:56 EST Date: Thu, 23 Feb 1995 00:12:54 -0500 (EST) From: Jeff Hoffman To: hackers@FreeBSD.org, current@FreeBSD.org Subject: UPDATE: Imagine128 & AccelX & 950210-SNAP Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Ok, for those of you who have been keeping up, I tried to re-install 2.0 and ended up back with 950210-SNAP because my floppy didn't work with 2.0 This time, I ftp'ed the the 950210-SNAP from scratch, and did not use one single non-950210-SNAP file (except my X server). I installed the 950210 bindist, compat1x, secure, and XFree86-3.1.1. I rebooted, just to make sure that all was OK. It was. I made a symlink from X11R6 to X386, then did a tar -xvzf /dev/rfd0 and AcceleratedX was installed fine. I ran setup, chose the default configuration (IBM VGA, 256k, 640x480x16, etc). I ran startx. Everything is OK. I think 'Hey, maybe it's fixed.' I run Xsetup again, choose Number9 I128 w/4MB, same resolution, same color depth (16 colors). I load up X, and things are no longer OK. Before I go into depth with the problems, let me say that I ran this server under 2.0 for a while (about a month) with 0 problems. I have not done one thing to my machine since then. It is _EXACTLY_ the same as it was then. _Something_ that was changed between 2.0 and 950210-SNAP is causing this problem, either directly or indirectly. I will let the XInside people know tomorrow, as well. Using TWM, I notice the following: 1) When moving a window (via click on title bar and drag), if the top of the title bar is moved above y = 0 then things go crazy. See diagram. top, left corner of entire screen | v \ | | | \\ | | | \ \ --|--|---| \ \ | | | \ --|\-|---| \ | |\ | \__________\ it's as if the upper left corner (0,0) grabs the top border of my window and pulls it up there or something. 2) Using Netscape, any pictures (including the animated N and anything that is supposed to be on the html document i'm viewing) are strewn all across the screen (everywhere but in the netscape window.) 3) Periodically (haven't figured out when or why yet) things fail to repaint correctly (can be fixed by switching virtual desktops and coming back.) I am letting you guys know so that you can fix whatever's wrong, or at least tell the people at XInside so they can fix it in the next version (1.2) of their server. Not being able to use a graphical WWW browser at home sucks. (I haven't tried xv, ghostview, or anything like that yet.) My system configuration is as follows: 90mhz Pentium 32mb RAM NCR 53c825 SCSI controller 1gig SCSI drive SCSI CD-ROM Unknown floppy controller Unknown serial/parallel port board Keyboard MS Serial Mouse 2.0 3.5" NEC floppy drive IOMEGA Tape250 If you have _ANY_ questions, I will do all I can to help. Jeff -- Jeff Hoffman -- jeffh@cybernetics.net ------------------------------------- "A man facing the light looks not into sorrow, but to to the future...always." WWW: http://www.cybernetics.net/users/jeffh ------------------------------------------------------------------------------ PGP Public Key available on request. From owner-freebsd-current Wed Feb 22 22:07:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id WAA23646 for current-outgoing; Wed, 22 Feb 1995 22:07:04 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id WAA23639 for ; Wed, 22 Feb 1995 22:06:54 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id WAA26576; Wed, 22 Feb 1995 22:05:40 -0800 From: "Rodney W. Grimes" Message-Id: <199502230605.WAA26576@gndrsh.aac.dev.com> Subject: Re: Building World from Read-Only Media To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 22 Feb 1995 22:05:40 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Feb 22, 95 10:48:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2139 Sender: current-owner@FreeBSD.org Precedence: bulk > > OK, guys! I have some new mk files that are much "cleaner" for our make world. > > I have identified 4 strategies for the placement of object files. If one of > these will not please you, SPEAK NOW, or hold your peace. > > Assume that we are compiling /home/my/src/prog/cfile.c > > Case 1. Just put the object next to its source > /home/my/src/prog/cfile.o Works now with current .mk rules. > Case 2. Put the objects in a directory > /home/my/src/prog/obj/cfile.o Works now with current .mk rules. (Just mkdir obj, could also be a very simple change to the obj: rule to create dirs instead of links to /usr/obj). > Case 3. Global object store > /usr/obj/home/my/src/prog/cfile.o Default make obj case now. > Case 4. Local object tree > /home/my/obj/prog/cfile.o Again, very simple change to .mk files. > Right now, the "world" uses links to make case 3 look like case 2. > My inclination is to go to case 4 instead. > > To build my own object tree from read-only media > > mkdir /home/my > ln -s /cdrom/some.version/Makefile /home/my > ln -s /cdrom/some.version/src /home/my > cd /home/my > make I see in no way how this causes ``make world'' to be any cleaner. > I am presently finishing up to procedures necessary to allow links in a > source tree to point to directory trees rather than each file. It is easy > unless you want to cd down in the tree and "make" some subtree rather than > making the whole tree. > However, I think I can do it provided you supply a DESTDIR in advance. DESTDIR should *ONLY* be used during install: rules, no place else should really be using DESTDIR. > Can I write a makefile rule that can export an env variable. You can't export a variable back to an envoking shell. > What I would like to do is > > cd /top/of/tree > make plant-my-root Replace with: SRC_ROOT=/top/of/tree; export SRC_ROOT; > cd down/the/tree > > and have DESTDIR=/top/of/tree -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-current Thu Feb 23 00:25:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id AAA25654 for current-outgoing; Thu, 23 Feb 1995 00:25:54 -0800 Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id AAA25648 for ; Thu, 23 Feb 1995 00:25:52 -0800 Received: from gilberto.physik.rwth-aachen.de by campino.informatik.rwth-aachen.de (4.1/campino-6) id AA13147; Thu, 23 Feb 95 09:25:21 +0100 Received: by gilberto.physik.rwth-aachen.de (JAA17330); Thu, 23 Feb 1995 09:30:52 +0100 Message-Id: <199502230830.JAA17330@gilberto.physik.rwth-aachen.de> Subject: kernel auf BLUES schiefgelaufen (fwd) To: freebsd-current@freefall.cdrom.com (user alias) Date: Thu, 23 Feb 1995 09:30:51 +0100 (MET) From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1414 Sender: current-owner@FreeBSD.org Precedence: bulk >From my 12hourly world/kernel build automatism: > From root@blues.physik.rwth-aachen.de Thu Feb 23 06:33:30 1995 > Date: Thu, 23 Feb 1995 06:31:25 GMT > From: Charlie Root > Message-Id: <199502230631.GAA20374@blues.physik.rwth-aachen.de> > To: kuku@blues.physik.rwth-aachen.de > Subject: kernel auf BLUES schiefgelaufen > > cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -I. -I../.. -I../../sys -DJAZZ -DI486_CPU -DBOUNCE_BUFFERS -DNCONS=8 -DSCSI_DELAY=15 -DFAT_CURSOR -DUCONSOLE -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 swapkernel.c > sh ../../conf/newvers.sh JAZZ -DJAZZ -DI486_CPU -DBOUNCE_BUFFERS -DNCONS=8 -DSCSI_DELAY=15 -DFAT_CURSOR -DUCONSOLE -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET > cc -O -W -Wreturn-type -Wcomment -Wredundant-decls -I. -I../.. -I../../sys -DJAZZ -DI486_CPU -DBOUNCE_BUFFERS -DNCONS=8 -DSCSI_DELAY=15 -DFAT_CURSOR -DUCONSOLE -DCOMPAT_43 -DPROCFS -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 -c vers.c > loading kernel > ufs_disksubr.o: Undefined symbol `_dsname' referenced from text segment > *** Error code 1 > > Stop. > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Thu Feb 23 00:28:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id AAA25690 for current-outgoing; Thu, 23 Feb 1995 00:28:38 -0800 Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id AAA25679 for ; Thu, 23 Feb 1995 00:28:14 -0800 Received: from gilberto.physik.rwth-aachen.de by campino.informatik.rwth-aachen.de (4.1/campino-6) id AA13177; Thu, 23 Feb 95 09:27:28 +0100 Received: by gilberto.physik.rwth-aachen.de (JAA17339); Thu, 23 Feb 1995 09:32:58 +0100 Message-Id: <199502230832.JAA17339@gilberto.physik.rwth-aachen.de> Subject: world build on blues Thu Feb 23 05:14:47 1995 (fwd) To: freebsd-current@freefall.cdrom.com (user alias) Date: Thu, 23 Feb 1995 09:32:58 +0100 (MET) From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1242 Sender: current-owner@FreeBSD.org Precedence: bulk Forwarded message: > From root@blues.physik.rwth-aachen.de Thu Feb 23 05:16:56 1995 > Date: Thu, 23 Feb 1995 05:14:49 GMT > From: Charlie Root > Message-Id: <199502230514.FAA19017@blues.physik.rwth-aachen.de> > To: kuku@blues.physik.rwth-aachen.de > Subject: world build on blues Thu Feb 23 05:14:47 1995 > > ===> usr.bin/vis > cc -O2 -c /usr/src/usr.bin/vis/vis.c > cc -O2 -c /usr/src/usr.bin/vis/foldit.c > cc -O2 -o vis vis.o foldit.o > ===> usr.bin/w > cc -O2 -c /usr/src/usr.bin/w/../../bin/ps/fmt.c > cc -O2 -c /usr/src/usr.bin/w/pr_time.c > cc -O2 -c /usr/src/usr.bin/w/proc_compare.c > cc -O2 -c /usr/src/usr.bin/w/w.c > cc -O2 -o w fmt.o pr_time.o proc_compare.o w.o -lkvm > ===> usr.bin/wall > cc -O2 -c /usr/src/usr.bin/wall/ttymsg.c > cc -O2 -c /usr/src/usr.bin/wall/wall.c > cc -O2 -o wall ttymsg.o wall.o > ===> usr.bin/watch > make: don't know how to make all. Stop > *** Error code 2 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Thu Feb 23 02:38:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA28451 for current-outgoing; Thu, 23 Feb 1995 02:38:51 -0800 Received: from dns.netvision.net.il (root@dns.NetVision.net.il [194.90.1.5]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA28443; Thu, 23 Feb 1995 02:38:45 -0800 Received: from ugen.NetManage.co.il (ugen.netmanage.co.il [192.114.78.165]) by dns.netvision.net.il (8.6.9/8.6.9) with SMTP id MAA07207; Thu, 23 Feb 1995 12:37:46 +0200 Date: Thu, 23 Feb 95 12:17:22 IST From: "Ugen J.S.Antsilevich" Subject: RE: snp(4)/watch(8) code review comments To: ugen@FreeBSD.org, Paul Traina Cc: current@FreeBSD.org X-Mailer: Chameleon 4.00-Arm-25, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk >I did a preliminary run through the snp device code that you added and had >some comments to make. No insult intended, but I see room for improvement >here: > >(a) we should document that this device is a BIG security hole and people > should only compile it into their kernels if they're willing to > take that risk Hmm..actually this is security help:) At least for me...:) If one already has root access to open /dev/snp (which is openable ONLY by root),he already found security breach and doesn't need another one..:) > >(b) It seems to me that having to specify the type of tty that you're > looking at is brain-dead. I see that you've got knowledge of the > tty structures for the ptys, sios, and vtys. All of this information > is already in the cdevsw table and you should be accessing it via > those vectors, not through your own back-door interface. ... Hmm..actually i agree with you and i also thought to do it that way... The only thing here is the fact you'll need to change watch utility to get another types of tty... ( i personally prefer to write "pty8" instead of "ttyp8" but this is really simple task..)..So you'r right and this should be done probably.. >Would you consider making these changes before 2.1 ships? If not, would >you mind if I changed the interface and watch and fixed it? Hmm...hmm..actually i thought to do it myself but if you want-you can do it,i don't mind..Wait,say, till 26-27,if i don't do it-you do it...If you impatient though you can do it now-just notify me...:) -- -=Ugen J.S.Antsilevich=- NetVision - Israeli Commercial Internet | Learning E-mail: ugen@NetVision.net.il | To Fly. [c] Phone : +972-4-550330 | From owner-freebsd-current Thu Feb 23 06:58:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id GAA03047 for current-outgoing; Thu, 23 Feb 1995 06:58:41 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id GAA03041 for ; Thu, 23 Feb 1995 06:58:39 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.9/8.6.9) with SMTP id GAA16315; Thu, 23 Feb 1995 06:56:25 -0800 Message-Id: <199502231456.GAA16315@precipice.Shockwave.COM> To: "Ugen J.S.Antsilevich" cc: current@FreeBSD.org Subject: Re: snp(4)/watch(8) code review comments In-reply-to: Your message of "Thu, 23 Feb 1995 12:17:22 +0700." Date: Thu, 23 Feb 1995 06:56:25 -0800 From: Paul Traina Sender: current-owner@FreeBSD.org Precedence: bulk From: "Ugen J.S.Antsilevich" Subject: RE: snp(4)/watch(8) code review comments >I did a preliminary run through the snp device code that you added and had >some comments to make. No insult intended, but I see room for improvement >here: > >(a) we should document that this device is a BIG security hole and people > should only compile it into their kernels if they're willing to > take that risk Hmm..actually this is security help:) At least for me...:) If one already has root access to open /dev/snp (which is openable ONLY by root),he already foun security breach and doesn't need another one..:) Well, I used to think that way, but over the past 12 months, I've learned just how nasty session sniffing can be, as I now have to worry about the machines of all of the users connected to my machine. It makes it that much easier for the bad guys to waltz from machine to machine. >(b) It seems to me that having to specify the type of tty that you're > looking at is brain-dead. I see that you've got knowledge of the > tty structures for the ptys, sios, and vtys. All of this information > is already in the cdevsw table and you should be accessing it via > those vectors, not through your own back-door interface. Hmm..actually i agree with you and i also thought to do it that way... The only thing here is the fact you'll need to change watch utility to get an types of tty... ( i personally prefer to write "pty8" instead of "ttyp8" but this is really simple task..)..So you'r right and this should be done pro Good, I'm glad we're in alignment there. I started whacking at a private copy of it last night and it's actually pretty far along, however there's one change I want to make to the system to do this cleanly. I want to add a new field to cdevsw[] that is a vector to a function in the driver that will return a pointer to the right struct tty element given a major/minor number. This sort of decision needs to be done locally to the driver to account for things like major/minor number masking (e.g. cua0 vs ttyd1 in the sio driver). Does anyone have an objection to my adding this new field? It will simply be NULL for any device not supporting that vector and all invocations of it test for non-NULL first before calling. >Would you consider making these changes before 2.1 ships? If not, would >you mind if I changed the interface and watch and fixed it? Hmm...hmm..actually i thought to do it myself but if you want-you can do it,i mind..Wait,say, till 26-27,if i don't do it-you do it...If you impatient thou you can do it now-just notify me...:) Actually, I'm just doing it on general principles, I never actually intend to use the snp drivers in real life, I was just digging through things and didn't like the current interface so I started hacking on it. If you want, I can feed you what I've done so far, or just finish it up this weekend. Paul From owner-freebsd-current Thu Feb 23 07:20:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA04411 for current-outgoing; Thu, 23 Feb 1995 07:20:15 -0800 Received: from dns.netvision.net.il (root@dns.NetVision.net.il [194.90.1.5]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id HAA04405 for ; Thu, 23 Feb 1995 07:20:09 -0800 Received: from ugen.NetManage.co.il (ugen.netmanage.co.il [192.114.78.165]) by dns.netvision.net.il (8.6.9/8.6.9) with SMTP id RAA25603; Thu, 23 Feb 1995 17:18:52 +0200 Date: Thu, 23 Feb 95 16:55:56 IST From: "Ugen J.S.Antsilevich" Subject: Re: snp(4)/watch(8) code review comments To: Paul Traina Cc: current@FreeBSD.org X-Mailer: Chameleon 4.00-Arm-25, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk >I want to add a new field to cdevsw[] that is a vector to a function in the >driver that will return a pointer to the right struct tty element given a >major/minor number. This sort of decision needs to be done locally to the >driver to account for things like major/minor number masking (e.g. cua0 vs >ttyd1 in the sio driver). > >Does anyone have an objection to my adding this new field? It will simply >be NULL for any device not supporting that vector and all invocations of it >test for non-NULL first before calling. Hmm...add the whole function just for such a thing like snoop...Too much:) Actually why can't you just use minor number as index in tty table already in cdevsw?? ok..i know that you'd have a problemm about serial lines with their weird minor number stuff but on the other hand you can put conversion of minor number to index in table as a part of watch utility..you anyway need some conversion if you want (at least I want:))) to use not only normal device names like ttyp0 but also pty0,vty0 and other symbolic names... Major change to cdevsw is may be nice but too big...:)) *IMHO* >Actually, I'm just doing it on general principles, I never actually intend >to use the snp drivers in real life, I was just digging through things and >didn't like the current interface so I started hacking on it. > >If you want, I can feed you what I've done so far, or just finish it up this >weekend. Hmm.if you already doing this-continue,it's ok with me 100% but better don't do that change to cdevsw-this still can be done another less radical ways..:) Thanx. -- -=Ugen J.S.Antsilevich=- NetVision - Israeli Commercial Internet | Learning E-mail: ugen@NetVision.net.il | To Fly. [c] Phone : +972-4-550330 | From owner-freebsd-current Thu Feb 23 07:39:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA04899 for current-outgoing; Thu, 23 Feb 1995 07:39:52 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id HAA04888 for ; Thu, 23 Feb 1995 07:39:49 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.9/8.6.9) with SMTP id HAA16439; Thu, 23 Feb 1995 07:37:42 -0800 Message-Id: <199502231537.HAA16439@precipice.Shockwave.COM> To: "Ugen J.S.Antsilevich" cc: current@FreeBSD.org Subject: Re: snp(4)/watch(8) code review comments In-reply-to: Your message of "Thu, 23 Feb 1995 16:55:56 +0700." Date: Thu, 23 Feb 1995 07:37:42 -0800 From: Paul Traina Sender: current-owner@FreeBSD.org Precedence: bulk From: "Ugen J.S.Antsilevich" Subject: Re: snp(4)/watch(8) code review comments >I want to add a new field to cdevsw[] that is a vector to a function in the >driver that will return a pointer to the right struct tty element given a >major/minor number. This sort of decision needs to be done locally to the >driver to account for things like major/minor number masking (e.g. cua0 vs >ttyd1 in the sio driver). >Does anyone have an objection to my adding this new field? It will simply >be NULL for any device not supporting that vector and all invocations of it >test for non-NULL first before calling. Hmm...add the whole function just for such a thing like snoop...Too much:) Why? It's clearly the most os/driver/architecture independant change and it's something that we kludge around elsewhere in the system too (for example, ttselect is wrappered in most drivers specificly to handle the minor number conversion brain-dammage). Actually why can't you just use minor number as index in tty table already in cdevsw?? ok..i know that you'd have a problemm about serial lines with their weird minor number stuff but on the other hand you can put conversion of minor number to index in table as a part of watch utility..you anyway need It doesn't belong in a user program, bite your tounge! The whole reason I was doing this was to remove evil stuff like that from watch. :-) Also, if we just index off the array, there's nothing that stops root from specifying an illegal device and crashing the system because we start corrupting kernel data space if you give a minor number that's too large. some conversion if you want (at least I want:))) to use not only normal device names like ttyp0 but also pty0,vty0 and other symbolic names... That's exactly what we get if we do this right, since each driver knows the relationship between minor number and tty structure already and that changes from driver to driver (e.g. if I rip out sio and install comm, major/minor number splitting changes, but the names, like cua0/ttyd1 don't). Major change to cdevsw is may be nice but too big...:)) *IMHO* It's not like we couldn't use it elsewhere. I'm not against doing architectual things if they implement something cleanly.... and adding an option vector is hardly a major change... just the core kernel changes. >Actually, I'm just doing it on general principles, I never actually intend >to use the snp drivers in real life, I was just digging through things and >didn't like the current interface so I started hacking on it. > >If you want, I can feed you what I've done so far, or just finish it up >this weekend. OK, I'm going to keep on going with what I've started and see what the total change is when I'm done. Right now, I'd much rather add an optional vector to cdevsw than make snp have to know about every single tty driver out there (for instance, you missed the tw and cy drivers, which this covers in an driver-independant fashion :-)) Hmm.if you already doing this-continue,it's ok with me 100% but better don't do that change to cdevsw-this still can be done another less radical ways. I'm more than open for suggestions for other ways to do this cleanly, using cdevsw was the first thing I thought of, but if anyone else on the team has a good idea here, I'll go for it. Paul p.s. yes, no problem, I'll go through and work on your ipfw man pages too, it shouldn't be too bad, it only took me about 20 minutes to do snp(4) and watch(8)... using mandoc is really easy once you do your first couple of pages... I wish I knew where the official guide to mandoc was in the FreeBSD source code, it seems we have lost it? From owner-freebsd-current Thu Feb 23 08:17:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA05587 for current-outgoing; Thu, 23 Feb 1995 08:17:33 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA05560 for ; Thu, 23 Feb 1995 08:16:01 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA01627; Fri, 24 Feb 1995 03:12:52 +1100 Date: Fri, 24 Feb 1995 03:12:52 +1100 From: Bruce Evans Message-Id: <199502231612.DAA01627@godzilla.zeta.org.au> To: bde@zeta.org.au, starkhome!gene@sbstark.cs.sunysb.edu Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) Cc: current@FreeBSD.org, regent.e-technik.tu-muenchen.de!jhs@sbstark.cs.sunysb.edu Sender: current-owner@FreeBSD.org Precedence: bulk >>I think the correct solution is to put the geometry that you want newfs >>to use in the label. The geometry in the label isn't used for many >>things other than newfs. It is used for booting and by fdisk. Disk >No, this won't work for IDE drives, which in my experience seem to be very >particular about what geometry is stuffed into the controller. If you put According to the ATA standard, IDE drives accept any possible geometry (sectors < 256, heads <= 16, cylinders < 65536). >some geometry in the disklabel that has nothing to do with the geometry >reported by the controller, then when that geometry is stuffed into the >controller when the disk is first opened, it will likely hose things badly. Problems occur when people put impossible geometries (heads > 16) in the label and perhaps for nonstandard drives. >>slicing will provide separate labels for the whole disk and the BSD >>slice (even when the BSD slice is the whole disk) so it will be possible >>to have separate geometries for booting/fdisk and newfs. >If this scheme uses the "native" geometry to initialize the controller, >and the BSD geometry for "soft" operations (like newfs) only, then it >should work. Yes. The driver still has to have complications to handle drives that don't have a (correct) "native" geometry. MFM drives don't report their geometry, and ESDI drives may report an unusable geometry (with more cylinders or sectors than can be used). These are currently handled by a 3-step bootstrap: stuff the controller with a minimal geometry; use this geometry to read the MBR, guess another geometry and stuff the controller with it; use the previous geometry to read the label and stuff the controller with the geometry in the label. It would have been better to get a usable geometry from the BIOS and never change it. However, the complicated method works for drives that aren't supported by the BIOS and/or don't report their geometry correctly (provided the mbr and/or the label is correctly initialized), and recent BIOSs may report physically impossible geometries (heads > 16). Bruce From owner-freebsd-current Thu Feb 23 08:27:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA05876 for current-outgoing; Thu, 23 Feb 1995 08:27:51 -0800 Received: from mail.netcom.com (root@mail.netcom.com [192.100.81.99]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA05870; Thu, 23 Feb 1995 08:27:50 -0800 From: patl@asimov.lashley.slip.netcom.com Received: from lashley.slip.netcom.com by mail.netcom.com (8.6.9/Netcom) id IAA08662; Thu, 23 Feb 1995 08:26:49 -0800 Received: by lashley.slip.netcom.com (5.x/SMI-SVR4) id AA04296; Thu, 23 Feb 1995 08:29:59 -0800 Date: Thu, 23 Feb 1995 08:29:59 -0800 Message-Id: <9502231629.AA04296@lashley.slip.netcom.com> To: jkh@freefall.cdrom.com, rkw@dataplex.net Subject: Re: Building World from Read-Only Media Cc: current@FreeBSD.org, phk@ref.tfs.com, rgrimes@gndrsh.aac.dev.com Reply-To: lashley@netcom.com X-Sun-Charset: US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk |> OK, guys! I have some new mk files that are much "cleaner" for our make world. |> |> I have identified 4 strategies for the placement of object files. If one of |> these will not please you, SPEAK NOW, or hold your peace. |> |> Assume that we are compiling /home/my/src/prog/cfile.c |> |> Case 1. Just put the object next to its source |> /home/my/src/prog/cfile.o I would tend to depriciate this on the grounds of future multi-platform support, or any of the other reasons that anyone might want to do slightly different builds in the same source tree. |> Case 2. Put the objects in a directory |> /home/my/src/prog/obj/cfile.o I'd prefer to see this generalized to: /home/my/src/prog/${OBJ_DIR}/cfile.o Same reasons. |> Case 3. Global object store |> /usr/obj/home/my/src/prog/cfile.o I'd prefer to see this generalized to: ${DESTDIR}/my/src/prog/cfile.o Same reasons, plus the following scenario: I'm trying to get it to work on my off-beat home system; but the only machine I can do the builds on is under someone else's control, and they won't give me root access to write into /usr/obj. |> Case 4. Local object tree |> /home/my/obj/prog/cfile.o Again, generalize to: /home/my/${OBJ_DIR}/prog/cfile.o Same reasons. |> Right now, the "world" uses links to make case 3 look like case 2. |> My inclination is to go to case 4 instead. I think I'd lean towards the generalized version of case 4 as well. One of the advantages of having the object tree branch off fairly early from the source is that it makes it easy for the object to be on a different partition. (Disk space issues, multiple builds, source NFS mounted/object local, source on read-only media...) |>... |> |> I am presently finishing up to procedures necessary to allow links in a |> source tree to point to directory trees rather than each file. It is easy |> unless you want to cd down in the tree and "make" some subtree rather than |> making the whole tree. |> However, I think I can do it provided you supply a DESTDIR in advance. Great idea. |> Can I write a makefile rule that can export an env variable. |> |> What I would like to do is |> |> cd /top/of/tree |> make plant-my-root |> cd down/the/tree |> |> and have DESTDIR=/top/of/tree The classic way of handling this is to have Makefiles at the first level include 'TOPDIR=../ and DESTDIR=${TOPDIR}mumble', at the second level: 'TOPDIR=../../ and DESTDIR=${TOPDIR}mumble/foo', etc. This has the advantage of containing a reasonable default, and being easy to override at make time. -Pat From owner-freebsd-current Thu Feb 23 08:39:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA06381 for current-outgoing; Thu, 23 Feb 1995 08:39:08 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id IAA06369 for ; Thu, 23 Feb 1995 08:39:06 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03022; Thu, 23 Feb 95 09:32:26 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502231632.AA03022@cs.weber.edu> Subject: Re: TRUE and FALSE To: nate@trout.sri.MT.net (Nate Williams) Date: Thu, 23 Feb 95 9:32:26 MST Cc: phk@ref.tfs.com, current@freefall.cdrom.com In-Reply-To: <199502230023.RAA16248@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 05:23:23 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > The fundamental problem is that the source-tree should be self-contained. > > > > Just think about the benefit of a "make world" which will not hose your > > c-compiler if the c-compiler source is sick... > > And just where am I going to install the new tools? This assumes that I > have room for 2 completely independant 'systems' on the same box. This > is very rarely the case for most folks. And for those that do have the > room for both, an chroot tree works *almost* as good as doesn't cause a > lot of un-ncessary headache for the common case. This is the reason I agreed with Garrett. It has to be possible, as an option, to build into the current installation. It doesn't mean that I think it should be the default. Ideally in this case, you would build-behind, deleting objects after install so at most the extra storage you'd need if you built from a CDROM would be the directory and object and binaries for a single system component. This is not to say that this won't be too much storage in some cases for some people, but then they don't get to rebuild. We can't make disk space out of air. Well I can, but I have a patent pending so it's all very hush-hush. 8-) 8-). The biggest messes would be the kernel and some of the GNU utilities that had large numbers of objects. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Feb 23 08:42:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA06474 for current-outgoing; Thu, 23 Feb 1995 08:42:53 -0800 Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA06468 for ; Thu, 23 Feb 1995 08:42:50 -0800 Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.9/8.6.9) with SMTP id KAA29550; Thu, 23 Feb 1995 10:41:51 -0600 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Feb 1995 10:41:53 -0600 To: lashley@netcom.com From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Building World from Read-Only Media Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >|> OK, guys! I have some new mk files that are much "cleaner" for our make >|> I have identified 4 strategies >|> Case 1. Just put the object next to its source >|> Case 2. Put the objects in a directory >|> Case 3. Global object store >|> Case 4. Local object tree Perhaps I was not clear.... I expect to support ALL 4 of these strategies. Let the user pick the strategy that {s}he wants. However, I prefer the default to be an object tree growing off of the root of the users source tree. For those who want a GLOBAL object tree, for example, on a scratch device, they can set that default in the system make.conf file. ---- Richard Wackerbarth rkw@dataplex.net From owner-freebsd-current Thu Feb 23 08:45:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA06545 for current-outgoing; Thu, 23 Feb 1995 08:45:33 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA06538 for ; Thu, 23 Feb 1995 08:45:25 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA01977; Fri, 24 Feb 1995 03:39:12 +1100 Date: Fri, 24 Feb 1995 03:39:12 +1100 From: Bruce Evans Message-Id: <199502231639.DAA01977@godzilla.zeta.org.au> To: pst@shockwave.com, ugen@netvision.net.il Subject: Re: snp(4)/watch(8) code review comments Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >I want to add a new field to cdevsw[] that is a vector to a function in the >driver that will return a pointer to the right struct tty element given a >major/minor number. This sort of decision needs to be done locally to the >driver to account for things like major/minor number masking (e.g. cua0 vs >ttyd1 in the sio driver). >Does anyone have an objection to my adding this new field? It will simply >be NULL for any device not supporting that vector and all invocations of it >test for non-NULL first before calling. A good idea...except I'd like to remove the tty struct in the cdevsw completely. It is currently only used (officially) by ttselect() and could easily be replaced by a new arg to ttselect(). Having it in the struct forces all tty drivers to allocate in the same way as well as special select routines to clip the minor numbers. A function field would be flexible enough to handle these problems nicely. Do you need to call it for possibly-non-open devices? This would inhibit really simple implementations such as `table[minor(dev) & MASK]->tty' (the table can only be guaranteed to be initialized for open devs). Bruce From owner-freebsd-current Thu Feb 23 08:50:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA06622 for current-outgoing; Thu, 23 Feb 1995 08:50:51 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id IAA06616 for ; Thu, 23 Feb 1995 08:50:49 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA02944; Thu, 23 Feb 95 09:22:18 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502231622.AA02944@cs.weber.edu> Subject: Re: TRUE and FALSE To: nate@trout.sri.MT.net (Nate Williams) Date: Thu, 23 Feb 95 9:22:17 MST Cc: phk@ref.tfs.com, wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com In-Reply-To: <199502222345.QAA15987@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 04:45:52 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > At what gain are we doing this? I believe it's a noble gain to have the > source tree compile w/out reference to /usr/include, but what does it > gain us? The only thing I can see where it's a big deal is building a > brand-new $(DESTDIR) tree. Other than that, most of the time I *want* > to use the files in /usr/include and NOT those in /usr/src (speaking as > a user-land kind of guy). 1) The ability to build multiple source tree instances on a single box prepatory to doing a distribution. 2) The ability to rebuild everything then chroot to test it prior to actually installing it. 3) The ability (eventually) to rebuild with a relocated source tree. For instance, off a remote mount or a cdrom. 4) The ability (eventually) to do a fully hosted crosscompile. This one is tricky, since you can't use any of the tools that result from the build in the build. This is an eventual goal since the tools-used-during-build reference and the divisions between system dependent code aren't there in FreeBSD's source tree. That's what it buys us. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Feb 23 09:08:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA07026 for current-outgoing; Thu, 23 Feb 1995 09:08:34 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA07019 for ; Thu, 23 Feb 1995 09:08:32 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03135; Thu, 23 Feb 95 10:02:05 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502231702.AA03135@cs.weber.edu> Subject: Re: TRUE and FALSE To: rmallory@wiley.csusb.edu (Rob Mallory) Date: Thu, 23 Feb 95 10:02:05 MST Cc: current@freefall.cdrom.com In-Reply-To: <199502230225.AA01350@wiley.csusb.edu> from "Rob Mallory" at Feb 22, 95 06:25:37 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > question: When I put the cdrom in to install, what the hell am I going to > do with all this VME-bus crap in my /sys tree? I dont think I will > ever be compiling something with VLIW's on my 386! [ ... ] > What about the people who want only an arch-specific /sys tree? > What if I want the whole enchilada so I can compile a new kernel for > my lonely 486 on my 250Mhz Alpha? The second question will probably be answered "it's in there!". The first question is tougher. I think one of the major mistakes that USL made in the SVR4.2 ES/MP source tree (hmmm... did that ever get put anywhere but UnixWare?) was that you extracted a buildable tree from a combination of three source repositories, two of them dependent on the actual machine you would be building for. Think about this a second. There was no reliable reverse-index mechanism for getting problem fixes back into an overall tree. One of my biggest complaints with UnixWare was that it didn't meet SVID III (I've bitched about this before). Basically, any UNIX as fo SVR4 was no longer SVID compliant and therefore no longer "System V" because of the distinction between "system clock frequency" and "clock update frequency". In other words, the getitimer(RT), setitimer(RT), and gettimeofday(RT) functions were screwed because interval timers had only a 10ms resoloution instead of 1sec/"system clock frequency" resoloution (if you don't think this is bad, then please consider the concept "double click" and then consider the concept "select timeout"). Finally I got it working on my personal machine with an extracted tree containing only Intel processer components. To get back to the point, fixing this would have required an interface change, but with a buildable tree an interface change was not possible; you could only do an interface change with the whole tree (and if you didn't have that you were screwed). And even if you had one, you were in for a 36 hour process of the extraction a full build necessary to see if the change worked, and you would only have verification on your personal architecture anyway: There was the assumption that all supported hardware would be available to whoever was doing this sort of work. And people call the *BSDs elitest now! I think FreeBSD should *run* the other direction from this type of partitioning. If it doesn't, there will be no way to get the changes needed for support of a particular architecture rolled back into the tree. Integration is a real (manual labor) bitch in this type of setup. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Feb 23 09:17:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA07236 for current-outgoing; Thu, 23 Feb 1995 09:17:39 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA07230 for ; Thu, 23 Feb 1995 09:17:38 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03169; Thu, 23 Feb 95 10:10:58 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502231710.AA03169@cs.weber.edu> Subject: Re: TRUE and FALSE -> is this true? To: nate@trout.sri.MT.net (Nate Williams) Date: Thu, 23 Feb 95 10:10:57 MST Cc: rcarter@geli.com, current@FreeBSD.org In-Reply-To: <199502230324.UAA17345@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 08:24:55 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > |Starting from a running system, you are guaranteed to get everything > > |working with 2 make worlds, and a 3rd certainly shouldn't hurt. > > > > For those of us suping current regularly, and having the make world > > occasionally fail, does this imply that it might work to try make world > > twice? (Or three times?) > > No, it implies that if a release is to be done, then make world should > work. If make world doesn't work, then the release isn't ready. So, > assuming a make world works, then it should work multiple times. For further rationale, look at the gcc documentation about compiler "stages". Basically it boils down to compiling the compiler with the compiler so that it doesn't have the bugs that it has. 8-). God, I love that explanation. So much so that I'm going to smile again. 8-). Too bad I can't take credit for it. 8-(. Ah! I claim paraphrase! "Build the system with the system on the system so that it doesn't have the bugs that it has". 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Feb 23 09:24:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA07348 for current-outgoing; Thu, 23 Feb 1995 09:24:08 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA07342 for ; Thu, 23 Feb 1995 09:24:06 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03193; Thu, 23 Feb 95 10:16:19 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502231716.AA03193@cs.weber.edu> Subject: Re: Include files and 'release' engineering To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Thu, 23 Feb 95 10:16:18 MST Cc: nate@trout.sri.MT.net, current@FreeBSD.org In-Reply-To: <199502230332.TAA07293@ref.tfs.com> from "Poul-Henning Kamp" at Feb 22, 95 07:32:28 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > My personal reason for being grumpy is that my trusty Gateway 2000 Handbook > has had a disk-crash and GW said that it will take around 3 weeks to swap > the disk :-( Did you offer to sell them a faster screwdriver? Two weeks without a handy computer would drive me insane. Hopefully you have sufficient support from the machine you are typing from and some rather over-intelligent appliances at home. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Feb 23 09:30:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA07475 for current-outgoing; Thu, 23 Feb 1995 09:30:31 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA07467 for ; Thu, 23 Feb 1995 09:30:30 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03217; Thu, 23 Feb 95 10:23:50 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502231723.AA03217@cs.weber.edu> Subject: Re: TRUE and FALSE To: nate@trout.sri.MT.net (Nate Williams) Date: Thu, 23 Feb 95 10:23:48 MST Cc: rmallory@wiley.csusb.edu, current@freefall.cdrom.com In-Reply-To: <199502230441.VAA17717@trout.sri.MT.net> from "Nate Williams" at Feb 22, 95 09:41:10 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > Setting up cross-compilation environment if very difficult to do, and > making it work while not affecting normal compilation would be more work > than it would be worth. However, if you are willing to present us with > the patches necessary for this to work, I'm sure you'd find someone to > champion the work and make it work right. The biggest pain I have found in trying to make this work (I did my initial work on 386BSD 0.0 and 0.1 on a Sun hosted environment because I couldn't get a machine up until the kernel had been patched in at least 3 places) was the compilation tools. GCC's idea of a hosted cross-compilation environment is orthoganal to the idea of the compiler being a system component and to the cross-compilation environment being a system instead of an application. The clearest artifact of this is the way it handles include files and the compiler having an expectation of the cross-compilation and compilation environments having the same install tree. Anything that gets done will eventaully have to reflect a special status fo the tools. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Feb 23 09:40:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA07908 for current-outgoing; Thu, 23 Feb 1995 09:40:51 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA07897 for ; Thu, 23 Feb 1995 09:40:32 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA02827; Fri, 24 Feb 1995 04:38:40 +1100 Date: Fri, 24 Feb 1995 04:38:40 +1100 From: Bruce Evans Message-Id: <199502231738.EAA02827@godzilla.zeta.org.au> To: freebsd-current@freefall.cdrom.com, kuku@gilberto.physik.rwth-aachen.de Subject: Re: kernel auf BLUES schiefgelaufen (fwd) Sender: current-owner@FreeBSD.org Precedence: bulk >> loading kernel >> ufs_disksubr.o: Undefined symbol `_dsname' referenced from text segment Fixed. Bruce From owner-freebsd-current Thu Feb 23 09:40:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA07915 for current-outgoing; Thu, 23 Feb 1995 09:40:59 -0800 Received: from netcom15.netcom.com (diamond@netcom15.netcom.com [192.100.81.128]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA07902 for ; Thu, 23 Feb 1995 09:40:46 -0800 Received: by netcom15.netcom.com (8.6.9/Netcom) id JAA07434; Thu, 23 Feb 1995 09:39:59 -0800 Date: Thu, 23 Feb 1995 09:39:59 -0800 From: diamond@netcom.com (diamond) Message-Id: <199502231739.JAA07434@netcom15.netcom.com> To: current@FreeBSD.org Subject: help Sender: current-owner@FreeBSD.org Precedence: bulk help From owner-freebsd-current Thu Feb 23 09:43:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA08037 for current-outgoing; Thu, 23 Feb 1995 09:43:49 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA08030 for ; Thu, 23 Feb 1995 09:43:47 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.9/8.6.9) with SMTP id JAA16718; Thu, 23 Feb 1995 09:40:17 -0800 Message-Id: <199502231740.JAA16718@precipice.Shockwave.COM> To: Bruce Evans cc: ugen@netvision.net.il, current@FreeBSD.org Subject: Re: snp(4)/watch(8) code review comments In-reply-to: Your message of "Fri, 24 Feb 1995 03:39:12 +1100." <199502231639.DAA01977@godzilla.zeta.org.au> Date: Thu, 23 Feb 1995 09:40:17 -0800 From: Paul Traina Sender: current-owner@FreeBSD.org Precedence: bulk From: Bruce Evans Subject: Re: snp(4)/watch(8) code review comments >I want to add a new field to cdevsw[] that is a vector to a function in the >driver that will return a pointer to the right struct tty element given a >major/minor number. This sort of decision needs to be done locally to the >driver to account for things like major/minor number masking (e.g. cua0 vs >ttyd1 in the sio driver). >Does anyone have an objection to my adding this new field? It will simply >be NULL for any device not supporting that vector and all invocations of it >test for non-NULL first before calling. A good idea...except I'd like to remove the tty struct in the cdevsw completely. It is currently only used (officially) by ttselect() and could easily be replaced by a new arg to ttselect(). Having it in the struct forces all tty drivers to allocate in the same way as well as special select routines to clip the minor numbers. I seem to recall that BSDI just passes in a pointer to the desired tty struct entry. In this case, every driver would require a wrapper calling potentially a common ttselect routine. I have no problem with making this change if there are no objections, ttselect gets replaced by int ttyselect (struct tty *, int flag, struct proc *) (note new name...since this is what BSDI calls the identical function). It would be reasonable to discuss this with the appropriate NetBSD folks too since it would good for the driver writers if we both support this change. A function field would be flexible enough to handle these problems nicely. Any objections to: struct tty *xxxdevtotty (dev_t dev) Returns a pointer to the right entry or NULL if entry not available/initialized. Do you need to call it for possibly-non-open devices? It should be robust enough to call for non-open devices and return an error indication if there's a problem. The $25k question is should we add a boolean parameter that would cause a tty entry to be malloced, initialized, and linked in if one doesn't already exist? If so, then the driver can use the same routine in its init code. Maybe later, seems like too much of a mess for this week. :-) This would inhibit really simple implementations such as `table[minor(dev) & MASK]->tty' (the table can only be guaranteed to be initialized for open devs). Do you mean open/initialized drivers or open devices? I could easily see the case where one is mallocing "struct tty" as required (say for example a pty driver without stupid limits). This would be a vast improvement over the current hard coded size of the pty entry array. From owner-freebsd-current Thu Feb 23 10:06:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA08472 for current-outgoing; Thu, 23 Feb 1995 10:06:52 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id KAA08466; Thu, 23 Feb 1995 10:06:49 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03444; Thu, 23 Feb 95 11:00:21 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9502231800.AA03444@cs.weber.edu> Subject: Re: TRUE and FALSE To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Thu, 23 Feb 95 11:00:20 MST Cc: jkh@freefall.cdrom.com, nate@trout.sri.mt.net, current@freefall.cdrom.com In-Reply-To: <199502230308.TAA07194@ref.tfs.com> from "Poul-Henning Kamp" at Feb 22, 95 07:08:48 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > > Get off of it. This always comes up, and all it does is ruffle > > > feathers. You don't have to be release engineer to understand some of > > > the issues required to do it. Heck, all of us do (our at least should > > > > Some of the issues, perhaps. Significant grasp of enough of them to > > argue this with me? No. Sorry, but no. You can change my mind by > > doing one thing and one thing ONLY, and that is to do a release or > > even a snapshot of your own and then come back to me with a > > description of what you did and how you did it. Otherwise I simply am > > I tend to agree here, and I belive Rod will agree. We have to cut the > effort to make a sterilized release from the present level to something > more managerable. Agreed! Anyone should be able to roll a release by typing "make release" somewhere! Not that everyone *should* be doing this, and not that this *should* be done without regression testing before plopping it into an FTP archive somewhere. The grunt work of the release has got to be the regression testing to make sure that what got rolled really installs somewhere. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Feb 23 11:06:05 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA09734 for current-outgoing; Thu, 23 Feb 1995 11:06:05 -0800 Received: from dolphin.mikom.csir.co.za (some.schmuck.lame.delegated.to.RAIN.PSG.COM [146.64.28.40]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id LAA09728 for ; Thu, 23 Feb 1995 11:05:59 -0800 Received: (from jhay@localhost) by dolphin.mikom.csir.co.za (8.6.9/8.6.6) id VAA07383 for current@FreeBSD.ORG; Thu, 23 Feb 1995 21:05:47 +0200 From: John Hay Message-Id: <199502231905.VAA07383@dolphin.mikom.csir.co.za> Subject: src/usr.sbin/rmt/Makefile breaking To: current@FreeBSD.org Date: Thu, 23 Feb 1995 21:05:46 +0200 (SAT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 348 Sender: current-owner@FreeBSD.org Precedence: bulk Hi, There were some talking about "make install" breaking in "usr.sbin/rmt" when it do the link to ${DESTDIR}/etc/rmt, but it seems nothing happened about it. Now I can see that if you have a clean DESTDIR it will always work, but if you don't, make will break there. Isn't it possible to change it please? -- John Hay -- jhay@mikom.csir.co.za From owner-freebsd-current Thu Feb 23 11:23:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA10204 for current-outgoing; Thu, 23 Feb 1995 11:23:46 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id LAA10198 for ; Thu, 23 Feb 1995 11:23:43 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id LAA10050; Thu, 23 Feb 1995 11:22:54 -0800 From: Poul-Henning Kamp Message-Id: <199502231922.LAA10050@ref.tfs.com> Subject: Re: src/usr.sbin/rmt/Makefile breaking To: jhay@mikom.csir.co.za (John Hay) Date: Thu, 23 Feb 1995 11:22:53 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: <199502231905.VAA07383@dolphin.mikom.csir.co.za> from "John Hay" at Feb 23, 95 09:05:46 pm Content-Type: text Content-Length: 490 Sender: current-owner@FreeBSD.org Precedence: bulk > Hi, > > There were some talking about "make install" breaking in "usr.sbin/rmt" when it > do the link to ${DESTDIR}/etc/rmt, but it seems nothing happened about it. > > Now I can see that if you have a clean DESTDIR it will always work, but if > you don't, make will break there. Isn't it possible to change it please? John, send us a patch :-) -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Thu Feb 23 11:38:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA10468 for current-outgoing; Thu, 23 Feb 1995 11:38:19 -0800 Received: from dolphin.mikom.csir.co.za (some.schmuck.lame.delegated.to.RAIN.PSG.COM [146.64.28.40]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id LAA10448 for ; Thu, 23 Feb 1995 11:38:12 -0800 Received: (from jhay@localhost) by dolphin.mikom.csir.co.za (8.6.9/8.6.6) id VAA07461; Thu, 23 Feb 1995 21:38:23 +0200 From: John Hay Message-Id: <199502231938.VAA07461@dolphin.mikom.csir.co.za> Subject: Re: src/usr.sbin/rmt/Makefile breaking To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Thu, 23 Feb 1995 21:38:22 +0200 (SAT) Cc: current@FreeBSD.org In-Reply-To: <199502231922.LAA10050@ref.tfs.com> from "Poul-Henning Kamp" at Feb 23, 95 11:22:53 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 578 Sender: current-owner@FreeBSD.org Precedence: bulk Ok, here is a patch that will do it. Now I know that there was talk of moving it to the release/Makefile or the etc/Makefile, but I don't think it was ever decided where. -- John Hay -- jhay@mikom.csir.co.za *** src/usr.sbin/rmt/Makefile.org Thu Feb 16 20:24:59 1995 --- src/usr.sbin/rmt/Makefile Thu Feb 23 21:28:14 1995 *************** *** 4,9 **** MAN8= rmt.8 beforeinstall: ! ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt .include --- 4,9 ---- MAN8= rmt.8 beforeinstall: ! ln -fs ${BINDIR}/rmt ${DESTDIR}/etc/rmt .include From owner-freebsd-current Thu Feb 23 12:09:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA11192 for current-outgoing; Thu, 23 Feb 1995 12:09:33 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA11186 for ; Thu, 23 Feb 1995 12:09:31 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id MAA10587; Thu, 23 Feb 1995 12:08:50 -0800 From: Poul-Henning Kamp Message-Id: <199502232008.MAA10587@ref.tfs.com> Subject: Re: Include files and 'release' engineering To: terry@cs.weber.edu (Terry Lambert) Date: Thu, 23 Feb 1995 12:08:50 -0800 (PST) Cc: nate@trout.sri.MT.net, current@FreeBSD.org In-Reply-To: <9502231716.AA03193@cs.weber.edu> from "Terry Lambert" at Feb 23, 95 10:16:18 am Content-Type: text Content-Length: 1596 Sender: current-owner@FreeBSD.org Precedence: bulk > > My personal reason for being grumpy is that my trusty Gateway 2000 Handbook > > has had a disk-crash and GW said that it will take around 3 weeks to swap > > the disk :-( > > Did you offer to sell them a faster screwdriver? Well, for a 2.94 lbs notebook, you don't use a screwdriver much. It's like those chinese puzzles: The cable to the hard-disk doubles as the latch that will prevent the motherboard from disengaging the serial-connector, thus avoiding the battery compartment from falling of, which would have released the plastic tab which attaches the display on top of the keyboard which that way is kept in place, acting as the external cabinet over the hard disk. To assemble: put all the things together, apply a slight pressure on the 'f' key on the keyboard until you hear a subtle "click", and your done. To disassemble: Apply dynamite generously. > Two weeks without a handy computer would drive me insane. Hopefully > you have sufficient support from the machine you are typing from and > some rather over-intelligent appliances at home. Well, I have the sun-x classic at work, the 486DX2 on my desk, the 130 other machines identical to it in the lab, the DX2 at home and the spambox at home, so I will survive I hope. It's the 30 minutes in the train that kills me :-) Having a 3 pound unix box in a shoulderstrap is very addictive. Highly recommended, cheaper and more legal than most drugs :-) -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Thu Feb 23 12:18:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA11446 for current-outgoing; Thu, 23 Feb 1995 12:18:03 -0800 Received: from goof.com (root@goof.com [198.82.204.15]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA11439 for ; Thu, 23 Feb 1995 12:18:02 -0800 Received: (from mmead@localhost) by goof.com (8.6.9/8.6.9) id PAA02633 for current@freebsd.org; Thu, 23 Feb 1995 15:17:24 -0500 From: "matthew c. mead" Message-Id: <199502232017.PAA02633@goof.com> Subject: max file descriptors To: current@FreeBSD.org Date: Thu, 23 Feb 1995 15:17:24 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 539 Sender: current-owner@FreeBSD.org Precedence: bulk I use zsh, and if I set my maximum file descriptors to >256, no rpc functions can be performed. David Greenman had helped me figure this problem out with NFS a while back, I just wanted to mention that it was still there. -matt -- Matthew C. Mead -> Virginia Tech Center for Transportation Research - -> Multiple Platform System and Network Administration Work Related -> mmead@ctr.vt.edu | mmead@goof.com <- All Other ---- ------- WWW -> http://www.goof.com/~mmead --- ----- From owner-freebsd-current Thu Feb 23 12:24:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA11575 for current-outgoing; Thu, 23 Feb 1995 12:24:16 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id MAA11567; Thu, 23 Feb 1995 12:24:15 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Jeff Hoffman cc: current@FreeBSD.org Subject: Re: UPDATE: Imagine128 & AccelX & 950210-SNAP In-reply-to: Your message of "Thu, 23 Feb 95 00:12:54 EST." Date: Thu, 23 Feb 1995 12:24:14 -0800 Message-ID: <11566.793571054@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > Ok, for those of you who have been keeping up, I tried to re-install 2.0 > and ended up back with 950210-SNAP because my floppy didn't work with > 2.0 This time, I ftp'ed the the 950210-SNAP from scratch, and did not > use one single non-950210-SNAP file (except my X server). [FYI - either -hackers OR -current, but never both. I have adjusted the CC line. Thank you] > I run Xsetup again, choose Number9 I128 w/4MB, same resolution, same > color depth (16 colors). I load up X, and things are no longer OK. > Before I go into depth with the problems, let me say that I ran this > server under 2.0 for a while (about a month) with 0 problems. I have not > done one thing to my machine since then. It is _EXACTLY_ the same as it > was then. _Something_ that was changed between 2.0 and 950210-SNAP is > causing this problem, either directly or indirectly. I will let the > XInside people know tomorrow, as well. I'm sorry, but this is just frankly bizarre. I can't think of anything except perhaps the mmap() semantics changing (David?) that would lead to semantics like you're describing. The X server should still be communicating just fine with the board's registers and video memory under either 2.0 or 950210-SNAP, and I've certainly been running Xaccel quite happily since pre-2.0 days all the way up to post-950210-SNAP with my #9 GXE64 Pro/4MB board. It's never given me anything but flawless performance. I presume that you have, of course, tried varying resolutions, pixel depths, etc? You really will have to help us narrow this down a little more if we're to have any hope of tracking it down and fixing it. Jordan From owner-freebsd-current Thu Feb 23 12:25:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA11624 for current-outgoing; Thu, 23 Feb 1995 12:25:34 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA11613 for ; Thu, 23 Feb 1995 12:25:26 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA05138; Fri, 24 Feb 1995 07:19:14 +1100 Date: Fri, 24 Feb 1995 07:19:14 +1100 From: Bruce Evans Message-Id: <199502232019.HAA05138@godzilla.zeta.org.au> To: jhay@mikom.csir.co.za, phk@ref.tfs.com Subject: Re: src/usr.sbin/rmt/Makefile breaking Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> There were some talking about "make install" breaking in "usr.sbin/rmt" when it >> do the link to ${DESTDIR}/etc/rmt, but it seems nothing happened about it. >John, send us a patch :-) Others have sent patches :-). I think the best one for now is to put a `-' in front of the ln. `ln -sf' would be wrong because it clobbers the existing file or link which may have been customized. Installing from src/etc depends on rmt having been built. Bruce From owner-freebsd-current Thu Feb 23 12:27:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA11707 for current-outgoing; Thu, 23 Feb 1995 12:27:49 -0800 Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA11701 for ; Thu, 23 Feb 1995 12:27:45 -0800 Received: from hermes (hermes.gordian.com [192.73.220.111]) by gordius.gordian.com (8.6.9/8.6.5) with SMTP id MAA19257; Thu, 23 Feb 1995 12:26:43 -0800 Received: by hermes (920330.SGI/920502.SGI) for @gordius.gordian.com:freebsd-current@FreeBSD.org id AA10408; Thu, 23 Feb 95 12:26:40 -0800 Date: Thu, 23 Feb 95 12:26:40 -0800 From: steve@gordian.com (Steve Khoo) Message-Id: <9502232026.AA10408@hermes> To: amurai@spec.co.jp Cc: freebsd-current@FreeBSD.org In-Reply-To: <199502190130.KAA20758@tama.spec.co.jp> (message from Atsushi Murai on Sun, 19 Feb 1995 10:30:28 +0900 (JST)) Subject: Re: ppp in 2.0-950210-SNAP Sender: current-owner@FreeBSD.org Precedence: bulk >>>>> "Atsushi" == Atsushi Murai writes: Atsushi> Sorry bad response. But late better than nothing ;-) >> OK, What am I doing wrong? >> >> On my 2.0-950210-SNAP box I can connect to a Sparc running pppd 2.1.2 >> without any problem. >> >> But if I use ppp(I used manual dialing) it doesn't work. >> >> here's the log: >> 02-17 19:36:57 [202] IPCP: SendConfigAck(Req-Sent) >> 02-17 19:36:57 [202] IPCP: state change Req-Sent --> Ack-Sent >> 02-17 19:36:57 [202] LCP: Received Protocol Reject (8) state = Opend (9) >> 02-17 19:36:57 [202] -- Protocol (c025) was rejected. Atsushi> I bleive pppd2.1.2 doesn't ahs capability for LQR. But it Atsushi> is doesn't matter for ppp(iijppp). Becauce this is a Atsushi> result by negotiation. Anyway "default:" in sample is Atsushi> disable lqr as default.... right ? >> 02-17 19:36:57 [202] IPCP: Received Configure Ack (2) state = Ack-Sent (8) >> 02-17 19:36:57 [202] IPCP: state change Ack-Sent --> Opend >> 02-17 19:36:57 [202] IPCP: LayerUp. >> 02-17 19:36:57 [202] myaddr = 192.73.220.175 hisaddr = 192.73.220.83 >> 02-17 19:36:57 [202] OsLinkup: 192.73.220.83 >> 02-17 19:36:58 [202] LCP: Received Protocol Reject (8) state = Opend (9) >> 02-17 19:36:58 [202] -- Protocol (80fd) was rejected. Atsushi> CCP i enable as default in ppp(iijppp). and pppd2.1.2 Atsushi> doesnt't support pred1 compression. So you can add Atsushi> "disable pred1" to "default:" in ppp.conf. By the way, I Atsushi> beleive pred1 commpression will give us good latency and Atsushi> less SIO interrupt overhead with modem Atsushi> compression(V.42bis). And VJ compression is just Atsushi> compress tcp header not a data. >> 02-17 19:36:58 [202] CCP: LayerFinish. Atsushi> Giving up using CCP as result of negotiation. >> 02-17 19:36:58 [202] CCP: state change Req-Sent --> Stopped >> 02-17 19:36:58 [202] LCP: Received Echo Reply (10) state = Opend (9) >> 02-17 19:39:00 [202] HDLC errros -> FCS: 7 ADDR: 0 COMD: 0 PROTO: 0 Atsushi> OK. It's up a link and working for while( 36:58 -> Atsushi> 39:00). And then they are 7 FCS errors occures. Too Atsushi> much... Check Flow control of modem both your and peer. Atsushi> (modem is setup correctly using a CTS/RTS line ?) >> 02-17 19:40:59 [202] LCP: LayerDown >> 02-17 19:40:59 [202] OsLinkdown: 192.73.220.83 >> 02-17 19:40:59 [202] Phase: Terminate >> 02-17 19:40:59 [202] LCP: SendTerminateReq. >> 02-17 19:40:59 [202] LCP: state change Opend --> Closing >> 02-17 19:41:00 [202] HDLC errros -> FCS: 1 ADDR: 0 COMD: 0 PROTO: 0 >> 02-17 19:41:09 [202] LCP: SendTerminateReq. Atsushi> It's seems to hang up the line by peer. Could you check Atsushi> peer's log ? >> 02-17 19:41:15 [202] PPP Terminated. >> >> What did I do wrong? Atsushi> You did not wrong but try and check as follows. Atsushi> 1. Disable lqr to ppp(iijppp) conf Atsushi> 2. Disable pred1 to ppp(iijpp) conf Atsushi> 3. Check Hard ware flow control and line. Atsushi> 4. Check peer's log by pppd2.1.2. Disabling the lqr and pred1 doesn't seem to help. I'm actually dialing into a terminal server at work that's incapable of doing RTS/CTS and telnetting into the Sparc10 and running pppd 2.1.2 after doing "/bin/mesg n" and "stty -tostop". The log on the pppd 2.1.2 side doesn't show any errors: Feb 19 19:41:37 vulcan pppd[5444]: pppd 2.1.2 started by steve, uid 192 Feb 19 19:41:37 vulcan pppd[5444]: Connect: ppp0 <--> /dev/ttype Feb 19 19:41:55 vulcan pppd[5444]: local IP address 192.73.220.83 Feb 19 19:41:55 vulcan pppd[5444]: remote IP address 192.73.220.175 Feb 19 19:47:03 vulcan pppd[5444]: Connection terminated. Your help is much appreciated. SEK From owner-freebsd-current Thu Feb 23 12:42:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA12098 for current-outgoing; Thu, 23 Feb 1995 12:42:38 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA12092; Thu, 23 Feb 1995 12:42:30 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id MAA13154; Thu, 23 Feb 1995 12:41:22 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id MAA00214; Thu, 23 Feb 1995 12:41:22 -0800 Message-Id: <199502232041.MAA00214@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: "Jordan K. Hubbard" cc: Jeff Hoffman , current@FreeBSD.org, jdc@day.xinside.com Subject: Re: UPDATE: Imagine128 & AccelX & 950210-SNAP In-reply-to: Your message of "Thu, 23 Feb 95 12:24:14 PST." <11566.793571054@freefall.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 23 Feb 1995 12:41:20 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >> Ok, for those of you who have been keeping up, I tried to re-install 2.0 >> and ended up back with 950210-SNAP because my floppy didn't work with >> 2.0 This time, I ftp'ed the the 950210-SNAP from scratch, and did not >> use one single non-950210-SNAP file (except my X server). > >[FYI - either -hackers OR -current, but never both. I have adjusted > the CC line. Thank you] > >> I run Xsetup again, choose Number9 I128 w/4MB, same resolution, same >> color depth (16 colors). I load up X, and things are no longer OK. >> Before I go into depth with the problems, let me say that I ran this >> server under 2.0 for a while (about a month) with 0 problems. I have not >> done one thing to my machine since then. It is _EXACTLY_ the same as it >> was then. _Something_ that was changed between 2.0 and 950210-SNAP is >> causing this problem, either directly or indirectly. I will let the >> XInside people know tomorrow, as well. > >I'm sorry, but this is just frankly bizarre. I can't think of >anything except perhaps the mmap() semantics changing (David?) that >would lead to semantics like you're describing. The X server should Ummm, nothing that I know of would affect this. There were a few minor bogons fixed in post 0210-SNAP, but these have been around forever. My #9GXE/Pro is working just fine. I know through explict checking that it is mmaping using /dev/mem and is mapping the a0000-ffffff range (why the whole thing I don't know). It is not doing linear mapping on my machine with the version of the XInside server that I'm using. Perhaps I need to tweak something somewhere to get it to do that, and perhaps this is why I don't see the problem? ...I dunno, but it's working fine with the stock configuration. Note: Jeremy Chatfield isn't on -current, so if you wish for him to see this discourse he needs to be CC'd (which I just did). -DG From owner-freebsd-current Thu Feb 23 12:48:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA12181 for current-outgoing; Thu, 23 Feb 1995 12:48:39 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id MAA12175 for ; Thu, 23 Feb 1995 12:48:35 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA10854; Thu, 23 Feb 1995 15:47:52 -0500 Date: Thu, 23 Feb 1995 15:47:52 -0500 From: Garrett Wollman Message-Id: <9502232047.AA10854@halloran-eldar.lcs.mit.edu> To: terry@cs.weber.edu (Terry Lambert) Cc: nate@trout.sri.MT.net (Nate Williams), rmallory@wiley.csusb.edu, current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-Reply-To: <9502231723.AA03217@cs.weber.edu> References: <199502230441.VAA17717@trout.sri.MT.net> <9502231723.AA03217@cs.weber.edu> Sender: current-owner@FreeBSD.org Precedence: bulk < Anything that gets done will eventaully have to reflect a special > status fo the tools. Which hopefully would consist of .include in the appropriate Makefiles... Cross-compilation is a good goal. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Thu Feb 23 13:40:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA13550 for current-outgoing; Thu, 23 Feb 1995 13:40:13 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id NAA13544; Thu, 23 Feb 1995 13:40:09 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id aa27486; 23 Feb 95 18:01 GMT Received: from localhost (gary@localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.9/8.6.9) with SMTP id RAA00162; Thu, 23 Feb 1995 17:59:40 GMT X-Authentication-Warning: palmer.demon.co.uk: Host localhost didn't use HELO protocol To: Peter Dufault cc: freebsd-hardware@FreeBSD.org, current@FreeBSD.org, nb@xap.com Subject: Re: Adaptec problems In-reply-to: Your message of "Wed, 22 Feb 1995 17:08:32 EST." <199502222208.RAA22363@hda.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <158.793562378.1@palmer.demon.co.uk> Date: Thu, 23 Feb 1995 17:59:39 +0000 Message-ID: <159.793562379@palmer.demon.co.uk> From: Gary Palmer Sender: current-owner@FreeBSD.org Precedence: bulk In message <199502222208.RAA22363@hda.com>, Peter Dufault writes: >You've disabled termination on the card? On the non-C you have >to remove the termination resistors. On the C it is under software >control. AARRGGGHHHH . I'd used the SCSISelect thingy to disable the card termination byt switch one was in the wrong position... termination was installed no matter what the s/w said... I'll go check what my friend has done and see if that's his problem also. Gary From owner-freebsd-current Thu Feb 23 13:48:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA14249 for current-outgoing; Thu, 23 Feb 1995 13:48:52 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id NAA13688 for ; Thu, 23 Feb 1995 13:43:36 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA13459; Thu, 23 Feb 1995 22:40:56 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id WAA23400 for freebsd-current@FreeBSD.org; Thu, 23 Feb 1995 22:40:56 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id WAA09080 for freebsd-current@FreeBSD.org; Thu, 23 Feb 1995 22:41:41 +0100 From: J Wunsch Message-Id: <199502232141.WAA09080@uriah.heep.sax.de> Subject: MD5 in ports To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Thu, 23 Feb 1995 22:41:40 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 296 Sender: current-owner@FreeBSD.org Precedence: bulk What will i have to do to create those mystic MD5 files for a port? I believed there were a comment in the GUIDELINES file, but couldn't find anything. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Feb 23 13:54:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA14869 for current-outgoing; Thu, 23 Feb 1995 13:54:42 -0800 Received: from cybernetics.net (jeffh@server0.cybernetics.net [198.80.48.52]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id NAA14859 for ; Thu, 23 Feb 1995 13:54:40 -0800 Received: by cybernetics.net (4.1/SMI-4.1) id AA01300; Thu, 23 Feb 95 16:53:54 EST Date: Thu, 23 Feb 1995 16:53:49 -0500 (EST) From: Jeff Hoffman To: "Jordan K. Hubbard" Cc: current@FreeBSD.org Subject: Re: UPDATE: Imagine128 & AccelX & 950210-SNAP In-Reply-To: <11566.793571054@freefall.cdrom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Thu, 23 Feb 1995, Jordan K. Hubbard wrote: > > Ok, for those of you who have been keeping up, I tried to re-install 2.0 > > and ended up back with 950210-SNAP because my floppy didn't work with > > 2.0 This time, I ftp'ed the the 950210-SNAP from scratch, and did not > > use one single non-950210-SNAP file (except my X server). > > [FYI - either -hackers OR -current, but never both. I have adjusted > the CC line. Thank you] Oops, sorry. Thanks. > > I run Xsetup again, choose Number9 I128 w/4MB, same resolution, same > > color depth (16 colors). I load up X, and things are no longer OK. > > Before I go into depth with the problems, let me say that I ran this > > server under 2.0 for a while (about a month) with 0 problems. I have not > > done one thing to my machine since then. It is _EXACTLY_ the same as it > > was then. _Something_ that was changed between 2.0 and 950210-SNAP is > > causing this problem, either directly or indirectly. I will let the > > XInside people know tomorrow, as well. > > I'm sorry, but this is just frankly bizarre. I can't think of > anything except perhaps the mmap() semantics changing (David?) that > would lead to semantics like you're describing. The X server should > still be communicating just fine with the board's registers and video > memory under either 2.0 or 950210-SNAP, and I've certainly been > running Xaccel quite happily since pre-2.0 days all the way up to > post-950210-SNAP with my #9 GXE64 Pro/4MB board. It's never given me > anything but flawless performance. I know. I never had any problems with 2.0 either. The board ran flawlessly and I thought I had died and gone to heaven. Now, it's a different story however. > I presume that you have, of course, tried varying resolutions, pixel > depths, etc? You really will have to help us narrow this down a > little more if we're to have any hope of tracking it down and fixing > it. Yes, I tried all resolutions supported by my board, as well as each color depth. It is worth noting that this problem only occurs when the I128 is selected. By using either the cirrus logic driver or the standard IBM VGA, 256k driver things are fine (no problems.) The second I switch to the I128, though, things begin going mad. This is true for 640x480x16 all the way up to 1600x1200x16bit. I am in contact with the people at XInside and will let you guys know if I come up with anything new from them. If you can think of anything new I can tell them to help them find and fix the problem then by all means e-mail me. I will do anything I can to help all parties involved get the problem fixed. > Jordan Jeff -- Jeff Hoffman -- jeffh@cybernetics.net ------------------------------------- "A man facing the light looks not into sorrow, but to to the future...always." WWW: http://www.cybernetics.net/users/jeffh ------------------------------------------------------------------------------ PGP Public Key available on request. From owner-freebsd-current Thu Feb 23 14:18:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA16390 for current-outgoing; Thu, 23 Feb 1995 14:18:19 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id OAA16354; Thu, 23 Feb 1995 14:18:05 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA11101; Thu, 23 Feb 1995 17:17:31 -0500 Date: Thu, 23 Feb 1995 17:17:31 -0500 From: Garrett Wollman Message-Id: <9502232217.AA11101@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-Reply-To: <15359.793507347@freefall.cdrom.com> References: <9502230051.AA09330@halloran-eldar.lcs.mit.edu> <15359.793507347@freefall.cdrom.com> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > Any program which is "part" of FreeBSD should be compiled "inside" the > source tree, period. Sure, it may work for some things to be compiled > in any old location but certainly not everything, and if it's not > guaranteed to be deterministic then it should be discouraged. Period. I very strongly disagree, and I think the work necessary to make in-tree-reference compiles work should, if done right, come close to making this work all the time. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Thu Feb 23 14:52:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA17512 for current-outgoing; Thu, 23 Feb 1995 14:52:00 -0800 Received: from crab.xinside.com (day.xinside.com [199.164.187.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA17506; Thu, 23 Feb 1995 14:51:57 -0800 Received: (from jdc@localhost) by crab.xinside.com (8.6.8/8.6.9) id PAA11444; Thu, 23 Feb 1995 15:52:58 -0700 From: Jeremy Chatfield Message-Id: <199502232252.PAA11444@crab.xinside.com> Subject: Re: UPDATE: Imagine128 & AccelX & 950210-SNAP To: davidg@Root.COM Date: Thu, 23 Feb 1995 15:52:58 -0700 (MST) Cc: jkh@freefall.cdrom.com, jeffh@cybernetics.net, current@FreeBSD.org In-Reply-To: <199502232041.MAA00214@corbin.Root.COM> from "David Greenman" at Feb 23, 95 12:41:20 pm Organization: X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA. Phone: +1(303)470-5302 Reply-To: jdc@xinside.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3581 Sender: current-owner@FreeBSD.org Precedence: bulk David Greenman writes: > >> Ok, for those of you who have been keeping up, I tried to re-install 2.0 > >> and ended up back with 950210-SNAP because my floppy didn't work with > >> 2.0 This time, I ftp'ed the the 950210-SNAP from scratch, and did not > >> use one single non-950210-SNAP file (except my X server). > > > >[FYI - either -hackers OR -current, but never both. I have adjusted > > the CC line. Thank you] Damn - and I follow the hackers. Oh well... > >> I run Xsetup again, choose Number9 I128 w/4MB, same resolution, same > >> color depth (16 colors). I load up X, and things are no longer OK. > >> Before I go into depth with the problems, let me say that I ran this > >> server under 2.0 for a while (about a month) with 0 problems. I have not > >> done one thing to my machine since then. It is _EXACTLY_ the same as it > >> was then. _Something_ that was changed between 2.0 and 950210-SNAP is > >> causing this problem, either directly or indirectly. I will let the > >> XInside people know tomorrow, as well. > > > >I'm sorry, but this is just frankly bizarre. I can't think of > >anything except perhaps the mmap() semantics changing (David?) that > >would lead to semantics like you're describing. The X server should > > Ummm, nothing that I know of would affect this. There were a few minor > bogons fixed in post 0210-SNAP, but these have been around forever. My > #9GXE/Pro is working just fine. I know through explict checking that it is > mmaping using /dev/mem and is mapping the a0000-ffffff range (why the whole > thing I don't know). It is not doing linear mapping on my machine with the > version of the XInside server that I'm using. Perhaps I need to tweak > something somewhere to get it to do that, and perhaps this is why I don't see > the problem? ...I dunno, but it's working fine with the stock configuration. > Note: Jeremy Chatfield isn't on -current, so if you wish for him to see > this discourse he needs to be CC'd (which I just did). We've had a little chat about this. The major difference between the I-128 and the GXE64pro is that the I-128 maps memory above and below the usual 1MB boundary. If the mmap code was probing, perhaps to test for the existance of real memory, that might upset the graphics engine. The problem is 90+% likely to be something that graphics engine is causing, because that's the bit that is being given an offset. To get a recognisable picture from a Netscape image, the only thing that can be changed is the graphics engine. The mmapping must be correct or there would be other symptoms (and the GXE64pro would probably fail in the same or similar ways). So, did someone introduce some kind of memory probes? Or anything that might read and write in the memory area mapped by the I-128. This has a huge address space BTW. We map 8MB for the Mach64 as well, but most boards have a lower maximum. The only other cause that we can think of is someone dinking with PCI registers. There are certain things that are proscribed and insufficient attention to these, or probing a video device as if a scsi board or something, might provoke a similar problem. We're much more vague about this as we don't have a huge amount of PCI experience, either :-) Cheers, JeremyC. -- Jeremy Chatfield, +1(303)470-5302, FAX:+1(303)470-5513, email:jdc@xinside.com X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA. Commercial X Server - for more information please try these services http://www.xinside.com info@xinside.com ftp.xinside.com From owner-freebsd-current Thu Feb 23 15:12:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA17912 for current-outgoing; Thu, 23 Feb 1995 15:12:41 -0800 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id PAA17905 for ; Thu, 23 Feb 1995 15:12:39 -0800 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA29473; Fri, 24 Feb 95 00:11:36 +0100 Date: Fri, 24 Feb 95 00:11:36 +0100 From: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Message-Id: <9502232311.AA29473@cabri.obs-besancon.fr> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.org In-Reply-To: <199502232141.WAA09080@uriah.heep.sax.de> (message from J Wunsch on Thu, 23 Feb 1995 22:41:40 +0100 (MET)) Subject: Re: MD5 in ports X-Mailer: Emacs Sender: current-owner@FreeBSD.org Precedence: bulk >>>>> "J" == J Wunsch writes: > What will i have to do to create those mystic MD5 files for a port? > I believed there were a comment in the GUIDELINES file, but couldn't > find anything. > -- `make makesum' > cheers, J"org > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) Jean-Marc -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Jean-Marc Zucconi | jmz@cabri.obs-besancon.fr Observatoire de Besancon | F 25010 Besancon cedex | PGP Key: finger jmz@cabri.obs-besancon.fr ========================================================================= From owner-freebsd-current Thu Feb 23 16:23:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA19341 for current-outgoing; Thu, 23 Feb 1995 16:23:10 -0800 Received: from cybernetics.net (jeffh@server0.cybernetics.net [198.80.48.52]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA19331 for ; Thu, 23 Feb 1995 16:23:07 -0800 Received: by cybernetics.net (4.1/SMI-4.1) id AA15909; Thu, 23 Feb 95 19:22:30 EST Date: Thu, 23 Feb 1995 19:22:24 -0500 (EST) From: Jeff Hoffman To: jdc@xinside.com Cc: davidg@Root.COM, jkh@freefall.cdrom.com, current@FreeBSD.org Subject: Re: UPDATE: Imagine128 & AccelX & 950210-SNAP In-Reply-To: <199502232252.PAA11444@crab.xinside.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk Ok, new development. Since my new SNAP installation, I re-ftp'd Netscape and it works flawlessly now. Also, when I hold down control and click on the xterm it works fine. The only thing that still does not work is the moving of the window off the top with twm, but to tell you the truth I don't know if I ran twm when I ran 2.0. Perhaps the first time I installed SNAP there were lib incompatibilities or something due to an error on my part, and now it's fixed because I ftp'd the whole distribution this time. Regardless, my Netscape works now, as does everything except twm (which I hate anyways!) I have no clue what I did, but... Jeff -- Jeff Hoffman -- jeffh@cybernetics.net ------------------------------------- "A man facing the light looks not into sorrow, but to to the future...always." WWW: http://www.cybernetics.net/users/jeffh ------------------------------------------------------------------------------ PGP Public Key available on request. From owner-freebsd-current Thu Feb 23 16:54:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA21061 for current-outgoing; Thu, 23 Feb 1995 16:54:39 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA21055 for ; Thu, 23 Feb 1995 16:54:35 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id aa03482; 23 Feb 95 18:19 GMT Received: from localhost (gary@localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.9/8.6.9) with SMTP id SAA00651; Thu, 23 Feb 1995 18:18:57 GMT X-Authentication-Warning: palmer.demon.co.uk: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: "Richard Wackerbarth " , current@FreeBSD.org Subject: Re: Why are these still here? In-reply-to: Your message of "Wed, 22 Feb 1995 19:46:05 PST." <199502230346.TAA26362@gndrsh.aac.dev.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <647.793563535.1@palmer.demon.co.uk> Date: Thu, 23 Feb 1995 18:18:56 +0000 Message-ID: <648.793563536@palmer.demon.co.uk> From: Gary Palmer Sender: current-owner@FreeBSD.org Precedence: bulk In message <199502230346.TAA26362@gndrsh.aac.dev.com>, "Rodney W. Grimes" write s: >> Mirrored FreeBSD-ports (ftp.FreeBSD.org:/pub/FreeBSD/ports-2.0/ -> >> /pub/FreeBSD/ports-2.0/) FreeBSD Ports @ Wed Feb 22 20:09:24 CST 1995 >> Failed to get x11/tk/patches/patch-ab: 550 x11/tk/patches/patch-ab: >> Permission denied. >... >Please check the permissions on your end, every thing looks find on >freefall... and on ftp.cdrom.com. It could be you can not write into >the directory on your system. Sorry Rod - he was referring to the 2.0-ports directory, and I checked the first on the list and the permissions error is right - the file is -rw-rw---- jkh wheel .... Gary From owner-freebsd-current Thu Feb 23 18:28:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAB22719 for current-outgoing; Thu, 23 Feb 1995 18:28:42 -0800 Received: from tinny.eis.net.au (ernie@[203.12.171.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA22711 for ; Thu, 23 Feb 1995 18:28:25 -0800 Received: (from ernie@localhost) by tinny.eis.net.au (8.6.9/8.6.9) id MAA21986 for freebsd-current@freebsd.org; Fri, 24 Feb 1995 12:27:29 +1000 From: Ernie Elu Message-Id: <199502240227.MAA21986@tinny.eis.net.au> Subject: Adaptec 1522A woes To: freebsd-current@FreeBSD.org Date: Fri, 24 Feb 1995 12:27:29 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1106 Sender: current-owner@FreeBSD.org Precedence: bulk I have an on-going problem that still occurs with the current version of FreeBSD. I am running an Adaptec 1522A SCSI controller and every time I boot the the access light on the card will function until FreeBSD finishes it's RAM test then the light never comes on again. But wait there's more. About 1 in every 3 reboots FreeBSD will load up to the message that says waiting for drives to settle, then the drive light on the boot drive (Quantum 540) will come on and the system is frozen and has to be powered off. The same computer can run Linux or Unixware without a sign of the above problems. Any suggestions? I seems to point to a 1522A drive problem I have reinstalled FreeBSD several times including all the recent snaps and current kernel (via sup from freebsd.org) I have also tried several drives. - Ernie. _______________________________________________________________________________ Elu Information Systems - ernie@tinny.eis.net.au Brisbane - Australia "I ping, therefore I am." _______________________________________________________________________________ From owner-freebsd-current Thu Feb 23 19:38:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id TAA23866 for current-outgoing; Thu, 23 Feb 1995 19:38:18 -0800 Received: from acatst01 (cos.titan.com [198.232.129.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id TAA23858 for ; Thu, 23 Feb 1995 19:38:15 -0800 Received: from cartis01.cos.titan.com by acatst01 with SMTP (1.38.193.4/16.2) id AA21271; Thu, 23 Feb 1995 20:37:43 -0700 Received: from carti004 by cartis01.cos.titan.com with SMTP (1.37.109.8/gateway-v7.cos.titan.com) id AA05244; Thu, 23 Feb 1995 21:35:43 -0600 Received: by carti004.cos.titan.com (1.37.109.8/client-v7.cos.titan.com) id AA01096; Thu, 23 Feb 1995 21:38:02 -0600 Date: Thu, 23 Feb 1995 21:38:02 -0600 From: Wen-Jer Chang Message-Id: <9502240338.AA01096@carti004.cos.titan.com> To: freebsd-current@FreeBSD.org, owner-freebsd-current@freefall.cdrom.com Subject: Re: Adaptec 1522A woes Sender: current-owner@FreeBSD.org Precedence: bulk Hi Ernie, Try to disable the sync and auto-disconnect by using SCSIselect. And disable BIOS installation. I got the same problem as you do. I am using Adaptec 2940 but I got it installed on my PC. Try that. Regards, Wen From owner-freebsd-current Thu Feb 23 20:00:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA24520 for current-outgoing; Thu, 23 Feb 1995 20:00:55 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA24513 for ; Thu, 23 Feb 1995 20:00:45 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA13601; Fri, 24 Feb 1995 14:55:04 +1100 Date: Fri, 24 Feb 1995 14:55:04 +1100 From: Bruce Evans Message-Id: <199502240355.OAA13601@godzilla.zeta.org.au> To: bde@zeta.org.au, pst@shockwave.com Subject: Re: snp(4)/watch(8) code review comments Cc: current@FreeBSD.org, ugen@netvision.net.il Sender: current-owner@FreeBSD.org Precedence: bulk >I seem to recall that BSDI just passes in a pointer to the desired tty struct >entry. In this case, every driver would require a wrapper calling potentially >a common ttselect routine. All the current drives except the pty and console drivers already have a wrapper. >I have no problem with making this change if there are no objections, ttselect >gets replaced by > int ttyselect (struct tty *, int flag, struct proc *) >(note new name...since this is what BSDI calls the identical function). >It would be reasonable to discuss this with the appropriate NetBSD folks too >since it would good for the driver writers if we both support this change. Which NetBSD mailing list is appropriate? >Any objections to: > struct tty *xxxdevtotty (dev_t dev) >Returns a pointer to the right entry or NULL if entry not >available/initialized. OK. > Do you need to call it for possibly-non-open devices? >... >Do you mean open/initialized drivers or open devices? I could easily see >the case where one is mallocing "struct tty" as required (say for example >a pty driver without stupid limits). This would be a vast improvement >over the current hard coded size of the pty entry array. I mean open devices. I'd like to be able to free the tty structs when the device is closed. The session reference to the tty still stops this. References by the snoop device might have to stop it too. Bruce From owner-freebsd-current Thu Feb 23 20:10:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA24826 for current-outgoing; Thu, 23 Feb 1995 20:10:00 -0800 Received: from dolphin.mikom.csir.co.za (some.schmuck.lame.delegated.to.RAIN.PSG.COM [146.64.28.40]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA24820 for ; Thu, 23 Feb 1995 20:09:56 -0800 Received: (from jhay@localhost) by dolphin.mikom.csir.co.za (8.6.9/8.6.6) id GAA08516; Fri, 24 Feb 1995 06:10:03 +0200 From: John Hay Message-Id: <199502240410.GAA08516@dolphin.mikom.csir.co.za> Subject: Re: src/usr.sbin/rmt/Makefile breaking To: bde@zeta.org.au (Bruce Evans) Date: Fri, 24 Feb 1995 06:10:02 +0200 (SAT) Cc: phk@ref.tfs.com, current@FreeBSD.org In-Reply-To: <199502232019.HAA05138@godzilla.zeta.org.au> from "Bruce Evans" at Feb 24, 95 07:19:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 328 Sender: current-owner@FreeBSD.org Precedence: bulk > I think the best one for now is to put a `-' in front of the ln. `ln -sf' > would be wrong because it clobbers the existing file or link which may have > been customized. Installing from src/etc depends on rmt having been built. > > Bruce > Now I also think that "-ln -s" is better. -- John Hay -- jhay@mikom.csir.co.za From owner-freebsd-current Thu Feb 23 20:19:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA25052 for current-outgoing; Thu, 23 Feb 1995 20:19:04 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA25046 for ; Thu, 23 Feb 1995 20:19:03 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id UAA12287; Thu, 23 Feb 1995 20:16:15 -0800 From: Poul-Henning Kamp Message-Id: <199502240416.UAA12287@ref.tfs.com> Subject: Re: src/usr.sbin/rmt/Makefile breaking To: jhay@mikom.csir.co.za (John Hay) Date: Thu, 23 Feb 1995 20:16:14 -0800 (PST) Cc: bde@zeta.org.au, current@FreeBSD.org In-Reply-To: <199502240410.GAA08516@dolphin.mikom.csir.co.za> from "John Hay" at Feb 24, 95 06:10:02 am Content-Type: text Content-Length: 448 Sender: current-owner@FreeBSD.org Precedence: bulk > > I think the best one for now is to put a `-' in front of the ln. `ln -sf' > > would be wrong because it clobbers the existing file or link which may have > > been customized. Installing from src/etc depends on rmt having been built. > > > > Bruce > > > Now I also think that "-ln -s" is better. done -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Thu Feb 23 20:32:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA25157 for current-outgoing; Thu, 23 Feb 1995 20:32:11 -0800 Received: from crab.xinside.com (day.xinside.com [199.164.187.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA25151; Thu, 23 Feb 1995 20:32:09 -0800 Received: (from jdc@localhost) by crab.xinside.com (8.6.8/8.6.9) id VAA12561; Thu, 23 Feb 1995 21:33:14 -0700 From: Jeremy Chatfield Message-Id: <199502240433.VAA12561@crab.xinside.com> Subject: Re: UPDATE: Imagine128 & AccelX & 950210-SNAP To: jeffh@cybernetics.net (Jeff Hoffman) Date: Thu, 23 Feb 1995 21:33:14 -0700 (MST) Cc: jdc@xinside.com, davidg@Root.COM, jkh@freefall.cdrom.com, current@FreeBSD.org In-Reply-To: from "Jeff Hoffman" at Feb 23, 95 07:22:24 pm Organization: X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA. Phone: +1(303)470-5302 Reply-To: jdc@xinside.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1104 Sender: current-owner@FreeBSD.org Precedence: bulk Jeff Hoffman writes: > > Ok, new development. Since my new SNAP installation, I re-ftp'd Netscape > and it works flawlessly now. Also, when I hold down control and click on > the xterm it works fine. > > The only thing that still does not work is the moving of the window off > the top with twm, but to tell you the truth I don't know if I ran twm > when I ran 2.0. > > Perhaps the first time I installed SNAP there were lib incompatibilities > or something due to an error on my part, and now it's fixed because I > ftp'd the whole distribution this time. > > Regardless, my Netscape works now, as does everything except twm (which I > hate anyways!) > > I have no clue what I did, but... > > Jeff I'm moving this to "Closed; watch for any other occurrence" for X Inside. Cheers, JeremyC. -- Jeremy Chatfield, +1(303)470-5302, FAX:+1(303)470-5513, email:jdc@xinside.com X Inside Inc, P O Box 10774, Golden, CO 80401-0610, USA. Commercial X Server - for more information please try these services http://www.xinside.com info@xinside.com ftp.xinside.com From owner-freebsd-current Thu Feb 23 20:33:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA25174 for current-outgoing; Thu, 23 Feb 1995 20:33:39 -0800 Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id UAA25168 for ; Thu, 23 Feb 1995 20:33:37 -0800 Received: from palmer.demon.co.uk by post.demon.co.uk id aa09877; 23 Feb 95 22:27 GMT Received: from localhost (gary@localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.9/8.6.9) with SMTP id WAA01569; Thu, 23 Feb 1995 22:27:16 GMT X-Authentication-Warning: palmer.demon.co.uk: Host localhost didn't use HELO protocol To: Joerg Wunsch cc: FreeBSD-current users Subject: Re: MD5 in ports In-reply-to: Your message of "Thu, 23 Feb 1995 22:41:40 +0100." <199502232141.WAA09080@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1565.793578434.1@palmer.demon.co.uk> Date: Thu, 23 Feb 1995 22:27:15 +0000 Message-ID: <1566.793578435@palmer.demon.co.uk> From: Gary Palmer Sender: current-owner@FreeBSD.org Precedence: bulk In message <199502232141.WAA09080@uriah.heep.sax.de>, J Wunsch writes: >What will i have to do to create those mystic MD5 files for a port? >I believed there were a comment in the GUIDELINES file, but couldn't >find anything. There is something about it in the /usr/share/FAQ/ports.FAQ, but all you really need to do is cd to the directory for the port you want the MD5 checksum made for, and type `make makesum'. `make checksum' will check it's OK. Gary From owner-freebsd-current Thu Feb 23 21:37:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id VAA26105 for current-outgoing; Thu, 23 Feb 1995 21:37:38 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id VAA26096 for ; Thu, 23 Feb 1995 21:37:37 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.9/8.6.9) with SMTP id VAA19198; Thu, 23 Feb 1995 21:35:56 -0800 Message-Id: <199502240535.VAA19198@precipice.Shockwave.COM> To: Bruce Evans cc: current@FreeBSD.org, ugen@netvision.net.il Subject: Re: snp(4)/watch(8) code review comments In-reply-to: Your message of "Fri, 24 Feb 1995 14:55:04 +1100." <199502240355.OAA13601@godzilla.zeta.org.au> Date: Thu, 23 Feb 1995 21:35:56 -0800 From: Paul Traina Sender: current-owner@FreeBSD.org Precedence: bulk OK, well I've done what I described, I just have to whip up some wrappers for the ptydevtotty and ptyselect devices which I'll probably get to tonight or tomorrow. I know that Charles is on current, I wonder if he has any opinions? From owner-freebsd-current Thu Feb 23 22:33:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id WAA01417 for current-outgoing; Thu, 23 Feb 1995 22:33:20 -0800 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id WAA01411 for ; Thu, 23 Feb 1995 22:33:18 -0800 Received: from s1.elec.uq.oz.au by bunyip.cc.uq.oz.au with SMTP (PP); Fri, 24 Feb 1995 16:32:36 +1000 Received: from s4 (s4.elec.uq.oz.au) by s1.elec.uq.oz.au (4.0/SMI-4.0) id AA12454; Fri, 24 Feb 95 16:31:44 EST From: clary@elec.uq.oz.au (Clary Harridge) Message-Id: <9502240631.AA12454@s1.elec.uq.oz.au> Subject: Disappearing root file system To: freebsd-current@FreeBSD.org Date: Fri, 24 Feb 1995 16:32:14 +1000 (EST) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 492 Sender: current-owner@FreeBSD.org Precedence: bulk Having just built a new system make world circa Feb 21 I find that the free space on / gradually diminishes until there is none left. du shows no changes on the contents of / A reboot shows that sd0a has unreferenced files. Has anyone seen this behaviour? Is so is there a cure for it? Thanks! -- regards Dept. of Electrical Engineering, Clary Harridge University of Queensland, QLD, Australia, 4072 Phone: +61-7-365-3636 Fax: +61-7-365-4999 INTERNET: clary@elec.uq.oz.au From owner-freebsd-current Fri Feb 24 02:02:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA12079 for current-outgoing; Fri, 24 Feb 1995 02:02:32 -0800 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA12067 for ; Fri, 24 Feb 1995 02:02:25 -0800 Received: from gilberto.physik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HNFBKAJLI8001BQU@mail.rwth-aachen.de>; Fri, 24 Feb 1995 11:00:47 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.8/8.6.9) id LAA21074; Fri, 24 Feb 1995 11:06:27 +0100 Date: Fri, 24 Feb 1995 11:06:26 +0100 (MET) From: Christoph Kukulies Subject: Re: Kernel Compile Error. In-reply-to: from "Eric M. Busalacchi" at Feb 24, 95 03:45:34 am To: emb@herman.tiac.net (Eric M. Busalacchi) Cc: freebsd-current@freefall.cdrom.com (user alias) Reply-to: Christoph Kukulies Message-id: <199502241006.LAA21074@gilberto.physik.rwth-aachen.de> X-Mailer: ELM [version 2.4 PL23] Content-type: text Content-transfer-encoding: 7BIT Content-length: 1635 Sender: current-owner@FreeBSD.org Precedence: bulk > > > > Hello, I was recompiling my kernel and got the following error: > > cc -O -W -Wreturn-type -Wcomment -Wredundant-decls -I. -I../.. -I../../sys > -DHERMAN -DI586_CPU -DPROBE_VERBOSE -DGATEWAY -DAUTO_EOI_1 > -DALLOW_CONFLICT_IRQ -DBOUNCE_BUFFERS -DNCONS=8 -DSCSI_DELAY=15 > -DFAT_CURSOR -DUCONSOLE -DXSERVER -DCOMPAT_43 -DCD9660 -DPROCFS > -DMSDOSFS -DFFS -DINET -DKERNEL -Di386 -DLOAD_ADDRESS=0xF > 0100000 -c vers.c > loading kernel > autoconf.o: Undefined symbol `_setconf' referenced from text segment > *** Error code 1 > > Stop. > root@herman: > > Now, let me explain a little about why I am wondering if this is > a bug. I do s 'sup' about once to twice a week. The last time I did a > sup was about a week and a half ago. I recompiled my kernel using the > same INDENT file, and it worked fine. I did a 'sup' tonight, and went to > recompile the kernel and I got this error. I don't know if it because I > have to rebuild the libraries or something like that, I just wanted to > let you know in case it was a bug. > > BTW: I have been running 2.1.0-Development since it came out without any > problems! It runs GREAT! Congrats! You supped but didn't rebuild the world - or at least didn't rebuild config. rebuild and install config and the problem will be gone. (I've been caught by this a couple of days ago, too). > > -- > Eric M. Busalacchi > emb@herman.tiac.net > > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Fri Feb 24 02:05:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA12156 for current-outgoing; Fri, 24 Feb 1995 02:05:20 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA12042 for ; Fri, 24 Feb 1995 02:01:13 -0800 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.9/8.6.9) id AAA16766; Wed, 22 Feb 1995 00:41:53 +0100 Date: Wed, 22 Feb 1995 00:41:53 +0100 From: Julian Howard Stacey Message-Id: <199502212341.AAA16766@vector.eikon.e-technik.tu-muenchen.de> To: davidg@Root.COM Subject: Re: Possible kern.maxproc fatal bug Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > From: David Greenman > Perhaps making the map accomodate 2 or 3 times maxproc might be a compromise. My acid test would be a fork going berserk recursively in user mode (no suid 0) if it could withstand that, would be nice :-) Julian S From owner-freebsd-current Fri Feb 24 02:07:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA12291 for current-outgoing; Fri, 24 Feb 1995 02:07:43 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA12127 for ; Fri, 24 Feb 1995 02:03:59 -0800 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.9/8.6.9) id AAA15887; Wed, 22 Feb 1995 00:33:19 +0100 Date: Wed, 22 Feb 1995 00:33:19 +0100 From: Julian Howard Stacey Message-Id: <199502212333.AAA15887@vector.eikon.e-technik.tu-muenchen.de> To: jhs@regent.e-technik.tu-muenchen.de, rgrimes@gndrsh.aac.dev.com Subject: Re: newfs: sectors per cylinder (4096) disagrees with disk label (36) Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > From: "Rodney W. Grimes" Re You can revert to the old behavior my adding -t 0 -u 0 to the newfs commands, which causes newfs to use the head/cylinder and sectors/track from the disklabel. OK Thanks Rod, No doubt if phk keeps the mods, we'll see -t 0 -u 0 added to etc/Makefile, so it can survive. Julian S From owner-freebsd-current Fri Feb 24 02:35:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA12917 for current-outgoing; Fri, 24 Feb 1995 02:35:31 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id CAA12409 for ; Fri, 24 Feb 1995 02:13:31 -0800 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.9/8.6.9) id AAA16408; Wed, 22 Feb 1995 00:39:16 +0100 Date: Wed, 22 Feb 1995 00:39:16 +0100 From: Julian Howard Stacey Message-Id: <199502212339.AAA16408@vector.eikon.e-technik.tu-muenchen.de> To: bde@zeta.org.au, davidg@Root.COM, jhs@regent.e-technik.tu-muenchen.de Subject: Re: Possible kern.maxproc fatal bug Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk > Bruce Evans Re. > Probably because the proc table is not dynamically sized. Basically, you >can't change maxproc - it probably should not by managed by sysctl. But it is dynamically sized. I can't see any problems that would cause a panic. Old rlimits for RLIMIT_NPROC become bogus when maxproc is changed but this probably won't cause a panic. Well now, I guess I don't make this offer often, or lightly, but it Will crash my machine, & as a normal user, so if someone Really wanted to prove it, I could issue a temporary login late one slip connected night (TZ=GMT+1), & let that person Prove it to their satisfaction :-) Of course I'd rather not ... but if it's necessary to prove the bug ;-) Julian S (fretting & worrying, hoping no one will take him up on his offer ;-) From owner-freebsd-current Fri Feb 24 08:34:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA19846 for current-outgoing; Fri, 24 Feb 1995 08:34:00 -0800 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA19840 for ; Fri, 24 Feb 1995 08:33:58 -0800 Received: from starkhome.UUCP (root@localhost) by sbstark.cs.sunysb.edu (8.6.9/8.6.9) with UUCP id LAA03715 for current@freebsd.org; Fri, 24 Feb 1995 11:30:26 -0500 Received: by starkhome.cs.sunysb.edu (8.6.9/1.34) id LAA15376; Fri, 24 Feb 1995 11:25:41 -0500 Date: Fri, 24 Feb 1995 11:25:41 -0500 From: starkhome!gene@sbstark.cs.sunysb.edu (Gene Stark) Message-Id: <199502241625.LAA15376@starkhome.cs.sunysb.edu> To: current@FreeBSD.org Subject: Decrease in namei cache effectiveness? Sender: current-owner@FreeBSD.org Precedence: bulk This morning I tried compiling up an up-to-date kernel, booting it, and then starting a make world. I stopped it after I noticed that the disk was getting an incredible pounding during C compilations that previously would be almost totally CPU-bound. My impression from "systat -vmstat" was that somehow the effectiveness of the namei cache had gotten drastically reduced, and the lookups of the names of include files were causing a lot of disk activity. Has anyone else seen this? - Gene From owner-freebsd-current Fri Feb 24 08:52:24 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA20084 for current-outgoing; Fri, 24 Feb 1995 08:52:24 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA20041 for ; Fri, 24 Feb 1995 08:48:08 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.10/jtpda-5.0) with SMTP id RAA23119 ; Fri, 24 Feb 1995 17:45:26 +0100 Received: by blaise.ibp.fr (4.1/SMI-4.1) id AA05148; Fri, 24 Feb 95 17:45:25 +0100 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <9502241645.AA05148@blaise.ibp.fr> Subject: Re: Decrease in namei cache effectiveness? To: starkhome!gene@sbstark.cs.sunysb.edu (Gene Stark) Date: Fri, 24 Feb 1995 17:45:25 +0100 (MET) Cc: current@FreeBSD.org In-Reply-To: <199502241625.LAA15376@starkhome.cs.sunysb.edu> from "Gene Stark" at Feb 24, 95 11:25:41 am X-Operating-System: FreeBSD 2.1.0-Development ctm#375 X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 641 Sender: current-owner@FreeBSD.org Precedence: bulk > starting a make world. I stopped it after I noticed that the disk was getting > an incredible pounding during C compilations that previously would be > almost totally CPU-bound. My impression from "systat -vmstat" was that > somehow the effectiveness of the namei cache had gotten drastically reduced, > and the lookups of the names of include files were causing a lot of disk > activity. > > Has anyone else seen this? Same here. Very very slow (I was compiling sendmail, guess why ? :-)) -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.1.0-Development #9: Sat Feb 18 19:21:00 MET 1995 From owner-freebsd-current Fri Feb 24 10:51:50 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA22116 for current-outgoing; Fri, 24 Feb 1995 10:51:50 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA22110 for ; Fri, 24 Feb 1995 10:51:44 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA02024; Sat, 25 Feb 1995 05:39:45 +1100 Date: Sat, 25 Feb 1995 05:39:45 +1100 From: Bruce Evans Message-Id: <199502241839.FAA02024@godzilla.zeta.org.au> To: roberto@blaise.ibp.fr, starkhome!gene@sbstark.cs.sunysb.edu Subject: Re: Decrease in namei cache effectiveness? Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> starting a make world. I stopped it after I noticed that the disk was getting >> an incredible pounding during C compilations that previously would be >> almost totally CPU-bound. My impression from "systat -vmstat" was that >> somehow the effectiveness of the namei cache had gotten drastically reduced, >> and the lookups of the names of include files were causing a lot of disk >> activity. >> >> Has anyone else seen this? >Same here. Very very slow (I was compiling sendmail, guess why ? :-)) Same here. `du -a /var | wc' accesses the disk every time to stat only 68 files. I suspect revision 1.30 to vfs_bio.c (1995/02/22 09:30:13) broke something. It was supposed to _stop_ the buffers associated with directories and metadata being thrashed by regular i/o. My getnewvnode() stops some of this thrashing (and thrashing of file data) by preferring to reuse vnodes with no attached buffers. Before 1995/02/22, this increased the maximum amount of directory and metadata info by a factor of about 10. I want it to be increased by another factor of 10. Bruce From owner-freebsd-current Fri Feb 24 10:59:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA22521 for current-outgoing; Fri, 24 Feb 1995 10:59:41 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA22515 for ; Fri, 24 Feb 1995 10:59:38 -0800 Received: (dyson@localhost) by Root.COM (8.6.8/8.6.5) id KAA15362; Fri, 24 Feb 1995 10:58:58 -0800 Date: Fri, 24 Feb 1995 10:58:58 -0800 From: John Dyson Message-Id: <199502241858.KAA15362@Root.COM> To: current@FreeBSD.org, starkhome!gene@sbstark.cs.sunysb.edu Subject: Re: Decrease in namei cache effectiveness? Sender: current-owner@FreeBSD.org Precedence: bulk I have noticed it also, others have informed me of the problem. I don't think that DG has commited my fix yet, but see if the problem goes away by removing the first !doingvmio check. I did not manifest the problem until last night (and boy was it irritating). The drives can make a fairly unpleasant sound, can't they?!?! :-). Hopefully, it'll be committed tonite... John From owner-freebsd-current Fri Feb 24 11:54:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA23399 for current-outgoing; Fri, 24 Feb 1995 11:54:13 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id LAA23393 for ; Fri, 24 Feb 1995 11:54:12 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA12573; Fri, 24 Feb 1995 14:53:23 -0500 Date: Fri, 24 Feb 1995 14:53:23 -0500 From: Garrett Wollman Message-Id: <9502241953.AA12573@halloran-eldar.lcs.mit.edu> To: Jim Bryant Cc: FreeBSD-Current Mailing List Subject: FreeBSD-current syscons bug/feature In-Reply-To: <199502241333.HAA06923@server.iadfw.net> References: <199502241333.HAA06923@server.iadfw.net> Sender: current-owner@FreeBSD.org Precedence: bulk < said: > Shouldn't the scrollback on the console only work if there is a valid > login at that particular /dev/ttyv* ? Logout from your console, try the > scrollback, and think for a sec... Among other wierdness in syscons... I don't think so. Oft as not, what I want to see when I use scrollback on my console is some syslog message or kernel printf that just scrolled off the screen... -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Fri Feb 24 13:28:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA24929 for current-outgoing; Fri, 24 Feb 1995 13:28:35 -0800 Received: from one.mind.net (one.mind.net [198.68.24.65]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id NAA24922 for ; Fri, 24 Feb 1995 13:28:31 -0800 Received: from abraxas (abraxas.mind.net [198.68.24.70]) by one.mind.net (8.6.10/8.6.9) with SMTP id NAA24436 for ; Fri, 24 Feb 1995 13:23:42 -0800 Date: Fri, 24 Feb 1995 13:23:42 -0800 Message-Id: <199502242123.NAA24436@one.mind.net> X-Sender: abraxas@mind.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: current@FreeBSD.org From: abraxas@mind.net (heart of the sun) Subject: src dist compile problems Sender: current-owner@FreeBSD.org Precedence: bulk Hello, I am running 2.0.5 which I downloaded and installed about a month ago it seems. I was having some problems getting perl to compile on this so I reasoned perhaps incorrectly that updating the os might help. I mirrored the src tre and installed it in /usr/FreeBSD/src and from that directory, I tried to do a make world. It went a way through this and couldn't find a bunch of things so it stopped. I have the feeling that i am doing something incorrectly. If someone could refer me to some docs that might help me out, that would be great! Thanks, Alan Laird From owner-freebsd-current Fri Feb 24 17:10:17 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA01629 for current-outgoing; Fri, 24 Feb 1995 17:10:17 -0800 Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.97.216]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA01623 for ; Fri, 24 Feb 1995 17:10:16 -0800 Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.6.9/8.6.9) id RAA01001 for freebsd-current@freefall.cdrom.com; Fri, 24 Feb 1995 17:04:57 -0800 From: Steven G Kargl Message-Id: <199502250104.RAA01001@troutmask.apl.washington.edu> Subject: syscon bug? To: freebsd-current@freefall.cdrom.com (FreeBSD Current) Date: Fri, 24 Feb 1995 17:04:54 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 511 Sender: current-owner@FreeBSD.org Precedence: bulk % vidcontrol -s help available screen saver type: getting screen saver info: Inappropriate ioctl for device I can not set a screen saver for syscon. I have sources supped this morning at 0900 PST 950224. A new kernel was build a short time later. -- Steven G. Kargl | Phone: 206-685-4677 | Applied Physics Laboratory | Fax: 206-543-6785 | University of Washington |---------------------| 1013 NE 40th St | FreeBSD 2.1-current | Seattle, WA 98105 |---------------------| From owner-freebsd-current Fri Feb 24 18:10:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA03197 for current-outgoing; Fri, 24 Feb 1995 18:10:30 -0800 Received: from venere.inet.it (root@venere.inet.it [194.20.8.4]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA03186 for ; Fri, 24 Feb 1995 18:10:23 -0800 Received: from piero.inet.it (uupiero@localhost) by venere.inet.it (8.6.9/8.6.9) with UUCP id DAA100036; Sat, 25 Feb 1995 03:00:49 +0100 Received: (from piero@localhost) by piero.inet.it (8.6.9/8.6.9) id CAA01200; Sat, 25 Feb 1995 02:10:04 +0100 From: Piero Serini Message-Id: <199502250110.CAA01200@piero.inet.it> Subject: Re: help To: diamond@netcom.com (diamond) Date: Sat, 25 Feb 1995 02:10:03 +0100 (MET) Cc: current@FreeBSD.org In-Reply-To: <199502231739.JAA07434@netcom15.netcom.com> from "diamond" at Feb 23, 95 09:39:59 am Reply-To: Piero@piero.inet.it Operating-System: FreeBSD 1.1.5.1 X-Phone-Number: +39 (2) 89405894 X-Faqs-Maintained: Elm (comp.mail.elm), Mail Archive Servers (comp.mail.misc) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 409 Sender: current-owner@FreeBSD.org Precedence: bulk Hello. Quoting from diamond (Thu Feb 23 18:39:40 1995): > > help > This is not a daemon. Real people here :) Bye, -- # $Id: .signature,v 1.10 1995/02/05 17:34:46 piero Exp $ Piero Serini Via Giambologna, 1 TEMP: I 20136 Milano - ITALY AKA: - But this address is suspended for a while From owner-freebsd-current Fri Feb 24 20:41:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id UAA05953 for current-outgoing; Fri, 24 Feb 1995 20:41:54 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id UAA05947 for ; Fri, 24 Feb 1995 20:41:52 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id UAA16372 for current@freebsd.org; Fri, 24 Feb 1995 20:41:16 -0800 From: Poul-Henning Kamp Message-Id: <199502250441.UAA16372@ref.tfs.com> Subject: lfs ? To: current@FreeBSD.org Date: Fri, 24 Feb 1995 20:41:16 -0800 (PST) Content-Type: text Content-Length: 215 Sender: current-owner@FreeBSD.org Precedence: bulk Is it still the case that having more than one LFS on a machine is stupid ? -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Fri Feb 24 21:22:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id VAA06529 for current-outgoing; Fri, 24 Feb 1995 21:22:49 -0800 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id VAA06523 for ; Fri, 24 Feb 1995 21:22:48 -0800 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.9/8.6.9) with SMTP id VAA02279; Fri, 24 Feb 1995 21:22:12 -0800 Message-Id: <199502250522.VAA02279@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Poul-Henning Kamp cc: current@FreeBSD.org Subject: Re: lfs ? In-reply-to: Your message of "Fri, 24 Feb 1995 20:41:16 PST." <199502250441.UAA16372@ref.tfs.com> Date: Fri, 24 Feb 1995 21:22:11 -0800 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk >Is it still the case that having more than one LFS on a machine is stupid ? >-- >Poul-Henning Kamp >TRW Financial Systems, Inc. >I am Pentium Of Borg. Division is Futile. You WILL be approximated. Having even one LFS on a system (other than 2.0R) is stupid. Once LFS is reintegrated into current, having more than one will be possible. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ============================================== From owner-freebsd-current Sat Feb 25 08:01:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA04935 for current-outgoing; Sat, 25 Feb 1995 08:01:56 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA04909 for ; Sat, 25 Feb 1995 08:01:41 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA25189 for current@freebsd.org; Sun, 26 Feb 1995 02:56:34 +1100 Date: Sun, 26 Feb 1995 02:56:34 +1100 From: Bruce Evans Message-Id: <199502251556.CAA25189@godzilla.zeta.org.au> To: current@FreeBSD.org Subject: getcwd hack Sender: current-owner@FreeBSD.org Precedence: bulk realpath() calls getcwd() to do most of the work and assumes that getcwd() returns a canonical path. Bruce From owner-freebsd-current Sat Feb 25 08:33:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA08526 for current-outgoing; Sat, 25 Feb 1995 08:33:40 -0800 Received: from prosun.first.gmd.de (prosun.first.gmd.de [192.35.150.136]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id IAA08509 for ; Sat, 25 Feb 1995 08:33:37 -0800 Received: from g386bsd.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1) id AA09863; Sat, 25 Feb 95 16:32:31 +0100 Received: by g386bsd.first.gmd.de (QAA11827); Sat, 25 Feb 1995 16:34:29 +0100 From: Andreas Schulz Message-Id: <199502251534.QAA11827@g386bsd.first.gmd.de> Subject: Re: src dist compile problems To: abraxas@mind.net (heart of the sun) Date: Sat, 25 Feb 1995 16:34:28 +0059 (MET) Cc: current@FreeBSD.org In-Reply-To: <199502242123.NAA24436@one.mind.net> from "heart of the sun" at Feb 24, 95 01:23:42 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 905 Sender: current-owner@FreeBSD.org Precedence: bulk > I am running 2.0.5 which I downloaded and installed about a month ago it > seems. I was having some problems getting perl to compile on this so I > reasoned perhaps incorrectly that updating the os might help. I mirrored > the src tre and installed it in /usr/FreeBSD/src and from that directory, I > tried to do a make world. It went a way through this and couldn't find a > bunch of things so it stopped. I have the feeling that i am doing something > incorrectly. If someone could refer me to some docs that might help me out, > that would be great! The src tree expects to be under /usr/src, so better move your old tree under some other name and put the new tree with a symlink to /usr/src. ATS ( ats@first.gmd.de or ats@cs.tu-berlin.de ) Andreas Schulz GMD-FIRST 12489 Berlin-Adlershof Rudower Chaussee 5 Gebaeude 13.7 Tel: +49-30-6392-1856/+49-177-2134745 Germany/Europe From owner-freebsd-current Sat Feb 25 08:46:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA09957 for current-outgoing; Sat, 25 Feb 1995 08:46:12 -0800 Received: from mail.rwth-aachen.de (mail.RWTH-Aachen.DE [137.226.144.9]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA09940 for ; Sat, 25 Feb 1995 08:46:07 -0800 Received: from gilberto.physik.rwth-aachen.de by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HNH41NEP40001FNL@mail.rwth-aachen.de>; Sat, 25 Feb 1995 17:46:30 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.8/8.6.9) id RAA23746 for freebsd-current@freefall.cdrom.com; Sat, 25 Feb 1995 17:52:10 +0100 Date: Sat, 25 Feb 1995 17:52:10 +0100 From: "Christoph P. Kukulies" Subject: swap_pager I/O error To: freebsd-current@freefall.cdrom.com Message-id: <199502251652.RAA23746@gilberto.physik.rwth-aachen.de> Content-transfer-encoding: 7BIT Sender: current-owner@FreeBSD.org Precedence: bulk While my -current system (kernel may be a few days old) was quite busy making world I copied some files to a msdos mounted filesystem (floppy) and right in the moment I unmounted it again I got the following: blues# I/O to empty block???? swap_pager: I/O error - async pageout failed; blkno 22, size -1, error 4096swap_pager_finish: I/O error, clean of page faf000 failed blues# --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de FreeBSD blues 2.1.0-Development FreeBSD 2.1.0-Development #0: Fri Feb 17 18:32:16 1995 root@blues:/usr/src/sys/compile/BLUES i386 From owner-freebsd-current Sat Feb 25 09:20:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA14634 for current-outgoing; Sat, 25 Feb 1995 09:20:04 -0800 Received: from python.bostic.com (python.BOSTIC.COM [198.3.132.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id JAA14603 for ; Sat, 25 Feb 1995 09:19:57 -0800 Received: by python.bostic.com (8.6.9.Beta4/2.6) id MAA23512; Sat, 25 Feb 1995 12:19:59 -0500 Date: Sat, 25 Feb 1995 12:19:59 -0500 From: bostic@CS.Berkeley.EDU (Keith Bostic) Message-Id: <199502251719.MAA23512@python.bostic.com> To: current@FreeBSD.org Subject: Re: getcwd hack Cc: bde@zeta.org.au, cgd@CS.CMU.EDU, davidg@Root.COM, jsp@sequent.com Sender: current-owner@FreeBSD.org Precedence: bulk > From: Bruce Evans > To: current@FreeBSD.org > Subject: getcwd hack > > realpath() calls getcwd() to do most of the work and assumes that getcwd() > returns a canonical path. Yes. Jan-Simon Pendry (jsp@sequent.com) integrated realpath() and getcwd() in order to make this work correctly. I'm sure he can send you a copy of the work if you like. --keith From owner-freebsd-current Sat Feb 25 12:00:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA25836 for current-outgoing; Sat, 25 Feb 1995 12:00:32 -0800 Received: (from pst@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA25818; Sat, 25 Feb 1995 12:00:29 -0800 Date: Sat, 25 Feb 1995 12:00:29 -0800 From: Paul Traina Message-Id: <199502252000.MAA25818@freefall.cdrom.com> To: phk Subject: daily compile of LINT kernel Cc: current Sender: current-owner@FreeBSD.org Precedence: bulk I just waded through a bunch of compile problems on the LINT kernel because folks aren't testing their changes before comitting them. I'd like to suggest a daily compilation of the LINT kernel occur on THUD so that we can catch these bugs right away. Paul From owner-freebsd-current Sat Feb 25 12:20:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA28861 for current-outgoing; Sat, 25 Feb 1995 12:20:43 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA28845; Sat, 25 Feb 1995 12:20:32 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.9/8.6.9) with SMTP id MAA29932; Sat, 25 Feb 1995 12:19:07 -0800 Message-Id: <199502252019.MAA29932@precipice.Shockwave.COM> To: current@FreeBSD.org cc: committers@FreeBSD.org Subject: generic kernels broken again... :-( Date: Sat, 25 Feb 1995 12:19:07 -0800 From: Paul Traina Sender: current-owner@FreeBSD.org Precedence: bulk loading kernel autoconf.o: Undefined symbol `_setconf' referenced from text segment *** Error code 1 Stop. This is compiling based upon our current "GENERIC" config file. From owner-freebsd-current Sat Feb 25 12:25:24 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA29398 for current-outgoing; Sat, 25 Feb 1995 12:25:24 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA29380; Sat, 25 Feb 1995 12:25:17 -0800 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id MAA18926; Sat, 25 Feb 1995 12:24:37 -0800 From: Poul-Henning Kamp Message-Id: <199502252024.MAA18926@ref.tfs.com> Subject: Re: generic kernels broken again... :-( To: pst@shockwave.com (Paul Traina) Date: Sat, 25 Feb 1995 12:24:37 -0800 (PST) Cc: current@FreeBSD.org, committers@FreeBSD.org In-Reply-To: <199502252019.MAA29932@precipice.Shockwave.COM> from "Paul Traina" at Feb 25, 95 12:19:07 pm Content-Type: text Content-Length: 287 Sender: current-owner@FreeBSD.org Precedence: bulk > loading kernel > autoconf.o: Undefined symbol `_setconf' referenced from text segment > *** Error code 1 > I belive you have to remake "config" -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Sat Feb 25 12:30:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA29658 for current-outgoing; Sat, 25 Feb 1995 12:30:20 -0800 Received: from precipice.Shockwave.COM (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id MAA29648; Sat, 25 Feb 1995 12:30:12 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.Shockwave.COM (8.6.9/8.6.9) with SMTP id MAA00142; Sat, 25 Feb 1995 12:28:15 -0800 Message-Id: <199502252028.MAA00142@precipice.Shockwave.COM> To: Poul-Henning Kamp cc: current@FreeBSD.org, committers@FreeBSD.org Subject: Re: generic kernels broken again... :-( In-reply-to: Your message of "Sat, 25 Feb 1995 12:24:37 PST." <199502252024.MAA18926@ref.tfs.com> Date: Sat, 25 Feb 1995 12:28:15 -0800 From: Paul Traina Sender: current-owner@FreeBSD.org Precedence: bulk ah, serves me right for compiling on freefall instead of thud, thank you. From: Poul-Henning Kamp Subject: Re: generic kernels broken again... :-( > loading kernel > autoconf.o: Undefined symbol `_setconf' referenced from text segment > *** Error code 1 > I belive you have to remake "config" -- Poul-Henning Kamp TRW Financial Systems, Inc. I am Pentium Of Borg. Division is Futile. You WILL be approximated. From owner-freebsd-current Sat Feb 25 15:32:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id PAA09358 for current-outgoing; Sat, 25 Feb 1995 15:32:29 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id PAA09350 for ; Sat, 25 Feb 1995 15:32:27 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.10/jtpda-5.0) with SMTP id AAA01655 ; Sun, 26 Feb 1995 00:30:39 +0100 Received: by blaise.ibp.fr (4.1/SMI-4.1) id AA09396; Sun, 26 Feb 95 00:30:38 +0100 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <9502252330.AA09396@blaise.ibp.fr> Subject: Re: Decrease in namei cache effectiveness? To: bde@zeta.org.au (Bruce Evans) Date: Sun, 26 Feb 1995 00:30:37 +0100 (MET) Cc: starkhome!gene@sbstark.cs.sunysb.edu, current@FreeBSD.org In-Reply-To: <199502241839.FAA02024@godzilla.zeta.org.au> from "Bruce Evans" at Feb 25, 95 05:39:45 am X-Operating-System: FreeBSD 2.1.0-Development ctm#375 X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 570 Sender: current-owner@FreeBSD.org Precedence: bulk > by preferring to reuse vnodes with no attached buffers. Before > 1995/02/22, this increased the maximum amount of directory and metadata > info by a factor of about 10. I want it to be increased by another > factor of 10. John's last commit to vfs_bio.c restored part of the old behaviour but not all. Even with 20 MB RAM I keep on seeing the disk going berseck during stats. Less often than before but its still there. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD keltia 2.1.0-Development #9: Sat Feb 18 19:21:00 MET 1995 From owner-freebsd-current Sat Feb 25 16:55:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA14625 for current-outgoing; Sat, 25 Feb 1995 16:55:02 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA14614; Sat, 25 Feb 1995 16:54:59 -0800 Received: from jsdinc.root.com (uucp@localhost) by Root.COM (8.6.8/8.6.5) with UUCP id QAA17508; Sat, 25 Feb 1995 16:54:14 -0800 Received: (root@localhost) by jsdinc (8.6.9/8.6.5) id TAA05560; Sat, 25 Feb 1995 19:04:34 -0500 From: "John S. Dyson" Message-Id: <199502260004.TAA05560@jsdinc> Subject: Re: Decrease in namei cache effectiveness? To: freefall.cdrom.com!owner-freebsd-current@implode.root.com (Ollivier Robert) Date: Sat, 25 Feb 1995 19:04:34 -0500 (EST) Cc: bde@zeta.org.au, starkhome!gene@sbstark.cs.sunysb.edu, current@FreeBSD.org In-Reply-To: <9502252330.AA09396@blaise.ibp.fr> from "Ollivier Robert" at Feb 26, 95 00:30:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 515 Sender: current-owner@FreeBSD.org Precedence: bulk > > John's last commit to vfs_bio.c restored part of the old behaviour but > not all. Even with 20 MB RAM I keep on seeing the disk going berseck > during stats. Less often than before but its still there. > Part of what I am doing tonite is integrating/testing Bruce's vnode change, and making an equivalent change to the object management. Hope that these changes will help. Also, I might change the threshold for the amount of meta-data storage allowed in vfs_bio. I'm working on it!!! John dyson@root.com