From owner-freebsd-arch Mon May 27 22: 4:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 9F64937B406 for ; Mon, 27 May 2002 22:04:47 -0700 (PDT) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id BEDEF81430; Tue, 28 May 2002 14:34:44 +0930 (CST) Date: Tue, 28 May 2002 14:34:44 +0930 From: Greg 'groggy' Lehey To: FreeBSD-arch@FreeBSD.org Subject: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020528143444.R16567@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've just had a question from some friends in the Linux space about why we install additional libraries in /usr/local/lib and their header files in /usr/local/include, but gcc by default only searches /usr/local/libexec and /usr/local/lib for libraries and /usr/include for header files. They think that this is inconsistent, and I tend to agree. What speaks against adding the /usr/local directories to the specs files for gcc? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 27 22:15:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 6AEDE37B403; Mon, 27 May 2002 22:15:38 -0700 (PDT) Received: from pool0419.cvx22-bradley.dialup.earthlink.net ([209.179.199.164] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17CZKb-0007Hw-00; Mon, 27 May 2002 22:15:37 -0700 Message-ID: <3CF3124D.8E98E9C@mindspring.com> Date: Mon, 27 May 2002 22:14:53 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg 'groggy' Lehey Cc: FreeBSD-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? References: <20020528143444.R16567@wantadilla.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg 'groggy' Lehey wrote: > I've just had a question from some friends in the Linux space about > why we install additional libraries in /usr/local/lib and their header > files in /usr/local/include, but gcc by default only searches > /usr/local/libexec and /usr/local/lib for libraries and /usr/include > for header files. They think that this is inconsistent, and I tend to > agree. What speaks against adding the /usr/local directories to the > specs files for gcc? The fact that ldconfig is assinine, and prevents loading the shared libraries at runtime, even if they are found at link time, for one, because ld.so doesn't fall back to searching known directories, if it fails to find libraries in cache, unless you set LD_LIBRARY_PATH explicitly. Or in shorting terms: "Doing that doesn't actually work". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 27 22:16:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 4FA1737B407; Mon, 27 May 2002 22:16:41 -0700 (PDT) Received: from pool0419.cvx22-bradley.dialup.earthlink.net ([209.179.199.164] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17CZLb-0000Fb-00; Mon, 27 May 2002 22:16:41 -0700 Message-ID: <3CF3128C.F686A139@mindspring.com> Date: Mon, 27 May 2002 22:15:56 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg 'groggy' Lehey , FreeBSD-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? References: <20020528143444.R16567@wantadilla.lemis.com> <3CF3124D.8E98E9C@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Or in shorter terms: "Doing that doesn't actually work". Ignore everything but this part; I thought it was a -chat posting. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 7: 7:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail1.qc.uunet.ca (mail1.qc.uunet.ca [198.168.54.16]) by hub.freebsd.org (Postfix) with ESMTP id A9F3637B403; Tue, 28 May 2002 07:07:45 -0700 (PDT) Received: from Xtanbul ([216.94.147.34]) by mail1.qc.uunet.ca (8.10.2/8.10.2) with ESMTP id g4SE7dN23618; Tue, 28 May 2002 10:07:40 -0400 Date: Tue, 28 May 2002 09:59:38 -0400 Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Greg 'groggy' Lehey" , FreeBSD-arch@FreeBSD.org To: Terry Lambert From: Antoine Beaupre In-Reply-To: <3CF3128C.F686A139@mindspring.com> Message-Id: <26911A2E-7243-11D6-93A2-0050E4A0BB3F@anarcat.ath.cx> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.481) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG We could still make the ports system try to use libraries in=20 /usr/local/lib too by default since most third party apps have=20 dependencies on other third-party apps. The way I usually do it is: CONFIGURE_ENV+=3D CPPFLAGS=3D"-I${LOCALBASE}/include" \ LDFLAGS=3D"-L${LOCALBASE}/lib" \ CFLAGS=3D"-I${LOCALBASE}/include ${CFLAGS}" \ CXXFLAGS=3D"-I${LOCALBASE}/include ${CXXFLAGS}" or something like that. I think a lot of ports have something like that=20= in there somewhere. A. Le mardi 28 mai 2002, =E0 01:15 AM, Terry Lambert a =E9crit : > Terry Lambert wrote: >> Or in shorter terms: "Doing that doesn't actually work". > > Ignore everything but this part; I thought it was a -chat posting. > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 8:42:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id BC6ED37B401; Tue, 28 May 2002 08:42:53 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g4SFgmJn059638; Tue, 28 May 2002 08:42:48 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g4SFgmbe059637; Tue, 28 May 2002 08:42:48 -0700 (PDT) Date: Tue, 28 May 2002 08:42:48 -0700 From: "David O'Brien" To: "Greg 'groggy' Lehey" Cc: FreeBSD-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020528084248.B59588@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.org References: <20020528143444.R16567@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020528143444.R16567@wantadilla.lemis.com>; from grog@FreeBSD.org on Tue, May 28, 2002 at 02:34:44PM +0930 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote: > I've just had a question from some friends in the Linux space about > why we install additional libraries in /usr/local/lib and their header > files in /usr/local/include, but gcc by default only searches > /usr/local/libexec and /usr/local/lib for libraries and /usr/include The system GCC searching any part of /usr/local is a bug. It is not [ports] PREFIX clean. (you have typos above about /usr/local/libexec don't you?) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 10:29:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from evilpete.dyndns.org (12-232-26-46.client.attbi.com [12.232.26.46]) by hub.freebsd.org (Postfix) with ESMTP id B0C6F37B403; Tue, 28 May 2002 10:29:21 -0700 (PDT) Received: from overcee.wemm.org ([10.0.0.3]) by evilpete.dyndns.org (8.11.6/8.11.6) with ESMTP id g4SHTL159941; Tue, 28 May 2002 10:29:21 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 2EBB6380A; Tue, 28 May 2002 10:29:21 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Greg 'groggy' Lehey" Cc: FreeBSD-arch@FreeBSD.ORG Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? In-Reply-To: <20020528143444.R16567@wantadilla.lemis.com> Date: Tue, 28 May 2002 10:29:21 -0700 From: Peter Wemm Message-Id: <20020528172921.2EBB6380A@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Greg 'groggy' Lehey" wrote: > I've just had a question from some friends in the Linux space about > why we install additional libraries in /usr/local/lib and their header > files in /usr/local/include, but gcc by default only searches > /usr/local/libexec and /usr/local/lib for libraries and /usr/include > for header files. They think that this is inconsistent, and I tend to > agree. What speaks against adding the /usr/local directories to the > specs files for gcc? gcc and ld do not look at /usr/local at all. We set /usr/local/lib in the ld-elf.so.1 search path, but ld-elf.so.1 != ld. ld actually looks for *.a and *.so, while ld-elf.so.1 looks for *.so.* We have folks who have ports elsewhere than /usr/local. Eg: when /usr/local is NFS shared from a netapp or something. If ports depend on gcc assuming that ports are in /usr/local, then they stop working when they are put elsewhere (/opt, /home/local, whatever) since they'd suddenly need to explicitly add -I and -L paths. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 12:18:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id C704837B403; Tue, 28 May 2002 12:18:47 -0700 (PDT) Received: from pool0281.cvx40-bradley.dialup.earthlink.net ([216.244.43.26] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17CmUY-0002Ad-00; Tue, 28 May 2002 12:18:47 -0700 Message-ID: <3CF3D7F7.20A30ACF@mindspring.com> Date: Tue, 28 May 2002 12:18:15 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Cc: Greg 'groggy' Lehey Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? References: <20020528143444.R16567@wantadilla.lemis.com> <20020528084248.B59588@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote: > > I've just had a question from some friends in the Linux space about > > why we install additional libraries in /usr/local/lib and their header > > files in /usr/local/include, but gcc by default only searches > > /usr/local/libexec and /usr/local/lib for libraries and /usr/include > > The system GCC searching any part of /usr/local is a bug. It is not > [ports] PREFIX clean. (you have typos above about /usr/local/libexec > don't you?) Potentialy, the ports .mk files, when they observe PREFIX, should reset the entire include and library path, so this really should not be an issue. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 12:31:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 1CC9337B405; Tue, 28 May 2002 12:31:44 -0700 (PDT) Received: from pool0281.cvx40-bradley.dialup.earthlink.net ([216.244.43.26] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17Cmh0-0004wR-00; Tue, 28 May 2002 12:31:38 -0700 Message-ID: <3CF3DAFB.7C9C5108@mindspring.com> Date: Tue, 28 May 2002 12:31:07 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Antoine Beaupre Cc: Greg 'groggy' Lehey , FreeBSD-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? References: <26911A2E-7243-11D6-93A2-0050E4A0BB3F@anarcat.ath.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Antoine Beaupre wrote: > We could still make the ports system try to use libraries in > /usr/local/lib too by default since most third party apps have > dependencies on other third-party apps. > > The way I usually do it is: > > CONFIGURE_ENV+= CPPFLAGS="-I${LOCALBASE}/include" \ > LDFLAGS="-L${LOCALBASE}/lib" \ > CFLAGS="-I${LOCALBASE}/include ${CFLAGS}" \ > CXXFLAGS="-I${LOCALBASE}/include ${CXXFLAGS}" > > or something like that. I think a lot of ports have something like that > in there somewhere. The resulting binaries still do not work, unless LD_LIBRARY_PATH is set, or there is an intervening run of "ldconfig". They fail to find shared libraries at runtime, installed after boot but before link (the libraries are found at link time, just not at runtime). It seems to me that either the ld should fail to find the libraries at link time if it's not going to find them at runtime, or it should find them at runtime if it found them at link time. But ldconfig is more than it should be... it's more of a csh "rehash" of the path hash, when it should probably be a tcsh "rehash": search the hash first, and on failure, search the PATH (adding to the hash automatically on a success would be the wrong thing to do, but finding it would not be). It's really annoying to have one algorithm for linking and another for running. I don't really understand the value of this assymetry; I guess it's intended to allow you to build without properly installing libraries on the build system. In practice, however, it is never really done this way in "ports" or other places, or the packages builds would not have to take place on virtually "clean" systems in order to ensure that a dependency is not missed. I put this one down to the lack of care taken in preparation of ports, to ensure that paths are limited on install and build, so that it should be possible to use a different PREFIX per port, and build simultaneously, without it "finding" things it shouldn't. If *that* were possible, then automatically finding headers and libraries in /usr/local during the build would *definitely* be the wrong thing to do: the local system would effect the dependency satisfaction of a package build when it shouldn't. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 13:31:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail2.qc.uunet.ca (mail2.qc.uunet.ca [198.168.54.17]) by hub.freebsd.org (Postfix) with ESMTP id DAF5537B401; Tue, 28 May 2002 13:31:41 -0700 (PDT) Received: from Xtanbul ([216.94.147.34]) by mail2.qc.uunet.ca (8.9.3/8.9.3) with ESMTP id QAA22453; Tue, 28 May 2002 16:31:34 -0400 Date: Tue, 28 May 2002 16:23:39 -0400 Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Greg 'groggy' Lehey" , FreeBSD-arch@FreeBSD.org To: Terry Lambert From: Antoine Beaupre In-Reply-To: <3CF3DAFB.7C9C5108@mindspring.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.481) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Le mardi 28 mai 2002, =E0 03:31 PM, Terry Lambert a =E9crit : > Antoine Beaupre wrote: >> We could still make the ports system try to use libraries in >> /usr/local/lib too by default since most third party apps have >> dependencies on other third-party apps. >> >> The way I usually do it is: >> >> CONFIGURE_ENV+=3D CPPFLAGS=3D"-I${LOCALBASE}/include" \ >> LDFLAGS=3D"-L${LOCALBASE}/lib" \ >> CFLAGS=3D"-I${LOCALBASE}/include ${CFLAGS}" \ >> CXXFLAGS=3D"-I${LOCALBASE}/include ${CXXFLAGS}" >> >> or something like that. I think a lot of ports have something like = that >> in there somewhere. > > The resulting binaries still do not work, unless LD_LIBRARY_PATH > is set, or there is an intervening run of "ldconfig". They fail > to find shared libraries at runtime, installed after boot but > before link (the libraries are found at link time, just not at > runtime). Well right now this does work because (I think) ldconfig *is* ran by=20 pkg_add (or make install) when installing the port, if it contains=20 shared libs. I'm not sure I agree that searching /usr/local by default is violating=20= PREFIX anymore, since /usr/local is usually our default prefix=20 (exception made of X) for ports. The initial problem is that we have 4 PREFIXes in common installs: /,=20 /usr, /usr/local and /usr/X11R6. How is a port supposed to find a=20 dependent package in there? How can it pretend to be PREFIX-independant=20= when the ports depending on it can be installed in one of these 4=20 different PREFIXes? /usr/local is an interesting abstraction. It allows us to distinguish=20 base from ports, but it's basically a hack. We have "ports" (sendmail,=20= openssh) in base, which blurs this line (and creates periodic threads on=20= various mailing lists). Ideally, we should be able to have all of our=20 software cleanly packaged, base would only be "software packages written=20= and/or maintained by FreeBSD", and would be a simple flag in the = package. Ideally, /usr/local should go away. Packages should install in /usr by=20= default. But the ports system would need a bigger fence around it to=20 expose /usr this way, IMHO. Unfortunatly, we're stuck with /usr/local, and I think that as soon as a=20= port depends on another *port* its linking search path should be hacked=20= to include the prefix of that dependent port. No, I don't have any patches. ;) A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 17: 0:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4066237B407 for ; Tue, 28 May 2002 17:00:17 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA35144; Tue, 28 May 2002 16:50:06 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4SNnHu88712; Tue, 28 May 2002 16:49:17 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205282349.g4SNnHu88712@arch20m.dellroad.org> Subject: Kernel stack overflow detection? To: freebsd-arch@freebsd.org Date: Tue, 28 May 2002 16:49:17 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, Got a question and a proposal... I'm trying to track down a mysterious bug and one possible theory is a kernel stack overflow (I've bloated the kernel with a bunch of custom code). This is in FreeBSD-stable. The question is: does INVARIANTS do anything to detect this? If not, what would be the "expected" behavior of such a bug? If INVARIANTS doesn't do so already, I'd like to propose to write up an INVARIANTS check that would validate that the kernel stack has not overflowed. However I'm curious if anyone has done this already and/or what the right way to go about it would be. E.g, add an extra stack page with read-only protection? Any hints appreciated. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 17: 0:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id EACDD37B408 for ; Tue, 28 May 2002 17:00:10 -0700 (PDT) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 213B181430; Wed, 29 May 2002 09:30:09 +0930 (CST) Date: Wed, 29 May 2002 09:30:09 +0930 From: Greg 'groggy' Lehey To: freebsd-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020529093009.C31668@wantadilla.lemis.com> References: <20020528143444.R16567@wantadilla.lemis.com> <20020528084248.B59588@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020528084248.B59588@dragon.nuxi.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 28 May 2002 at 8:42:48 -0700, David O'Brien wrote: > On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote: >> I've just had a question from some friends in the Linux space about >> why we install additional libraries in /usr/local/lib and their header >> files in /usr/local/include, but gcc by default only searches >> /usr/local/libexec and /usr/local/lib for libraries and /usr/include > > The system GCC searching any part of /usr/local is a bug. It is not > [ports] PREFIX clean. So how would you recommend we solve the issue? > (you have typos above about /usr/local/libexec don't you?) Yes, sorry. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 18: 4:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id BF86B37B405; Tue, 28 May 2002 18:04:35 -0700 (PDT) Received: from pool0456.cvx40-bradley.dialup.earthlink.net ([216.244.43.201] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17CrtC-0001cP-00; Tue, 28 May 2002 18:04:34 -0700 Message-ID: <3CF42902.70A697C8@mindspring.com> Date: Tue, 28 May 2002 18:04:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg 'groggy' Lehey Cc: freebsd-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? References: <20020528143444.R16567@wantadilla.lemis.com> <20020528084248.B59588@dragon.nuxi.com> <20020529093009.C31668@wantadilla.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg 'groggy' Lehey wrote: > > The system GCC searching any part of /usr/local is a bug. It is not > > [ports] PREFIX clean. > > So how would you recommend we solve the issue? I hesitate to mention this. But there are two obvious ways: 1) Add the expectation paths for things to the default, and if someone puts the libraries or headers in a non-default place, it's their responsibility. This would also require changing the ldconfig cache to be "hints", rather than "the only path". 2) Make the compiler use the ldconfig cache path prefixes; then everything would "just work". #2 is harder. I also don't think it's what you really want. The Linux people who are complaining are probably also complaining about including one include file not including all include files, and the lack of a /usr/include/linux/. PS: I put number 2 last on purpose because I really don't like it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 18:25:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from evilpete.dyndns.org (12-232-26-46.client.attbi.com [12.232.26.46]) by hub.freebsd.org (Postfix) with ESMTP id B660A37B40A; Tue, 28 May 2002 18:25:49 -0700 (PDT) Received: from overcee.wemm.org ([10.0.0.3]) by evilpete.dyndns.org (8.11.6/8.11.6) with ESMTP id g4T1Pn161613; Tue, 28 May 2002 18:25:49 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 14816380A; Tue, 28 May 2002 18:25:44 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Greg 'groggy' Lehey" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? In-Reply-To: <20020529093009.C31668@wantadilla.lemis.com> Date: Tue, 28 May 2002 18:25:44 -0700 From: Peter Wemm Message-Id: <20020529012544.14816380A@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Greg 'groggy' Lehey" wrote: > On Tuesday, 28 May 2002 at 8:42:48 -0700, David O'Brien wrote: > > On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote: > >> I've just had a question from some friends in the Linux space about > >> why we install additional libraries in /usr/local/lib and their header > >> files in /usr/local/include, but gcc by default only searches > >> /usr/local/libexec and /usr/local/lib for libraries and /usr/include > > > > The system GCC searching any part of /usr/local is a bug. It is not > > [ports] PREFIX clean. > > So how would you recommend we solve the issue? Err, what issue? gcc does not search /usr/local anywhere. peter@daintree[6:22pm]/tmp-106> ls -l /usr/local/include/jerror.h -r--r--r-- 1 root wheel 13936 May 28 16:52 /usr/local/include/jerror.h peter@daintree[6:22pm]/tmp-107> cc -c foo.c foo.c:1:20: jerror.h: No such file or directory peter@daintree[6:22pm]/tmp-108> grep jerror foo.c #include and eter@daintree[6:23pm]/tmp-113> ls -l /usr/local/lib | grep libxml -rw-r--r-- 1 root wheel 523838 Apr 17 04:23 libxml.a lrwxr-xr-x 1 root wheel 11 May 21 19:08 libxml.so@ -> libxml.so.5 -rwxr-xr-x 1 root wheel 495202 Apr 17 04:23 libxml.so.5* peter@daintree[6:23pm]/tmp-114> cc -o foo foo.c -lxml /usr/libexec/elf/ld: cannot find -lxml Yes, /usr/local/lib is on my ldconfig path. peter@daintree[6:24pm]/tmp-120> ldconfig -r | head -2 /var/run/ld-elf.so.hints: search directories: /usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib This is working exactly as designed. Your email suggests you found a bug in the implementation of this.. Or are you complaining about the design itself? > > (you have typos above about /usr/local/libexec don't you?) > > Yes, sorry. > > Greg Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 19: 3: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 2453B37B403 for ; Tue, 28 May 2002 19:02:55 -0700 (PDT) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g4T2ICk27787; Tue, 28 May 2002 22:18:13 -0400 (EDT) (envelope-from jake) Date: Tue, 28 May 2002 22:18:12 -0400 From: Jake Burkholder To: Archie Cobbs Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Kernel stack overflow detection? Message-ID: <20020528221812.O62759@locore.ca> References: <200205282349.g4SNnHu88712@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205282349.g4SNnHu88712@arch20m.dellroad.org>; from archie@dellroad.org on Tue, May 28, 2002 at 04:49:17PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Tue, May 28, 2002 at 04:49:17PM -0700, Archie Cobbs said words to the effect of; > Hi, > > Got a question and a proposal... I'm trying to track down a mysterious > bug and one possible theory is a kernel stack overflow (I've bloated > the kernel with a bunch of custom code). This is in FreeBSD-stable. > > The question is: does INVARIANTS do anything to detect this? If not, > what would be the "expected" behavior of such a bug? > > If INVARIANTS doesn't do so already, I'd like to propose to write > up an INVARIANTS check that would validate that the kernel stack > has not overflowed. However I'm curious if anyone has done this > already and/or what the right way to go about it would be. E.g, add > an extra stack page with read-only protection? Any hints appreciated. -current has a guard page, -stable does not. Also, in -current the u. area and the pcb were moved so the kernel stack grows away from them, instead of towards. Either of these changes should be relatively easy to back port. Note that on x86 a page fault due a stack overflow will cause a double fault; the double fault handler uses a task gate which does a hardware context switch to get off of the bad stack. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 19:53:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 85EDE37B401 for ; Tue, 28 May 2002 19:53:29 -0700 (PDT) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 863D781467; Wed, 29 May 2002 12:23:27 +0930 (CST) Date: Wed, 29 May 2002 12:23:27 +0930 From: Greg 'groggy' Lehey To: Peter Wemm Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020529122327.C82424@wantadilla.lemis.com> References: <20020529093009.C31668@wantadilla.lemis.com> <20020529012544.14816380A@overcee.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020529012544.14816380A@overcee.wemm.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 28 May 2002 at 18:25:44 -0700, Peter Wemm wrote: > "Greg 'groggy' Lehey" wrote: >> On Tuesday, 28 May 2002 at 8:42:48 -0700, David O'Brien wrote: >>> On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote: >>>> I've just had a question from some friends in the Linux space about >>>> why we install additional libraries in /usr/local/lib and their header >>>> files in /usr/local/include, but gcc by default only searches >>>> /usr/local/libexec and /usr/local/lib for libraries and /usr/include >>> >>> The system GCC searching any part of /usr/local is a bug. It is not >>> [ports] PREFIX clean. >> >> So how would you recommend we solve the issue? > > Err, what issue? gcc does not search /usr/local anywhere. Correct. As obrien observed, I mean to say > gcc by default only searches /usr/libexec and /usr/lib for > libraries... >>> The system GCC searching any part of /usr/local is a bug. It is not >>> [ports] PREFIX clean. > > peter@daintree[6:22pm]/tmp-106> ls -l /usr/local/include/jerror.h > -r--r--r-- 1 root wheel 13936 May 28 16:52 /usr/local/include/jerror.h > peter@daintree[6:22pm]/tmp-107> cc -c foo.c > foo.c:1:20: jerror.h: No such file or directory > peter@daintree[6:22pm]/tmp-108> grep jerror foo.c > #include > > and > > eter@daintree[6:23pm]/tmp-113> ls -l /usr/local/lib | grep libxml > -rw-r--r-- 1 root wheel 523838 Apr 17 04:23 libxml.a > lrwxr-xr-x 1 root wheel 11 May 21 19:08 libxml.so@ -> libxml.so.5 > -rwxr-xr-x 1 root wheel 495202 Apr 17 04:23 libxml.so.5* > peter@daintree[6:23pm]/tmp-114> cc -o foo foo.c -lxml > /usr/libexec/elf/ld: cannot find -lxml > > Yes, /usr/local/lib is on my ldconfig path. Right, but ldconfig is used only at run time. gcc -v shows (not surprisingly) that the /usr/local hierarchy is ignored. > peter@daintree[6:24pm]/tmp-120> ldconfig -r | head -2 > /var/run/ld-elf.so.hints: > search directories: /usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib > > This is working exactly as designed. Your email suggests you found a bug > in the implementation of this.. Or are you complaining about the design > itself? I'm complaining about the implementation. Since the Ports Collection installs by default in /usr/local, it seems reasonable to at least put these directories at the end of the search paths for header files and libraries. >>> (you have typos above about /usr/local/libexec don't you?) >> >> Yes, sorry. This is where you put obrien's reference to my typos. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 21:15:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 92CEF37B401; Tue, 28 May 2002 21:15:21 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g4T4FEY27588; Tue, 28 May 2002 22:15:14 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g4T4FDG33925; Tue, 28 May 2002 22:15:13 -0600 (MDT) (envelope-from imp@village.org) Date: Tue, 28 May 2002 22:14:53 -0600 (MDT) Message-Id: <20020528.221453.83474290.imp@village.org> To: grog@FreeBSD.ORG Cc: peter@wemm.org, freebsd-arch@FreeBSD.ORG Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? From: "M. Warner Losh" In-Reply-To: <20020529122327.C82424@wantadilla.lemis.com> References: <20020529093009.C31668@wantadilla.lemis.com> <20020529012544.14816380A@overcee.wemm.org> <20020529122327.C82424@wantadilla.lemis.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020529122327.C82424@wantadilla.lemis.com> "Greg 'groggy' Lehey" writes: : I'm complaining about the implementation. Since the Ports Collection : installs by default in /usr/local, it seems reasonable to at least put : these directories at the end of the search paths for header files and : libraries. It is working as designed. /usr/local/* isn't searched by default, and never have been in BSD. Just because Linux is lame doesn't mean that we should be too. We shouldn't search /usr/local by default because PREFIX can be set to anything. We shouldn't search it because that may break other things. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 21:38:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id AA83237B400 for ; Tue, 28 May 2002 21:38:16 -0700 (PDT) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id A8F0F81430; Wed, 29 May 2002 14:08:13 +0930 (CST) Date: Wed, 29 May 2002 14:08:13 +0930 From: Greg 'groggy' Lehey To: "M. Warner Losh" Cc: peter@wemm.org, freebsd-arch@FreeBSD.ORG Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020529140813.P82424@wantadilla.lemis.com> References: <20020529093009.C31668@wantadilla.lemis.com> <20020529012544.14816380A@overcee.wemm.org> <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020528.221453.83474290.imp@village.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 28 May 2002 at 22:14:53 -0600, Warner Losh wrote: > In message: <20020529122327.C82424@wantadilla.lemis.com> > "Greg 'groggy' Lehey" writes: >> I'm complaining about the implementation. Since the Ports Collection >> installs by default in /usr/local, it seems reasonable to at least put >> these directories at the end of the search paths for header files and >> libraries. > > It is working as designed. /usr/local/* isn't searched by default, > and never have been in BSD. "We do it this way because our grandfathers did it this way"? > Just because Linux is lame I think that's a rather blanked statement. > doesn't mean that we should be too. No, but I can see (and have presented) good reasons. > We shouldn't search /usr/local by default because PREFIX can be set > to anything. It doesn't do any harm even in that case. > We shouldn't search it because that may break other things. What? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 22:37:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E077937B409; Tue, 28 May 2002 22:37:47 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g4T5bkY27898; Tue, 28 May 2002 23:37:46 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g4T5bdG34288; Tue, 28 May 2002 23:37:39 -0600 (MDT) (envelope-from imp@village.org) Date: Tue, 28 May 2002 23:37:29 -0600 (MDT) Message-Id: <20020528.233729.115542684.imp@village.org> To: grog@FreeBSD.org Cc: peter@wemm.org, freebsd-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? From: "M. Warner Losh" In-Reply-To: <20020529140813.P82424@wantadilla.lemis.com> References: <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020529140813.P82424@wantadilla.lemis.com> "Greg 'groggy' Lehey" writes: : > We shouldn't search it because that may break other things. : : What? It increases the default security domain from /usr/include and /usr/lib to also include /usr/local/lib and /usr/local/include silently. Right now users must explicitly declare that they want to link against this less secure domain by adding -I/usr/local/include and -L/usr/lcoal/include to the build process. Maybe this isn't a show stopper, but it is the sort of thing that needs to be considered before we put a change like this into the tree. I think that it is a sufficient reason to block the addition. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 22:59:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id E185737B403; Tue, 28 May 2002 22:59:30 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g4T5xUJ62713; Tue, 28 May 2002 22:59:30 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.3/8.12.3) with ESMTP id g4T5xbVJ000397; Tue, 28 May 2002 22:59:37 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.3/8.12.3/Submit) id g4T5xbY5000396; Tue, 28 May 2002 22:59:37 -0700 (PDT) (envelope-from marcel) Date: Tue, 28 May 2002 22:59:37 -0700 From: Marcel Moolenaar To: "Greg 'groggy' Lehey" Cc: Peter Wemm , freebsd-arch@FreeBSD.ORG Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020529055937.GB306@dhcp01.pn.xcllnt.net> References: <20020529093009.C31668@wantadilla.lemis.com> <20020529012544.14816380A@overcee.wemm.org> <20020529122327.C82424@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020529122327.C82424@wantadilla.lemis.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 29, 2002 at 12:23:27PM +0930, Greg 'groggy' Lehey wrote: > > I'm complaining about the implementation. Since the Ports Collection > installs by default in /usr/local, it seems reasonable to at least put > these directories at the end of the search paths for header files and > libraries. Putting /usr/local at the end of the search path by default does not yield the same result as putting -I/usr/include on the command line when there's a conflict (db.h and/or ndbm.h come to mind), because -I is search before the default (system) search path. On the other hand, putting /usr/include up front by default is probably just broken by design. I think adding /usr/include to the default search path is based on the optimistic assumption that there's no conflict. This may cause unexpected random failures when there is a conflict that the user can subsequently blame on the compiler, because the user didn't do anything. Not searching searching /usr/include is then based on the pessimistic assumption that there can be a conflict and it's better to have the user be explicit all the time so it's always his fault. What applies to conflict also applies to headers not found. If one likes: s/optimistic/rose-colored/g s/pessimistic/realistic/g I don't see an inconsistency. Just differing point of views. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 23: 3: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 2761537B400; Tue, 28 May 2002 23:03:01 -0700 (PDT) Received: from pool0116.cvx21-bradley.dialup.earthlink.net ([209.179.192.116] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17CwXs-00011S-00; Tue, 28 May 2002 23:02:53 -0700 Message-ID: <3CF46EE9.6C6030C0@mindspring.com> Date: Tue, 28 May 2002 23:02:17 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg 'groggy' Lehey Cc: "M. Warner Losh" , peter@wemm.org, freebsd-arch@FreeBSD.ORG Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? References: <20020529093009.C31668@wantadilla.lemis.com> <20020529012544.14816380A@overcee.wemm.org> <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg 'groggy' Lehey wrote: > > We shouldn't search /usr/local by default because PREFIX can be set > > to anything. > > It doesn't do any harm even in that case. Actually, in this case, it can. > > We shouldn't search it because that may break other things. > > What? The issue with "PREFIX" is that it's used for the "ports" system, including "packages". There _is_ actually a way that this could be bad. The place it would be bad is for ports maintainers and ports users (but not packages, since they will get caught during the build process). The way this could go sour is to hide dependencies. Consider a port maintainer who has a working system where they do ports. This system may have things installed on it that the port maintainer uses in everyday use of the system -- when the box is not being used to maintain the port. In this case, what this means is that an updated version of software could grow a dependency on the installed software -- _because the compiler finds it without being told_, ad the port maintainer may not become aware of this situation at the time of the port _because the compiler finds it_. IMO, this is *probably* what happened with the recent "getopt_long" problem that someone posted about to both -ports and -hackers. FWIW, "PREFIX", in my book, is not a "ports-only thing". That makes an argument against the extension your Linux friends want, based soley on "PREFIX", pretty specious. I'd also argue that ports should be maintained in a jail, so that this is never an issue; we know already that we can have mistakes in found dependencies, even if the linker and the autoconfig process is too stupid gto catch them: that's why the packages build farm is a farm, and why it requires "clean" system images to build out the packages prior to a FreeBSD release. Without a "portsjail" port, though, this is unlikely to magically happen all on its own. FWIW, I think that the developement environment should cater to the developer. You can argue this both ways: that it should be a minimal set, or that it should "just work". I don't think it's correct to try to make the "PREFIX" argument on the basis of ports maintainers, though, since they aren't really the majority of developers. On the other hand, it's pretty self-evident that the rules for doing compiling (include paths) are different from those for linking (library paths) are different from those from running (ldconfig cache contents), and that these three things should at least *try* to be the same. My own perspective, having used FreeBSD as a developement platorm for code to be deployed on AIX and Solaris... is that FreeBSD "comes with" too much crap. The OpenSSL stuff along means that any code I develope without paying particular attention, is automatically unportable, since I may forget to import the OpenSSL sources into my source tree, incorrectly assuming that the OS will provide the support for me (this is not true!). In general, I have to say that the FreeBSD ports system itself doesn't take these dependencies into account very well (I guess it would be the "Open Ports" system, if it did, since that would mean it would run on any minimal POSIX compliant system, not just FreeBSD). It's very hard, IMO, to argue against including well known add-on include and library paths in the compiler and linker, when they are there in the ldconfig library path cache, and OpenSSL is in the base system for FreeBSD, but not other OS's: the PREFIX argument is a portability argument, and you can't make one portability argument without making *all* portability arguments. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 23: 7:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by hub.freebsd.org (Postfix) with ESMTP id 6056337B405; Tue, 28 May 2002 23:07:38 -0700 (PDT) Received: from pool0116.cvx21-bradley.dialup.earthlink.net ([209.179.192.116] helo=mindspring.com) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17CwcS-0004CT-00; Tue, 28 May 2002 23:07:36 -0700 Message-ID: <3CF47004.EC99DC1D@mindspring.com> Date: Tue, 28 May 2002 23:07:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: grog@FreeBSD.org, peter@wemm.org, freebsd-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include bydefault? References: <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> <20020528.233729.115542684.imp@village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > In message: <20020529140813.P82424@wantadilla.lemis.com> > "Greg 'groggy' Lehey" writes: > : > We shouldn't search it because that may break other things. > : > : What? > > It increases the default security domain from /usr/include and > /usr/lib to also include /usr/local/lib and /usr/local/include > silently. Right now users must explicitly declare that they want to > link against this less secure domain by adding -I/usr/local/include > and -L/usr/lcoal/include to the build process. What is the preference order for shared libraries with the same name? If you have to look to answer this question, or if it depends on the contents of the /etc/rc.conf file variable's arguments to ldconfig, based on list order, then I would argue that the domain is already expanded. There's also a nice hidden assuption there, that the environmental library path overrides are otherwise "safe". > Maybe this isn't a show stopper, but it is the sort of thing that > needs to be considered before we put a change like this into the tree. > I think that it is a sufficient reason to block the addition. I think the fact that it doesn't rationalize compiler, linker, and runtime linker behaviour is sufficient to say "no". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 28 23:30:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by hub.freebsd.org (Postfix) with ESMTP id 9EF4E37B40A; Tue, 28 May 2002 23:30:37 -0700 (PDT) Received: from hpausa5.aus.hp.com (hpausa5.aus.hp.com [15.23.66.135]) by palrel11.hp.com (Postfix) with ESMTP id 85D9E600BA4; Tue, 28 May 2002 23:29:53 -0700 (PDT) Received: from anomic.aus.hp.com (nevada.aus.hp.com [15.30.165.16]) by hpausa5.aus.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.03) id QAA12058; Wed, 29 May 2002 16:27:14 +1000 (EST) Received: from mbp by anomic.aus.hp.com with local (Exim 3.35 #1 (Debian)) id 17Cwvn-00072h-00; Wed, 29 May 2002 14:27:35 +0800 Date: Wed, 29 May 2002 16:27:31 +1000 From: Martin Pool To: "M. Warner Losh" Cc: grog@freebsd.org, peter@wemm.org, freebsd-arch@freebsd.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020529062728.GJ25763@samba.org> References: <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> <20020528.233729.115542684.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020528.233729.115542684.imp@village.org> User-Agent: Mutt/1.3.28i X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 28 May 2002, "M. Warner Losh" wrote: > In message: <20020529140813.P82424@wantadilla.lemis.com> > "Greg 'groggy' Lehey" writes: > : > We shouldn't search it because that may break other things. > : > : What? > > It increases the default security domain from /usr/include and > /usr/lib to also include /usr/local/lib and /usr/local/include > silently. Right now users must explicitly declare that they want to > link against this less secure domain by adding -I/usr/local/include > and -L/usr/lcoal/include to the build process. I thought that was probably the reason. Given the arguments advanced, I'm curious whether you think that packages which are not specific to BSD ought to detect BSD and add those paths, or whether they ought to break by default and require the user to specifically nominate /usr/local/? The first is probably more friendly, but in a way it undermines the BSD maintainers' design. -- Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 4:31: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.inka.de (quechua.inka.de [212.227.14.2]) by hub.freebsd.org (Postfix) with ESMTP id 690CF37B408 for ; Wed, 29 May 2002 04:30:57 -0700 (PDT) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with local-bsmtp id 17D1fM-00012B-00; Wed, 29 May 2002 13:30:56 +0200 Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.3/8.12.2) with ESMTP id g4TB4xij009815 for ; Wed, 29 May 2002 13:04:59 +0200 (CEST) (envelope-from mailnull@localhost.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.3/8.12.3/Submit) id g4TB4xx2009814 for freebsd-arch@freebsd.org; Wed, 29 May 2002 13:04:59 +0200 (CEST) From: naddy@mips.inka.de (Christian Weisgerber) Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Date: Wed, 29 May 2002 11:04:58 +0000 (UTC) Message-ID: References: <20020529093009.C31668@wantadilla.lemis.com> <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg 'groggy' Lehey wrote: > > We shouldn't search /usr/local by default because PREFIX can be set > > to anything. > > It doesn't do any harm even in that case. Yes, it does. It will just about ensure that building with a LOCALBASE other than /usr/local will break, because if /usr/local is searched automatically most port maintainers will forget to specify -I${LOCALBASE}/include and -L${LOCALBASE}/lib. -- Christian "naddy" Weisgerber naddy@mips.inka.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 12:36:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id EFA7337B404 for ; Wed, 29 May 2002 12:36:11 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA41803; Wed, 29 May 2002 12:21:38 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4TJKkE92786; Wed, 29 May 2002 12:20:46 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205291920.g4TJKkE92786@arch20m.dellroad.org> Subject: Re: Kernel stack overflow detection? In-Reply-To: <20020528221812.O62759@locore.ca> "from Jake Burkholder at May 28, 2002 10:18:12 pm" To: Jake Burkholder Date: Wed, 29 May 2002 12:20:45 -0700 (PDT) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jake Burkholder writes: > > If INVARIANTS doesn't do so already, I'd like to propose to write > > up an INVARIANTS check that would validate that the kernel stack > > has not overflowed. However I'm curious if anyone has done this > > already and/or what the right way to go about it would be. E.g, add > > an extra stack page with read-only protection? Any hints appreciated. > > -current has a guard page, -stable does not. Also, in -current the > u. area and the pcb were moved so the kernel stack grows away from > them, instead of towards. Either of these changes should be relatively > easy to back port. > > Note that on x86 a page fault due a stack overflow will cause a double > fault; the double fault handler uses a task gate which does a hardware > context switch to get off of the bad stack. So here's a first attempt at a patch for -stable. This patch does not try to be too ambitious: - It doesn't move the relative position of the stack in the u. area - It only works for i386 This is a MFC of the -current option KSTACK_GUARD although it's done differently (-current and -stable are different anyway in this area). It appears that the -current KSTACK_GUARD doesn't mark the page as read-only (?), whereas this patch does. The advantage is automated hardware detection of stack overflow, but the disadvantage is that we have to increase UPAGES by 2 instead of 1 to avoid making the writable portion of the stack smaller (because before it was not a multiple of PAGE_SIZE). Eventually, this option can be applied to other architectures and moved from conf/options.i386 into conf/options. Thanks for any reviews/comments. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com --- i386/i386/locore.s Thu Sep 20 02:29:23 2001 +++ i386/i386/locore.s Wed May 29 11:30:20 2002 @@ -813,9 +813,34 @@ fillkptphys($PG_RW) /* Map proc0's UPAGES in the physical way ... */ +#ifdef KSTACK_GUARD + /* + * Map the 1st and the 3rd UPAGES pages as writable and the 2nd + * page as read-only to detect kernel stack overflows. + * + * Because of the way fillkptphys() works we have to do this in + * three stages: 1st page RW, 2nd page RO, and pages 3-N RW. + */ + movl R(p0upa), %eax + movl $1, %ecx + fillkptphys($PG_RW) + + movl R(p0upa), %eax + addl $PAGE_SIZE, %eax + movl $1, %ecx + fillkptphys($PG_V) + + movl R(p0upa), %eax + addl $PAGE_SIZE, %eax + addl $PAGE_SIZE, %eax + movl $UPAGES, %ecx + subl $2, %ecx + fillkptphys($PG_RW) +#else movl R(p0upa), %eax movl $UPAGES, %ecx fillkptphys($PG_RW) +#endif /* Map ISA hole */ movl $ISA_HOLE_START, %eax --- i386/i386/pmap.c Thu Jan 3 17:17:33 2002 +++ i386/i386/pmap.c Wed May 29 11:45:39 2002 @@ -890,7 +890,17 @@ /* * Enter the page into the kernel address space. */ +#ifdef KSTACK_GUARD + /* Make bottom page of stack area un-writable */ + if (i == 1) + *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_V | pgeflag; + else { + *(ptek + i) = VM_PAGE_TO_PHYS(m) + | PG_RW | PG_V | pgeflag; + } +#else *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_RW | PG_V | pgeflag; +#endif if (oldpte) { if ((oldpte & PG_G) || (cpu_class > CPUCLASS_386)) { invlpg((vm_offset_t) up + i * PAGE_SIZE); @@ -901,7 +911,15 @@ vm_page_wakeup(m); vm_page_flag_clear(m, PG_ZERO); +#ifdef KSTACK_GUARD + /* Make bottom page of stack area un-writable */ + if (i == 1) + vm_page_flag_set(m, PG_MAPPED); + else + vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); +#else vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); +#endif m->valid = VM_PAGE_BITS_ALL; } if (updateneeded) @@ -997,7 +1015,15 @@ vm_page_wire(m); vm_page_wakeup(m); +#ifdef KSTACK_GUARD + /* Make bottom page of stack area un-writable */ + if (i == 1) + vm_page_flag_set(m, PG_MAPPED); + else + vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); +#else vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); +#endif } } --- i386/include/param.h Mon Sep 24 23:14:07 2001 +++ i386/include/param.h Wed May 29 11:34:56 2002 @@ -110,7 +110,11 @@ #define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE) #define IOPAGES 2 /* pages of i/o permission bitmap */ +#ifdef KSTACK_GUARD +#define UPAGES 5 /* pages of u-area + kernel stack guard */ +#else #define UPAGES 3 /* pages of u-area */ +#endif /* * Ceiling on amount of swblock kva space. --- conf/options.i386 Mon Dec 10 04:17:04 2001 +++ conf/options.i386 Wed May 29 11:32:38 2002 @@ -30,6 +30,9 @@ COMPAT_SVR4 opt_dontuse.h DEBUG_SVR4 opt_svr4.h +# Kernel stack guard +KSTACK_GUARD opt_global.h + # i386 SMP options APIC_IO opt_global.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 12:49:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 3D2F537B405 for ; Wed, 29 May 2002 12:49:03 -0700 (PDT) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id g4TK4Y631933; Wed, 29 May 2002 16:04:35 -0400 (EDT) (envelope-from jake) Date: Wed, 29 May 2002 16:04:34 -0400 From: Jake Burkholder To: Archie Cobbs Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Kernel stack overflow detection? Message-ID: <20020529160434.P62759@locore.ca> References: <20020528221812.O62759@locore.ca> <200205291920.g4TJKkE92786@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205291920.g4TJKkE92786@arch20m.dellroad.org>; from archie@dellroad.org on Wed, May 29, 2002 at 12:20:45PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apparently, On Wed, May 29, 2002 at 12:20:45PM -0700, Archie Cobbs said words to the effect of; > Jake Burkholder writes: > > > If INVARIANTS doesn't do so already, I'd like to propose to write > > > up an INVARIANTS check that would validate that the kernel stack > > > has not overflowed. However I'm curious if anyone has done this > > > already and/or what the right way to go about it would be. E.g, add > > > an extra stack page with read-only protection? Any hints appreciated. > > > > -current has a guard page, -stable does not. Also, in -current the > > u. area and the pcb were moved so the kernel stack grows away from > > them, instead of towards. Either of these changes should be relatively > > easy to back port. > > > > Note that on x86 a page fault due a stack overflow will cause a double > > fault; the double fault handler uses a task gate which does a hardware > > context switch to get off of the bad stack. > > So here's a first attempt at a patch for -stable. This patch does > not try to be too ambitious: > > - It doesn't move the relative position of the stack in the u. area > - It only works for i386 > > This is a MFC of the -current option KSTACK_GUARD although it's > done differently (-current and -stable are different anyway in > this area). > > It appears that the -current KSTACK_GUARD doesn't mark the page > as read-only (?), whereas this patch does. The advantage is automated > hardware detection of stack overflow, but the disadvantage is > that we have to increase UPAGES by 2 instead of 1 to avoid making > the writable portion of the stack smaller (because before it was > not a multiple of PAGE_SIZE). -current just leaves the page unmapped which has the same effect and doesn't waste a physical page for it. This is slightly eaiser to do if the stack is moved in the u. area. I think sparc64 is the only architecture that uses a guard page for proc0's kstack; this is worth doing in -current for i386 at least. > > Eventually, this option can be applied to other architectures and > moved from conf/options.i386 into conf/options. > > Thanks for any reviews/comments. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > --- i386/i386/locore.s Thu Sep 20 02:29:23 2001 > +++ i386/i386/locore.s Wed May 29 11:30:20 2002 > @@ -813,9 +813,34 @@ > fillkptphys($PG_RW) > > /* Map proc0's UPAGES in the physical way ... */ > +#ifdef KSTACK_GUARD > + /* > + * Map the 1st and the 3rd UPAGES pages as writable and the 2nd > + * page as read-only to detect kernel stack overflows. > + * > + * Because of the way fillkptphys() works we have to do this in > + * three stages: 1st page RW, 2nd page RO, and pages 3-N RW. > + */ > + movl R(p0upa), %eax > + movl $1, %ecx > + fillkptphys($PG_RW) > + > + movl R(p0upa), %eax > + addl $PAGE_SIZE, %eax > + movl $1, %ecx > + fillkptphys($PG_V) > + > + movl R(p0upa), %eax > + addl $PAGE_SIZE, %eax > + addl $PAGE_SIZE, %eax > + movl $UPAGES, %ecx > + subl $2, %ecx > + fillkptphys($PG_RW) > +#else > movl R(p0upa), %eax > movl $UPAGES, %ecx > fillkptphys($PG_RW) > +#endif > > /* Map ISA hole */ > movl $ISA_HOLE_START, %eax > --- i386/i386/pmap.c Thu Jan 3 17:17:33 2002 > +++ i386/i386/pmap.c Wed May 29 11:45:39 2002 > @@ -890,7 +890,17 @@ > /* > * Enter the page into the kernel address space. > */ > +#ifdef KSTACK_GUARD > + /* Make bottom page of stack area un-writable */ > + if (i == 1) > + *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_V | pgeflag; > + else { > + *(ptek + i) = VM_PAGE_TO_PHYS(m) > + | PG_RW | PG_V | pgeflag; > + } > +#else > *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_RW | PG_V | pgeflag; > +#endif > if (oldpte) { > if ((oldpte & PG_G) || (cpu_class > CPUCLASS_386)) { > invlpg((vm_offset_t) up + i * PAGE_SIZE); > @@ -901,7 +911,15 @@ > > vm_page_wakeup(m); > vm_page_flag_clear(m, PG_ZERO); > +#ifdef KSTACK_GUARD > + /* Make bottom page of stack area un-writable */ > + if (i == 1) > + vm_page_flag_set(m, PG_MAPPED); > + else > + vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); > +#else > vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); > +#endif > m->valid = VM_PAGE_BITS_ALL; > } > if (updateneeded) > @@ -997,7 +1015,15 @@ > > vm_page_wire(m); > vm_page_wakeup(m); > +#ifdef KSTACK_GUARD > + /* Make bottom page of stack area un-writable */ > + if (i == 1) > + vm_page_flag_set(m, PG_MAPPED); > + else > + vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); > +#else > vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); > +#endif > } > } > > --- i386/include/param.h Mon Sep 24 23:14:07 2001 > +++ i386/include/param.h Wed May 29 11:34:56 2002 > @@ -110,7 +110,11 @@ > #define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE) > > #define IOPAGES 2 /* pages of i/o permission bitmap */ > +#ifdef KSTACK_GUARD > +#define UPAGES 5 /* pages of u-area + kernel stack guard */ > +#else > #define UPAGES 3 /* pages of u-area */ > +#endif > > /* > * Ceiling on amount of swblock kva space. > --- conf/options.i386 Mon Dec 10 04:17:04 2001 > +++ conf/options.i386 Wed May 29 11:32:38 2002 > @@ -30,6 +30,9 @@ > COMPAT_SVR4 opt_dontuse.h > DEBUG_SVR4 opt_svr4.h > > +# Kernel stack guard > +KSTACK_GUARD opt_global.h > + > # i386 SMP options > APIC_IO opt_global.h > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 12:52: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id C418B37B408; Wed, 29 May 2002 12:51:29 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g4TJpRJn002347; Wed, 29 May 2002 12:51:27 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g4TJpMTA002346; Wed, 29 May 2002 12:51:22 -0700 (PDT) Date: Wed, 29 May 2002 12:51:22 -0700 From: "David O'Brien" To: Terry Lambert Cc: Antoine Beaupre , "Greg 'groggy' Lehey" , FreeBSD-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020529125122.B2156@dragon.nuxi.com> Reply-To: FreeBSD-arch@FreeBSD.org References: <26911A2E-7243-11D6-93A2-0050E4A0BB3F@anarcat.ath.cx> <3CF3DAFB.7C9C5108@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CF3DAFB.7C9C5108@mindspring.com>; from tlambert2@mindspring.com on Tue, May 28, 2002 at 12:31:07PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 28, 2002 at 12:31:07PM -0700, Terry Lambert wrote: > Antoine Beaupre wrote: > > We could still make the ports system try to use libraries in > > /usr/local/lib too by default since most third party apps have > > dependencies on other third-party apps. > > > > The way I usually do it is: > > > > CONFIGURE_ENV+= CPPFLAGS="-I${LOCALBASE}/include" \ > > LDFLAGS="-L${LOCALBASE}/lib" \ > > CFLAGS="-I${LOCALBASE}/include ${CFLAGS}" \ > > CXXFLAGS="-I${LOCALBASE}/include ${CXXFLAGS}" > > > > or something like that. I think a lot of ports have something like that > > in there somewhere. > > > The resulting binaries still do not work, unless LD_LIBRARY_PATH > is set, or there is an intervening run of "ldconfig". They fail > to find shared libraries at runtime, installed after boot but > before link (the libraries are found at link time, just not at > runtime). Terry, the Ports Collection *does* do `ldconfig' after installing shared libs. We also do have the assumption that "ldconfig_paths" in /etc/rc.conf is set to match PREFIX. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 12:54:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 4433F37B404; Wed, 29 May 2002 12:54:06 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g4TJs5Jn002416; Wed, 29 May 2002 12:54:05 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g4TJs1TD002411; Wed, 29 May 2002 12:54:01 -0700 (PDT) Date: Wed, 29 May 2002 12:54:01 -0700 From: "David O'Brien" To: "Greg 'groggy' Lehey" Cc: "M. Warner Losh" , peter@wemm.org, freebsd-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020529125401.C2156@dragon.nuxi.com> Reply-To: freebsd-arch@FreeBSD.org References: <20020529093009.C31668@wantadilla.lemis.com> <20020529012544.14816380A@overcee.wemm.org> <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020529140813.P82424@wantadilla.lemis.com>; from grog@FreeBSD.org on Wed, May 29, 2002 at 02:08:13PM +0930 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 29, 2002 at 02:08:13PM +0930, Greg 'groggy' Lehey wrote: > On Tuesday, 28 May 2002 at 22:14:53 -0600, Warner Losh wrote: > > In message: <20020529122327.C82424@wantadilla.lemis.com> > > "Greg 'groggy' Lehey" writes: > >> I'm complaining about the implementation. Since the Ports Collection > >> installs by default in /usr/local, it seems reasonable to at least put > >> these directories at the end of the search paths for header files and > >> libraries. > > > > It is working as designed. /usr/local/* isn't searched by default, > > and never have been in BSD. > > "We do it this way because our grandfathers did it this way"? I speak English because my grandfather did. A good enough reason for me. > > Just because Linux is lame > > I think that's a rather blanked statement. Doesn't make it any less true. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 12:56:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 7B5B837B401; Wed, 29 May 2002 12:56:16 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g4TJuFJn002444; Wed, 29 May 2002 12:56:15 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g4TJuFOL002443; Wed, 29 May 2002 12:56:15 -0700 (PDT) Date: Wed, 29 May 2002 12:56:15 -0700 From: "David O'Brien" To: Martin Pool Cc: "M. Warner Losh" , grog@freebsd.org, peter@wemm.org, freebsd-arch@freebsd.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <20020529125615.D2156@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> <20020528.233729.115542684.imp@village.org> <20020529062728.GJ25763@samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020529062728.GJ25763@samba.org>; from mbp@samba.org on Wed, May 29, 2002 at 04:27:31PM +1000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 29, 2002 at 04:27:31PM +1000, Martin Pool wrote: > Given the arguments advanced, I'm curious whether you think that > packages which are not specific to BSD ought to detect BSD and add > those paths, or whether they ought to break by default and require the > user to specifically nominate /usr/local/? *sigh* All the word is NOT GCC on 386 Linux! No, packages should add those paths. The SUNpro compiler on Solaris does not check /usr/local by default either. Nor does the native compilers on Tru64 and HP-UX (IIRC). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 13:16:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 2F06437B406 for ; Wed, 29 May 2002 13:16:44 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g4TKFcKu010947 for ; Wed, 29 May 2002 22:15:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: CRC32 derived questions... From: Poul-Henning Kamp Date: Wed, 29 May 2002 22:15:38 +0200 Message-ID: <10946.1022703338@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I noticed that Marcel put a crc32 function in geom_gpt, and wondered if we didn't have one some other place already. Sure enough, we did. In if_wi.c. And in libz. And in if_sbni.c (in assembler even). Then I tried to put one copy in libkern but ran into conflicts with zlib.h. And that made me wonder: Why on earth is sys/zlib.h in net/zlib.h ??? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 13:19: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 3C47B37B404 for ; Wed, 29 May 2002 13:18:58 -0700 (PDT) Received: from pool0344.cvx22-bradley.dialup.earthlink.net ([209.179.199.89] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17D9uF-0002Hw-00; Wed, 29 May 2002 13:18:52 -0700 Message-ID: <3CF5378C.52C15200@mindspring.com> Date: Wed, 29 May 2002 13:18:20 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: Jake Burkholder , freebsd-arch@FreeBSD.ORG Subject: Re: Kernel stack overflow detection? References: <200205291920.g4TJKkE92786@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Archie Cobbs wrote: > + * Map the 1st and the 3rd UPAGES pages as writable and the 2nd > + * page as read-only to detect kernel stack overflows. > + * > + * Because of the way fillkptphys() works we have to do this in > + * three stages: 1st page RW, 2nd page RO, and pages 3-N RW. > + */ IMO, the 2nd page should be unmapped, not mapped R/O. With it mapped R/O, you won't detect reads of auto variables in a terminal function which are not used for a given code path, but might be used for a different code path. You might be able to 100% trust the compiler for "might be used before initialized". Also, while it's not a problem for most people, mapping it R/O on the 386 won't actually do anything when it comes to writing it from kernel space (no fault will be generated because the 386 lacks this capability, even if it lets you map that way). Unmapping it will ensure a fault, even on the 386. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 13:28:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id F257337B40F; Wed, 29 May 2002 13:27:47 -0700 (PDT) Received: from pool0344.cvx22-bradley.dialup.earthlink.net ([209.179.199.89] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17DA2s-000613-00; Wed, 29 May 2002 13:27:47 -0700 Message-ID: <3CF539A3.68FCD21@mindspring.com> Date: Wed, 29 May 2002 13:27:15 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD-arch@FreeBSD.org Cc: Antoine Beaupre , Greg 'groggy' Lehey Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? References: <26911A2E-7243-11D6-93A2-0050E4A0BB3F@anarcat.ath.cx> <3CF3DAFB.7C9C5108@mindspring.com> <20020529125122.B2156@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > The resulting binaries still do not work, unless LD_LIBRARY_PATH > > is set, or there is an intervening run of "ldconfig". They fail > > to find shared libraries at runtime, installed after boot but > > before link (the libraries are found at link time, just not at > > runtime). > > Terry, the Ports Collection *does* do `ldconfig' after installing shared > libs. We also do have the assumption that "ldconfig_paths" in > /etc/rc.conf is set to match PREFIX. This does nothing if I mount /usr/local from some place else, rather than installing the port locally. Also, we know about the PREFIX/ports interaction. Not all the world's a port. I think the people who were complaining to Greg were Linux wonks who expected FreeBSD to "work like Linux". I can't really get behind Linux setting architectural direction; however... the issue has made the point that there is a differece between library-and-header-file-finding-behaviour at compile, link, and (in the shared library case) run. I don't like that. I'm not claiming to have a golden fix for it, but I'd at least like to know that other people don't like it. 8-). I think I'm pretty much the only one in this thread (besides the Linux wonks) talking about compiling an arbitrary set of sources, NOT in the context of the ports system. PREFIX has some meaning, but it's mostly linked to ports. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 13:29:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id D0BD737B404 for ; Wed, 29 May 2002 13:29:00 -0700 (PDT) Received: from pool0344.cvx22-bradley.dialup.earthlink.net ([209.179.199.89] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17DA43-000016-00 for freebsd-arch@FreeBSD.org; Wed, 29 May 2002 13:29:00 -0700 Message-ID: <3CF539EC.EAD68F3C@mindspring.com> Date: Wed, 29 May 2002 13:28:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? References: <20020529093009.C31668@wantadilla.lemis.com> <20020529012544.14816380A@overcee.wemm.org> <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> <20020529125401.C2156@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > > Just because Linux is lame > > > > I think that's a rather blanked statement. > > Doesn't make it any less true. Almost said nearly the same thing. I "played nice" instead. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 14:19:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 152AC37B406 for ; Wed, 29 May 2002 14:19:16 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g4TLJAY32162 for ; Wed, 29 May 2002 15:19:11 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g4TLJ9G40382 for ; Wed, 29 May 2002 15:19:10 -0600 (MDT) (envelope-from imp@village.org) Date: Wed, 29 May 2002 15:18:44 -0600 (MDT) Message-Id: <20020529.151844.49472446.imp@village.org> To: freebsd-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? From: "M. Warner Losh" In-Reply-To: <20020529125401.C2156@dragon.nuxi.com> References: <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> <20020529125401.C2156@dragon.nuxi.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020529125401.C2156@dragon.nuxi.com> "David O'Brien" writes: : On Wed, May 29, 2002 at 02:08:13PM +0930, Greg 'groggy' Lehey wrote: : > On Tuesday, 28 May 2002 at 22:14:53 -0600, Warner Losh wrote: : > > In message: <20020529122327.C82424@wantadilla.lemis.com> : > > "Greg 'groggy' Lehey" writes: : > >> I'm complaining about the implementation. Since the Ports Collection : > >> installs by default in /usr/local, it seems reasonable to at least put : > >> these directories at the end of the search paths for header files and : > >> libraries. : > > : > > It is working as designed. /usr/local/* isn't searched by default, : > > and never have been in BSD. : > : > "We do it this way because our grandfathers did it this way"? : : I speak English because my grandfather did. A good enough reason for me. Also, "If everybody were jumping off of cliffs, would you do it too?" Add /usr/local/* by default is just a really dumb idea. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 15:15:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 2575637B400 for ; Wed, 29 May 2002 15:15:04 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA42935; Wed, 29 May 2002 15:10:55 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4TMA3D93662; Wed, 29 May 2002 15:10:03 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205292210.g4TMA3D93662@arch20m.dellroad.org> Subject: Re: Kernel stack overflow detection? In-Reply-To: <20020529160434.P62759@locore.ca> "from Jake Burkholder at May 29, 2002 04:04:34 pm" To: Jake Burkholder Date: Wed, 29 May 2002 15:10:03 -0700 (PDT) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jake Burkholder writes: > -current just leaves the page unmapped which has the same effect > and doesn't waste a physical page for it. This is slightly eaiser > to do if the stack is moved in the u. area. I agree leaving the page unmapped makes more sense. I'm not exactly sure how to do that but below is an updated patch that attempts to.. Basically I replaced all the PG_V's and PG_MAPPED's in the previous patch with zeroes. However I think this is still wasting a page of memory. I'd appreciate someone who understands this stuff better than me taking a look at it. > I think sparc64 is the only architecture that uses a guard page > for proc0's kstack; this is worth doing in -current for i386 > at least. This patch is supposed to handle proc0 as well (the locore.s patch)... Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com --- i386/i386/locore.s Thu Sep 20 02:29:23 2001 +++ i386/i386/locore.s Wed May 29 14:57:18 2002 @@ -813,9 +813,34 @@ fillkptphys($PG_RW) /* Map proc0's UPAGES in the physical way ... */ +#ifdef KSTACK_GUARD + /* + * Map the 1st and the 3rd..Nth UPAGES pages as writable and + * leave the 2nd page unmapped to detect kernel stack overflows. + * + * Because of the way fillkptphys() works we have to do this in + * three stages: 1st page RW, 2nd page unmapped, and pages 3-N RW. + */ + movl R(p0upa), %eax + movl $1, %ecx + fillkptphys($PG_RW) + + movl R(p0upa), %eax + addl $PAGE_SIZE, %eax + movl $1, %ecx + fillkptphys($0) + + movl R(p0upa), %eax + addl $PAGE_SIZE, %eax + addl $PAGE_SIZE, %eax + movl $UPAGES, %ecx + subl $2, %ecx + fillkptphys($PG_RW) +#else movl R(p0upa), %eax movl $UPAGES, %ecx fillkptphys($PG_RW) +#endif /* Map ISA hole */ movl $ISA_HOLE_START, %eax --- i386/i386/pmap.c Thu Jan 3 17:17:33 2002 +++ i386/i386/pmap.c Wed May 29 15:03:24 2002 @@ -890,7 +890,17 @@ /* * Enter the page into the kernel address space. */ +#ifdef KSTACK_GUARD + /* Make bottom page of stack area invalid */ + if (i == 1) + *(ptek + i) = VM_PAGE_TO_PHYS(m) | pgeflag; + else { + *(ptek + i) = VM_PAGE_TO_PHYS(m) + | PG_RW | PG_V | pgeflag; + } +#else *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_RW | PG_V | pgeflag; +#endif if (oldpte) { if ((oldpte & PG_G) || (cpu_class > CPUCLASS_386)) { invlpg((vm_offset_t) up + i * PAGE_SIZE); @@ -901,7 +911,15 @@ vm_page_wakeup(m); vm_page_flag_clear(m, PG_ZERO); +#ifdef KSTACK_GUARD + /* Make bottom page of stack area invalid */ + if (i == 1) + vm_page_flag_set(m, 0); + else + vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); +#else vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); +#endif m->valid = VM_PAGE_BITS_ALL; } if (updateneeded) @@ -997,7 +1015,15 @@ vm_page_wire(m); vm_page_wakeup(m); +#ifdef KSTACK_GUARD + /* Make bottom page of stack area invalid */ + if (i == 1) + vm_page_flag_set(m, 0); + else + vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); +#else vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); +#endif } } --- i386/include/param.h Mon Sep 24 23:14:07 2001 +++ i386/include/param.h Wed May 29 11:34:56 2002 @@ -110,7 +110,11 @@ #define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE) #define IOPAGES 2 /* pages of i/o permission bitmap */ +#ifdef KSTACK_GUARD +#define UPAGES 5 /* pages of u-area + kernel stack guard */ +#else #define UPAGES 3 /* pages of u-area */ +#endif /* * Ceiling on amount of swblock kva space. --- conf/options.i386 Mon Dec 10 04:17:04 2001 +++ conf/options.i386 Wed May 29 11:32:38 2002 @@ -30,6 +30,9 @@ COMPAT_SVR4 opt_dontuse.h DEBUG_SVR4 opt_svr4.h +# Kernel stack guard +KSTACK_GUARD opt_global.h + # i386 SMP options APIC_IO opt_global.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 17:35:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from evilpete.dyndns.org (12-232-26-46.client.attbi.com [12.232.26.46]) by hub.freebsd.org (Postfix) with ESMTP id 1FFD737B400; Wed, 29 May 2002 17:35:10 -0700 (PDT) Received: from overcee.wemm.org ([10.0.0.3]) by evilpete.dyndns.org (8.11.6/8.11.6) with ESMTP id g4U0Z4166566; Wed, 29 May 2002 17:35:04 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 2AFB0380A; Wed, 29 May 2002 17:35:04 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: CRC32 derived questions... In-Reply-To: <10946.1022703338@critter.freebsd.dk> Date: Wed, 29 May 2002 17:35:04 -0700 From: Peter Wemm Message-Id: <20020530003504.2AFB0380A@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > Then I tried to put one copy in libkern but ran into conflicts with zlib.h. > > And that made me wonder: Why on earth is sys/zlib.h in net/zlib.h ??? net/zlib.c and net/zlib.h are hacked versions that are part of the in-kernel pppd. I would be suprised if the more modern versions of zlib didn't have the extra API's that pppd needs. We have a decompress-only kern/inflate.c. We could probably gather a more modern zlib library and replace net/zlib* and kern/inflate.c Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 29 23:12:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id AC6CF37B400 for ; Wed, 29 May 2002 23:12:48 -0700 (PDT) Received: from 66-75-153-50.san.rr.com ([66.75.153.50] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17DJAd-0004Mv-00; Thu, 30 May 2002 00:12:23 -0600 Message-ID: <3CF5C2F2.60C199F3@softweyr.com> Date: Wed, 29 May 2002 23:13:06 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: freebsd-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include bydefault? References: <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com> <20020529125401.C2156@dragon.nuxi.com> <20020529.151844.49472446.imp@village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > > In message: <20020529125401.C2156@dragon.nuxi.com> > "David O'Brien" writes: > : On Wed, May 29, 2002 at 02:08:13PM +0930, Greg 'groggy' Lehey wrote: > : > On Tuesday, 28 May 2002 at 22:14:53 -0600, Warner Losh wrote: > : > > In message: <20020529122327.C82424@wantadilla.lemis.com> > : > > "Greg 'groggy' Lehey" writes: > : > >> I'm complaining about the implementation. Since the Ports Collection > : > >> installs by default in /usr/local, it seems reasonable to at least put > : > >> these directories at the end of the search paths for header files and > : > >> libraries. > : > > > : > > It is working as designed. /usr/local/* isn't searched by default, > : > > and never have been in BSD. > : > > : > "We do it this way because our grandfathers did it this way"? > : > : I speak English because my grandfather did. A good enough reason for me. > > Also, "If everybody were jumping off of cliffs, would you do it too?" > > Add /usr/local/* by default is just a really dumb idea. Well-behaved packages ldconfig {PREFIX}/lib and/or {PREFIX}/libexec on installation, which is acceptable for users. Poorly behaved packages should be corrected rather than dorking up the system to accomodate them. As far as -L and -I arguments to cc, programmers should be able to figger out which libraries they want. This pretty much falls in the category of "works as intended" doesn't it? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 0:57: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 0547737B404; Thu, 30 May 2002 00:56:51 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id DA34EAE162; Thu, 30 May 2002 00:56:50 -0700 (PDT) Date: Thu, 30 May 2002 00:56:50 -0700 From: Alfred Perlstein To: arch@freebsd.org Cc: obrien@freebsd.org, markm@freebsd.org, darrenr@freebsd.org, christos@netbsd.org, peter@freebsd.org Subject: defined(i386) -> defined(__i386__) Message-ID: <20020530075650.GM17045@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think I've got all the cases where we need to fix i386 -> __i386__ however, there's some bogons in contrib'ified code. I need help contacting authors or permission to commit to contrib. Here's what appears to need fixing and who I've contacted via CC'. Index: contrib/bind/include/arpa/nameser_compat.h (??? peter?) Index: contrib/ipfilter/ipsend/ip_var.h (darrenr) Index: contrib/tcsh/tc.wait.h (christos) Index: crypto/heimdal/lib/des/des_locl.h (markm) Index: crypto/heimdal/lib/des/des_locl.org (markm) Index: crypto/kerberosIV/lib/rxkad/rxk_crpt.c (markm) Index: crypto/openssl/crypto/opensslconf.h (markm) Index: gnu/include/values.h (obrien) Index: secure/lib/libcrypto/opensslconf-i386.h (markm) Here's the diff. Index: contrib/bind/include/arpa/nameser_compat.h =================================================================== RCS file: /home/ncvs/src/contrib/bind/include/arpa/nameser_compat.h,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 nameser_compat.h --- contrib/bind/include/arpa/nameser_compat.h 4 Feb 2002 19:12:36 -0000 1.1.1.3 +++ contrib/bind/include/arpa/nameser_compat.h 30 May 2002 07:52:33 -0000 @@ -51,7 +51,7 @@ #define BIG_ENDIAN 4321 /* most-significant byte first (IBM, net) */ #define PDP_ENDIAN 3412 /* LSB first in word, MSW first in long (pdp)*/ -#if defined(vax) || defined(ns32000) || defined(sun386) || defined(i386) || \ +#if defined(vax) || defined(ns32000) || defined(sun386) || defined(__i386__) || \ defined(MIPSEL) || defined(_MIPSEL) || defined(BIT_ZERO_ON_RIGHT) || \ defined(__alpha__) || defined(__alpha) || \ (defined(__Lynx__) && defined(__x86__)) Index: contrib/ipfilter/ipsend/ip_var.h =================================================================== RCS file: /home/ncvs/src/contrib/ipfilter/ipsend/ip_var.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 ip_var.h --- contrib/ipfilter/ipsend/ip_var.h 9 Feb 1997 22:50:02 -0000 1.1.1.1 +++ contrib/ipfilter/ipsend/ip_var.h 30 May 2002 07:22:09 -0000 @@ -44,7 +44,7 @@ * Note: ipf_next must be at same offset as ipq_next above */ struct ipasfrag { -#if defined(vax) || defined(i386) +#if defined(vax) || defined(i386) || defined(__i386__) u_char ip_hl:4, ip_v:4; #endif Index: contrib/tcsh/tc.wait.h =================================================================== RCS file: /home/ncvs/src/contrib/tcsh/tc.wait.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 tc.wait.h --- contrib/tcsh/tc.wait.h 30 Nov 2000 21:05:20 -0000 1.1.1.2 +++ contrib/tcsh/tc.wait.h 30 May 2002 07:07:15 -0000 @@ -98,7 +98,7 @@ # define w_stopval w_S.w_Stopval # define w_stopsig w_S.w_Stopsig # else /* _SEQUENT_ */ -# if defined(vax) || defined(i386) || defined(_I386) +# if defined(vax) || defined(__i386__) || defined(_I386) union { struct { unsigned int w_Termsig:7; @@ -131,7 +131,7 @@ unsigned int w_Stopval:8; } w_S; } w_P; -# endif /* vax || i386 || _I386 */ +# endif /* vax || __i386__ || _I386 */ }; # define w_termsig w_P.w_T.w_Termsig Index: crypto/heimdal/lib/des/des_locl.h =================================================================== RCS file: /home/ncvs/src/crypto/heimdal/lib/des/des_locl.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 des_locl.h --- crypto/heimdal/lib/des/des_locl.h 21 Jun 2001 02:11:50 -0000 1.1.1.1 +++ crypto/heimdal/lib/des/des_locl.h 30 May 2002 07:23:24 -0000 @@ -167,7 +167,7 @@ #define DES_PTR #define DES_RISC2 #define DES_UNROLL -#elif defined( i386 ) /* x86 boxes, should be gcc */ +#elif defined( __i386__ ) /* x86 boxes, should be gcc */ #define DES_PTR #define DES_RISC1 #define DES_UNROLL Index: crypto/heimdal/lib/des/des_locl.org =================================================================== RCS file: /home/ncvs/src/crypto/heimdal/lib/des/des_locl.org,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 des_locl.org --- crypto/heimdal/lib/des/des_locl.org 21 Jun 2001 02:11:51 -0000 1.1.1.1 +++ crypto/heimdal/lib/des/des_locl.org 30 May 2002 07:23:37 -0000 @@ -141,7 +141,7 @@ #define DES_PTR #define DES_RISC2 #define DES_UNROLL -#elif defined( i386 ) /* x86 boxes, should be gcc */ +#elif defined( __i386__ ) /* x86 boxes, should be gcc */ #define DES_PTR #define DES_RISC1 #define DES_UNROLL Index: crypto/kerberosIV/lib/rxkad/rxk_crpt.c =================================================================== RCS file: /home/ncvs/src/crypto/kerberosIV/lib/rxkad/rxk_crpt.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 rxk_crpt.c --- crypto/kerberosIV/lib/rxkad/rxk_crpt.c 29 Dec 2000 20:59:28 -0000 1.1.1.1 +++ crypto/kerberosIV/lib/rxkad/rxk_crpt.c 30 May 2002 07:24:07 -0000 @@ -71,14 +71,14 @@ #define ROT32L(x, n) ((((u_int32) x) << (n)) | (((u_int32) x) >> (32-(n)))) #define bswap32(x) (((ROT32L(x, 16) & 0x00ff00ff)<<8) | ((ROT32L(x, 16)>>8) & 0x00ff00ff)) -#if defined(__alpha) || defined(i386) || defined(MIPSEL) +#if defined(__alpha) || defined(__i386__) || defined(MIPSEL) #define NTOH(x) bswap32(x) #else #define NTOH(x) (x) #endif #if defined(__GNUC__) && (GNU_ASM == 1) -#if defined(i386) +#if defined(__i386__) #undef ntohl #define ntohl rxk_ntohl static inline @@ -226,7 +226,7 @@ u.l = sched ^ R; \ L ^= sbox0[u.c[0]] ^ sbox1[u.c[1]] ^ sbox2[u.c[2]] ^ sbox3[u.c[3]]; } -#if defined(i386) +#if defined(__i386__) /* BEWARE: this code is endian dependent. * This should really be inline assembler on the x86. */ Index: crypto/openssl/crypto/opensslconf.h =================================================================== RCS file: /home/ncvs/src/crypto/openssl/crypto/opensslconf.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 opensslconf.h --- crypto/openssl/crypto/opensslconf.h 13 Apr 2000 06:26:05 -0000 1.1.1.2 +++ crypto/openssl/crypto/opensslconf.h 30 May 2002 07:08:47 -0000 @@ -156,7 +156,7 @@ # define DES_PTR # define DES_RISC2 # define DES_UNROLL -#elif defined( i386 ) /* x86 boxes, should be gcc */ +#elif defined( __i386__ ) /* x86 boxes, should be gcc */ # define DES_PTR # define DES_RISC1 # define DES_UNROLL Index: gnu/include/values.h =================================================================== RCS file: /home/ncvs/src/gnu/include/values.h,v retrieving revision 1.4 diff -u -r1.4 values.h --- gnu/include/values.h 30 May 1995 04:41:37 -0000 1.4 +++ gnu/include/values.h 30 May 2002 07:09:04 -0000 @@ -102,7 +102,7 @@ #define DMAXEXP ((1 << _DEXPLEN - 1) - 1 + _IEEE) #define FMAXEXP ((1 << _FEXPLEN - 1) - 1 + _IEEE) -#elif defined(i386) +#elif defined(__i386__) #define MAXDOUBLE 1.79769313486231570e+308 #define MAXFLOAT ((float)3.40282346638528860e+38) #define MINDOUBLE 2.22507385850720140e-308 Index: secure/lib/libcrypto/opensslconf-i386.h =================================================================== RCS file: /home/ncvs/src/secure/lib/libcrypto/opensslconf-i386.h,v retrieving revision 1.3 diff -u -r1.3 opensslconf-i386.h --- secure/lib/libcrypto/opensslconf-i386.h 16 Jul 2000 05:52:52 -0000 1.3 +++ secure/lib/libcrypto/opensslconf-i386.h 30 May 2002 07:25:50 -0000 @@ -164,7 +164,7 @@ # define DES_PTR # define DES_RISC2 # define DES_UNROLL -#elif defined( i386 ) /* x86 boxes, should be gcc */ +#elif defined( __i386__ ) /* x86 boxes, should be gcc */ # define DES_PTR # define DES_RISC1 # define DES_UNROLL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 8:22:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from beowulf.gw.com (beowulf.gw.com [204.80.150.34]) by hub.freebsd.org (Postfix) with ESMTP id B1F4D37B406 for ; Thu, 30 May 2002 08:22:47 -0700 (PDT) Received: by beowulf.gw.com (Postfix, from userid 10080) id C5C477E03; Thu, 30 May 2002 11:22:46 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Thu, 30 May 2002 11:22:46 -0400 In-Reply-To: <20020530075650.GM17045@elvis.mu.org> from Alfred Perlstein (May 30, 12:56am) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: Alfred Perlstein , arch@freebsd.org Subject: Re: defined(i386) -> defined(__i386__) Message-Id: <20020530152246.C5C477E03@beowulf.gw.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On May 30, 12:56am, bright@mu.org (Alfred Perlstein) wrote: -- Subject: defined(i386) -> defined(__i386__) | I think I've got all the cases where we need to fix i386 -> __i386__ | however, there's some bogons in contrib'ified code. | | I need help contacting authors or permission to commit to contrib. | | Here's what appears to need fixing and who I've contacted via CC'. | | Index: contrib/tcsh/tc.wait.h (christos) Ok, fixed christos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 8:43:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id D069737B409 for ; Thu, 30 May 2002 08:43:05 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id A392BAE162; Thu, 30 May 2002 08:43:00 -0700 (PDT) Date: Thu, 30 May 2002 08:43:00 -0700 From: Alfred Perlstein To: Christos Zoulas Cc: arch@freebsd.org Subject: Re: defined(i386) -> defined(__i386__) Message-ID: <20020530154300.GS17045@elvis.mu.org> References: <20020530075650.GM17045@elvis.mu.org> <20020530152246.C5C477E03@beowulf.gw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020530152246.C5C477E03@beowulf.gw.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Christos Zoulas [020530 08:22] wrote: > On May 30, 12:56am, bright@mu.org (Alfred Perlstein) wrote: > -- Subject: defined(i386) -> defined(__i386__) > > | I think I've got all the cases where we need to fix i386 -> __i386__ > | however, there's some bogons in contrib'ified code. > | > | I need help contacting authors or permission to commit to contrib. > | > | Here's what appears to need fixing and who I've contacted via CC'. > | > | Index: contrib/tcsh/tc.wait.h (christos) > > Ok, fixed Thank you! -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 8:45:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id ACA2937B407 for ; Thu, 30 May 2002 08:45:10 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020530154509.YSEH27513.fepC.post.tele.dk@rafter> for ; Thu, 30 May 2002 17:45:09 +0200 Message-ID: <030001c207f0$fb79e390$6800a8c0@rafter> From: "Daniel Blankensteiner" To: Subject: FreeBSD daemon configurations redesign Date: Thu, 30 May 2002 17:45:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all I was just wondering, if we could start all over again, would we design FreeBSD exactly the same way? I mean by making the system more logical organized/structured and thereby more well-arranged, this should lead to a more easy to configure and thereby more secure system, without reducing the power and opportunities of the system. I am talking about giving daemons special treatment. I know you are working on pulling the port and base system apart, but please hear me out. Let's take an example: All services/daemons config files are in: /etc/daemons/ and here you have: /ftp /ftp/users //Users whom may not login /ftp/chroot //Users whom is chroot'ed /ftp/hosts /ftp/commands //commands which we don't want the user to have access to (maybe like "syst") /ftp/answer //Decide the text to the answers the server give the client /ftp/conf //The config file Let us look at 2 of the files: /etc/daemons/ftp/conf #The FTP config file Allow_anonymous_access="n" Log_anonymous_transfers="n" Ftp_log_file="/var/log/ftpd" Log_connection_fail="y" Log_connections_success="y" Log_command_get="n" Log_command_put="y" //This way you can log the commands you want and so on........ #end /etc/daemons/ftp/answer #The FreeBSD ftp answer file Gretting_message="Welcome the FreeBSD's FTP server" //no need for /ect/ftpwelcome When_logged_in="You are now logged in your home dir" //no need for /ect/ftpmodt Answer_command_syst="Windows NT ;-P" //replies with that text, when the client send that command Answer_command_error="Say what?" #end Almost the same with fx pop3 /pop3 /pop3/answer /pop3/users /pop3/commands /pop3/conf and so on. Or maybe also a user access file, to control all the login services: /ect/daemons/login.conf This file is "like" /etc/login.conf, meaning you can set permissions for a group, user or default, telling the system where the user may login. The file should look like this: #Please "x" those services where the users may login default: POP3="" Imap="X" ssh_password="X" ssh_key="x" ssh_sftp="x" telnet="" ftp="" Next come permissions for special users or groups, centralized control, making the system more easy to configure and more secure. May also a /ect/daemons/statup Here you can "X" all the services you want to start at boot time. I know you do this in /etc/rc.* and /usr/local/etc/rc.d/*.sh But regarding daemons this should for security reasons, only be done from /ect/daemons/statup A main daemons log file? /etc/daemons/log But it is probably better to use /etc/daemons/"TheService"/conf We should learn from other system like solaris, linux and especially the Hurd, even though I think FreeBSD is the best system in the world, there should always be room for new thinking. E.g. should all daemons run as a special user (which only control that service) in jail, I know that the way FreeBSD is now, this is not possible, but then we have to make it possible. Anyway, this is just what I think could make FreeBSD a better system, so this is not a well thought out plan ready to implemented *G* :-) I have a lot of ideas how logging, daemons and configuration, can become more centralized and thereby more easy to run, but I am just a user so I have no power regarding FreeBSD's development and design..but maybe you also think this is the way to go? br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 11:30:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id D36DD37B401; Thu, 30 May 2002 11:30:19 -0700 (PDT) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g4UISQ636502; Thu, 30 May 2002 14:28:26 -0400 (EDT) (envelope-from mike) Date: Thu, 30 May 2002 14:28:26 -0400 From: Mike Barcroft To: Alfred Perlstein Cc: arch@freebsd.org, peter@freebsd.org Subject: Re: defined(i386) -> defined(__i386__) Message-ID: <20020530142826.A35795@espresso.q9media.com> References: <20020530075650.GM17045@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020530075650.GM17045@elvis.mu.org>; from bright@mu.org on Thu, May 30, 2002 at 12:56:50AM -0700 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein writes: > I think I've got all the cases where we need to fix i386 -> __i386__ > however, there's some bogons in contrib'ified code. > > I need help contacting authors or permission to commit to contrib. > > Here's what appears to need fixing and who I've contacted via CC'. > > Index: contrib/bind/include/arpa/nameser_compat.h (??? peter?) I wonder if this file is even being used, since we also have src/include/arpa/nameser_compat.h. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 14:10:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 993DC37B400 for ; Thu, 30 May 2002 14:10:40 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020530211038.NOP27513.fepC.post.tele.dk@rafter>; Thu, 30 May 2002 23:10:38 +0200 Message-ID: <003f01c2081e$738df740$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Gary Thorpe" Cc: References: Subject: Re: FreeBSD daemon configurations redesign Date: Thu, 30 May 2002 23:10:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Gary Thorpe" >How about making all this easier by advocating a move to System V-styled > init and rc? It is much more centralized, flexible and reconfigurable, but > of course lacks the 'BSD-original sign of approval'. I spend 2 years choosing the best OS for my server and personal use, the first choice was between Windows vs Unix, then Linux vs BSD and then Openbsd vs FreeBSD. Now I have read and learned a great deal about FreeBSD and I'm not leaving! I really love this OS! ;-) Do you find it logical that all the ftp config files are floating around in /etc? Together with sendmail and other config files? I am just talking about cleaning up in /etc. I have learned about the different files, but for the sake of future users and our self we should do this. Don't get me wrong, I will always think of FreeBSD as a server system and I wish for a small base system, but when more daemons and other programs is added, this problem is only going to get worse. The other things I was talking about was more power over the daemons, by controlling the answers, commands and what it should log and where to log it. Also a main user access, daemon startup and maybe main (network?) log-conf file. In FreeBSD 5.0 the kernel has moved to /boot, so why not continue this clean up with daemons? br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 16: 0: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id C0BDE37B400 for ; Thu, 30 May 2002 16:00:03 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020530230002.ZYP27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 01:00:02 +0200 Message-ID: <00c601c2082d$bc531ff0$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Gary Thorpe" Cc: References: Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 01:00:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Gary Thorpe" > I do agree that making an /etc/daemon directory to store daemon > configuration files is probably a good thing to do. A SysV-style init would > help with this though. Also, I am sure people will want to distinguish > between 'core' daemons and user-added ones external to the base. I don't know anything about the SysV-style, but yes the core/base daemons and the user/port daemons should be kept apart! br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 16:13:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 8EA9037B40E for ; Thu, 30 May 2002 16:13:21 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020530231320.BAYF27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 01:13:20 +0200 Message-ID: <00f601c2082f$97f7f4d0$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Gary Thorpe" Cc: References: Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 01:13:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Gary Thorpe" > How about making all this easier by advocating a move to System V-styled > init and rc? It is much more centralized, flexible and reconfigurable, but > of course lacks the 'BSD-original sign of approval'. By this I thought you meant I should move to System V*GG* Therefore my reply about I am here to stay (in the FreeBSD world) :-) But that does the other subscribers think? I am learning about FreeBSD, assembly, C/C++, sockets, security and other stuff as fast as I can, but I am not a good enough programmer to make these changes or join the development team. I help in the FreeBSD world the best I can, by telling people about FreeBSD, helping people on usenet and the maillingslists and soon writting about securing FreeBSD. But what I can do is this, come with suggestions how the system can be improved. br db br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 16:18: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 1937E37B405 for ; Thu, 30 May 2002 16:18:01 -0700 (PDT) Received: from pool0713.cvx21-bradley.dialup.earthlink.net ([209.179.194.203] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17DZB3-0007TR-00; Thu, 30 May 2002 16:17:53 -0700 Message-ID: <3CF6B300.145E0CD9@mindspring.com> Date: Thu, 30 May 2002 16:17:20 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Blankensteiner Cc: Gary Thorpe , freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Blankensteiner wrote: > From: "Gary Thorpe" > > I do agree that making an /etc/daemon directory to store daemon > > configuration files is probably a good thing to do. A SysV-style init > would > > help with this though. Also, I am sure people will want to distinguish > > between 'core' daemons and user-added ones external to the base. > > I don't know anything about the SysV-style, but yes the core/base > daemons and the user/port daemons should be kept apart! If they weren't, then all daemons might as well be ports, have package registrations, and be easily replaceable and/or removable for small footprint installations. And without our bimonthly "why is sendmail there by default?" flame-fest, where would we be? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 16:32:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 83DA337B40F for ; Thu, 30 May 2002 16:32:02 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020530233201.BDDH27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 01:32:01 +0200 Message-ID: <011201c20832$34404750$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Terry Lambert" Cc: References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 01:32:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Terry Lambert" > Daniel Blankensteiner wrote: > > I don't know anything about the SysV-style, but yes the core/base > > daemons and the user/port daemons should be kept apart! > > If they weren't, then all daemons might as well be ports, > have package registrations, and be easily replaceable and/or > removable for small footprint installations. > > And without our bimonthly "why is sendmail there by default?" > flame-fest, where would we be? Well maybe create a daemons system. Something like ports but only with daemons, then all daemons work the same way (regarding where they place the files and what they are called and "what" is in them). Then no daemons it there by default, but when they are installed they all act and look like base daemons? Or something like that......maybe the daemon "ports" should not have 3 ftp server to choose from, but then services like sendmail it not there by default. Terry, what do you think about the /etc/daemons/ suggestion? and the other things about logging, user access file and so on? br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 16:42:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 05D5837B401 for ; Thu, 30 May 2002 16:42:26 -0700 (PDT) Received: (qmail 53486 invoked from network); 30 May 2002 23:42:00 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 30 May 2002 23:42:00 -0000 Message-ID: <3CF6B895.FC525A19@pipeline.ch> Date: Fri, 31 May 2002 01:41:09 +0200 From: Andre Oppermann Reply-To: freebsd-chat@freebsd.org X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Blankensteiner Cc: Terry Lambert , freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel, Terry, whoever, Please move this discussion from -arch to -chat. F'upt set. Thanks -- Andre Daniel Blankensteiner wrote: > > ----- Original Message ----- > From: "Terry Lambert" > > Daniel Blankensteiner wrote: > > > I don't know anything about the SysV-style, but yes the core/base > > > daemons and the user/port daemons should be kept apart! > > > > If they weren't, then all daemons might as well be ports, > > have package registrations, and be easily replaceable and/or > > removable for small footprint installations. > > > > And without our bimonthly "why is sendmail there by default?" > > flame-fest, where would we be? > > Well maybe create a daemons system. Something like ports but only with > daemons, then all daemons work the same way (regarding where they place > the files and what they are called and "what" is in them). Then no > daemons it there by default, but when they are installed they all act > and look like base daemons? > Or something like that......maybe the daemon "ports" should not have 3 > ftp server to choose from, but then services like sendmail it not there > by default. > > Terry, what do you think about the /etc/daemons/ suggestion? and the > other things about logging, user access file and so on? > > br > db > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 16:46:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 25F8937B404 for ; Thu, 30 May 2002 16:46:35 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020530234633.BFEK27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 01:46:33 +0200 Message-ID: <000801c20834$3c4a5060$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Daniel Blankensteiner" Cc: References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 01:46:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Daniel Blankensteiner" > Well maybe create a daemons system. Something like ports but only with > daemons, then all daemons work the same way (regarding where they place > the files and what they are called and "what" is in them). Then no > daemons it there by default, but when they are installed they all act > and look like base daemons? > Or something like that......maybe the daemon "ports" should not have 3 > ftp server to choose from, but then services like sendmail it not there > by default. I don't know how many network daemons are in the base system now, but this could lead to more base daemons and also reduce the base system, because they are not there by default. br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 16:53:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 5654C37B40A for ; Thu, 30 May 2002 16:53:38 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020530235337.BGBO27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 01:53:37 +0200 Message-ID: <001f01c20835$3904f3f0$6800a8c0@rafter> From: "Daniel Blankensteiner" To: Cc: References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6B895.FC525A19@pipeline.ch> Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 01:53:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Andre Oppermann" > Daniel, Terry, whoever, > > Please move this discussion from -arch to -chat. F'upt set. Is this not the right group to dissuss the FreeBSD design? freebsd-chat is certainly not. Then tell me, if I want to create a debate about changing /etc where do I write to? br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 18: 5:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 8DAC837B40A for ; Thu, 30 May 2002 18:05:43 -0700 (PDT) Received: from pool0215.cvx22-bradley.dialup.earthlink.net ([209.179.198.215] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17DarK-0000e0-00; Thu, 30 May 2002 18:05:40 -0700 Message-ID: <3CF6CC39.BFC0A232@mindspring.com> Date: Thu, 30 May 2002 18:04:57 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Blankensteiner Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Blankensteiner wrote: > Terry, what do you think about the /etc/daemons/ suggestion? and the > other things about logging, user access file and so on? I think it's a bad idea to move to per program configuration files. I am reminded of "*.INI" in Windows 3.11. I also think it's bad to put things under /etc, since I think /etc should be read-only. I think that eventually, we will see all such things live under /var. I think it's an especially bad idea to put configuration data into files in subdirectories of /etc. I wouldn't have sent the configuration patches to the bind 9 folks, if I liked the factory defaults. 8-). I just wish that "flash" had caught on more, when the limiting factor was the number of times that it could be written, and the footprint of the resulting system. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 18: 9:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 55A2B37B401 for ; Thu, 30 May 2002 18:09:42 -0700 (PDT) Received: from pool0215.cvx22-bradley.dialup.earthlink.net ([209.179.198.215] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17Dav6-0005i2-00; Thu, 30 May 2002 18:09:32 -0700 Message-ID: <3CF6CD2B.CCB56553@mindspring.com> Date: Thu, 30 May 2002 18:08:59 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Blankensteiner Cc: oppermann@pipeline.ch, freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6B895.FC525A19@pipeline.ch> <001f01c20835$3904f3f0$6800a8c0@rafter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Blankensteiner wrote: > From: "Andre Oppermann" > > Daniel, Terry, whoever, > > > > Please move this discussion from -arch to -chat. F'upt set. > > Is this not the right group to dissuss the FreeBSD design? > freebsd-chat is certainly not. > Then tell me, if I want to create a debate about changing /etc where do > I write to? He was being less polite than I was. He's saying he likes things just fine the way they are, and so there's no need to discuss them. I'm saying that this has been discussed to death, the conclusion is a given, and that Eric Melville and others are already on it, so you should either get with them, or look at the archives to see how your discussion will end. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 18:11:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id D8FB337B40A for ; Thu, 30 May 2002 18:11:41 -0700 (PDT) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g4V19uM53394; Thu, 30 May 2002 21:09:56 -0400 (EDT) (envelope-from mike) Date: Thu, 30 May 2002 21:09:56 -0400 From: Mike Barcroft To: Daniel Blankensteiner Cc: Gary Thorpe , freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign Message-ID: <20020530210956.C35795@espresso.q9media.com> References: <003f01c2081e$738df740$6800a8c0@rafter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003f01c2081e$738df740$6800a8c0@rafter>; from db@traceroute.dk on Thu, May 30, 2002 at 11:10:39PM +0200 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Blankensteiner writes: > Do you find it logical that all the ftp config files are floating around > in /etc? Together with sendmail and other config files? > I am just talking about cleaning up in /etc. We usually start creating directories in /etc after we have several configuration files to put there. For instance: /etc/namedb/, /etc/mail/, /etc/ssh/. It might not be a bad idea to create an /etc/ftpd/. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 18:32:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by hub.freebsd.org (Postfix) with ESMTP id 2ACA037B41C for ; Thu, 30 May 2002 18:32:08 -0700 (PDT) Received: from areilly.bpc-users.org ([144.135.25.78]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GWYC9I00.8AW for ; Fri, 31 May 2002 11:32:06 +1000 Received: from CPE-144-132-243-222.nsw.bigpond.net.au ([144.132.243.222]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0m 92/1016668); 31 May 2002 11:32:06 Received: (qmail 29446 invoked from network); 31 May 2002 01:32:06 -0000 Received: from localhost (andrew@127.0.0.1) by localhost with SMTP; 31 May 2002 01:32:06 -0000 Subject: Re: FreeBSD daemon configurations redesign From: Andrew Reilly To: Daniel Blankensteiner Cc: freebsd-arch@freebsd.org In-Reply-To: <030001c207f0$fb79e390$6800a8c0@rafter> References: <030001c207f0$fb79e390$6800a8c0@rafter> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 31 May 2002 11:32:06 +1000 Message-Id: <1022808726.16007.83.camel@gurney.reilly.home> Mime-Version: 1.0 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 2002-05-31 at 01:45, Daniel Blankensteiner wrote: > I mean by making the system more logical organized/structured and thereby > more > well-arranged, this should lead to a more easy to configure and thereby > more secure system, without reducing the power and opportunities > of the system. I am talking about giving daemons special treatment. You should check out the sysutils/daemontools port. It gets a _lot_ right, in my opinion. OK, you have to tweak it so that log files go into /var/log/foo-service/ instead of /etc/foo-service/log/main/, but that's not hard to do. Even the configuration mechanism (envdir: set environment variables according to the contents of files in the named directory) is neat. Thats part of the blurry line between the design of the daemons themselves and the control framework, I guess. Multilog handles log file rotation naturally, without having to interrupt the daemon to tell it to close and re-open the file. Process signalling without needing write access to /var/run, (to write a PID file), so daemons can run as non-root users and not require looking their process number up with ps in order to send them a signal. Many good design ideas. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 22:56:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from evilpete.dyndns.org (12-232-26-46.client.attbi.com [12.232.26.46]) by hub.freebsd.org (Postfix) with ESMTP id 04C7A37B401; Thu, 30 May 2002 22:56:33 -0700 (PDT) Received: from overcee.wemm.org ([10.0.0.3]) by evilpete.dyndns.org (8.11.6/8.11.6) with ESMTP id g4V5uU171680; Thu, 30 May 2002 22:56:32 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 3AABE380F; Thu, 30 May 2002 22:56:29 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mike Barcroft Cc: Alfred Perlstein , arch@freebsd.org Subject: Re: defined(i386) -> defined(__i386__) In-Reply-To: <20020530142826.A35795@espresso.q9media.com> Date: Thu, 30 May 2002 22:56:29 -0700 From: Peter Wemm Message-Id: <20020531055629.3AABE380F@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Barcroft wrote: > Alfred Perlstein writes: > > I think I've got all the cases where we need to fix i386 -> __i386__ > > however, there's some bogons in contrib'ified code. > > > > I need help contacting authors or permission to commit to contrib. > > > > Here's what appears to need fixing and who I've contacted via CC'. > > > > Index: contrib/bind/include/arpa/nameser_compat.h (??? peter?) > > I wonder if this file is even being used, since we also have > src/include/arpa/nameser_compat.h. named and associated tools use its own internal resolver instead of the system resolver. However: #if (BSD >= 199103) # include #else .... including if defined(i386). #endif So, fortunately it is irrelevant to us. We just use machine/endian.h. Dont touch this file. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 30 23:48:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6647D37B404; Thu, 30 May 2002 23:48:45 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id DCDA05307; Fri, 31 May 2002 08:48:43 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Mike Barcroft Cc: Daniel Blankensteiner , Gary Thorpe , freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <003f01c2081e$738df740$6800a8c0@rafter> <20020530210956.C35795@espresso.q9media.com> From: Dag-Erling Smorgrav Date: 31 May 2002 08:48:43 +0200 In-Reply-To: <20020530210956.C35795@espresso.q9media.com> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Barcroft writes: > We usually start creating directories in /etc after we have several > configuration files to put there. For instance: /etc/namedb/, > /etc/mail/, /etc/ssh/. It might not be a bad idea to create an > /etc/ftpd/. /etc/ftpusers is (ab)used by much more than just ftpd. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 2:27:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id A25C937B406 for ; Fri, 31 May 2002 02:27:46 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020531092744.EBLH27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 11:27:44 +0200 Message-ID: <011001c20885$6dc3db60$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Terry Lambert" Cc: References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 11:27:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Terry Lambert" To: "Daniel Blankensteiner" > I also think it's bad to put things under /etc, since I think > /etc should be read-only. I think that eventually, we will > see all such things live under /var. I am only talk about config files, the binaries and log should not be in here. br b To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 2:31:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 9062337B414; Fri, 31 May 2002 02:31:43 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020531093142.ECJA27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 11:31:42 +0200 Message-ID: <012c01c20885$fb90d240$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Mike Barcroft" Cc: References: <003f01c2081e$738df740$6800a8c0@rafter> <20020530210956.C35795@espresso.q9media.com> Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 11:31:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Mike Barcroft" To: "Daniel Blankensteiner" > Daniel Blankensteiner writes: > > Do you find it logical that all the ftp config files are floating around > > in /etc? Together with sendmail and other config files? > > I am just talking about cleaning up in /etc. > > We usually start creating directories in /etc after we have several > configuration files to put there. For instance: /etc/namedb/, > /etc/mail/, /etc/ssh/. It might not be a bad idea to create an > /etc/ftpd/. Glad you agree on that :-) br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 2:51:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 2C3FA37B405 for ; Fri, 31 May 2002 02:51:20 -0700 (PDT) Received: from rafter ([80.63.125.30]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020531095119.EHIP27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 11:51:19 +0200 Message-ID: <016201c20888$b8b52950$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Andrew Reilly" Cc: References: <030001c207f0$fb79e390$6800a8c0@rafter> <1022808726.16007.83.camel@gurney.reilly.home> Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 11:51:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Andrew Reilly" > On Fri, 2002-05-31 at 01:45, Daniel Blankensteiner wrote: > > I mean by making the system more logical organized/structured and thereby > > more > > well-arranged, this should lead to a more easy to configure and thereby > > more secure system, without reducing the power and opportunities > > of the system. I am talking about giving daemons special treatment. > > You should check out the sysutils/daemontools port. It gets a _lot_ > right, in my opinion. OK, you have to tweak it so that log files go > into /var/log/foo-service/ instead of /etc/foo-service/log/main/, but > that's not hard to do. > > Even the configuration mechanism (envdir: set environment variables > according to the contents of files in the named directory) is neat. > Thats part of the blurry line between the design of the daemons > themselves and the control framework, I guess. > > Multilog handles log file rotation naturally, without having to > interrupt the daemon to tell it to close and re-open the file. > > Process signalling without needing write access to /var/run, (to write a > PID file), so daemons can run as non-root users and not require looking > their process number up with ps in order to send them a signal. > > Many good design ideas. Ok and we should discuss every (serious) idea and do it, if the outcome is a better system. br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 13:40:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id 62F5C37B403 for ; Fri, 31 May 2002 13:40:12 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020531204011.MEEN20219.sccrmhc03.attbi.com@InterJet.elischer.org>; Fri, 31 May 2002 20:40:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA29828; Fri, 31 May 2002 13:36:16 -0700 (PDT) Date: Fri, 31 May 2002 13:36:15 -0700 (PDT) From: Julian Elischer To: Archie Cobbs Cc: Jake Burkholder , freebsd-arch@FreeBSD.ORG Subject: Re: Kernel stack overflow detection? In-Reply-To: <200205291920.g4TJKkE92786@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 29 May 2002, Archie Cobbs wrote: > Jake Burkholder writes: > > > If INVARIANTS doesn't do so already, I'd like to propose to write > > > up an INVARIANTS check that would validate that the kernel stack > > > has not overflowed. However I'm curious if anyone has done this > > > already and/or what the right way to go about it would be. E.g, add > > > an extra stack page with read-only protection? Any hints appreciated. > > > > -current has a guard page, -stable does not. Also, in -current the > > u. area and the pcb were moved so the kernel stack grows away from > > them, instead of towards. Either of these changes should be relatively > > easy to back port. In -current the U-area and the stack are becoming completely separate, as the stack and pcb is a per-thread thing and the remaining parts of the u-area (signal stuff) is a per-process thing. > > > > Note that on x86 a page fault due a stack overflow will cause a double > > fault; the double fault handler uses a task gate which does a hardware > > context switch to get off of the bad stack. > > So here's a first attempt at a patch for -stable. This patch does > not try to be too ambitious: > > - It doesn't move the relative position of the stack in the u. area > - It only works for i386 > > This is a MFC of the -current option KSTACK_GUARD although it's > done differently (-current and -stable are different anyway in > this area). > > It appears that the -current KSTACK_GUARD doesn't mark the page > as read-only (?), whereas this patch does. The advantage is automated > hardware detection of stack overflow, but the disadvantage is > that we have to increase UPAGES by 2 instead of 1 to avoid making > the writable portion of the stack smaller (because before it was > not a multiple of PAGE_SIZE). the guard page should be completely un-mapped. > > Eventually, this option can be applied to other architectures and > moved from conf/options.i386 into conf/options. > > Thanks for any reviews/comments. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > --- i386/i386/locore.s Thu Sep 20 02:29:23 2001 > +++ i386/i386/locore.s Wed May 29 11:30:20 2002 > @@ -813,9 +813,34 @@ > fillkptphys($PG_RW) > > /* Map proc0's UPAGES in the physical way ... */ > +#ifdef KSTACK_GUARD > + /* > + * Map the 1st and the 3rd UPAGES pages as writable and the 2nd > + * page as read-only to detect kernel stack overflows. > + * > + * Because of the way fillkptphys() works we have to do this in > + * three stages: 1st page RW, 2nd page RO, and pages 3-N RW. > + */ > + movl R(p0upa), %eax > + movl $1, %ecx > + fillkptphys($PG_RW) This was the u-area.. ok. though we probably need to check sizeof(strucr user). > + > + movl R(p0upa), %eax > + addl $PAGE_SIZE, %eax > + movl $1, %ecx > + fillkptphys($PG_V) > + This was the guard page.. If we don't call fillkptphys, but just skip over it I think we'd be ok.. I haven't looked at fillkptphys() to see if we need to increment something, probably not. > + movl R(p0upa), %eax > + addl $PAGE_SIZE, %eax > + addl $PAGE_SIZE, %eax > + movl $UPAGES, %ecx > + subl $2, %ecx no, we should split upages into KSTACK_PAGES and USER_PAGES as we did in -current > + fillkptphys($PG_RW) > +#else > movl R(p0upa), %eax > movl $UPAGES, %ecx > fillkptphys($PG_RW) > +#endif > > /* Map ISA hole */ > movl $ISA_HOLE_START, %eax > --- i386/i386/pmap.c Thu Jan 3 17:17:33 2002 > +++ i386/i386/pmap.c Wed May 29 11:45:39 2002 > @@ -890,7 +890,17 @@ > /* > * Enter the page into the kernel address space. > */ > +#ifdef KSTACK_GUARD > + /* Make bottom page of stack area un-writable */ if you just left it alone it would already be so.. > + if (i == 1) > + *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_V | pgeflag; > + else { > + *(ptek + i) = VM_PAGE_TO_PHYS(m) > + | PG_RW | PG_V | pgeflag; > + } > +#else > *(ptek + i) = VM_PAGE_TO_PHYS(m) | PG_RW | PG_V | pgeflag; > +#endif > if (oldpte) { > if ((oldpte & PG_G) || (cpu_class > CPUCLASS_386)) { > invlpg((vm_offset_t) up + i * PAGE_SIZE); > @@ -901,7 +911,15 @@ > > vm_page_wakeup(m); > vm_page_flag_clear(m, PG_ZERO); > +#ifdef KSTACK_GUARD > + /* Make bottom page of stack area un-writable */ > + if (i == 1) > + vm_page_flag_set(m, PG_MAPPED); > + else > + vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); > +#else > vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); > +#endif > m->valid = VM_PAGE_BITS_ALL; > } > if (updateneeded) > @@ -997,7 +1015,15 @@ > > vm_page_wire(m); > vm_page_wakeup(m); > +#ifdef KSTACK_GUARD > + /* Make bottom page of stack area un-writable */ > + if (i == 1) > + vm_page_flag_set(m, PG_MAPPED); > + else > + vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); > +#else > vm_page_flag_set(m, PG_MAPPED | PG_WRITEABLE); > +#endif > } > } > > --- i386/include/param.h Mon Sep 24 23:14:07 2001 > +++ i386/include/param.h Wed May 29 11:34:56 2002 > @@ -110,7 +110,11 @@ > #define MAXDUMPPGS (DFLTPHYS/PAGE_SIZE) > > #define IOPAGES 2 /* pages of i/o permission bitmap */ > +#ifdef KSTACK_GUARD > +#define UPAGES 5 /* pages of u-area + kernel stack guard */ > +#else > #define UPAGES 3 /* pages of u-area */ > +#endif the patches to separate out the u-area and the stack were pretty trivial check the code in -current. > > /* > * Ceiling on amount of swblock kva space. > --- conf/options.i386 Mon Dec 10 04:17:04 2001 > +++ conf/options.i386 Wed May 29 11:32:38 2002 > @@ -30,6 +30,9 @@ > COMPAT_SVR4 opt_dontuse.h > DEBUG_SVR4 opt_svr4.h > > +# Kernel stack guard > +KSTACK_GUARD opt_global.h > + > # i386 SMP options > APIC_IO opt_global.h > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 13:56:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id BD4E737B41A for ; Fri, 31 May 2002 13:56:14 -0700 (PDT) Received: from pool0324.cvx40-bradley.dialup.earthlink.net ([216.244.43.69] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17DtRK-0006jc-00; Fri, 31 May 2002 13:56:02 -0700 Message-ID: <3CF7E342.C351A12E@mindspring.com> Date: Fri, 31 May 2002 13:55:30 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Blankensteiner Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Blankensteiner wrote: > From: "Terry Lambert" > To: "Daniel Blankensteiner" > > I also think it's bad to put things under /etc, since I think > > /etc should be read-only. I think that eventually, we will > > see all such things live under /var. > > I am only talk about config files, the binaries and log should not be in > here. I'm also taling about config files. Seperate config files is a bad idea. We tolerate it now because a lot of things wouldn't fit into rc.conf (like the sendmail configuration data). For things that can, they should. Your examples were all things that can. I don't understand the benefit of breaking them up, except to have more files to worry about, and more things that need to be writeable (or symlinked and moved, when / isn't writeable). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 14:46:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 8C80737B408 for ; Fri, 31 May 2002 14:46:53 -0700 (PDT) Received: from rafter ([80.63.125.78]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020531214652.IGCT27513.fepC.post.tele.dk@rafter>; Fri, 31 May 2002 23:46:52 +0200 Message-ID: <01bf01c208ec$b11a7380$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Terry Lambert" Cc: References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> Subject: Re: FreeBSD daemon configurations redesign Date: Fri, 31 May 2002 23:46:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Terry Lambert" > > I am only talk about config files, the binaries and log should not be in > > here. > > I'm also taling about config files. > > Seperate config files is a bad idea. We tolerate it now because > a lot of things wouldn't fit into rc.conf (like the sendmail > configuration data). For things that can, they should. Your > examples were all things that can. I don't understand the > benefit of breaking them up, except to have more files to worry > about, and more things that need to be writeable (or symlinked > and moved, when / isn't writeable). I think it is easier to setup, let's say FTP, if you know ALL the config files are in /etv/daemons/ftp. And the only place to start the ftpd from when booting, is from /etc/daemons/startup. When you add a user, you have to grand him or deny him access to services. This you do by changing a lot of config files, maybe forgetting some? So a central access file, is maybe not so bad. When more services are added, /etc will "explode". We already got /etc/mail and /etc/ssh, why not /etc/ftp? And then put them in /etc/daemons/, it makes more sence. db db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 15:52: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 8B80C37B400 for ; Fri, 31 May 2002 15:51:57 -0700 (PDT) Received: from pool0324.cvx40-bradley.dialup.earthlink.net ([216.244.43.69] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17DvFS-0001xv-00; Fri, 31 May 2002 15:51:54 -0700 Message-ID: <3CF7FE67.868D4EF9@mindspring.com> Date: Fri, 31 May 2002 15:51:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Blankensteiner Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> <01bf01c208ec$b11a7380$6800a8c0@rafter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Blankensteiner wrote: > I think it is easier to setup, let's say FTP, if you know ALL the config > files are in /etv/daemons/ftp. And the only place to start the ftpd from > when booting, is from /etc/daemons/startup. It's even easier when you don't supply knobs to twiddle in the first place. Can't pick a wrong setting, if there is no way to change it from a right setting... > When you add a user, you have to grand him or deny him access to > services. This you do by changing a lot of config files, maybe > forgetting some? So a central access file, is maybe not so bad. > When more services are added, /etc will "explode". We already got > /etc/mail and /etc/ssh, why not /etc/ftp? And then put them in > /etc/daemons/, it makes more sence. I will share with you "Lessons I have learned about doing business using Open Source: Lesson #31": There are three ways to view this: o System-centric o Service-centric o User-centric Right now, things are (mostly) system-centric. In your example of adding a user and establishing permissions, you have a problem which is user-centric. Then you propose a solution which is service-centric. This doesn't make a lot of sense. When you are trying to create a user-centric model (e.g. the InterJet was such a model), then the best possible world is to implement a user-centric parameter store. When you have to live in the world of attempting to leverage existing source code, then you have to accept some limitations that come with that existing source code. This was a lesson that some of our UI people never learned, and so they tried to change some basic underlying paradigms. Yes, it's possible to do what they wanted (though, probably not wise, if you get right down to it), but the cost would be to not be able to use the exisiting code out there for leverage: the job would have to be done "from scratch"... and there are litterally hundreds of thousands of man years of effort in software like DNS and sendmail, etc., that it would be a shame to have to duplicate. Most companies that try to base products on Open Source really fail to learn this lesson: sometimes you have to bend to the software, rather than attempt to bend the software to your will. Then, of course, the companies themselves fail. The best compromise for a user-centric administrative view is to leave the configuration file layouts and formats alone, and put your own database out there. Then derive the configuration data for the software -- in its native format -- from the contents of your magic user-centric database. There are a couple of interesting problems you end up needing to solve when you take this approach, but they are ultimatrely soluable. I think you are much better off trying to build something like this (if you are smart, it will probably be based on LDAP), than you are in trying to change every piece of software out there to fit a paradigm that is specific to FreeBSD, and will lose you the third party maintenance that makes the current model valuable: it offloads maintenance onto third parties. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 16: 4:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns2.gnf.org (ns2.gnf.org [63.196.132.68]) by hub.freebsd.org (Postfix) with ESMTP id C792437B401 for ; Fri, 31 May 2002 16:04:55 -0700 (PDT) Received: from mail.gnf.org (smtp.gnf.org [172.25.11.11]) by ns2.gnf.org (8.11.6/8.11.6) with ESMTP id g4VMrCO13413; Fri, 31 May 2002 15:53:12 -0700 (PDT) (envelope-from gordon@FreeBSD.org) Received: by mail.gnf.org (Postfix, from userid 888) id 0265411E512; Fri, 31 May 2002 16:04:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.gnf.org (Postfix) with ESMTP id 00E9411A572; Fri, 31 May 2002 16:04:52 -0700 (PDT) Date: Fri, 31 May 2002 16:04:51 -0700 (PDT) From: Gordon Tetlow X-X-Sender: gordont@smtp.gnf.org To: Daniel Blankensteiner Cc: Terry Lambert , Subject: Re: FreeBSD daemon configurations redesign In-Reply-To: <01bf01c208ec$b11a7380$6800a8c0@rafter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 31 May 2002, Daniel Blankensteiner wrote: > I think it is easier to setup, let's say FTP, if you know ALL the config > files are in /etv/daemons/ftp. And the only place to start the ftpd from > when booting, is from /etc/daemons/startup. > When you add a user, you have to grand him or deny him access to > services. This you do by changing a lot of config files, maybe > forgetting some? So a central access file, is maybe not so bad. > When more services are added, /etc will "explode". We already got > /etc/mail and /etc/ssh, why not /etc/ftp? And then put them in > /etc/daemons/, it makes more sence. The problem with this is that the past 15 years of software doesn't work this way. It would take a fair amount of legwork to go through and hammer everything into this mold that would be FreeBSD-specific. I think it would be *very* difficult to get buy-in from all the projets out there that we might potentially use. It's a lot of work already keeping the contrib'ified sources in sync with the vendors, now imagine customizing everything so it was in /etc/daemons/* It's a lot of work to do what you propose. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 16:29:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 6867F37B405 for ; Fri, 31 May 2002 16:29:41 -0700 (PDT) Received: from rafter ([80.63.125.78]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020531232940.JPLX27513.fepC.post.tele.dk@rafter>; Sat, 1 Jun 2002 01:29:40 +0200 Message-ID: <024201c208fb$0df8ae10$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Terry Lambert" Cc: References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> <01bf01c208ec$b11a7380$6800a8c0@rafter> <3CF7FE67.868D4EF9@mindspring.com> Subject: Re: FreeBSD daemon configurations redesign Date: Sat, 1 Jun 2002 01:29:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Terry Lambert" > I will share with you "Lessons I have learned about doing business > using Open Source: Lesson #31": > > There are three ways to view this: > > o System-centric > o Service-centric > o User-centric > > Right now, things are (mostly) system-centric. In your example of > adding a user and establishing permissions, you have a problem which > is user-centric. Then you propose a solution which is service-centric. > This doesn't make a lot of sense. > > When you are trying to create a user-centric model (e.g. the InterJet > was such a model), then the best possible world is to implement a > user-centric parameter store. > > When you have to live in the world of attempting to leverage existing > source code, then you have to accept some limitations that come with > that existing source code. > > This was a lesson that some of our UI people never learned, and so > they tried to change some basic underlying paradigms. Yes, it's > possible to do what they wanted (though, probably not wise, if you > get right down to it), but the cost would be to not be able to use > the exisiting code out there for leverage: the job would have to be > done "from scratch"... and there are litterally hundreds of thousands > of man years of effort in software like DNS and sendmail, etc., that > it would be a shame to have to duplicate. UI? > Most companies that try to base products on Open Source really fail > to learn this lesson: sometimes you have to bend to the software, > rather than attempt to bend the software to your will. Then, of > course, the companies themselves fail. > > The best compromise for a user-centric administrative view is to > leave the configuration file layouts and formats alone, and put > your own database out there. Then derive the configuration data > for the software -- in its native format -- from the contents of > your magic user-centric database. > > There are a couple of interesting problems you end up needing to > solve when you take this approach, but they are ultimatrely > soluable. > > I think you are much better off trying to build something like > this (if you are smart, it will probably be based on LDAP), than > you are in trying to change every piece of software out there to > fit a paradigm that is specific to FreeBSD, and will lose you the > third party maintenance that makes the current model valuable: > it offloads maintenance onto third parties. LDAP? Ok, I did not know it all had to be rewritten from scratch. I thought you just had to rewrite where the daemons store it's confil files. Making an interface to all these config files (like you said), is maybe a better idea. I would like to design this, but I don't think my code will be good enogh for FreeBSD? br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 31 16:34:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 6F00F37B401; Fri, 31 May 2002 16:34:11 -0700 (PDT) Received: from rafter ([80.63.125.78]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020531233410.JPSO27513.fepC.post.tele.dk@rafter>; Sat, 1 Jun 2002 01:34:10 +0200 Message-ID: <024c01c208fb$aefdfe50$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Gordon Tetlow" Cc: References: Subject: Re: FreeBSD daemon configurations redesign Date: Sat, 1 Jun 2002 01:34:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Gordon Tetlow" > The problem with this is that the past 15 years of software doesn't work > this way. It would take a fair amount of legwork to go through and hammer > everything into this mold that would be FreeBSD-specific. I think it would > be *very* difficult to get buy-in from all the projets out there that we > might potentially use. It's a lot of work already keeping the > contrib'ified sources in sync with the vendors, now imagine customizing > everything so it was in /etc/daemons/* > > It's a lot of work to do what you propose. Ok, the idea was good and it can't be done. Some of the things I was talking about can't be done whitout this "new system", but some of the things we can make by faking central control. If you think this is a good idea, then I will be glad (very glad) to help out, anyway I can. br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 1 0:25:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 688C537B408; Sat, 1 Jun 2002 00:25:27 -0700 (PDT) Received: from pool0040.cvx40-bradley.dialup.earthlink.net ([216.244.42.40] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17E3GJ-0004te-00; Sat, 01 Jun 2002 00:25:20 -0700 Message-ID: <3CF876BF.28882CC0@mindspring.com> Date: Sat, 01 Jun 2002 00:24:47 -0700 From: Terry Lambert Reply-To: freebsd-config@freebsd.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Blankensteiner Cc: freebsd-config@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> <01bf01c208ec$b11a7380$6800a8c0@rafter> <3CF7FE67.868D4EF9@mindspring.com> <024201c208fb$0df8ae10$6800a8c0@rafter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Daniel Blankensteiner wrote: > > This was a lesson that some of our UI people never learned, and so > > they tried to change some basic underlying paradigms. Yes, it's > > possible to do what they wanted (though, probably not wise, if you > > get right down to it), but the cost would be to not be able to use > > the exisiting code out there for leverage: the job would have to be > > done "from scratch"... and there are litterally hundreds of thousands > > of man years of effort in software like DNS and sendmail, etc., that > > it would be a shame to have to duplicate. > > UI? "User Interface". > > I think you are much better off trying to build something like > > this (if you are smart, it will probably be based on LDAP), than > > you are in trying to change every piece of software out there to > > fit a paradigm that is specific to FreeBSD, and will lose you the > > third party maintenance that makes the current model valuable: > > it offloads maintenance onto third parties. > > LDAP? "Light-weight Directory Access Protocol". Basically, a hierarchical, rather than relational, database. The /etc/rc.conf, if you take "_" as a hierarchy delimiter, is already organized this way. > Ok, I did not know it all had to be rewritten from scratch. I thought > you just had to rewrite where the daemons store it's confil files. Each daemon has different configuration file code. You would have to replace it, and then, forever after, maintain it. > Making an interface to all these config files (like you said), is maybe > a better idea. Not what I said. I said that you should build a central data store for configuration data, and then derive the real configuration files, in whatever format is expected by the daemon, from the data in the central configuration store. > I would like to design this, but I don't think my code will be good > enogh for FreeBSD? There are a couple of programs that have dealt with this. One is the result of a thread called "Junior Annoying Hacker Task". See the message archives for -current from around the start of February. This really isn't an -arch discussion any more at this point; followups to the -config mailing list. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 1 2:54:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id E9EC837B401 for ; Sat, 1 Jun 2002 02:54:34 -0700 (PDT) Received: from rafter ([80.63.125.78]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020601095433.PWX9333.fepC.post.tele.dk@rafter>; Sat, 1 Jun 2002 11:54:33 +0200 Message-ID: <008a01c20952$58ee84b0$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Terry Lambert" Cc: References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> <01bf01c208ec$b11a7380$6800a8c0@rafter> <3CF7FE67.868D4EF9@mindspring.com> <024201c208fb$0df8ae10$6800a8c0@rafter> <3CF876BF.28882CC0@mindspring.com> Subject: Re: FreeBSD daemon configurations redesign Date: Sat, 1 Jun 2002 11:54:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Terry Lambert" > > Making an interface to all these config files (like you said), is maybe > > a better idea. > > Not what I said. I said that you should build a central data > store for configuration data, and then derive the real configuration > files, in whatever format is expected by the daemon, from the data > in the central configuration store. That was also what I meant :-) But like you said, I/we should stop writting in -arch. br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 1 8:58:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id C082737B404 for ; Sat, 1 Jun 2002 08:58:39 -0700 (PDT) Received: from 66-75-153-50.san.rr.com ([66.75.153.50] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17EBGa-0006yC-00; Sat, 01 Jun 2002 09:58:09 -0600 Message-ID: <3CF8EF2E.241A2A4D@softweyr.com> Date: Sat, 01 Jun 2002 08:58:38 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Daniel Blankensteiner , oppermann@pipeline.ch, freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6B895.FC525A19@pipeline.ch> <001f01c20835$3904f3f0$6800a8c0@rafter> <3CF6CD2B.CCB56553@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Daniel Blankensteiner wrote: > > From: "Andre Oppermann" > > > Daniel, Terry, whoever, > > > > > > Please move this discussion from -arch to -chat. F'upt set. > > > > Is this not the right group to dissuss the FreeBSD design? > > freebsd-chat is certainly not. > > Then tell me, if I want to create a debate about changing /etc where do > > I write to? > > He was being less polite than I was. Perhaps in setting follups to chat he was. In asking you to move a system architecture discussion to -arch, he was just trying to keep the noise level on -developers down. > He's saying he likes things just fine the way they are, and so > there's no need to discuss them. > > I'm saying that this has been discussed to death, the conclusion > is a given, and that Eric Melville and others are already on it, > so you should either get with them, or look at the archives to > see how your discussion will end. People used to say that about the rc system also, and one of these days we're going to actually have the lukem rc system imported and working, with improvements no less. The conclusion of the rc "discussions" always drew was that the SysV init system was too weak to bother moving to. Luke finally came up with something that is demonstrably better, and implemented it in NetBSD. The work to import it to FreeBSD has been slow, but it is happening, and it is enough of an improvement to bother with. So, the bar for your design has been set. Is breaking up the system configuration into all those little bitty files really an improvement? Discuss how this will improve the system, rather than just calling the existing implementation "not designed" and flinging around a few directory trees. Tell us why and how this will improve the system, how it will interact with SNMP or something like that, etc. Give us a reason to believe, other than "it's better because Daniel designed it." Some of the people who developed the existing system weren't complete buffoons, you know. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 1 9: 9:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id AB41637B406 for ; Sat, 1 Jun 2002 09:09:02 -0700 (PDT) Received: from 66-75-153-50.san.rr.com ([66.75.153.50] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17EBR1-0006yg-00; Sat, 01 Jun 2002 10:08:56 -0600 Message-ID: <3CF8F1C1.D28E5CCA@softweyr.com> Date: Sat, 01 Jun 2002 09:09:37 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Daniel Blankensteiner , freebsd-arch@freebsd.org Subject: Re: FreeBSD daemon configurations redesign References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> <01bf01c208ec$b11a7380$6800a8c0@rafter> <3CF7FE67.868D4EF9@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > Daniel Blankensteiner wrote: > > I think it is easier to setup, let's say FTP, if you know ALL the config > > files are in /etv/daemons/ftp. And the only place to start the ftpd from > > when booting, is from /etc/daemons/startup. > > It's even easier when you don't supply knobs to twiddle in the first > place. Can't pick a wrong setting, if there is no way to change it > from a right setting... > > > When you add a user, you have to grand him or deny him access to > > services. This you do by changing a lot of config files, maybe > > forgetting some? So a central access file, is maybe not so bad. > > When more services are added, /etc will "explode". We already got > > /etc/mail and /etc/ssh, why not /etc/ftp? And then put them in > > /etc/daemons/, it makes more sence. > > I will share with you "Lessons I have learned about doing business > using Open Source: Lesson #31": > > There are three ways to view this: > > o System-centric > o Service-centric > o User-centric > > Right now, things are (mostly) system-centric. In your example of > adding a user and establishing permissions, you have a problem which > is user-centric. Then you propose a solution which is service-centric. > This doesn't make a lot of sense. > > When you are trying to create a user-centric model (e.g. the InterJet > was such a model), then the best possible world is to implement a > user-centric parameter store. > > When you have to live in the world of attempting to leverage existing > source code, then you have to accept some limitations that come with > that existing source code. > > This was a lesson that some of our UI people never learned, and so > they tried to change some basic underlying paradigms. Yes, it's > possible to do what they wanted (though, probably not wise, if you > get right down to it), but the cost would be to not be able to use > the exisiting code out there for leverage: the job would have to be > done "from scratch"... and there are litterally hundreds of thousands > of man years of effort in software like DNS and sendmail, etc., that > it would be a shame to have to duplicate. > > Most companies that try to base products on Open Source really fail > to learn this lesson: sometimes you have to bend to the software, > rather than attempt to bend the software to your will. Then, of > course, the companies themselves fail. > > The best compromise for a user-centric administrative view is to > leave the configuration file layouts and formats alone, and put > your own database out there. Then derive the configuration data > for the software -- in its native format -- from the contents of > your magic user-centric database. This is exactly the approach DoBox took to the problem. The DoBox user database (implemented in PostgreSQL, but could be anything) was the central store for all of the user information. Anytime a user was addeded, deleted, or changed, an outcall was made to a program that exported the database to whatever external configurations were needed. It worked quite well, modulo a few potention race conditions that were solved with a sledgehammer (giant-type semaphore). > There are a couple of interesting problems you end up needing to > solve when you take this approach, but they are ultimatrely > soluable. The solutions often end up simpler than the problem would seem in the first place. You get to encapsulate the user design stuff in the database and handle all the hard icky stuff like configuring mail account information in a separate program the UI designers never have to worry about. > I think you are much better off trying to build something like > this (if you are smart, it will probably be based on LDAP), than > you are in trying to change every piece of software out there to > fit a paradigm that is specific to FreeBSD, and will lose you the > third party maintenance that makes the current model valuable: > it offloads maintenance onto third parties. Yes. Anyone looking to "improve" the configuration of FreeBSD, or any other network-attached system, needs to consider LDAP and SNMP. Plus whatever their eventual replaces will be. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 1 10:18:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fepC.post.tele.dk (fepC.post.tele.dk [195.41.46.147]) by hub.freebsd.org (Postfix) with ESMTP id 9C52237B40B for ; Sat, 1 Jun 2002 10:18:41 -0700 (PDT) Received: from rafter ([80.63.125.78]) by fepC.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020601171840.CIAM9333.fepC.post.tele.dk@rafter>; Sat, 1 Jun 2002 19:18:40 +0200 Message-ID: <00d701c20990$648c4490$6800a8c0@rafter> From: "Daniel Blankensteiner" To: "Wes Peters" Cc: References: <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6B895.FC525A19@pipeline.ch> <001f01c20835$3904f3f0$6800a8c0@rafter> <3CF6CD2B.CCB56553@mindspring.com> <3CF8EF2E.241A2A4D@softweyr.com> Subject: Re: FreeBSD daemon configurations redesign Date: Sat, 1 Jun 2002 19:18:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Wes Peters" > So, the bar for your design has been set. Is breaking up the system > configuration into all those little bitty files really an improvement? Little bitty files? I am just talking about putting all the ftp config files in /etc/ftp and then all daemon dir's in /etc/daemons. But as I was told, this will be to much work. > Discuss how this will improve the system, rather than just calling the > existing implementation "not designed" and flinging around a few > directory trees. Tell us why and how this will improve the system, how > it will interact with SNMP or something like that, etc. Give us a > reason to believe, other than "it's better because Daniel designed it." > Some of the people who developed the existing system weren't complete > buffoons, you know. I said in the very first mail, that this is not a well thought out plan. I have never said or hinted that the people who designed /etc are buffoons (what ever that is), so just relax! But a lot of files have be add to /etc and I was asking you if we could clean it up and gave a suggestion of how it could be done, regarding daemons. The reason to do this was to make user access, daemons configuration and logging more simple, which would improve security. br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 1 22: 3:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id 0874B37B401 for ; Sat, 1 Jun 2002 22:03:01 -0700 (PDT) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g52518N00893 for arch@FreeBSD.org; Sun, 2 Jun 2002 01:01:08 -0400 (EDT) (envelope-from mike) Date: Sun, 2 Jun 2002 01:01:08 -0400 From: Mike Barcroft To: arch@FreeBSD.org Subject: Removing wait union Message-ID: <20020602010108.B16166@espresso.q9media.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Does anyone have any objections to removing the deprecated 4.2/4.3BSD wait union in ? It's been deprecating since Rev 1.1 and there are only a few consumers in the base system. Attached are two patches, one to removing it from and the other to remove its consumers. Changes to lpd(8) sent directly to its maintainer. Best regards, Mike Barcroft --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="waith.diff" Remove the deprecated 4.2/4.3BSD wait union. Index: wait.h =================================================================== RCS file: /work/repo/src/sys/sys/wait.h,v retrieving revision 1.16 diff -u -r1.16 wait.h --- wait.h 1 Jun 2002 21:07:10 -0000 1.16 +++ wait.h 2 Jun 2002 04:43:35 -0000 @@ -37,6 +37,8 @@ #ifndef _SYS_WAIT_H_ #define _SYS_WAIT_H_ +#include + /* * This file holds definitions relevant to the wait4 system call and the * alternate interfaces that use it (wait, wait3, waitpid). @@ -86,71 +88,16 @@ #define WLINUXCLONE 0x80000000 /* Wait for kthread spawned from linux_clone. */ #endif -#if __BSD_VISIBLE -/* POSIX extensions and 4.2/4.3 compatibility: */ - /* * Tokens for special values of the "pid" parameter to wait4. */ +#if __BSD_VISIBLE #define WAIT_ANY (-1) /* any process */ #define WAIT_MYPGRP 0 /* any process in my process group */ - -#include - -/* - * Deprecated: - * Structure of the information in the status word returned by wait4. - * If w_stopval==WSTOPPED, then the second structure describes - * the information returned, else the first. - */ -union wait { - int w_status; /* used in syscall */ - /* - * Terminated process status. - */ - struct { -#if _BYTE_ORDER == _LITTLE_ENDIAN - unsigned int w_Termsig:7, /* termination signal */ - w_Coredump:1, /* core dump indicator */ - w_Retcode:8, /* exit code if w_termsig==0 */ - w_Filler:16; /* upper bits filler */ -#endif -#if _BYTE_ORDER == _BIG_ENDIAN - unsigned int w_Filler:16, /* upper bits filler */ - w_Retcode:8, /* exit code if w_termsig==0 */ - w_Coredump:1, /* core dump indicator */ - w_Termsig:7; /* termination signal */ -#endif - } w_T; - /* - * Stopped process status. Returned only for traced children unless - * requested with the WUNTRACED option bit. - */ - struct { -#if _BYTE_ORDER == _LITTLE_ENDIAN - unsigned int w_Stopval:8, /* == W_STOPPED if stopped */ - w_Stopsig:8, /* signal that stopped us */ - w_Filler:16; /* upper bits filler */ -#endif -#if _BYTE_ORDER == _BIG_ENDIAN - unsigned int w_Filler:16, /* upper bits filler */ - w_Stopsig:8, /* signal that stopped us */ - w_Stopval:8; /* == W_STOPPED if stopped */ -#endif - } w_S; -}; -#define w_termsig w_T.w_Termsig -#define w_coredump w_T.w_Coredump -#define w_retcode w_T.w_Retcode -#define w_stopval w_S.w_Stopval -#define w_stopsig w_S.w_Stopsig - -#define WSTOPPED _WSTOPPED #endif /* __BSD_VISIBLE */ #ifndef _KERNEL #include -#include __BEGIN_DECLS struct rusage; /* forward declaration */ --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="waitu.diff" Use POSIX macros for wait(2)-style status information instead of the deprecated 4.2/4.3BSD wait union. Fix some nearby pid_t/int confusion. Index: games/cribbage/instr.c =================================================================== RCS file: /work/repo/src/games/cribbage/instr.c,v retrieving revision 1.5 diff -u -r1.5 instr.c --- games/cribbage/instr.c 12 Dec 1999 03:04:15 -0000 1.5 +++ games/cribbage/instr.c 2 Jun 2002 04:46:42 -0000 @@ -58,8 +58,8 @@ instructions() { struct stat sb; - union wait pstat; pid_t pid; + int pstat; char *pager, *path; if (stat(_PATH_INSTR, &sb)) { @@ -84,7 +84,7 @@ do { pid = waitpid(pid, (int *)&pstat, 0); } while (pid == -1 && errno == EINTR); - if (pid == -1 || pstat.w_status) + if (pid == -1 || WEXITSTATUS(pstat) || WTERMSIG(pstat)) exit(1); } } Index: games/sail/pl_1.c =================================================================== RCS file: /work/repo/src/games/sail/pl_1.c,v retrieving revision 1.2 diff -u -r1.2 pl_1.c --- games/sail/pl_1.c 30 Nov 1999 03:49:36 -0000 1.2 +++ games/sail/pl_1.c 2 Jun 2002 04:47:55 -0000 @@ -126,8 +126,8 @@ void child() { - union wait status; - int pid; + pid_t pid; + int status; (void) signal(SIGCHLD, SIG_IGN); do { Index: gnu/lib/libdialog/raw_popen.c =================================================================== RCS file: /work/repo/src/gnu/lib/libdialog/raw_popen.c,v retrieving revision 1.3 diff -u -r1.3 raw_popen.c --- gnu/lib/libdialog/raw_popen.c 9 Jul 2001 09:23:38 -0000 1.3 +++ gnu/lib/libdialog/raw_popen.c 2 Jun 2002 01:03:41 -0000 @@ -131,8 +131,7 @@ raw_pclose(FILE *iop) { register struct pid *cur, *last; - int omask; - union wait pstat; + int omask, pstat; pid_t pid; (void)fclose(iop); @@ -158,5 +157,5 @@ last->next = cur->next; free(cur); - return (pid == -1 ? -1 : pstat.w_status); + return (pid == -1 ? -1 : pstat); } Index: usr.bin/rlogin/rlogin.c =================================================================== RCS file: /work/repo/src/usr.bin/rlogin/rlogin.c,v retrieving revision 1.32 diff -u -r1.32 rlogin.c --- usr.bin/rlogin/rlogin.c 8 May 2002 00:46:30 -0000 1.32 +++ usr.bin/rlogin/rlogin.c 2 Jun 2002 04:50:45 -0000 @@ -468,16 +468,16 @@ void catch_child(int signo __unused) { - union wait status; - int pid; + pid_t pid; + int status; for (;;) { - pid = wait3((int *)&status, WNOHANG|WUNTRACED, NULL); + pid = wait3(&status, WNOHANG|WUNTRACED, NULL); if (pid == 0) return; /* if the child (reader) dies, just quit */ if (pid < 0 || (pid == child && !WIFSTOPPED(status))) - done((int)(status.w_termsig | status.w_retcode)); + done(WTERMSIG(status) | WEXITSTATUS(status)); } /* NOTREACHED */ } Index: usr.bin/script/script.c =================================================================== RCS file: /work/repo/src/usr.bin/script/script.c,v retrieving revision 1.18 diff -u -r1.18 script.c --- usr.bin/script/script.c 22 Mar 2002 01:42:27 -0000 1.18 +++ usr.bin/script/script.c 2 Jun 2002 02:30:34 -0000 @@ -209,11 +209,11 @@ void finish() { - int die, e, pid; - union wait status; + pid_t pid; + int die, e, status; die = e = 0; - while ((pid = wait3((int *)&status, WNOHANG, 0)) > 0) + while ((pid = wait3(&status, WNOHANG, 0)) > 0) if (pid == child) { die = 1; if (WIFEXITED(status)) Index: usr.bin/window/wwchild.c =================================================================== RCS file: /work/repo/src/usr.bin/window/wwchild.c,v retrieving revision 1.4 diff -u -r1.4 wwchild.c --- usr.bin/window/wwchild.c 17 May 2001 09:38:48 -0000 1.4 +++ usr.bin/window/wwchild.c 2 Jun 2002 04:51:38 -0000 @@ -48,10 +48,9 @@ void wwchild() { - int olderrno; register struct ww **wp; - union wait w; - int pid; + pid_t pid; + int olderrno, w; char collected = 0; olderrno = errno; --oC1+HKm2/end4ao3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message