From owner-freebsd-arch@FreeBSD.ORG Sun May 4 16:51:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF88D37B401; Sun, 4 May 2003 16:51:04 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F34143F3F; Sun, 4 May 2003 16:51:04 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h44Np2Th017215; Sun, 4 May 2003 16:51:03 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305042351.h44Np2Th017215@beastie.mckusick.com> To: Bruce Evans In-Reply-To: Your message of "Sun, 04 May 2003 11:42:24 +1000." <20030504110643.Q1248@gamplex.bde.org> Date: Sun, 04 May 2003 16:51:02 -0700 From: Kirk McKusick cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2003 23:51:05 -0000 Date: Sun, 4 May 2003 11:42:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick cc: Jens Schweikhardt , "" , Brian Buhrow Subject: Re: Access times on executables (kern/25777) In-Reply-To: <200305040032.h440WvTh015707@beastie.mckusick.com> X-ASK-Info: Whitelist match This doesn't work unless the user has permission to change the atime using utimes(2) with a non-NULL times pointer. My version of it has a VA_EXECVE_ATIME flag which tells VOP_SETATTR() to bypass the permissions checks. I only implemented checking this flag for ufs. Another problem with setting the atime like utimes() would instead of like read() would is that utimes() is required to update the times immediately, so VOP_SETATTR() does this, but updates for read() are normally optimized to just set a flag. The difference is not large for ufs since the UFS_UPDATE() call in ufs_setattr() doesn't wait. The VA_EXECVE_ATIME flag could be used to optimize this, but I didn't try this. The overhead for setting atimes on exec only seemed to be large for nfs. This was before nfs had an attribute cache, and I think it is unavoidable for utimes()-like updates. On one of my systems now, futimes() takes about 12.5 times longer than reading 1 byte from a file on an nfs-mounted file system with the server's file system mounted -async (239 usec versus 19 usec averaged over for 10^4 futimes()s and 10^6 read()s). Bruce OK, so how about instead of use VOP_SETATTR, we just try to VOP_READ one byte of data. It will run with the speed of read (and indeed since we just mapped in the header above, the data should be in the cache). It has the benefit of speed and not requiring the user to own the file. It has the drawback of requiring that the file be readable though most executables are set to be readable. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Sun May 4 19:43:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04B2237B401; Sun, 4 May 2003 19:43:04 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43FDF43F3F; Sun, 4 May 2003 19:43:02 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id MAA08778; Mon, 5 May 2003 12:42:51 +1000 Date: Mon, 5 May 2003 12:42:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick In-Reply-To: <200305042351.h44Np2Th017215@beastie.mckusick.com> Message-ID: <20030505113734.I6343@gamplex.bde.org> References: <200305042351.h44Np2Th017215@beastie.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 02:43:04 -0000 On Sun, 4 May 2003, Kirk McKusick wrote: > From: Bruce Evans > ... > This doesn't work unless the user has permission to change the atime > using utimes(2) with a non-NULL times pointer. > ... > OK, so how about instead of use VOP_SETATTR, we just try to VOP_READ > one byte of data. It will run with the speed of read (and indeed since > we just mapped in the header above, the data should be in the cache). > It has the benefit of speed and not requiring the user to own the file. > It has the drawback of requiring that the file be readable though most > executables are set to be readable. It would work better than that. VOP_READ() works right here since the permissions checks are done at the vfs level at open(2) time, not on every VOP_READ() or read(2). I think VOP_SETATTR() should work similarly: do permissions checks at the vfs level using VOP_ACCESS() instead of in every file system, so that there is less duplicated code and the permissions checks don't get in the way when you don't want them. This change is now easy for at least setting times. In Lite2, ufs_setattr() had to dereference `ip' for its permissions check for times, but this detail is now pushed down to VOP_ACCESS() using the VADMIN flag. There is a new reference to `ip' for SF_SNAPSHOT, but this is unrelated to normal permissions except it can cause EPERM to be returned for reasons not documented in utimes.2. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun May 4 23:17:25 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EB9237B401; Sun, 4 May 2003 23:17:25 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF16F43FAF; Sun, 4 May 2003 23:17:24 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h456HNTh017652; Sun, 4 May 2003 23:17:23 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305050617.h456HNTh017652@beastie.mckusick.com> To: Bruce Evans In-Reply-To: Your message of "Mon, 05 May 2003 12:42:50 +1000." <20030505113734.I6343@gamplex.bde.org> Date: Sun, 04 May 2003 23:17:23 -0700 From: Kirk McKusick cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 06:17:25 -0000 > Date: Mon, 5 May 2003 12:42:50 +1000 (EST) > From: Bruce Evans > X-X-Sender: bde@gamplex.bde.org > To: Kirk McKusick > cc: Jens Schweikhardt , "" , > Brian Buhrow > Subject: Re: Access times on executables (kern/25777) > In-Reply-To: <200305042351.h44Np2Th017215@beastie.mckusick.com> > X-ASK-Info: Whitelist match > > On Sun, 4 May 2003, Kirk McKusick wrote: > > > From: Bruce Evans > > ... > > This doesn't work unless the user has permission to change the atime > > using utimes(2) with a non-NULL times pointer. > > ... > > OK, so how about instead of use VOP_SETATTR, we just try to VOP_READ > > one byte of data. It will run with the speed of read (and indeed since > > we just mapped in the header above, the data should be in the cache). > > It has the benefit of speed and not requiring the user to own the file. > > It has the drawback of requiring that the file be readable though most > > executables are set to be readable. > > It would work better than that. VOP_READ() works right here since the > permissions checks are done at the vfs level at open(2) time, not on every > VOP_READ() or read(2). > > I think VOP_SETATTR() should work similarly: do permissions checks at > the vfs level using VOP_ACCESS() instead of in every file system, so > that there is less duplicated code and the permissions checks don't > get in the way when you don't want them. This change is now easy for > at least setting times. In Lite2, ufs_setattr() had to dereference > `ip' for its permissions check for times, but this detail is now pushed > down to VOP_ACCESS() using the VADMIN flag. There is a new reference > to `ip' for SF_SNAPSHOT, but this is unrelated to normal permissions > except it can cause EPERM to be returned for reasons not documented > in utimes.2. > > Bruce It will work right on the local filesystem, but I think that it would still be broken on NFS since NFS does permission checking on every RPC. Still, I think that VOP_READ is likely to be more efficient and work in a higher percentage of the times (always on the local filesystem and most of the time on NFS). Thus, I enclose my (new) proposed change below. Kirk McKusick =-=-=-=-=-=-= Index: sys/kern_exec.c =================================================================== RCS file: /usr/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.218 diff -c -r1.218 kern_exec.c *** kern_exec.c 1 Apr 2003 01:26:20 -0000 1.218 --- kern_exec.c 5 May 2003 06:15:21 -0000 *************** *** 598,603 **** --- 598,626 ---- exec_setregs(td, imgp->entry_addr, (u_long)(uintptr_t)stack_base, imgp->ps_strings); + /* + * At this point, it counts as an access. + * Ensure that atime gets updated if needed. + */ + if (!(textvp->v_mount->mnt_flag & MNT_NOATIME)) { + struct uio auio; + struct iovec aiov; + char ch; + + auio.uio_iov = &aiov; + auio.uio_iovcnt = 1; + aiov.iov_base = &ch; + aiov.iov_len = 1; + auio.uio_resid = 1; + auio.uio_offset = 0; + auio.uio_segflg = UIO_SYSSPACE; + auio.uio_rw = UIO_READ; + auio.uio_td = td; + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); + (void) VOP_READ(textvp, &auio, 0, p->p_ucred); + VOP_UNLOCK(textvp, 0, td); + } + done1: /* * Free any resources malloc'd earlier that we didn't use. From owner-freebsd-arch@FreeBSD.ORG Sun May 4 23:57:28 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F9E337B401; Sun, 4 May 2003 23:57:28 -0700 (PDT) Received: from builder.freebsdmall.com (builder.freebsdmall.com [65.86.180.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 731B043FB1; Sun, 4 May 2003 23:57:27 -0700 (PDT) (envelope-from murray@builder.freebsdmall.com) Received: (from root@localhost) by builder.freebsdmall.com (8.12.9/8.11.6) id h456vKZM099687; Sun, 4 May 2003 23:57:20 -0700 (PDT) (envelope-from murray) Date: Sun, 4 May 2003 23:57:20 -0700 From: Murray Stokely To: David Magda Message-ID: <20030504235720.B225@freebsdmall.com> References: <200304182047.h3IKlhIZ000817@number6.magda.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200304182047.h3IKlhIZ000817@number6.magda.ca>; from dmagda+fbugs@magda.ca on Fri, Apr 18, 2003 at 04:47:43PM -0400 X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D cc: arch@freebsd.org cc: jeff@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/51137: config(8) should check if a scheduler is selected X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 06:57:28 -0000 On Fri, Apr 18, 2003 at 04:47:43PM -0400, David Magda wrote: > Make config(8) check to see that a scheduler is there. I have also been bitten by this and I agree that it would be a nice change. Any chance you can submit a patch? - Murray From owner-freebsd-arch@FreeBSD.ORG Mon May 5 01:00:31 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E1037B401; Mon, 5 May 2003 01:00:31 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2165943FA3; Mon, 5 May 2003 01:00:30 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h4580Bp9001646; Mon, 5 May 2003 18:00:15 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h45800LV001639; Mon, 5 May 2003 18:00:00 +1000 (EST) Date: Mon, 5 May 2003 18:00:00 +1000 From: Peter Jeremy To: Kirk McKusick Message-ID: <20030505080000.GA1595@cirb503493.alcatel.com.au> References: <20030504110643.Q1248@gamplex.bde.org> <200305042351.h44Np2Th017215@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305042351.h44Np2Th017215@beastie.mckusick.com> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org cc: Jens Schweikhardt cc: Brian Buhrow Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 08:00:32 -0000 On Sun, May 04, 2003 at 04:51:02PM -0700, Kirk McKusick wrote: >OK, so how about instead of use VOP_SETATTR, we just try to VOP_READ >one byte of data. ... >It has the drawback of requiring that the file be readable though most >executables are set to be readable. I think it's common for set[gu]id executables not to be readable. Though, looking at my systems, I can only find xterm (from 4.3.0) and Xwrapper (from 3.3.6) that restrict read access more than execute access. Peter From owner-freebsd-arch@FreeBSD.ORG Mon May 5 01:47:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6701137B401 for ; Mon, 5 May 2003 01:47:03 -0700 (PDT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6478743FAF for ; Mon, 5 May 2003 01:47:02 -0700 (PDT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h458l1mF055060 for ; Mon, 5 May 2003 12:47:01 +0400 (MSD) Date: Mon, 5 May 2003 12:47:01 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 08:47:03 -0000 As stated in http://www.freebsd.org/cgi/query-pr.cgi?pr=50923 rfork(RFPROC|RFMEM) in 4.8-STABLE and 5.0-CURRENT requires RFTHREAD flag but it is not even mentioned in man page. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-arch@FreeBSD.ORG Mon May 5 02:14:20 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25D8D37B401; Mon, 5 May 2003 02:14:20 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9382043FA3; Mon, 5 May 2003 02:14:18 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h459EHE08503; Mon, 5 May 2003 11:14:17 +0200 (MEST) Date: Mon, 5 May 2003 11:14:17 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030501191027.GA53801@madman.celabo.org> Message-ID: <20030505110601.H53365@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 09:14:20 -0000 On Thu, 1 May 2003, Jacques A. Vidrine wrote: JAV> (c) Hide all symbols, except those that are likely to JAV> be candidates to be overridden. malloc/free seem JAV> to be the only ones here. As far as I know, all programs from J.Schilling (cdrecord, star, ...) carry their own printf (and a good other half of libc). I suppose there are others that do this. While overriding libc functions is not exactly standard supported (as far as I understand), it has been used ever since. If there are un-overridable functions (for whatever reasons) they should be documented somewhere (say in the man page of that function). We should not expect application writers/porters to dig around in libc internals. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Mon May 5 04:30:48 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6FA237B401; Mon, 5 May 2003 04:30:48 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2946243F85; Mon, 5 May 2003 04:30:47 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id VAA07088; Mon, 5 May 2003 21:30:41 +1000 Date: Mon, 5 May 2003 21:30:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick In-Reply-To: <200305050617.h456HNTh017652@beastie.mckusick.com> Message-ID: <20030505205914.D8183@gamplex.bde.org> References: <200305050617.h456HNTh017652@beastie.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 11:30:49 -0000 On Sun, 4 May 2003, Kirk McKusick wrote: > > From: Bruce Evans > > > > On Sun, 4 May 2003, Kirk McKusick wrote: > > > OK, so how about instead of use VOP_SETATTR, we just try to VOP_READ > > > one byte of data. It will run with the speed of read (and indeed since > > > we just mapped in the header above, the data should be in the cache). > > > It has the benefit of speed and not requiring the user to own the file. > > > It has the drawback of requiring that the file be readable though most > > > executables are set to be readable. > > > > It would work better than that. VOP_READ() works right here since the > > permissions checks are done at the vfs level at open(2) time, not on every > > VOP_READ() or read(2). > > > > I think VOP_SETATTR() should work similarly: do permissions checks at > > the vfs level using VOP_ACCESS() instead of in every file system, so > > that there is less duplicated code and the permissions checks don't > > get in the way when you don't want them. This change is now easy for > > at least setting times. In Lite2, ufs_setattr() had to dereference > It will work right on the local filesystem, but I think that it would > still be broken on NFS since NFS does permission checking on every RPC. I assume that "it" is VOP_ACCESS() here. Yes, we don't want to go near VOP_ACCESS() or the normal path of VOP_SETATTR(set_times) for remote file systems since the access checking would be very expensive. > Still, I think that VOP_READ is likely to be more efficient and work in > a higher percentage of the times (always on the local filesystem and > most of the time on NFS). Thus, I enclose my (new) proposed change below. > Index: sys/kern_exec.c > =================================================================== > RCS file: /usr/ncvs/src/sys/kern/kern_exec.c,v > retrieving revision 1.218 > diff -c -r1.218 kern_exec.c > *** kern_exec.c 1 Apr 2003 01:26:20 -0000 1.218 > --- kern_exec.c 5 May 2003 06:15:21 -0000 > *************** > *** 598,603 **** > --- 598,626 ---- > exec_setregs(td, imgp->entry_addr, > (u_long)(uintptr_t)stack_base, imgp->ps_strings); > > + /* > + * At this point, it counts as an access. > + * Ensure that atime gets updated if needed. > + */ > + if (!(textvp->v_mount->mnt_flag & MNT_NOATIME)) { Note that this check doesn't help for the most expensive case (nfs), since nfs doesn't implement the noatime mount flag so it never sets MNT_NOATIME. However, nfs doesn't actually implement setting of atimes either -- if the read goes to the server, then the server sets the atime (unless the file system on the server is mounted -noatime) and the change is eventually seen by the clent, but most reads on the client are from the buffer cache so they don't affect the atime on the server unless we tell it, and we never tell it directly. This seems to be required for reasonable efficiency. > + struct uio auio; > + struct iovec aiov; > + char ch; > + > + auio.uio_iov = &aiov; > + auio.uio_iovcnt = 1; > + aiov.iov_base = &ch; > + aiov.iov_len = 1; > + auio.uio_resid = 1; > + auio.uio_offset = 0; > + auio.uio_segflg = UIO_SYSSPACE; > + auio.uio_rw = UIO_READ; > + auio.uio_td = td; > + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); > + (void) VOP_READ(textvp, &auio, 0, p->p_ucred); In the nfs clase, this read is very unlikely to do anything, because we read the header earlier so this read is very likely to be from the buffer cache. Then the previous read may have set the atime, but this one won't. > + VOP_UNLOCK(textvp, 0, td); > + } > + > done1: > /* > * Free any resources malloc'd earlier that we didn't use. > I think this version would be OK if it skipped remote file systems explicitly. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon May 5 04:48:06 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8506937B401; Mon, 5 May 2003 04:48:06 -0700 (PDT) Received: from tomts9-srv.bellnexxia.net (tomts9.bellnexxia.net [209.226.175.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D11443F3F; Mon, 5 May 2003 04:48:02 -0700 (PDT) (envelope-from dmagda@magda.ca) Received: from number6.magda.ca ([64.229.225.45]) by tomts9-srv.bellnexxia.netESMTP <20030505114801.IELI12868.tomts9-srv.bellnexxia.net@number6.magda.ca>; Mon, 5 May 2003 07:48:01 -0400 Received: from number6.magda.ca (localhost.magda.ca [127.0.0.1]) by number6.magda.ca (8.12.9/8.12.7) with ESMTP id h45Bm1hQ000245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2003 07:48:01 -0400 (EDT) (envelope-from dmagda@magda.ca) Received: (from dmagda@localhost) by number6.magda.ca (8.12.9/8.12.7/Submit) id h45Bm13E000244; Mon, 5 May 2003 07:48:01 -0400 (EDT) (envelope-from dmagda) Date: Mon, 5 May 2003 07:48:01 -0400 From: David Magda To: Murray Stokely Message-ID: <20030505114759.GA238@number6.magda.ca> References: <200304182047.h3IKlhIZ000817@number6.magda.ca> <20030504235720.B225@freebsdmall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030504235720.B225@freebsdmall.com> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org cc: jeff@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/51137: config(8) should check if a scheduler is selected X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Magda List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 11:48:06 -0000 On Sun, May 04, 2003 at 11:57:20PM -0700, Murray Stokely wrote: > I have also been bitten by this and I agree that it would be a nice > change. Any chance you can submit a patch? You really don't want me to code -- trust me on this. :> From owner-freebsd-arch@FreeBSD.ORG Mon May 5 06:53:43 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C74537B401 for ; Mon, 5 May 2003 06:53:43 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82BE143FBD for ; Mon, 5 May 2003 06:53:42 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0250.cvx22-bradley.dialup.earthlink.net ([209.179.198.250] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19CgPS-0007Q2-00; Mon, 05 May 2003 06:53:38 -0700 Message-ID: <3EB66C92.304110A4@mindspring.com> Date: Mon, 05 May 2003 06:52:18 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a425d9fdc57a87e0409ec6b597a9d6ce5e387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 13:53:43 -0000 Igor Sysoev wrote: > As stated in http://www.freebsd.org/cgi/query-pr.cgi?pr=50923 > rfork(RFPROC|RFMEM) in 4.8-STABLE and 5.0-CURRENT requires RFTHREAD flag > but it is not even mentioned in man page. This makes the stack glue implicit. You can also use explicit stack glue. Most people using the RFPROC flag use explicit stack glue, i.e. we carry arounbd our own assembly language trampoline code for stack setup that John Dyson originally wrote. I think wanting RFPROC to act like Linux's "clone" system call is probably wrong. -- Terry From owner-freebsd-arch@FreeBSD.ORG Mon May 5 07:07:58 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D34B937B401 for ; Mon, 5 May 2003 07:07:58 -0700 (PDT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E3E743F75 for ; Mon, 5 May 2003 07:07:57 -0700 (PDT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h45E7tmF061397; Mon, 5 May 2003 18:07:55 +0400 (MSD) Date: Mon, 5 May 2003 18:07:55 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: Terry Lambert In-Reply-To: <3EB66C92.304110A4@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 14:07:59 -0000 On Mon, 5 May 2003, Terry Lambert wrote: > Igor Sysoev wrote: > > As stated in http://www.freebsd.org/cgi/query-pr.cgi?pr=50923 > > rfork(RFPROC|RFMEM) in 4.8-STABLE and 5.0-CURRENT requires RFTHREAD flag > > but it is not even mentioned in man page. > > This makes the stack glue implicit. You can also use explicit > stack glue. Most people using the RFPROC flag use explicit > stack glue, i.e. we carry arounbd our own assembly language > trampoline code for stack setup that John Dyson originally > wrote. I think wanting RFPROC to act like Linux's "clone" > system call is probably wrong. What is stack glue ? I use rfork_thread(3) wrapper that allows to setup another stack for rfork()ed process. What RFTHREAD flag does ? By the way linuxthreads port always uses RFTHREAD flag. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-arch@FreeBSD.ORG Mon May 5 07:21:28 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EE6F37B401; Mon, 5 May 2003 07:21:28 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9E643F93; Mon, 5 May 2003 07:21:27 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0250.cvx22-bradley.dialup.earthlink.net ([209.179.198.250] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19CgqI-0005AE-00; Mon, 05 May 2003 07:21:23 -0700 Message-ID: <3EB67318.17C3A06C@mindspring.com> Date: Mon, 05 May 2003 07:20:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harti Brandt References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4fb8c1b037403cfd6f2b438097e994dfe93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 14:21:28 -0000 Harti Brandt wrote: > On Thu, 1 May 2003, Jacques A. Vidrine wrote: > JAV> (c) Hide all symbols, except those that are likely to > JAV> be candidates to be overridden. malloc/free seem > JAV> to be the only ones here. > > As far as I know, all programs from J.Schilling (cdrecord, star, ...) > carry their own printf (and a good other half of libc). I suppose there > are others that do this. While overriding libc functions is not exactly > standard supported (as far as I understand), it has been used ever since. > If there are un-overridable functions (for whatever reasons) they should > be documented somewhere (say in the man page of that function). We should > not expect application writers/porters to dig around in libc internals. Most commercial applications vendors I have ever worked for have carried around their own libraries of functions that were potentially implemented differently on different platforms, and "printf" has always been at the top of this list, along with the entire curses library, the entire termcap library, and all termcap entries used by that library. It just makes good portability sense to carry around anything you suspect of being platform dependent, and minimizing your system-dependent API "footprint" for your application, as much as possible. -- Terry From owner-freebsd-arch@FreeBSD.ORG Mon May 5 10:31:07 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC7CC37B401; Mon, 5 May 2003 10:31:07 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4D1943F85; Mon, 5 May 2003 10:31:06 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h45HV5Th018656; Mon, 5 May 2003 10:31:06 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305051731.h45HV5Th018656@beastie.mckusick.com> To: Bruce Evans In-Reply-To: Your message of "Mon, 05 May 2003 21:30:39 +1000." <20030505205914.D8183@gamplex.bde.org> Date: Mon, 05 May 2003 10:31:05 -0700 From: Kirk McKusick cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 17:31:08 -0000 As you note, NFS does not implement MNT_NOATIME. But since it does not update the atime when the read is done and since the data will already be in the cache from the earlier read of the header, there is unlikely to be an efficiency impact for NFS. Thus, it does not seem necessary to add code to explicitly exclude NFS. So, I would be inclined to just put the code in as proposed. I would rather not have a bunch of filesystem exceptions in otherwise generic code. Kirk McKusick > Date: Mon, 5 May 2003 21:30:39 +1000 (EST) > From: Bruce Evans > X-X-Sender: bde@gamplex.bde.org > To: Kirk McKusick > cc: Jens Schweikhardt , arch@FreeBSD.org, > Brian Buhrow > Subject: Re: Access times on executables (kern/25777) > In-Reply-To: <200305050617.h456HNTh017652@beastie.mckusick.com> > X-ASK-Info: Whitelist match > > On Sun, 4 May 2003, Kirk McKusick wrote: > > > Index: sys/kern_exec.c > > =================================================================== > > RCS file: /usr/ncvs/src/sys/kern/kern_exec.c,v > > retrieving revision 1.218 > > diff -c -r1.218 kern_exec.c > > *** kern_exec.c 1 Apr 2003 01:26:20 -0000 1.218 > > --- kern_exec.c 5 May 2003 06:15:21 -0000 > > *************** > > *** 598,603 **** > > --- 598,626 ---- > > exec_setregs(td, imgp->entry_addr, > > (u_long)(uintptr_t)stack_base, imgp->ps_strings); > > > > + /* > > + * At this point, it counts as an access. > > + * Ensure that atime gets updated if needed. > > + */ > > + if (!(textvp->v_mount->mnt_flag & MNT_NOATIME)) { > > Note that this check doesn't help for the most expensive case (nfs), > since nfs doesn't implement the noatime mount flag so it never sets > MNT_NOATIME. However, nfs doesn't actually implement setting of atimes > either -- if the read goes to the server, then the server sets the atime > (unless the file system on the server is mounted -noatime) and the change > is eventually seen by the clent, but most reads on the client are from > the buffer cache so they don't affect the atime on the server unless we > tell it, and we never tell it directly. This seems to be required for > reasonable efficiency. > > > + struct uio auio; > > + struct iovec aiov; > > + char ch; > > + > > + auio.uio_iov = &aiov; > > + auio.uio_iovcnt = 1; > > + aiov.iov_base = &ch; > > + aiov.iov_len = 1; > > + auio.uio_resid = 1; > > + auio.uio_offset = 0; > > + auio.uio_segflg = UIO_SYSSPACE; > > + auio.uio_rw = UIO_READ; > > + auio.uio_td = td; > > + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); > > + (void) VOP_READ(textvp, &auio, 0, p->p_ucred); > > In the nfs clase, this read is very unlikely to do anything, because > we read the header earlier so this read is very likely to be from > the buffer cache. Then the previous read may have set the atime, but > this one won't. > > > + VOP_UNLOCK(textvp, 0, td); > > + } > > + > > done1: > > /* > > * Free any resources malloc'd earlier that we didn't use. > > > > I think this version would be OK if it skipped remote file systems > explicitly. > > Bruce From owner-freebsd-arch@FreeBSD.ORG Mon May 5 10:54:28 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F51C37B401 for ; Mon, 5 May 2003 10:54:28 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E13B43FA3 for ; Mon, 5 May 2003 10:54:27 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id AD3D44; Mon, 5 May 2003 12:54:26 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 299DE78C66; Mon, 5 May 2003 12:54:26 -0500 (CDT) Date: Mon, 5 May 2003 12:54:26 -0500 From: "Jacques A. Vidrine" To: Harti Brandt Message-ID: <20030505175426.GA19352@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , freebsd-arch@freebsd.org References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030505110601.H53365@beagle.fokus.fraunhofer.de> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 17:54:28 -0000 On Mon, May 05, 2003 at 11:14:17AM +0200, Harti Brandt wrote: > On Thu, 1 May 2003, Jacques A. Vidrine wrote: > > JAV> (c) Hide all symbols, except those that are likely to > JAV> be candidates to be overridden. malloc/free seem > JAV> to be the only ones here. > > As far as I know, all programs from J.Schilling (cdrecord, star, ...) > carry their own printf (and a good other half of libc). I suppose there > are others that do this. While overriding libc functions is not exactly > standard supported (as far as I understand), it has been used ever since. > If there are un-overridable functions (for whatever reasons) they should > be documented somewhere (say in the man page of that function). We should > not expect application writers/porters to dig around in libc internals. There are no un-overrideable functions. I have never suggested making any function un-overrideable. Perhaps you are thinking of the standards folk who claimed that qpopper had no business defining its own version of `strlcpy'. I did a survey of the currently-built binary packages for 5.x. I found that 714 packages define functions with the same name as those defined in libc, and that there were 407 unique functions which were hijacked in this way. Over 25% of these functions are, happily, already hidden in libc. The remaining 296 different functions, ranging from `atoi' to `mkstemp' to `vis', all may indicate subtle bugs. (Realistically, the number of truly buggy combinations is probably low.) Some of these applications really want to override the functions for their own purposes, like arts which overrides the hidden `open' stub. Note that these applications work just fine even though the symbols are `hidden' ... that is not the issue. The rest of the applications seem to be defining their own versions of some functions for portability purposes. Defining `printf' seems pretty funny, but J. Schilling is not the only author who has done so. In these cases, it seems dangerous to have libc calling into the application's implementation, e.g. calling Mozilla's `mkstemp' in order to implement `hashopen', or calling Smiley's `bsearch' in order to implement `nsdispatch', or calling MySQL's `strstr' to implement `syslog' and so on and on. So, I advocate hiding all symbols in libc by default. The Real World doesn't seem to care whether the symbols are defined by any standard or not. Or maybe someone wants to go fix the 714 `broken' ports and the innumerable other applications that were not included in my survey. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Mon May 5 10:54:29 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D18237B401 for ; Mon, 5 May 2003 10:54:29 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB15743FA3 for ; Mon, 5 May 2003 10:54:28 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 6355626 for ; Mon, 5 May 2003 12:54:28 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 17AFB78C69; Mon, 5 May 2003 12:54:28 -0500 (CDT) Date: Mon, 5 May 2003 12:54:28 -0500 From: "Jacques A. Vidrine" To: freebsd-arch@FreeBSD.org Message-ID: <20030505175428.GA19275@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030503201409.GA41554@dragon.nuxi.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 17:54:29 -0000 On Sat, May 03, 2003 at 01:14:09PM -0700, David O'Brien wrote: > On Thu, May 01, 2003 at 01:28:20PM -0500, Jacques A. Vidrine wrote: > > A lot of folks are focused on qpopper and strlcpy. I believe that > > the big picture is being missed. I moved this thread to freebsd-arch > > so that we could discuss how to hide all (or most, or non-standard) > > symbols in libc. Not so that we could argue about this particular > > commit. > > Perhaps you and a contentent of the rest are looking at different > pictures. In the our big picture, we don't want this being done to most > of libc. You don't want /what/ being done to most of libc? (No, really, I'm not sure what you mean.) > > I'm backing out the commit in good faith and in the hopes that the > > big picture comes more clearly into focus. > > Thanks. Do you also want to `fix' the other ports that define their own strlcpy? cyrus-imapd-2.0.17 cyrus-imapd-2.1.12 cyrus-imspd-v1.6a3 gnapster-1.5.0 hotwayd-0.51 isakmpd-20021118 openssh-3.5 snort-1.9.0 totd-1.3_3 xpilot-4.5.3 Probably others. What about the hundreds of other ports that also define symbols that we use from within libc? Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Mon May 5 11:44:01 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3983B37B401; Mon, 5 May 2003 11:44:01 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4857943F75; Mon, 5 May 2003 11:44:00 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h45IhrBg026117; Mon, 5 May 2003 14:43:53 -0400 (EDT) Received: from localhost (eischen@localhost)h45Ihrkv026114; Mon, 5 May 2003 14:43:53 -0400 (EDT) Date: Mon, 5 May 2003 14:43:53 -0400 (EDT) From: Daniel Eischen To: "Jacques A. Vidrine" In-Reply-To: <20030505175426.GA19352@madman.celabo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 18:44:01 -0000 On Mon, 5 May 2003, Jacques A. Vidrine wrote: > On Mon, May 05, 2003 at 11:14:17AM +0200, Harti Brandt wrote: > > On Thu, 1 May 2003, Jacques A. Vidrine wrote: > > > > JAV> (c) Hide all symbols, except those that are likely to > > JAV> be candidates to be overridden. malloc/free seem > > JAV> to be the only ones here. > > > > As far as I know, all programs from J.Schilling (cdrecord, star, ...) > > carry their own printf (and a good other half of libc). I suppose there > > are others that do this. While overriding libc functions is not exactly > > standard supported (as far as I understand), it has been used ever since. > > If there are un-overridable functions (for whatever reasons) they should > > be documented somewhere (say in the man page of that function). We should > > not expect application writers/porters to dig around in libc internals. > > There are no un-overrideable functions. I have never suggested making > any function un-overrideable. Perhaps you are thinking of the standards > folk who claimed that qpopper had no business defining its own version > of `strlcpy'. > > I did a survey of the currently-built binary packages for 5.x. I > found that 714 packages define functions with the same name as those > defined in libc, and that there were 407 unique functions which were > hijacked in this way. > > Over 25% of these functions are, happily, already hidden in libc. The > remaining 296 different functions, ranging from `atoi' to `mkstemp' to > `vis', all may indicate subtle bugs. (Realistically, the number of > truly buggy combinations is probably low.) > > Some of these applications really want to override the functions for > their own purposes, like arts which overrides the hidden `open' stub. > Note that these applications work just fine even though the symbols are > `hidden' ... that is not the issue. > > The rest of the applications seem to be defining their own versions of > some functions for portability purposes. Defining `printf' seems pretty > funny, but J. Schilling is not the only author who has done so. > In these cases, it seems dangerous to have libc calling into the > application's implementation, e.g. calling Mozilla's `mkstemp' in order > to implement `hashopen', or calling Smiley's `bsearch' in order to > implement `nsdispatch', or calling MySQL's `strstr' to implement > `syslog' and so on and on. > > > So, I advocate hiding all symbols in libc by default. The Real World > doesn't seem to care whether the symbols are defined by any standard or > not. I would tend to agree. For all the naysayers, perhaps have a look at NetBSD's namespace.h: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/include/namespace.h?rev=1.76&content-type=text/x-cvsweb-markup -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Mon May 5 13:01:59 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2F6E37B420 for ; Mon, 5 May 2003 13:01:59 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84AD943FAF for ; Mon, 5 May 2003 13:01:58 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 12633 invoked from network); 5 May 2003 20:02:05 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 5 May 2003 20:02:05 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h45K1tdt015301; Mon, 5 May 2003 16:01:56 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200305050617.h456HNTh017652@beastie.mckusick.com> Date: Mon, 05 May 2003 16:02:03 -0400 (EDT) From: John Baldwin To: Kirk McKusick cc: Brian Buhrow cc: arch@FreeBSD.org cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 20:02:00 -0000 On 05-May-2003 Kirk McKusick wrote: > + auio.uio_td = td; > + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); > + (void) VOP_READ(textvp, &auio, 0, p->p_ucred); This should use td->td_ucred instead of p->p_ucred. > + VOP_UNLOCK(textvp, 0, td); > + } > + -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Mon May 5 13:25:59 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68A8F37B401; Mon, 5 May 2003 13:25:58 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59C7643F75; Mon, 5 May 2003 13:25:57 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 0871E530F; Mon, 5 May 2003 22:25:54 +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: "Jacques A. Vidrine" References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> From: Dag-Erling Smorgrav Date: Mon, 05 May 2003 22:25:54 +0200 In-Reply-To: <20030505175426.GA19352@madman.celabo.org> (Jacques A. Vidrine's message of "Mon, 5 May 2003 12:54:26 -0500") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 20:25:59 -0000 "Jacques A. Vidrine" writes: > So, I advocate hiding all symbols in libc by default. The Real World > doesn't seem to care whether the symbols are defined by any standard or > not. I'm with you, but I would also like to point out that there is a small number of ports which will require changes: ports like electricfence, boehm-gc and others that rely at least in part on replacing libc's malloc(), calloc(), realloc() and free(). DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Mon May 5 13:50:55 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F5A137B401; Mon, 5 May 2003 13:50:55 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AA8643F93; Mon, 5 May 2003 13:50:53 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h45KopMr040724; Tue, 6 May 2003 00:50:51 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h45KopbY040723; Tue, 6 May 2003 00:50:51 +0400 (MSD) Date: Tue, 6 May 2003 00:50:51 +0400 From: "Andrey A. Chernov" To: Dag-Erling Smorgrav Message-ID: <20030505205051.GA40572@nagual.pp.ru> References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 20:50:55 -0000 On Mon, May 05, 2003 at 22:25:54 +0200, Dag-Erling Smorgrav wrote: > "Jacques A. Vidrine" writes: > > So, I advocate hiding all symbols in libc by default. The Real World > > doesn't seem to care whether the symbols are defined by any standard or > > not. > > I'm with you, but I would also like to point out that there is a small > number of ports which will require changes: ports like electricfence, > boehm-gc and others that rely at least in part on replacing libc's > malloc(), calloc(), realloc() and free(). Unless my point was not clear from my previous posts, I advocate exact opposite: to unhide all standard symbols from libc, including here standard prefixes like str*. We must not encourage programmer error when he define standard function, it easily leads to unexpected results. Better reject such error automatically at the linkage stage. Programmers are always free to redefine their functions in case of conflict. From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:05:18 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADE1037B401; Mon, 5 May 2003 14:05:18 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1AE543F93; Mon, 5 May 2003 14:05:17 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 468C3530F; Mon, 5 May 2003 23:05:16 +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: "Andrey A. Chernov" References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> From: Dag-Erling Smorgrav Date: Mon, 05 May 2003 23:05:15 +0200 In-Reply-To: <20030505205051.GA40572@nagual.pp.ru> (Andrey A. Chernov's message of "Tue, 6 May 2003 00:50:51 +0400") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 21:05:19 -0000 "Andrey A. Chernov" writes: > Better reject such error automatically at the linkage stage. Programmers > are always free to redefine their functions in case of conflict. There must be something wrong with my MUA, as I can't see a patch attached to your message. Could you please resend it? DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:13:53 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AE3337B401; Mon, 5 May 2003 14:13:53 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93DD243FBD; Mon, 5 May 2003 14:13:52 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h45LDpTh019142; Mon, 5 May 2003 14:13:51 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305052113.h45LDpTh019142@beastie.mckusick.com> To: John Baldwin In-Reply-To: Your message of "Mon, 05 May 2003 16:02:03 EDT." Date: Mon, 05 May 2003 14:13:51 -0700 From: Kirk McKusick cc: Brian Buhrow cc: arch@FreeBSD.org cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 21:13:53 -0000 Date: Mon, 05 May 2003 16:02:03 -0400 (EDT) From: John Baldwin To: Kirk McKusick Subject: Re: Access times on executables (kern/25777) Cc: Jens Schweikhardt , Brian Buhrow , arch@FreeBSD.org, Bruce Evans X-ASK-Info: Whitelist match On 05-May-2003 Kirk McKusick wrote: > + auio.uio_td = td; > + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); > + (void) VOP_READ(textvp, &auio, 0, p->p_ucred); This should use td->td_ucred instead of p->p_ucred. > + VOP_UNLOCK(textvp, 0, td); > + } > + -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Thanks for pointing that out. I will make that update before I check anything in. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:20:30 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6D3737B401; Mon, 5 May 2003 14:20:30 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA0DA43FBD; Mon, 5 May 2003 14:20:28 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h45LKRMr041521; Tue, 6 May 2003 01:20:28 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h45LKRKK041520; Tue, 6 May 2003 01:20:27 +0400 (MSD) Date: Tue, 6 May 2003 01:20:27 +0400 From: "Andrey A. Chernov" To: Dag-Erling Smorgrav Message-ID: <20030505212027.GA41263@nagual.pp.ru> References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 21:20:31 -0000 On Mon, May 05, 2003 at 23:05:15 +0200, Dag-Erling Smorgrav wrote: > "Andrey A. Chernov" writes: > > Better reject such error automatically at the linkage stage. Programmers > > are always free to redefine their functions in case of conflict. > > There must be something wrong with my MUA, as I can't see a patch > attached to your message. Could you please resend it? Which one do you mean? If one for affected ports, it is corresponding maintainers task. If one for libc, it is difficult (for me). The problem is that threads people do all that hiding in first place for their own needs. To simple unhide it, breaks threads. I think they must change replacement they need for functions to be truely internal, it makes all unhiding automatically. From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:25:49 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7561D37B401 for ; Mon, 5 May 2003 14:25:49 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC73C43FBF for ; Mon, 5 May 2003 14:25:48 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 56168530E; Mon, 5 May 2003 23:25:47 +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: "Andrey A. Chernov" References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505212027.GA41263@nagual.pp.ru> From: Dag-Erling Smorgrav Date: Mon, 05 May 2003 23:25:46 +0200 In-Reply-To: <20030505212027.GA41263@nagual.pp.ru> (Andrey A. Chernov's message of "Tue, 6 May 2003 01:20:27 +0400") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 21:25:49 -0000 "Andrey A. Chernov" writes: > On Mon, May 05, 2003 at 23:05:15 +0200, Dag-Erling Smorgrav wrote: > > "Andrey A. Chernov" writes: > > > Better reject such error automatically at the linkage stage. Programmers > > > are always free to redefine their functions in case of conflict. > > There must be something wrong with my MUA, as I can't see a patch > > attached to your message. Could you please resend it? > Which one do you mean? The patch that makes the linker produce warnings or errors like you suggested. You seemed so convinced it was the best solution that I figured you had to have a patch ready to commit. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:33:07 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 418F337B401 for ; Mon, 5 May 2003 14:33:07 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D808943FAF for ; Mon, 5 May 2003 14:33:05 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h45LX4Lr046564 for ; Mon, 5 May 2003 23:33:04 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 05 May 2003 14:28:08 PDT." <200305052128.h45LS8Zk011878@repoman.freebsd.org> Date: Mon, 05 May 2003 23:33:04 +0200 Message-ID: <46563.1052170384@critter.freebsd.dk> Subject: Re: cvs commit: src/sbin Makefile src/sbin/bsdlabel Makefile X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 21:33:07 -0000 With reference to the commit below, we need to decide our strategy with such disk maintenance tools. Do we compile&install only what is used for the current platform ? Do we compile&install all tools on all platforms ? I don't particularly care one way or the other. The intent is that the tools work on all platforms, but since we don't cross-build boot-code, there is some natural limits to their usefulness. For make [cross-]release, we can build the necessary tools as release tools, so that does not necesarily factor in this discussion. Poul-Henning In message <200305052128.h45LS8Zk011878@repoman.freebsd.org>, Poul-Henning Kamp writes: >phk 2003/05/05 14:28:08 PDT > > FreeBSD src repository > > Modified files: > sbin Makefile > sbin/bsdlabel Makefile > Log: > Compile bsdlabel on all platforms. > > Install a link to the disklabel(8) name on i386 and alpha platforms. > > Leave old disklabel(8) sources intact but disconnected from the build > for now. > > Revision Changes Path > 1.120 +1 -6 src/sbin/Makefile > 1.15 +10 -0 src/sbin/bsdlabel/Makefile > -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon May 5 14:46:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C63937B401 for ; Mon, 5 May 2003 14:46:13 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FA2143F75 for ; Mon, 5 May 2003 14:46:12 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h45Lk6Mr042131; Tue, 6 May 2003 01:46:11 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h45Lk6Nj042130; Tue, 6 May 2003 01:46:06 +0400 (MSD) Date: Tue, 6 May 2003 01:46:06 +0400 From: "Andrey A. Chernov" To: Dag-Erling Smorgrav Message-ID: <20030505214605.GA41803@nagual.pp.ru> References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505212027.GA41263@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 21:46:13 -0000 On Mon, May 05, 2003 at 23:25:46 +0200, Dag-Erling Smorgrav wrote: > > The patch that makes the linker produce warnings or errors like you > suggested. You seemed so convinced it was the best solution that I > figured you had to have a patch ready to commit. I don't write one yet (since some functions are still hidden by threads). >From first look, it will be based on ".protected" gas instruction or something like. From owner-freebsd-arch@FreeBSD.ORG Mon May 5 15:02:45 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B50137B407 for ; Mon, 5 May 2003 15:02:45 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B1A043F3F for ; Mon, 5 May 2003 15:02:44 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h45M2hBg001796; Mon, 5 May 2003 18:02:43 -0400 (EDT) Received: from localhost (eischen@localhost)h45M2gBm001792; Mon, 5 May 2003 18:02:42 -0400 (EDT) Date: Mon, 5 May 2003 18:02:42 -0400 (EDT) From: Daniel Eischen To: "Andrey A. Chernov" In-Reply-To: <20030505205051.GA40572@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 22:02:45 -0000 On Tue, 6 May 2003, Andrey A. Chernov wrote: > On Mon, May 05, 2003 at 22:25:54 +0200, Dag-Erling Smorgrav wrote: > > "Jacques A. Vidrine" writes: > > > So, I advocate hiding all symbols in libc by default. The Real World > > > doesn't seem to care whether the symbols are defined by any standard or > > > not. > > > > I'm with you, but I would also like to point out that there is a small > > number of ports which will require changes: ports like electricfence, > > boehm-gc and others that rely at least in part on replacing libc's > > malloc(), calloc(), realloc() and free(). > > Unless my point was not clear from my previous posts, I advocate exact > opposite: to unhide all standard symbols from libc, including here > standard prefixes like str*. We must not encourage programmer error > when he define standard function, it easily leads to unexpected results. > Better reject such error automatically at the linkage stage. Programmers > are always free to redefine their functions in case of conflict. Can't you still do what you want even with the standard symbols hidden? -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Mon May 5 15:14:47 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2A2F37B401 for ; Mon, 5 May 2003 15:14:47 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8F0D43F93 for ; Mon, 5 May 2003 15:14:46 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h45MEkBg003625; Mon, 5 May 2003 18:14:46 -0400 (EDT) Received: from localhost (eischen@localhost)h45MEjVP003622; Mon, 5 May 2003 18:14:45 -0400 (EDT) Date: Mon, 5 May 2003 18:14:45 -0400 (EDT) From: Daniel Eischen To: "Andrey A. Chernov" In-Reply-To: <20030505214605.GA41803@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 22:14:47 -0000 On Tue, 6 May 2003, Andrey A. Chernov wrote: > On Mon, May 05, 2003 at 23:25:46 +0200, Dag-Erling Smorgrav wrote: > > > > The patch that makes the linker produce warnings or errors like you > > suggested. You seemed so convinced it was the best solution that I > > figured you had to have a patch ready to commit. > > I don't write one yet (since some functions are still hidden by threads). > From first look, it will be based on ".protected" gas instruction or > something like. As the person who went through libc and added most of the weak symbols in order to satisfy the needs of the threads library and to separate libc_r from libc, I would kindly suggest that you leave things alone. But if want to change things, please make sure they work with all the threads libraries that we currently have. I don't want the burden of doing this nor have it impact our current efforts. -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Mon May 5 15:16:44 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C22EF37B401 for ; Mon, 5 May 2003 15:16:44 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F9343F85 for ; Mon, 5 May 2003 15:16:43 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h45MGfMr042911; Tue, 6 May 2003 02:16:42 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h45MGflM042910; Tue, 6 May 2003 02:16:41 +0400 (MSD) Date: Tue, 6 May 2003 02:16:41 +0400 From: "Andrey A. Chernov" To: Daniel Eischen Message-ID: <20030505221641.GA42722@nagual.pp.ru> References: <20030505205051.GA40572@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 22:16:45 -0000 On Mon, May 05, 2003 at 18:02:42 -0400, Daniel Eischen wrote: > > Can't you still do what you want even with the standard symbols > hidden? If you mean to produce linker error for replaced standard functions in current hiding model (i.e. for threads) - I don't know - threads implementation is completely unknown to me to deal with. From owner-freebsd-arch@FreeBSD.ORG Mon May 5 15:24:43 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CA8E37B401 for ; Mon, 5 May 2003 15:24:43 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A496343FD7 for ; Mon, 5 May 2003 15:24:42 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h45MOfBg005155; Mon, 5 May 2003 18:24:41 -0400 (EDT) Received: from localhost (eischen@localhost)h45MOf3t005150; Mon, 5 May 2003 18:24:41 -0400 (EDT) Date: Mon, 5 May 2003 18:24:41 -0400 (EDT) From: Daniel Eischen To: "Andrey A. Chernov" In-Reply-To: <20030505221641.GA42722@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Dag-Erling Smorgrav cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 22:24:43 -0000 On Tue, 6 May 2003, Andrey A. Chernov wrote: > On Mon, May 05, 2003 at 18:02:42 -0400, Daniel Eischen wrote: > > > > Can't you still do what you want even with the standard symbols > > hidden? > > If you mean to produce linker error for replaced standard functions in > current hiding model (i.e. for threads) - I don't know - threads > implementation is completely unknown to me to deal with. The threads libraries don't have any strong symbols that don't begin with an underscore: $ nm /usr/obj/.../lib/libc_r/libc_r.so.5 | grep " T " If libc also doesn't have any strong symbols (at least for the functions you want to check), then I suppose you can check the linked application for these (strong) definitions. I don't know how to do it myself, but this may give you some idea. -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Mon May 5 15:52:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A928637B409 for ; Mon, 5 May 2003 15:52:02 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B1BA44141 for ; Mon, 5 May 2003 15:50:39 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h45MoMrO043564; Tue, 6 May 2003 02:50:26 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h45MoLhr043563; Tue, 6 May 2003 02:50:21 +0400 (MSD) Date: Tue, 6 May 2003 02:50:21 +0400 From: "Andrey A. Chernov" To: Daniel Eischen Message-ID: <20030505225021.GA43345@nagual.pp.ru> References: <20030505214605.GA41803@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 22:52:03 -0000 On Mon, May 05, 2003 at 18:14:45 -0400, Daniel Eischen wrote: > symbols in order to satisfy the needs of the threads library > and to separate libc_r from libc, I would kindly suggest that > you leave things alone. But if want to change things, please > make sure they work with all the threads libraries that we > currently have. I don't want the burden of doing this nor > have it impact our current efforts. Please calm down, I don't want to break threads badly or anything like. Especially when I don't understands threads details. At this stage we just discuss here how to make things better. My point will be clear answering on this simple question: What produce less errors in application and libraries? a) Allow application to replace any standard function. b) Produce linker error on such attempts. Please also note that I not treat functions like err(), warn() etc. as standard, so namespace.h is right for them. From owner-freebsd-arch@FreeBSD.ORG Mon May 5 16:06:47 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B077137B401 for ; Mon, 5 May 2003 16:06:47 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E76543F3F for ; Mon, 5 May 2003 16:06:47 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h45N6kBg011962; Mon, 5 May 2003 19:06:46 -0400 (EDT) Received: from localhost (eischen@localhost)h45N6jPf011957; Mon, 5 May 2003 19:06:45 -0400 (EDT) Date: Mon, 5 May 2003 19:06:45 -0400 (EDT) From: Daniel Eischen To: "Andrey A. Chernov" In-Reply-To: <20030505225021.GA43345@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 23:06:48 -0000 On Tue, 6 May 2003, Andrey A. Chernov wrote: > On Mon, May 05, 2003 at 18:14:45 -0400, Daniel Eischen wrote: > > symbols in order to satisfy the needs of the threads library > > and to separate libc_r from libc, I would kindly suggest that > > you leave things alone. But if want to change things, please > > make sure they work with all the threads libraries that we > > currently have. I don't want the burden of doing this nor > > have it impact our current efforts. > > Please calm down, I don't want to break threads badly or anything like. Don't worry, I'm calm :-) > Especially when I don't understands threads details. At this stage we just > discuss here how to make things better. My point will be clear answering > on this simple question: > > What produce less errors in application and libraries? > a) Allow application to replace any standard function. I thought Jacques found lots of ports that replaced standard functions... > b) Produce linker error on such attempts. If there are a lot of applications that override printf() and the like, you might get lots of complaints about the new link warnings... > Please also note that I not treat functions like err(), warn() etc. as > standard, so namespace.h is right for them. OK. -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Mon May 5 16:11:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 274A037B401 for ; Mon, 5 May 2003 16:11:37 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4667743FCB for ; Mon, 5 May 2003 16:11:36 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id A29804; Mon, 5 May 2003 18:11:35 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 8801578C66; Mon, 5 May 2003 18:11:35 -0500 (CDT) Date: Mon, 5 May 2003 18:11:35 -0500 From: "Jacques A. Vidrine" To: "Andrey A. Chernov" Message-ID: <20030505231135.GA21953@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Andrey A. Chernov" , Dag-Erling Smorgrav , freebsd-arch@freebsd.org References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030505205051.GA40572@nagual.pp.ru> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 23:11:37 -0000 On Tue, May 06, 2003 at 12:50:51AM +0400, Andrey A. Chernov wrote: > On Mon, May 05, 2003 at 22:25:54 +0200, Dag-Erling Smorgrav wrote: > > "Jacques A. Vidrine" writes: > > > So, I advocate hiding all symbols in libc by default. The Real World > > > doesn't seem to care whether the symbols are defined by any standard or > > > not. > > > > I'm with you, but I would also like to point out that there is a small > > number of ports which will require changes: ports like electricfence, > > boehm-gc and others that rely at least in part on replacing libc's > > malloc(), calloc(), realloc() and free(). > > Unless my point was not clear from my previous posts, I advocate exact > opposite: to unhide all standard symbols from libc, including here > standard prefixes like str*. We must not encourage programmer error > when he define standard function, it easily leads to unexpected results. > Better reject such error automatically at the linkage stage. Programmers > are always free to redefine their functions in case of conflict. And what will you do with the hundreds (perhaps thousands) of applications that (IMHO most legitimately, some not) define symbols that are technically in some standard's space, such as `snprintf', `strlcpy', `accept', `close', ... ? ``Fix'' them all? Throw them away? What about applications that are already compiled? I think such fascism would result in us behaving in a very un-UNIX fashion. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Mon May 5 16:18:48 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D3BA37B401; Mon, 5 May 2003 16:18:48 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D57F43F75; Mon, 5 May 2003 16:18:47 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h45NIjrO044650; Tue, 6 May 2003 03:18:46 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h45NIjZ5044647; Tue, 6 May 2003 03:18:45 +0400 (MSD) Date: Tue, 6 May 2003 03:18:42 +0400 From: "Andrey A. Chernov" To: "Jacques A. Vidrine" , Dag-Erling Smorgrav , freebsd-arch@FreeBSD.org Message-ID: <20030505231837.GA44533@nagual.pp.ru> References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030505231135.GA21953@madman.celabo.org> User-Agent: Mutt/1.5.4i Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 23:18:48 -0000 On Mon, May 05, 2003 at 18:11:35 -0500, Jacques A. Vidrine wrote: > applications that (IMHO most legitimately, some not) define symbols > that are technically in some standard's space, such as `snprintf', > `strlcpy', `accept', `close', ... ? ``Fix'' them all? Throw them > away? Fix them all. It is as easy as putting #define printf myprintf somewhere into headers or even into CC flags. When this task is spreaded among corresponding ports maintainers, the number for each of them will be not too big. > What about applications that are already compiled? Leave them as is. I mean linker time error, not runtime. > I think such fascism would result in us behaving in a very un-UNIX > fashion. And I think just opposite. From owner-freebsd-arch@FreeBSD.ORG Mon May 5 16:20:14 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B62F37B401 for ; Mon, 5 May 2003 16:20:14 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D91F43FAF for ; Mon, 5 May 2003 16:20:13 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id EEA204; Mon, 5 May 2003 18:20:12 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id DE81178C66; Mon, 5 May 2003 18:20:12 -0500 (CDT) Date: Mon, 5 May 2003 18:20:12 -0500 From: "Jacques A. Vidrine" To: Daniel Eischen Message-ID: <20030505232012.GC21953@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Daniel Eischen , "Andrey A. Chernov" , freebsd-arch@freebsd.org References: <20030505225021.GA43345@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 23:20:14 -0000 Hi, Daniel! On Mon, May 05, 2003 at 07:06:45PM -0400, Daniel Eischen wrote: > I thought Jacques found lots of ports that replaced standard > functions... I did a survey of 6,817 packages. Over 700 of them defined symbols that are also defined in libc. The symbols which `clashed' are below for the curious. (I only examined symbols in the text segment.) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se abort abs accept access acl_init adjtime alarm alloca asprintf atexit atoi atoll basename bcmp bcopy bind bindresvport brk bsearch bzero calloc cfgetispeed cfgetospeed cfmakeraw cfsetispeed cfsetospeed cfsetspeed chmod chown chroot close closelog connect creat daemon dbm_close dbm_delete dbm_error dbm_fetch dbm_firstkey dbm_nextkey dbm_open dbm_store dbopen dirname dladdr dn_comp dn_expand drand48 dup eaccess encrypt endgrent endhostent endnetent endnetgrent endprotoent endpwent endservent endttyent err err_set_exit errx execl execle execlp execv execvp exit f_prealloc fabs fchmod fchown fclose fcntl fdopen fflush ffs fgets fhstat fileno fmtmsg fnmatch fopen fork fprintf free freeaddrinfo freehostent fsync ftruncate getaddrinfo getc getchar getcontext getegid getenv geteuid getgid getgrent getgrgid getgrnam getgrouplist gethostbyaddr gethostbyaddr_r gethostbyname gethostbyname2 gethostent getipnodebyaddr getipnodebyname getmode getnameinfo getnetbyaddr getnetbyname getnetent getnetgrent getopt getopt_long getpass getpeername getprogname getprotobyname getprotobynumber getprotoent getpublickey getpwent getpwnam getpwuid getresgid getresuid gets getservbyname getservbyport getservent getsockname getsubopt getttyent getuid glob globfree gmtime_r hash_create hash_destroy hash_search hash_stats hash_traverse hcreate hdestroy herror hesiod_end hesiod_free_list hesiod_init hesiod_resolve hesiod_to_bind hsearch hstrerror index inet_addr inet_aton inet_nsap_addr inet_nsap_ntoa inet_ntoa inet_ntop inet_pton initstate innetgr insque ioctl isatty isinf isnan isnumber iswalnum iswprint iswspace kill lchown link localeconv localtime_r lseek malloc mbrlen mbrtowc mbsinit mbsrtowcs memchr memcmp memcpy memset mkdir mkdtemp mknod mkstemp mktemp mktime mmap mpool_close mpool_filter mpool_get mpool_new mpool_open mpool_put mpool_sync munmap nlist open openlog paddr pause pclose perror pipe poll popen pread printf pthread_cond_broadcast pthread_cond_destroy pthread_cond_init pthread_cond_signal pthread_cond_wait pthread_getspecific pthread_key_create pthread_key_delete pthread_mutex_destroy pthread_mutex_init pthread_mutex_lock pthread_mutex_trylock pthread_mutex_unlock pthread_mutexattr_destroy pthread_mutexattr_init pthread_mutexattr_settype pthread_once pthread_rwlock_destroy pthread_rwlock_init pthread_rwlock_rdlock pthread_rwlock_tryrdlock pthread_rwlock_trywrlock pthread_rwlock_unlock pthread_rwlock_wrlock pthread_self pthread_setspecific pthread_sigmask putchar putenv puts pwrite qsort raise rand random read readdir readpassphrase readv realloc reallocf recv recvfrom recvmsg regcomp regerror regexec regfree remove remque rename res_init res_mkquery res_query res_querydomain res_search res_send res_send_setqhook res_send_setrhook rindex rmdir rresvport sbrk select sem_wait send sendfile sendmsg sendto setenv setgrent setgroupent sethostent setjmp setkey setmode setnetent setnetgrent setpassent setproctitle setprogname setprotoent setpwent setservent setsid setstate setttyent shutdown sigaction sigaddset sigblock sigdelset sigemptyset sigfillset sigismember signal sigpause sigprocmask sigsetmask sigvec sigwait sl_add sl_find sl_free sl_init sleep snprintf socket sprintf srandom stat stpcpy strcasecmp strcasestr strcat strchr strcmp strcpy strdup strerror strlcat strlcpy strncasecmp strncmp strncpy strnstr strsep strsignal strstr strtod strtok strtol strtoul strvis strvisx symlink system tcflow tcflush tcgetattr tcgetpgrp tcsendbreak tcsetattr tcsetpgrp tdelete time timegm timelocal tolower toupper towlower towupper truncate tsearch unlink unsetenv usleep uuid_compare uuid_create uuid_create_nil uuid_equal uuid_from_string uuid_hash uuid_is_nil uuid_to_string valloc vasprintf verr verrx vfprintf vis vsnprintf vsprintf vwarn vwarnx wait warn warnx wcrtomb wcscpy wcsrtombs wcstok wcswidth wcwidth wordfree wprintf write writev xdr_int64_t xdr_u_int64_t From owner-freebsd-arch@FreeBSD.ORG Mon May 5 16:26:57 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27F7B37B401; Mon, 5 May 2003 16:26:57 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BF7E43F85; Mon, 5 May 2003 16:26:56 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc52) with ESMTP id <20030505232655052006p8bpe>; Mon, 5 May 2003 23:26:55 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA30012; Mon, 5 May 2003 16:26:53 -0700 (PDT) Date: Mon, 5 May 2003 16:26:52 -0700 (PDT) From: Julian Elischer To: "Andrey A. Chernov" In-Reply-To: <20030505231837.GA44533@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Jacques A. Vidrine" cc: freebsd-arch@FreeBSD.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 23:26:57 -0000 On Tue, 6 May 2003, Andrey A. Chernov wrote: > On Mon, May 05, 2003 at 18:11:35 -0500, Jacques A. Vidrine wrote: > > applications that (IMHO most legitimately, some not) define symbols > > that are technically in some standard's space, such as `snprintf', > > `strlcpy', `accept', `close', ... ? ``Fix'' them all? Throw them > > away? > > Fix them all. It is as easy as putting > #define printf myprintf > somewhere into headers or even into CC flags. When this task is spreaded > among corresponding ports maintainers, the number for each of them will be > not too big. > > > What about applications that are already compiled? > > Leave them as is. I mean linker time error, not runtime. > > > I think such fascism would result in us behaving in a very un-UNIX > > fashion. If Linux had a clash they would fix the application software in a flash.. > > And I think just opposite. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon May 5 16:29:06 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9186137B401; Mon, 5 May 2003 16:29:06 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96FF843FAF; Mon, 5 May 2003 16:29:05 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (sccrmhc03) with ESMTP id <2003050523290400300dgs6ge>; Mon, 5 May 2003 23:29:04 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA30025; Mon, 5 May 2003 16:29:03 -0700 (PDT) Date: Mon, 5 May 2003 16:29:02 -0700 (PDT) From: Julian Elischer To: "Jacques A. Vidrine" In-Reply-To: <20030505232012.GC21953@madman.celabo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 23:29:06 -0000 On Mon, 5 May 2003, Jacques A. Vidrine wrote: > Hi, Daniel! > > On Mon, May 05, 2003 at 07:06:45PM -0400, Daniel Eischen wrote: > > I thought Jacques found lots of ports that replaced standard > > functions... > > I did a survey of 6,817 packages. Over 700 of them defined symbols > that are also defined in libc. The symbols which `clashed' are below > for the curious. (I only examined symbols in the text segment.) do you have a version with the symbols themselves? I'm guessing that some of the ones that use 'configure' might have them due to 'configure' not making the right decision in FreeBSD. > > Cheers, > -- > Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal > nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se > > abort > abs > accept > access > acl_init > adjtime > alarm > alloca > asprintf > atexit > atoi > atoll > basename > bcmp > bcopy > bind > bindresvport > brk > bsearch > bzero > calloc > cfgetispeed > cfgetospeed > cfmakeraw > cfsetispeed > cfsetospeed > cfsetspeed > chmod > chown > chroot > close > closelog > connect > creat > daemon > dbm_close > dbm_delete > dbm_error > dbm_fetch > dbm_firstkey > dbm_nextkey > dbm_open > dbm_store > dbopen > dirname > dladdr > dn_comp > dn_expand > drand48 > dup > eaccess > encrypt > endgrent > endhostent > endnetent > endnetgrent > endprotoent > endpwent > endservent > endttyent > err > err_set_exit > errx > execl > execle > execlp > execv > execvp > exit > f_prealloc > fabs > fchmod > fchown > fclose > fcntl > fdopen > fflush > ffs > fgets > fhstat > fileno > fmtmsg > fnmatch > fopen > fork > fprintf > free > freeaddrinfo > freehostent > fsync > ftruncate > getaddrinfo > getc > getchar > getcontext > getegid > getenv > geteuid > getgid > getgrent > getgrgid > getgrnam > getgrouplist > gethostbyaddr > gethostbyaddr_r > gethostbyname > gethostbyname2 > gethostent > getipnodebyaddr > getipnodebyname > getmode > getnameinfo > getnetbyaddr > getnetbyname > getnetent > getnetgrent > getopt > getopt_long > getpass > getpeername > getprogname > getprotobyname > getprotobynumber > getprotoent > getpublickey > getpwent > getpwnam > getpwuid > getresgid > getresuid > gets > getservbyname > getservbyport > getservent > getsockname > getsubopt > getttyent > getuid > glob > globfree > gmtime_r > hash_create > hash_destroy > hash_search > hash_stats > hash_traverse > hcreate > hdestroy > herror > hesiod_end > hesiod_free_list > hesiod_init > hesiod_resolve > hesiod_to_bind > hsearch > hstrerror > index > inet_addr > inet_aton > inet_nsap_addr > inet_nsap_ntoa > inet_ntoa > inet_ntop > inet_pton > initstate > innetgr > insque > ioctl > isatty > isinf > isnan > isnumber > iswalnum > iswprint > iswspace > kill > lchown > link > localeconv > localtime_r > lseek > malloc > mbrlen > mbrtowc > mbsinit > mbsrtowcs > memchr > memcmp > memcpy > memset > mkdir > mkdtemp > mknod > mkstemp > mktemp > mktime > mmap > mpool_close > mpool_filter > mpool_get > mpool_new > mpool_open > mpool_put > mpool_sync > munmap > nlist > open > openlog > paddr > pause > pclose > perror > pipe > poll > popen > pread > printf > pthread_cond_broadcast > pthread_cond_destroy > pthread_cond_init > pthread_cond_signal > pthread_cond_wait > pthread_getspecific > pthread_key_create > pthread_key_delete > pthread_mutex_destroy > pthread_mutex_init > pthread_mutex_lock > pthread_mutex_trylock > pthread_mutex_unlock > pthread_mutexattr_destroy > pthread_mutexattr_init > pthread_mutexattr_settype > pthread_once > pthread_rwlock_destroy > pthread_rwlock_init > pthread_rwlock_rdlock > pthread_rwlock_tryrdlock > pthread_rwlock_trywrlock > pthread_rwlock_unlock > pthread_rwlock_wrlock > pthread_self > pthread_setspecific > pthread_sigmask > putchar > putenv > puts > pwrite > qsort > raise > rand > random > read > readdir > readpassphrase > readv > realloc > reallocf > recv > recvfrom > recvmsg > regcomp > regerror > regexec > regfree > remove > remque > rename > res_init > res_mkquery > res_query > res_querydomain > res_search > res_send > res_send_setqhook > res_send_setrhook > rindex > rmdir > rresvport > sbrk > select > sem_wait > send > sendfile > sendmsg > sendto > setenv > setgrent > setgroupent > sethostent > setjmp > setkey > setmode > setnetent > setnetgrent > setpassent > setproctitle > setprogname > setprotoent > setpwent > setservent > setsid > setstate > setttyent > shutdown > sigaction > sigaddset > sigblock > sigdelset > sigemptyset > sigfillset > sigismember > signal > sigpause > sigprocmask > sigsetmask > sigvec > sigwait > sl_add > sl_find > sl_free > sl_init > sleep > snprintf > socket > sprintf > srandom > stat > stpcpy > strcasecmp > strcasestr > strcat > strchr > strcmp > strcpy > strdup > strerror > strlcat > strlcpy > strncasecmp > strncmp > strncpy > strnstr > strsep > strsignal > strstr > strtod > strtok > strtol > strtoul > strvis > strvisx > symlink > system > tcflow > tcflush > tcgetattr > tcgetpgrp > tcsendbreak > tcsetattr > tcsetpgrp > tdelete > time > timegm > timelocal > tolower > toupper > towlower > towupper > truncate > tsearch > unlink > unsetenv > usleep > uuid_compare > uuid_create > uuid_create_nil > uuid_equal > uuid_from_string > uuid_hash > uuid_is_nil > uuid_to_string > valloc > vasprintf > verr > verrx > vfprintf > vis > vsnprintf > vsprintf > vwarn > vwarnx > wait > warn > warnx > wcrtomb > wcscpy > wcsrtombs > wcstok > wcswidth > wcwidth > wordfree > wprintf > write > writev > xdr_int64_t > xdr_u_int64_t > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon May 5 16:33:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2BD337B401; Mon, 5 May 2003 16:33:13 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B08D43F93; Mon, 5 May 2003 16:33:12 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h45NXBrO045058; Tue, 6 May 2003 03:33:11 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h45NXBU7045057; Tue, 6 May 2003 03:33:11 +0400 (MSD) Date: Tue, 6 May 2003 03:33:11 +0400 From: "Andrey A. Chernov" To: "Jacques A. Vidrine" , Daniel Eischen , freebsd-arch@FreeBSD.org Message-ID: <20030505233311.GB44533@nagual.pp.ru> References: <20030505225021.GA43345@nagual.pp.ru> <20030505232012.GC21953@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030505232012.GC21953@madman.celabo.org> User-Agent: Mutt/1.5.4i Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 23:33:14 -0000 On Mon, May 05, 2003 at 18:20:12 -0500, Jacques A. Vidrine wrote: > for the curious. (I only examined symbols in the text segment.) > err_set_exit > errx Please exlude all non-standard one like above. The number will be twice less (or even more less). From owner-freebsd-arch@FreeBSD.ORG Mon May 5 16:40:18 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FCB837B401; Mon, 5 May 2003 16:40:18 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7266E43F85; Mon, 5 May 2003 16:40:17 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h45NeCA7048272; Mon, 5 May 2003 17:40:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 05 May 2003 17:38:01 -0600 (MDT) Message-Id: <20030505.173801.71910777.imp@bsdimp.com> To: nectar@freebsd.org From: "M. Warner Losh" In-Reply-To: <20030505175426.GA19352@madman.celabo.org> References: <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 23:40:18 -0000 In message: <20030505175426.GA19352@madman.celabo.org> "Jacques A. Vidrine" writes: : So, I advocate hiding all symbols in libc by default. The Real World : doesn't seem to care whether the symbols are defined by any standard or : not. >From a security perspective, this makes good sense. Warner From owner-freebsd-arch@FreeBSD.ORG Mon May 5 19:23:54 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8850937B401; Mon, 5 May 2003 19:23:54 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56CBA43F93; Mon, 5 May 2003 19:23:52 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id DD4CA530E; Tue, 6 May 2003 04:23:49 +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: "Andrey A. Chernov" References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> From: Dag-Erling Smorgrav Date: Tue, 06 May 2003 04:23:48 +0200 In-Reply-To: <20030505231837.GA44533@nagual.pp.ru> (Andrey A. Chernov's message of "Tue, 6 May 2003 03:18:42 +0400") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: "Jacques A. Vidrine" cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 02:23:54 -0000 "Andrey A. Chernov" writes: > On Mon, May 05, 2003 at 18:11:35 -0500, Jacques A. Vidrine wrote: > > I think such fascism would result in us behaving in a very un-UNIX > > fashion. > And I think just opposite. And I think you just don't understand the issue, and should leave it to those who do while you take time off to read ISO/IEC 9899:1990. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Mon May 5 19:46:29 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CC037B407 for ; Mon, 5 May 2003 19:46:29 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id C481E43F93 for ; Mon, 5 May 2003 19:46:28 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 0DEEA530E; Tue, 6 May 2003 04:46:27 +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: "Poul-Henning Kamp" References: <46563.1052170384@critter.freebsd.dk> From: Dag-Erling Smorgrav Date: Tue, 06 May 2003 04:46:26 +0200 In-Reply-To: <46563.1052170384@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 05 May 2003 23:33:04 +0200") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: arch@freebsd.org Subject: Re: cvs commit: src/sbin Makefile src/sbin/bsdlabel Makefile X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 02:46:29 -0000 "Poul-Henning Kamp" writes: > Do we compile&install only what is used for the current platform ? > > Do we compile&install all tools on all platforms ? I don't see why we shouldn't build and install tools that build and run fine and are useful. We may want to mount mobile media formatted on one system on another, or mount a dead system's disks on another system to retrieve its data; or we may want to use one system to prepare media for another. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Mon May 5 20:32:52 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCFFA37B42A for ; Mon, 5 May 2003 20:32:51 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34D1C43F75 for ; Mon, 5 May 2003 20:32:51 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19CtCA-0005aZ-00; Mon, 05 May 2003 20:32:47 -0700 Message-ID: <3EB72C95.6E9EEA50@mindspring.com> Date: Mon, 05 May 2003 20:31:33 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e7a3804c4321f93ff2d78645e0d3f35793caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 03:32:53 -0000 Igor Sysoev wrote: > On Mon, 5 May 2003, Terry Lambert wrote: > What is stack glue ? See the code in fork1() in /sys/kern/kern_fork.c. > I use rfork_thread(3) wrapper that allows to setup another stack for > rfork()ed process. > > What RFTHREAD flag does ? See the code. It basically sets up for kernel threading, rather than merely for processes sharing the same address space and/or file descriptor table and/or heap, which is what rfork was intended to be able to do. It also ensures propagation of any SIGKILL to all peers, so they die all at once, in exit1() in /sys/kern/kern_exit.c. > By the way linuxthreads port always uses RFTHREAD flag. They don't know any other way than the moral equivalent of the Linux "clone" system call, so that's what they use; it's technically not necessary. See also the source code in the directory /usr/src/lib/libpthread, which doesn't use rfork() at all. -- Terry From owner-freebsd-arch@FreeBSD.ORG Mon May 5 21:33:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0934A37B401 for ; Mon, 5 May 2003 21:33:17 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 738FB43FBD for ; Mon, 5 May 2003 21:33:16 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Cu8Q-0005gg-00; Mon, 05 May 2003 21:32:59 -0700 Message-ID: <3EB73AA4.ADDDE95@mindspring.com> Date: Mon, 05 May 2003 21:31:32 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ed6b0842f6f101520709b87d324181eb548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 04:33:17 -0000 Daniel Eischen wrote: > If libc also doesn't have any strong symbols (at least for > the functions you want to check), then I suppose you can > check the linked application for these (strong) definitions. > I don't know how to do it myself, but this may give you some > idea. There's really no way to do it. Even with strong symbols; the ones that get linked first "win", and any later references lose. The relocation isn't seperate enough to allow relinking the libc into a .o file (via ld -r). Maybe the answer is to put "/usr/lib/libc.a" on the linker line, instead of "-L/usr/lib -llibc"; even then, it might not work unless you forced the symbol import, and "ld -r"'ed the libc.a into a libc.o, to conver the types. Bottom line: it's a pretty bad idea, and most of the problems are coming from functions that are not in any ratified standard in the first place, which iw why the ports are carrying them around themselves (in the expectation that they will not be present in the host OS). Overriding libc symbols that *are* defined by a standard has a long and glorious history. It's the same one that says that preventing people from doing stupid things also prevents them from doing clever things. Personally, I'd be much happier with the "nm"-based symbol collision checker, whose results were recently posted, being made available in ports, so that ports maintainers who care can check for themselves, and provide patches to their ports to pluck out the offensive symbols: if thine symbols offend thee, pluck them out, oh port maintainer... -- Terry From owner-freebsd-arch@FreeBSD.ORG Mon May 5 21:36:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E8D337B401 for ; Mon, 5 May 2003 21:36:41 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDB8E43FBD for ; Mon, 5 May 2003 21:36:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19CuBx-0006Hx-00; Mon, 05 May 2003 21:36:38 -0700 Message-ID: <3EB73B84.20DBAD91@mindspring.com> Date: Mon, 05 May 2003 21:35:16 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Andrey A. Chernov" References: <20030505214605.GA41803@nagual.pp.ru> <20030505225021.GA43345@nagual.pp.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ed6b0842f6f101525f1ec9742978031293caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: Dag-Erling Smorgrav cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 04:36:41 -0000 "Andrey A. Chernov" wrote: > What produce less errors in application and libraries? > a) Allow application to replace any standard function. > b) Produce linker error on such attempts. > > Please also note that I not treat functions like err(), warn() etc. as > standard, so namespace.h is right for them. Probably you want to add an option to the linker to make it treat weak symbols as strong, and *do not* turn it on by default, and make it apply positionally, so that it can be applied on a per-library basis by the ports maintainer. It would be a much better approach than trying to relink, which, after reading the code, I'm convinced would not work (my previous suggestion). -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue May 6 00:46:15 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FDC037B418; Tue, 6 May 2003 00:46:15 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D15AD43F3F; Tue, 6 May 2003 00:46:13 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h467kCE14946; Tue, 6 May 2003 09:46:12 +0200 (MEST) Date: Tue, 6 May 2003 09:46:12 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030505175426.GA19352@madman.celabo.org> Message-ID: <20030506093754.B838@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 07:46:15 -0000 On Mon, 5 May 2003, Jacques A. Vidrine wrote: JAV>On Mon, May 05, 2003 at 11:14:17AM +0200, Harti Brandt wrote: JAV>> On Thu, 1 May 2003, Jacques A. Vidrine wrote: JAV>> JAV>Some of these applications really want to override the functions for JAV>their own purposes, like arts which overrides the hidden `open' stub. JAV>Note that these applications work just fine even though the symbols are JAV>`hidden' ... that is not the issue. JAV> JAV>The rest of the applications seem to be defining their own versions of JAV>some functions for portability purposes. Defining `printf' seems pretty JAV>funny, but J. Schilling is not the only author who has done so. JAV>In these cases, it seems dangerous to have libc calling into the JAV>application's implementation, e.g. calling Mozilla's `mkstemp' in order JAV>to implement `hashopen', or calling Smiley's `bsearch' in order to JAV>implement `nsdispatch', or calling MySQL's `strstr' to implement JAV>`syslog' and so on and on. JAV> JAV>So, I advocate hiding all symbols in libc by default. The Real World JAV>doesn't seem to care whether the symbols are defined by any standard or JAV>not. No. If I define my own printf() I want that printf to be called even by library internal calls. This is even more obvious, for example, for things like stdio where it would simply not work when the library calls its own fputc() and the application calls its application defined fputc(). The same holds for printf() that may use private interfaces into stdio. These will not work if the file was opened with the applications fopen(). The situation may be different for non-standardized functions with names in the application space like err(). It is certainly unwise to require that no application should define err() so that it wont conflict with our library's err(). In these cases it may make really sense to hide this functions. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 00:56:09 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EE1737B401; Tue, 6 May 2003 00:56:09 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF64B43FCB; Tue, 6 May 2003 00:56:07 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h467u6E16145; Tue, 6 May 2003 09:56:06 +0200 (MEST) Date: Tue, 6 May 2003 09:56:06 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030505232012.GC21953@madman.celabo.org> Message-ID: <20030506095424.G838@beagle.fokus.fraunhofer.de> References: <20030505225021.GA43345@nagual.pp.ru> <20030505232012.GC21953@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 07:56:09 -0000 On Mon, 5 May 2003, Jacques A. Vidrine wrote: JAV>Hi, Daniel! JAV> JAV>On Mon, May 05, 2003 at 07:06:45PM -0400, Daniel Eischen wrote: JAV>> I thought Jacques found lots of ports that replaced standard JAV>> functions... JAV> JAV>I did a survey of 6,817 packages. Over 700 of them defined symbols JAV>that are also defined in libc. The symbols which `clashed' are below JAV>for the curious. (I only examined symbols in the text segment.) There is no guarantee that you 'fix' the port by hiding the symbol. You may as well break it. This depends on the function itself and on the internal relationships in libc. You have to go through each individual port and see what happens anyway. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 02:25:39 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE86E37B401; Tue, 6 May 2003 02:25:39 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC8B43FE1; Tue, 6 May 2003 02:25:35 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h469PNp9003242; Tue, 6 May 2003 19:25:23 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h469PKaV003241; Tue, 6 May 2003 19:25:20 +1000 (EST) Date: Tue, 6 May 2003 19:25:20 +1000 From: Peter Jeremy To: Harti Brandt Message-ID: <20030506092519.GA3158@cirb503493.alcatel.com.au> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506093754.B838@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 09:25:40 -0000 On Tue, May 06, 2003 at 09:46:12AM +0200, Harti Brandt wrote: >On Mon, 5 May 2003, Jacques A. Vidrine wrote: >JAV>So, I advocate hiding all symbols in libc by default. The Real World >JAV>doesn't seem to care whether the symbols are defined by any standard or >JAV>not. > >No. If I define my own printf() I want that printf to be called even by >library internal calls. What if I define my own printf() that doesn't fully implement all the functionality of the FreeBSD printf()? It works meets all the requirements for my code (and maybe even runs correctly elsewhere) but doesn't work on FreeBSD because a library internal call (hypothetically) relies on functionality that I don't need. This is most likely to surface in functions like strlcpy(), strlcat() and snprintf() where the return value includes a reference to the size of the buffer that would be required to perform the requested operation without truncation. This is the most likely area where an implementor may cut corners if hir application does not rely on the return value. >The situation may be different for non-standardized functions with names >in the application space like err(). Last time I checked, the base system included a program that included its own err() function - with functionality substantially different to err(3). Peter From owner-freebsd-arch@FreeBSD.ORG Tue May 6 02:43:23 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2D3237B401; Tue, 6 May 2003 02:43:22 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8445C43F3F; Tue, 6 May 2003 02:43:21 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h469hEE01833; Tue, 6 May 2003 11:43:14 +0200 (MEST) Date: Tue, 6 May 2003 11:43:13 +0200 (CEST) From: Harti Brandt To: Peter Jeremy In-Reply-To: <20030506092519.GA3158@cirb503493.alcatel.com.au> Message-ID: <20030506112711.K838@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 09:43:23 -0000 On Tue, 6 May 2003, Peter Jeremy wrote: PJ>On Tue, May 06, 2003 at 09:46:12AM +0200, Harti Brandt wrote: PJ>>On Mon, 5 May 2003, Jacques A. Vidrine wrote: PJ>>JAV>So, I advocate hiding all symbols in libc by default. The Real World PJ>>JAV>doesn't seem to care whether the symbols are defined by any standard or PJ>>JAV>not. PJ>> PJ>>No. If I define my own printf() I want that printf to be called even by PJ>>library internal calls. PJ> PJ>What if I define my own printf() that doesn't fully implement all the PJ>functionality of the FreeBSD printf()? It works meets all the requirements PJ>for my code (and maybe even runs correctly elsewhere) but doesn't work PJ>on FreeBSD because a library internal call (hypothetically) relies on PJ>functionality that I don't need. That's the fault of the application. When I replace a standard defined function I have to know what I do. The problem with printf and the entire stdio stuff is, that it has interdependencies between several functions. These come from using macros in stdio.h and using internal interfaces between these library functions. If a library function calls the librarie's printf it will end up in __svfwrite which knows the internals of how an i/o stream works. The application's replacement may function differently, it's printf may be based on calls to write() using fileno() or it may replace the entire stdio. In either case the application will simply not work. Here I have to support Terry's statement that replacing libc symbols has a long history and allows you to do things, that otherwise will be impossible or much harder. PJ>This is most likely to surface in functions like strlcpy(), strlcat() PJ>and snprintf() where the return value includes a reference to the PJ>size of the buffer that would be required to perform the requested PJ>operation without truncation. This is the most likely area where an PJ>implementor may cut corners if hir application does not rely on the PJ>return value. PJ> PJ>>The situation may be different for non-standardized functions with names PJ>>in the application space like err(). PJ> PJ>Last time I checked, the base system included a program that included its PJ>own err() function - with functionality substantially different to err(3). To say it otherwise: I think hiding names that are not in Posix/Ansi is a good thing, because we must assume, that applications have functions with the same names doing entirely different things. Hiding names that are not standardized functions, but are in the standard or implementation namespace is probably a good thing to do too. Hiding functions that are in the standards is a bad thing. If applications use these names, we should assume that the function does at least what the standard requires. If not the application is broken and must be fixed. Otherwise we will break an unknown number of applications. In your example: err() is a function from the first class, so hiding it would appropriate. (And I should say, that my pdp11 emulator suffered from exactly this problem: it had an err() function with a different arguments than that in libc. I had to replace it with a different name.) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 07:13:51 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2BC637B401 for ; Tue, 6 May 2003 07:13:51 -0700 (PDT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5977D43FBD for ; Tue, 6 May 2003 07:13:50 -0700 (PDT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h46EDmmF084433; Tue, 6 May 2003 18:13:48 +0400 (MSD) Date: Tue, 6 May 2003 18:13:48 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: Terry Lambert In-Reply-To: <3EB72C95.6E9EEA50@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 14:13:52 -0000 On Mon, 5 May 2003, Terry Lambert wrote: > Igor Sysoev wrote: > > On Mon, 5 May 2003, Terry Lambert wrote: > > What is stack glue ? > > See the code in fork1() in /sys/kern/kern_fork.c. I do not see any stack manipulation in kern_fork.c except the creating alternate kstack for KSE thread in 5.0. And rfork(2) can not create such stack - it passes 0 to fork1(). In 4.x there's no stack code at all. > > I use rfork_thread(3) wrapper that allows to setup another stack for > > rfork()ed process. By the way I found the bug in x86 rfork_thread(3)'s error handling: --- /usr/src/lib/libc/i386/gen/rfork_thread.S Wed Feb 7 03:12:45 2001 +++ /usr/src/lib/libc/i386/gen/rfork_thread.S Tue May 6 17:45:14 2003 @@ -108,5 +108,8 @@ * Branch here if the thread creation fails: */ 2: + popl %esi + movl %ebp, %esp + popl %ebp PIC_PROLOGUE jmp PIC_PLT(HIDENAME(cerror)) > > What RFTHREAD flag does ? > > See the code. It basically sets up for kernel threading, rather > than merely for processes sharing the same address space and/or > file descriptor table and/or heap, which is what rfork was > intended to be able to do. It also ensures propagation of any > SIGKILL to all peers, so they die all at once, in exit1() in > /sys/kern/kern_exit.c. It seems that the single purpose of the RFTHREAD flag is to kill peers when the leader got SIGKILL. And in 4.8-STABLE and 5.0-CURRENT (after 5.0-RELEASE) the leader also holds P_ADVLOCK flag. > > By the way linuxthreads port always uses RFTHREAD flag. > > They don't know any other way than the moral equivalent of > the Linux "clone" system call, so that's what they use; it's > technically not necessary. See also the source code in the Now it's necessary. Otherwise rfork() returns EINVAL. > directory /usr/src/lib/libpthread, which doesn't use rfork() > at all. I know it. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-arch@FreeBSD.ORG Tue May 6 07:56:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E98937B401 for ; Tue, 6 May 2003 07:56:00 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id B98EA43FB1 for ; Tue, 6 May 2003 07:55:59 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0297.cvx40-bradley.dialup.earthlink.net ([216.244.43.42] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19D3rG-00079R-00; Tue, 06 May 2003 07:55:54 -0700 Message-ID: <3EB7CC73.9C61C27E@mindspring.com> Date: Tue, 06 May 2003 07:53:39 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4cd605700a281f5a66db403488a789133a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 14:56:00 -0000 Peter Jeremy wrote: > What if I define my own printf() that doesn't fully implement all the > functionality of the FreeBSD printf()? It works meets all the requirements > for my code (and maybe even runs correctly elsewhere) but doesn't work > on FreeBSD because a library internal call (hypothetically) relies on > functionality that I don't need. This is actually a library implementation problem, related to incestuous implementation of library calls. If another library function doesn't use e.g. strlcpy() internally, then it will not be effected by an application replacing strlcpy(). It's only when a library function depends on another library function, rather than itself, that it's at risk for this type of failure. Perhaps instead of asking how to prevent symbol replacement, one should be asking how to get rid of incestuous functions in the library implementation for standard library functions. No, I do not expect "_fmt" (or whatever) to go away from common code in printf/sprintf/whatever. But I do expect it to be "_fmt" instead of "fmt", i.e. in implementation space, rather than in the symbol space legal for users to use. -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:14:36 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2D7637B401 for ; Tue, 6 May 2003 08:14:35 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87B8E43F3F for ; Tue, 6 May 2003 08:14:34 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46FESE20844; Tue, 6 May 2003 17:14:28 +0200 (MEST) Date: Tue, 6 May 2003 17:14:28 +0200 (CEST) From: Harti Brandt To: Terry Lambert In-Reply-To: <3EB7CC73.9C61C27E@mindspring.com> Message-ID: <20030506165850.Y601@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030506093754.B838@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:14:36 -0000 On Tue, 6 May 2003, Terry Lambert wrote: TL>Peter Jeremy wrote: TL>> What if I define my own printf() that doesn't fully implement all the TL>> functionality of the FreeBSD printf()? It works meets all the requirements TL>> for my code (and maybe even runs correctly elsewhere) but doesn't work TL>> on FreeBSD because a library internal call (hypothetically) relies on TL>> functionality that I don't need. TL> TL>This is actually a library implementation problem, related to TL>incestuous implementation of library calls. TL> TL>If another library function doesn't use e.g. strlcpy() internally, TL>then it will not be effected by an application replacing strlcpy(). TL> TL>It's only when a library function depends on another library TL>function, rather than itself, that it's at risk for this type of TL>failure. It is also when two library functions dependend on implementation-internal data layout, initialisation sequence, whatever... TL>Perhaps instead of asking how to prevent symbol replacement, one TL>should be asking how to get rid of incestuous functions in the TL>library implementation for standard library functions. TL> TL>No, I do not expect "_fmt" (or whatever) to go away from common TL>code in printf/sprintf/whatever. But I do expect it to be "_fmt" TL>instead of "fmt", i.e. in implementation space, rather than in TL>the symbol space legal for users to use. That doesn't help in this case actually. the __foo() functions called by printf() depend on the internals of stdio, so internally calling _printf() while a user has replaced stdio will sure give you trouble. Another datapoint: glibc implements gcvt in terms of printf(). This is funny, because the intention of gcvt() is to implement printf(). By 'hiding' gcvt() through a weak symbol, there is no way an application can correct the buggy library. I have checked with the ISO-C draft I have around here. From a principal point of view, we are allowed to disable the redefinition of C-library functions. The question is, what does it help us and what do we loose: It helps us to catch one particular kind of bugs in 3rd party software, where the software has a buggy implementation (in the context of our own implementation) of a standard function. This also rules actually non-buggy implementations of functions that adhere to newer standards than our own implementations. This means that in order to actually help we have to go through each instance of a port redefining a libc function and decide, whether it is buggy, the same as our implementation or simply more featureful and whether it is compatible with our implementation. We loose the ability to do certain well known tricks (which have worked since C was invented), most of which help in debugging (f.e. replacing malloc or str* for range checking) and we make the porting of several software packages to FreeBSD actually harder. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:19:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50E3C37B401 for ; Tue, 6 May 2003 08:19:41 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEB2E43FCB for ; Tue, 6 May 2003 08:19:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0297.cvx40-bradley.dialup.earthlink.net ([216.244.43.42] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19D4EA-00052f-00; Tue, 06 May 2003 08:19:35 -0700 Message-ID: <3EB7D23D.FD5E4191@mindspring.com> Date: Tue, 06 May 2003 08:18:21 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43780838b73a9dade91a8d1173f4a58de93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:19:41 -0000 Igor Sysoev wrote: > On Mon, 5 May 2003, Terry Lambert wrote: > > Igor Sysoev wrote: > > > On Mon, 5 May 2003, Terry Lambert wrote: > > > What is stack glue ? > > > > See the code in fork1() in /sys/kern/kern_fork.c. > > I do not see any stack manipulation in kern_fork.c except the creating > alternate kstack for KSE thread in 5.0. And rfork(2) can not create > such stack - it passes 0 to fork1(). You misunderstand. After the rfork() returns, there is different stack glue required to implement "a threads library" when you use RFTHREAD than when you don't use RFTHREAD. And I *know* it can't create the stack: you have to do that in user space with assembly language glue you provide. In other words, it's working without RFTHREAD, you're just using the wrong stack glue in user space. > In 4.x there's no stack code at all. That's because there's no thread library that uses rfork(), apart from the linuxthreads port. > > > I use rfork_thread(3) wrapper that allows to setup another stack for > > > rfork()ed process. > > By the way I found the bug in x86 rfork_thread(3)'s error handling: > > --- /usr/src/lib/libc/i386/gen/rfork_thread.S Wed Feb 7 03:12:45 2001 > +++ /usr/src/lib/libc/i386/gen/rfork_thread.S Tue May 6 17:45:14 2003 > @@ -108,5 +108,8 @@ > * Branch here if the thread creation fails: > */ > 2: > + popl %esi > + movl %ebp, %esp > + popl %ebp > PIC_PROLOGUE > jmp PIC_PLT(HIDENAME(cerror)) sendpr the fix to the linuxthreads maintainer, please. > > > What RFTHREAD flag does ? > > > > See the code. It basically sets up for kernel threading, rather > > than merely for processes sharing the same address space and/or > > file descriptor table and/or heap, which is what rfork was > > intended to be able to do. It also ensures propagation of any > > SIGKILL to all peers, so they die all at once, in exit1() in > > /sys/kern/kern_exit.c. > > It seems that the single purpose of the RFTHREAD flag is to kill peers > when the leader got SIGKILL. > And in 4.8-STABLE and 5.0-CURRENT (after 5.0-RELEASE) the leader also > holds P_ADVLOCK flag. Yes, that's just for cleaning up advisory locks, which mostly no one uses in threads applications, since they can cause one thread to deadlock another. > > > By the way linuxthreads port always uses RFTHREAD flag. > > > > They don't know any other way than the moral equivalent of > > the Linux "clone" system call, so that's what they use; it's > > technically not necessary. See also the source code in the > > Now it's necessary. Otherwise rfork() returns EINVAL. It only does that if at least one of a set of flags is not set; I don't see where you think EINVAL is coming from. But in any case, if RFTHREAD makes something work for you, then by all means use it. It should not be implied, and it should not be required by documentation, since, as you noticed reading the code, all it does is associate sibling threads under a parent for killing and advisory locking. > > directory /usr/src/lib/libpthread, which doesn't use rfork() > > at all. > > I know it. My point was that the only code that uses it without RFTHREAD successfully is probably about two years old, and was never committed to the tree as part of a threads library. You would need to check the mailing list archives for "Jason Evans" and "John Dyson", in combination with "rfork", to find the code that "fixes" needing RFTHREAD. -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:23:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DCC637B401 for ; Tue, 6 May 2003 08:23:41 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FB4343F75 for ; Tue, 6 May 2003 08:23:40 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 030B544; Tue, 6 May 2003 10:23:40 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 558F678C66; Tue, 6 May 2003 10:23:41 -0500 (CDT) Date: Tue, 6 May 2003 10:23:41 -0500 From: "Jacques A. Vidrine" To: Julian Elischer Message-ID: <20030506152341.GA77708@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Julian Elischer , Daniel Eischen , "Andrey A. Chernov" , freebsd-arch@freebsd.org References: <20030505232012.GC21953@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:23:41 -0000 On Mon, May 05, 2003 at 04:29:02PM -0700, Julian Elischer wrote: > > do you have a version with the symbols themselves? Was this directed at me? I'm sorry, but I don't understand the question. > I'm guessing that some of the ones that use 'configure' might > have them due to 'configure' not making the right decision in FreeBSD. Some yes, but not in the majority of cases. (I'm not sure what your point might be.) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:24:07 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A74637B401 for ; Tue, 6 May 2003 08:24:07 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4817C43F75 for ; Tue, 6 May 2003 08:24:06 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id D7D4C44; Tue, 6 May 2003 10:24:05 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 6A86078C69; Tue, 6 May 2003 10:24:07 -0500 (CDT) Date: Tue, 6 May 2003 10:24:07 -0500 From: "Jacques A. Vidrine" To: "Andrey A. Chernov" Message-ID: <20030506152407.GB77708@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "Andrey A. Chernov" , Daniel Eischen , freebsd-arch@FreeBSD.org References: <20030505225021.GA43345@nagual.pp.ru> <20030505232012.GC21953@madman.celabo.org> <20030505233311.GB44533@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030505233311.GB44533@nagual.pp.ru> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: Daniel Eischen cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:24:07 -0000 On Tue, May 06, 2003 at 03:33:11AM +0400, Andrey A. Chernov wrote: > On Mon, May 05, 2003 at 18:20:12 -0500, Jacques A. Vidrine wrote: > > for the curious. (I only examined symbols in the text segment.) > > > err_set_exit > > errx > > > Please exlude all non-standard one like above. The number will be twice > less (or even more less). So? -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:25:42 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB58E37B401 for ; Tue, 6 May 2003 08:25:42 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id D55A743F85 for ; Tue, 6 May 2003 08:25:41 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 737A744; Tue, 6 May 2003 10:25:41 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 07A8678C66; Tue, 6 May 2003 10:25:43 -0500 (CDT) Date: Tue, 6 May 2003 10:25:42 -0500 From: "Jacques A. Vidrine" To: Harti Brandt Message-ID: <20030506152542.GC77708@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , Daniel Eischen , "Andrey A. Chernov" , freebsd-arch@freebsd.org References: <20030505225021.GA43345@nagual.pp.ru> <20030505232012.GC21953@madman.celabo.org> <20030506095424.G838@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506095424.G838@beagle.fokus.fraunhofer.de> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:25:43 -0000 On Tue, May 06, 2003 at 09:56:06AM +0200, Harti Brandt wrote: > There is no guarantee that you 'fix' the port by hiding the symbol. You > may as well break it. This depends on the function itself and on the > internal relationships in libc. You have to go through each individual > port and see what happens anyway. Please explain. I _am_ guaranteed that keeping the port from hijacking strlcpy calls in libc will not break the port. How could the port rely on the internals of libc? Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:25:57 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5518C37B401 for ; Tue, 6 May 2003 08:25:57 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 883B743FA3 for ; Tue, 6 May 2003 08:25:56 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 1A95DBB; Tue, 6 May 2003 10:25:56 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 9FAAD78C69; Tue, 6 May 2003 10:25:57 -0500 (CDT) Date: Tue, 6 May 2003 10:25:57 -0500 From: "Jacques A. Vidrine" To: Terry Lambert Message-ID: <20030506152557.GD77708@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Terry Lambert , Peter Jeremy , freebsd-arch@freebsd.org References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> <3EB7CC73.9C61C27E@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EB7CC73.9C61C27E@mindspring.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:25:57 -0000 On Tue, May 06, 2003 at 07:53:39AM -0700, Terry Lambert wrote: > Perhaps instead of asking how to prevent symbol replacement, one > should be asking how to get rid of incestuous functions in the > library implementation for standard library functions. > > No, I do not expect "_fmt" (or whatever) to go away from common > code in printf/sprintf/whatever. But I do expect it to be "_fmt" > instead of "fmt", i.e. in implementation space, rather than in > the symbol space legal for users to use. This is exactly what I wish to achieve. This is exactly the approach that I took with strlcpy [1]: the internal implementation is called `_strlcpy', while the exported symbol remains `strlcpy'. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se [1] Before I backed it out in an attempt to demonstrate good will. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:26:05 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64FB337B401 for ; Tue, 6 May 2003 08:26:05 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A18B43FA3 for ; Tue, 6 May 2003 08:26:04 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 0E63FCE; Tue, 6 May 2003 10:26:04 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 9878F78C66; Tue, 6 May 2003 10:26:05 -0500 (CDT) Date: Tue, 6 May 2003 10:26:05 -0500 From: "Jacques A. Vidrine" To: Harti Brandt Message-ID: <20030506152605.GE77708@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , Terry Lambert , freebsd-arch@freebsd.org References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030506093754.B838@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com> <20030506165850.Y601@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506165850.Y601@beagle.fokus.fraunhofer.de> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:26:05 -0000 On Tue, May 06, 2003 at 05:14:28PM +0200, Harti Brandt wrote: > I have checked with the ISO-C draft I have around here. From a principal > point of view, we are allowed to disable the redefinition of C-library > functions. The question is, what does it help us and what do we loose: > > It helps us to catch one particular kind of bugs in 3rd party software, > where the software has a buggy implementation (in the context of our own > implementation) of a standard function. This also rules actually non-buggy > implementations of functions that adhere to newer standards than our own > implementations. This means that in order to actually help we have to go > through each instance of a port redefining a libc function and decide, > whether it is buggy, the same as our implementation or simply more > featureful and whether it is compatible with our implementation. > > We loose the ability to do certain well known tricks (which have worked > since C was invented), most of which help in debugging (f.e. replacing > malloc or str* for range checking) and we make the porting of several > software packages to FreeBSD actually harder. For these reasons and others, I cannot support any attempt to make it impossible for a programmer to define his/her own symbols that conflict with the [foo] Standard. Or stated more agressively, the day the FreeBSD toolchain refuses to allow me to define my own version of strlcpy _for use by my application_ is the day I find another development platform. Tools, not policy. If I can create code to override the internal libc strlcpy, too, that's just a plus. (Note we have this today even with `hidden' symbols.) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:29:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F44137B401 for ; Tue, 6 May 2003 08:29:26 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id A95A943F93 for ; Tue, 6 May 2003 08:29:25 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 305D5BB; Tue, 6 May 2003 10:29:25 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 92EB178C66; Tue, 6 May 2003 10:29:26 -0500 (CDT) Date: Tue, 6 May 2003 10:29:26 -0500 From: "Jacques A. Vidrine" To: Harti Brandt Message-ID: <20030506152926.GG77708@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , freebsd-arch@FreeBSD.org References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506093754.B838@beagle.fokus.fraunhofer.de> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:29:26 -0000 On Tue, May 06, 2003 at 09:46:12AM +0200, Harti Brandt wrote: > No. If I define my own printf() I want that printf to be called even by > library internal calls. No, you really don't. If you do, then you use the techniques that dozens of applications already use today. `Hiding' libc symbols do not get in the way of these techniques. printf is an incredibly bad example, of course. What makes you think there are any calls to printf in libc anyway? Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:30:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EB3B37B404 for ; Tue, 6 May 2003 08:30:41 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A27243F85 for ; Tue, 6 May 2003 08:30:40 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 8D67866; Tue, 6 May 2003 10:30:39 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 2382778C66; Tue, 6 May 2003 10:30:41 -0500 (CDT) Date: Tue, 6 May 2003 10:30:41 -0500 From: "Jacques A. Vidrine" To: Peter Jeremy Message-ID: <20030506153040.GH77708@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Peter Jeremy , Harti Brandt , freebsd-arch@freebsd.org References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506092519.GA3158@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506092519.GA3158@cirb503493.alcatel.com.au> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:30:41 -0000 On Tue, May 06, 2003 at 07:25:20PM +1000, Peter Jeremy wrote: > >The situation may be different for non-standardized functions with names > >in the application space like err(). > > Last time I checked, the base system included a program that included its > own err() function - with functionality substantially different to err(3). Yep, these symbols (err, warn) are already hidden using namespace.h. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:36:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5259237B401 for ; Tue, 6 May 2003 08:36:41 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73EDD43FBF for ; Tue, 6 May 2003 08:36:40 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id C42F166; Tue, 6 May 2003 10:36:39 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 27B7378C66; Tue, 6 May 2003 10:36:41 -0500 (CDT) Date: Tue, 6 May 2003 10:36:41 -0500 From: "Jacques A. Vidrine" To: Harti Brandt Message-ID: <20030506153641.GI77708@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , Peter Jeremy , freebsd-arch@freebsd.org References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506112711.K838@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506112711.K838@beagle.fokus.fraunhofer.de> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:36:41 -0000 On Tue, May 06, 2003 at 11:43:13AM +0200, Harti Brandt wrote: > To say it otherwise: I think hiding names that are not in Posix/Ansi is a > good thing, because we must assume, that applications have functions with > the same names doing entirely different things. Hiding names that are not > standardized functions, but are in the standard or implementation > namespace is probably a good thing to do too. Hiding functions that are in > the standards is a bad thing. If applications use these names, we should > assume that the function does at least what the standard requires. If not > the application is broken and must be fixed. Otherwise we will break an > unknown number of applications. We _already_ hide many POSIX/ANSI names, without any ill effects or portability consequences. Please understand the issues before posting. Since I set $SUBJECT, I will re-state what I meant by `hiding' libc symbols. I was specifically referring to the namespace.h/weak symbol method which we have been using for over 100 functions in libc for years. That is: Renaming the internal implementation of `foo' to `_foo', and creating a weak symbol alias with the original name (`foo'). Within libc, use the `_foo' name when the semantics must be known (e.g. when the behavior must not be overridden by an application accidently, i.e. almost always). Macros in `namespace.h' help the compiler with prototypes etc. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:38:08 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1E3B37B401; Tue, 6 May 2003 08:38:08 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F29943F75; Tue, 6 May 2003 08:38:07 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46Fc6E24185; Tue, 6 May 2003 17:38:06 +0200 (MEST) Date: Tue, 6 May 2003 17:38:06 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030506152926.GG77708@madman.celabo.org> Message-ID: <20030506173249.V631@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506152926.GG77708@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:38:09 -0000 On Tue, 6 May 2003, Jacques A. Vidrine wrote: JAV>On Tue, May 06, 2003 at 09:46:12AM +0200, Harti Brandt wrote: JAV>> No. If I define my own printf() I want that printf to be called even by JAV>> library internal calls. JAV> JAV>No, you really don't. If you do, then you use the techniques that JAV>dozens of applications already use today. `Hiding' libc symbols do JAV>not get in the way of these techniques. While you certainly can replace printf(), this will fail if you happen to also replace fopen(). Even if you only replace fopen(). If there are several functions that depend on each other by calling or by using the same data you must replace them all. JAV>printf is an incredibly bad example, of course. What makes you think JAV>there are any calls to printf in libc anyway? try find /usr/src/lib/libc -name \*.c | xargs grep printf There are a lot of calls in debugging code, but there are many left from regular code (error messages for example). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:42:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA91837B401 for ; Tue, 6 May 2003 08:42:13 -0700 (PDT) Received: from Daffy.timing.com (ns2.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id C951B43FA3 for ; Tue, 6 May 2003 08:42:12 -0700 (PDT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@piglet.timing.com [206.168.13.178]) by Daffy.timing.com (8.11.3/8.11.3) with ESMTP id h46Fg6H27461; Tue, 6 May 2003 09:42:06 -0600 (MDT) (envelope-from ben@timing.com) Received: from piglet.timing.com (oink@localhost.timing.com [127.0.0.1]) by piglet.timing.com (8.12.6/8.12.6) with ESMTP id h46Fg6g2016266; Tue, 6 May 2003 09:42:06 -0600 (MDT) (envelope-from ben@piglet.timing.com) Received: (from ben@localhost) by piglet.timing.com (8.12.6/8.12.6/Submit) id h46Fg4Fk016263; Tue, 6 May 2003 09:42:04 -0600 (MDT) From: Ben Mesander MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16055.55244.458061.779430@piglet.timing.com> Date: Tue, 6 May 2003 09:42:04 -0600 To: Daniel Eischen In-Reply-To: References: <20030505225021.GA43345@nagual.pp.ru> X-Mailer: VM 7.00 under Emacs 21.2.95.2 cc: "Andrey A. Chernov" cc: Dag-Erling Smorgrav cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:42:14 -0000 Daniel Eischen writes: > On Tue, 6 May 2003, Andrey A. Chernov wrote: > > On Mon, May 05, 2003 at 18:14:45 -0400, Daniel Eischen wrote: > > Especially when I don't understands threads details. At this stage we just > > discuss here how to make things better. My point will be clear answering > > on this simple question: > > > > What produce less errors in application and libraries? > > a) Allow application to replace any standard function. > > I thought Jacques found lots of ports that replaced standard > functions... In addition to ports which override libc functions like printf() for ease of porting, there are important ports, such as the Boehm garbage collector for C/C++ or electric fence, which _depend_ upon the ability to override libc functions such as malloc() and free(). Whatever decision is eventually made must allow such ports to function. This has been brought up once before, but I do not see how any of the advocates for change have addressed it. --Ben From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:49:55 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBFCE37B401; Tue, 6 May 2003 08:49:55 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 589CA43F93; Tue, 6 May 2003 08:49:54 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46FnrE25913; Tue, 6 May 2003 17:49:53 +0200 (MEST) Date: Tue, 6 May 2003 17:49:53 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030506152542.GC77708@madman.celabo.org> Message-ID: <20030506173822.A631@beagle.fokus.fraunhofer.de> References: <20030505225021.GA43345@nagual.pp.ru> <20030506095424.G838@beagle.fokus.fraunhofer.de> <20030506152542.GC77708@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:49:56 -0000 On Tue, 6 May 2003, Jacques A. Vidrine wrote: JAV>On Tue, May 06, 2003 at 09:56:06AM +0200, Harti Brandt wrote: JAV>> There is no guarantee that you 'fix' the port by hiding the symbol. You JAV>> may as well break it. This depends on the function itself and on the JAV>> internal relationships in libc. You have to go through each individual JAV>> port and see what happens anyway. JAV> JAV>Please explain. I _am_ guaranteed that keeping the port from hijacking JAV>strlcpy calls in libc will not break the port. How could the port rely JAV>on the internals of libc? Well, strlcpy is not a very interesting example because it stand on its own. More interesting are examples where library functions depend on each other (malloc/free, fopen and co.) The user calls its own malloc(), the library tries to free with its own free(). The application could replace *printf() to actually redirect output... At the end the port might have its own strlcpy to track buffers it has written to for whatever reason. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:51:28 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74D4437B401 for ; Tue, 6 May 2003 08:51:28 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4684643F3F for ; Tue, 6 May 2003 08:51:27 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id BB1E0CE; Tue, 6 May 2003 10:51:26 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 28F7978C66; Tue, 6 May 2003 10:51:28 -0500 (CDT) Date: Tue, 6 May 2003 10:51:28 -0500 From: "Jacques A. Vidrine" To: Ben Mesander Message-ID: <20030506155128.GB77956@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Ben Mesander , Daniel Eischen , "Andrey A. Chernov" , Dag-Erling Smorgrav , freebsd-arch@freebsd.org References: <20030505225021.GA43345@nagual.pp.ru> <16055.55244.458061.779430@piglet.timing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16055.55244.458061.779430@piglet.timing.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org cc: Daniel Eischen cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:51:28 -0000 On Tue, May 06, 2003 at 09:42:04AM -0600, Ben Mesander wrote: > In addition to ports which override libc functions like printf() for > ease of porting, there are important ports, such as the Boehm garbage > collector for C/C++ or electric fence, which _depend_ upon the ability > to override libc functions such as malloc() and free(). > > Whatever decision is eventually made must allow such ports to > function. > > This has been brought up once before, but I do not see how any of the > advocates for change have addressed it. Probably because there is not much to address. I think it is universally agreed that the allocator is likely to need to be overridden. There are at least two solutions: (a) Treat malloc & company as an exception: always call them by their un-adorned name from within libc. (b) Let these specialized applications override the adorned names instead. There is probably already code within these ports to deal with underscore-prefixed names. I don't really have a preference for either solution. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:53:19 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B28E37B401; Tue, 6 May 2003 08:53:19 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C50343FA3; Tue, 6 May 2003 08:53:18 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46FrGE26330; Tue, 6 May 2003 17:53:16 +0200 (MEST) Date: Tue, 6 May 2003 17:53:16 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030506152605.GE77708@madman.celabo.org> Message-ID: <20030506175017.C631@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com> <20030506152605.GE77708@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:53:19 -0000 On Tue, 6 May 2003, Jacques A. Vidrine wrote: JAV>On Tue, May 06, 2003 at 05:14:28PM +0200, Harti Brandt wrote: JAV>> I have checked with the ISO-C draft I have around here. From a principal JAV>> point of view, we are allowed to disable the redefinition of C-library JAV>> functions. The question is, what does it help us and what do we loose: JAV>> JAV>> It helps us to catch one particular kind of bugs in 3rd party software, JAV>> where the software has a buggy implementation (in the context of our own JAV>> implementation) of a standard function. This also rules actually non-buggy JAV>> implementations of functions that adhere to newer standards than our own JAV>> implementations. This means that in order to actually help we have to go JAV>> through each instance of a port redefining a libc function and decide, JAV>> whether it is buggy, the same as our implementation or simply more JAV>> featureful and whether it is compatible with our implementation. JAV>> JAV>> We loose the ability to do certain well known tricks (which have worked JAV>> since C was invented), most of which help in debugging (f.e. replacing JAV>> malloc or str* for range checking) and we make the porting of several JAV>> software packages to FreeBSD actually harder. JAV> JAV>For these reasons and others, I cannot support any attempt to make JAV>it impossible for a programmer to define his/her own symbols that JAV>conflict with the [foo] Standard. JAV> JAV>Or stated more agressively, the day the FreeBSD toolchain refuses JAV>to allow me to define my own version of strlcpy _for use by my JAV>application_ is the day I find another development platform. So if you 'hide' all the libc symbols you will to exactly that. I can, of course then define _malloc() instead of malloc(), but that is just another case in the ever growing incompatibility between unices. JAV>If I can create code to override the internal libc strlcpy, too, JAV>that's just a plus. (Note we have this today even with `hidden' JAV>symbols.) We have that if you happen to be a toolchain/libc expert, that knows, that magically the linker does not do what it has done for decades - using the first definition of a symbol for ALL following references and that you have to prepend an underscore to work around this. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 08:59:24 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C2BC37B401; Tue, 6 May 2003 08:59:24 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FAF743F93; Tue, 6 May 2003 08:59:22 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46FxLE27334; Tue, 6 May 2003 17:59:21 +0200 (MEST) Date: Tue, 6 May 2003 17:59:21 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030506153641.GI77708@madman.celabo.org> Message-ID: <20030506175400.F631@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506153641.GI77708@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 15:59:24 -0000 On Tue, 6 May 2003, Jacques A. Vidrine wrote: JAV>On Tue, May 06, 2003 at 11:43:13AM +0200, Harti Brandt wrote: JAV>> To say it otherwise: I think hiding names that are not in Posix/Ansi is a JAV>> good thing, because we must assume, that applications have functions with JAV>> the same names doing entirely different things. Hiding names that are not JAV>> standardized functions, but are in the standard or implementation JAV>> namespace is probably a good thing to do too. Hiding functions that are in JAV>> the standards is a bad thing. If applications use these names, we should JAV>> assume that the function does at least what the standard requires. If not JAV>> the application is broken and must be fixed. Otherwise we will break an JAV>> unknown number of applications. JAV> JAV>We _already_ hide many POSIX/ANSI names, without any ill effects or JAV>portability consequences. Please understand the issues before posting. JAV> JAV>Since I set $SUBJECT, I will re-state what I meant by `hiding' libc JAV>symbols. I was specifically referring to the namespace.h/weak symbol JAV>method which we have been using for over 100 functions in libc for JAV>years. Please! I know what I'm talking about. I have been hit by the broken shared library design in BSD/OS and I have been hit by all those non-standard functions with names that each application writer loves to use in our libc (err for example), but I have also on occasions replace exit with abort to find a very obscure bug, I sometimes use a debugging libmalloc, I know libraries that replace str* functions to find bound errors. I'm just telling that simply hiding all symbols without caring of what that may cause is certainly wrong. And stating that this will automagically make buggy ports un-buggier is also wrong. JAV>That is: JAV> JAV>Renaming the internal implementation of `foo' to `_foo', and creating JAV>a weak symbol alias with the original name (`foo'). Within libc, JAV>use the `_foo' name when the semantics must be known (e.g. when the JAV>behavior must not be overridden by an application accidently, i.e. JAV>almost always). Macros in `namespace.h' help the compiler with JAV>prototypes etc. Go ahead with non-standard functions, but make sure that you don't break ports when doing this with standard functions. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 09:12:18 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7425737B401; Tue, 6 May 2003 09:12:18 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01EB643FD7; Tue, 6 May 2003 09:12:15 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46GCDE29141; Tue, 6 May 2003 18:12:13 +0200 (MEST) Date: Tue, 6 May 2003 18:12:13 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030506155128.GB77956@madman.celabo.org> Message-ID: <20030506180935.A631@beagle.fokus.fraunhofer.de> References: <20030505225021.GA43345@nagual.pp.ru> <20030506155128.GB77956@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Andrey A. Chernov" cc: Dag-Erling Smorgrav cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 16:12:18 -0000 On Tue, 6 May 2003, Jacques A. Vidrine wrote: JAV>On Tue, May 06, 2003 at 09:42:04AM -0600, Ben Mesander wrote: JAV>> In addition to ports which override libc functions like printf() for JAV>> ease of porting, there are important ports, such as the Boehm garbage JAV>> collector for C/C++ or electric fence, which _depend_ upon the ability JAV>> to override libc functions such as malloc() and free(). JAV>> JAV>> Whatever decision is eventually made must allow such ports to JAV>> function. JAV>> JAV>> This has been brought up once before, but I do not see how any of the JAV>> advocates for change have addressed it. JAV> JAV>Probably because there is not much to address. I think it is JAV>universally agreed that the allocator is likely to need to be JAV>overridden. There are at least two solutions: JAV> JAV> (a) Treat malloc & company as an exception: always call them by JAV> their un-adorned name from within libc. JAV> JAV> (b) Let these specialized applications override the adorned names JAV> instead. There is probably already code within these ports to JAV> deal with underscore-prefixed names. JAV> JAV>I don't really have a preference for either solution. If you absolutely need to, use b). Treating all functions uniform reduces the number of surprises one will encounter by 1. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 09:17:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 924F337B4AF for ; Tue, 6 May 2003 09:17:33 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 611C943FA3 for ; Tue, 6 May 2003 09:17:32 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id AF35E44; Tue, 6 May 2003 11:17:31 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 2568978C66; Tue, 6 May 2003 11:17:33 -0500 (CDT) Date: Tue, 6 May 2003 11:17:33 -0500 From: "Jacques A. Vidrine" To: Harti Brandt Message-ID: <20030506161732.GB78486@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , freebsd-arch@FreeBSD.org References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506112711.K838@beagle.fokus.fraunhofer.de> <20030506153641.GI77708@madman.celabo.org> <20030506175400.F631@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506175400.F631@beagle.fokus.fraunhofer.de> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 16:17:34 -0000 On Tue, May 06, 2003 at 05:59:21PM +0200, Harti Brandt wrote: > Please! I know what I'm talking about. I have been hit by the broken > shared library design in BSD/OS and I have been hit by all those > non-standard functions with names that each application writer loves to > use in our libc (err for example), but I have also on occasions replace > exit with abort to find a very obscure bug, I sometimes use a debugging > libmalloc, I know libraries that replace str* functions to find bound > errors. You have yet to indicate how hiding some additional symbols in libc, using the method that we already have, will cause this hair loss to which you are referring. You can certainly replace `exit' with `abort' now if you want. As a matter of fact, `exit' is already `hidden' for a few years, and I haven't seen you complain earlier. % nm -D --defined-only /usr/lib/libc.so | grep '\b_\?exit\b' 0004368c W _exit 000a5558 T exit > I'm just telling that simply hiding all symbols without caring of what > that may cause is certainly wrong. I concede that might be the case. It seems clear that hiding the allocators might be of questionable use. Anything else? > And stating that this will > automagically make buggy ports un-buggier is also wrong. Well, we've already had at least one port where it most certainly made a difference. The issue is one of safety and robustness ... we should not be calling into application's functions _on accident_. > Go ahead with non-standard functions, but make sure that you don't break > ports when doing this with standard functions. Quick question: is strlcpy a standard function, or a non-standard function? What else are standard functions? Many `standard' functions are already hidden. I don't expect much, if any, breakage, but testing against the port cluster would be advisable before committing en masse. Actually, even if we had consensus to go this route, I'm not sure that one would want to do it en masse? Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 09:22:36 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5580D37B401; Tue, 6 May 2003 09:22:36 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 292E243F3F; Tue, 6 May 2003 09:22:35 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 8CBA05310; Tue, 6 May 2003 18:22:33 +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: "Jacques A. Vidrine" References: <20030505225021.GA43345@nagual.pp.ru> <16055.55244.458061.779430@piglet.timing.com> <20030506155128.GB77956@madman.celabo.org> From: Dag-Erling Smorgrav Date: Tue, 06 May 2003 18:22:32 +0200 In-Reply-To: <20030506155128.GB77956@madman.celabo.org> (Jacques A. Vidrine's message of "Tue, 6 May 2003 10:51:28 -0500") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 16:22:36 -0000 "Jacques A. Vidrine" writes: > There are at least two solutions: > > (a) Treat malloc & company as an exception: always call them by > their un-adorned name from within libc. > > (b) Let these specialized applications override the adorned names > instead. There is probably already code within these ports to > deal with underscore-prefixed names. > > I don't really have a preference for either solution. I have a strong preference for (b)... in case anyone cares :) DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 09:23:52 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF64537B401 for ; Tue, 6 May 2003 09:23:52 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2A7743FAF for ; Tue, 6 May 2003 09:23:51 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 3BC8544; Tue, 6 May 2003 11:23:51 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id AA6BD78C66; Tue, 6 May 2003 11:23:52 -0500 (CDT) Date: Tue, 6 May 2003 11:23:52 -0500 From: "Jacques A. Vidrine" To: Harti Brandt Message-ID: <20030506162352.GC78486@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , Terry Lambert , freebsd-arch@FreeBSD.org References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030506093754.B838@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com> <20030506165850.Y601@beagle.fokus.fraunhofer.de> <20030506152605.GE77708@madman.celabo.org> <20030506175017.C631@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506175017.C631@beagle.fokus.fraunhofer.de> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 16:23:53 -0000 On Tue, May 06, 2003 at 05:53:16PM +0200, Harti Brandt wrote: > JAV>Or stated more agressively, the day the FreeBSD toolchain refuses > JAV>to allow me to define my own version of strlcpy _for use by my > JAV>application_ is the day I find another development platform. > > So if you 'hide' all the libc symbols you will to exactly that. Of course not. I can define strlcpy like so void strlcpy(struct string *a, struct string *b) { if (a->size == 0) { b->size = 0; return; } /* really copy the string */ } if I want to, and my application will then behave exactly as my insane mind expects. (this is just a sillier example of the real world problem that was encountered) However, since strlcpy is _not_ protected/hidden today, my application as a whole will likely not behave as I expect. I'll innocently call something like getaddrinfo() and *BOOM*. :-) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 09:46:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 295B337B401; Tue, 6 May 2003 09:46:02 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 550C243F75; Tue, 6 May 2003 09:46:01 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h46GjYm2037063; Tue, 6 May 2003 09:45:38 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h46GjYT5037062; Tue, 6 May 2003 09:45:34 -0700 (PDT) Date: Tue, 6 May 2003 09:45:34 -0700 From: "David O'Brien" To: "Jacques A. Vidrine" , Ben Mesander , Daniel Eischen , "Andrey A. Chernov" , Dag-Erling Smorgrav , freebsd-arch@FreeBSD.org Message-ID: <20030506164534.GB36798@dragon.nuxi.com> References: <20030505225021.GA43345@nagual.pp.ru> <16055.55244.458061.779430@piglet.timing.com> <20030506155128.GB77956@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506155128.GB77956@madman.celabo.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 16:46:02 -0000 On Tue, May 06, 2003 at 10:51:28AM -0500, Jacques A. Vidrine wrote: > On Tue, May 06, 2003 at 09:42:04AM -0600, Ben Mesander wrote: > > In addition to ports which override libc functions like printf() for > > ease of porting, there are important ports, such as the Boehm garbage > > collector for C/C++ or electric fence, which _depend_ upon the ability > > to override libc functions such as malloc() and free(). > > > > Whatever decision is eventually made must allow such ports to > > function. > > > > This has been brought up once before, but I do not see how any of the > > advocates for change have addressed it. > > Probably because there is not much to address. I think it is > universally agreed that the allocator is likely to need to be > overridden. There are at least two solutions: > > (a) Treat malloc & company as an exception: always call them by > their un-adorned name from within libc. > > (b) Let these specialized applications override the adorned names > instead. There is probably already code within these ports to > deal with underscore-prefixed names. > > I don't really have a preference for either solution. I have a strong preference for (c) Do nothing. (a)'s over time we'll just add to (a)'s list, so the exceptions are just too ad-hoc. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 09:53:47 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53B1237B401; Tue, 6 May 2003 09:53:47 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 809D243F85; Tue, 6 May 2003 09:53:46 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h46GrNm2037123; Tue, 6 May 2003 09:53:23 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h46GrJjQ037122; Tue, 6 May 2003 09:53:19 -0700 (PDT) Date: Tue, 6 May 2003 09:53:19 -0700 From: "David O'Brien" To: "Jacques A. Vidrine" , Harti Brandt , freebsd-arch@FreeBSD.org Message-ID: <20030506165319.GC36798@dragon.nuxi.com> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506112711.K838@beagle.fokus.fraunhofer.de> <20030506153641.GI77708@madman.celabo.org> <20030506175400.F631@beagle.fokus.fraunhofer.de> <20030506161732.GB78486@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506161732.GB78486@madman.celabo.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 16:53:47 -0000 On Tue, May 06, 2003 at 11:17:33AM -0500, Jacques A. Vidrine wrote: > Actually, even if we had consensus to go this route, I'm not sure that > one would want to do it en masse? You're not going to get consensus. This thread should just DIE, and be taken to the TRB/Core if you want it continued. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Tue May 6 10:01:07 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55E7537B401; Tue, 6 May 2003 10:01:07 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8EE643FAF; Tue, 6 May 2003 10:01:05 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h46H14E05835; Tue, 6 May 2003 19:01:04 +0200 (MEST) Date: Tue, 6 May 2003 19:00:05 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030506161732.GB78486@madman.celabo.org> Message-ID: <20030506185026.B965@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506153641.GI77708@madman.celabo.org> <20030506161732.GB78486@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 17:01:07 -0000 On Tue, 6 May 2003, Jacques A. Vidrine wrote: JAV>On Tue, May 06, 2003 at 05:59:21PM +0200, Harti Brandt wrote: JAV>> Please! I know what I'm talking about. I have been hit by the broken JAV>> shared library design in BSD/OS and I have been hit by all those JAV>> non-standard functions with names that each application writer loves to JAV>> use in our libc (err for example), but I have also on occasions replace JAV>> exit with abort to find a very obscure bug, I sometimes use a debugging JAV>> libmalloc, I know libraries that replace str* functions to find bound JAV>> errors. JAV> JAV>You have yet to indicate how hiding some additional symbols in libc, JAV>using the method that we already have, will cause this hair loss to JAV>which you are referring. You can certainly replace `exit' with `abort' JAV>now if you want. As a matter of fact, `exit' is already `hidden' for JAV>a few years, and I haven't seen you complain earlier. Well that may be some years ago actually, when I also decided to rename the err() function in my PDP-11 emulator :-( With exit() the situation actually seems a little bit more complex, because there is already an _exit() with different semantics. JAV>> I'm just telling that simply hiding all symbols without caring of what JAV>> that may cause is certainly wrong. JAV> JAV>I concede that might be the case. It seems clear that hiding the JAV>allocators might be of questionable use. Anything else? Watch out for Schilling's programs (star, cdrecord). And other programs that use to carry half of libc around. JAV>> And stating that this will JAV>> automagically make buggy ports un-buggier is also wrong. JAV> JAV>Well, we've already had at least one port where it most certainly JAV>made a difference. The issue is one of safety and robustness ... JAV>we should not be calling into application's functions _on accident_. Actually fixing the problem at the source would be even better. JAV>> Go ahead with non-standard functions, but make sure that you don't break JAV>> ports when doing this with standard functions. JAV> JAV>Quick question: is strlcpy a standard function, or a non-standard JAV>function? What else are standard functions? All str* functions are in the implementation name space so any program using a name starting with str is non-conforming. At the moment I cannot start my acroread or I would point you at the corresponding paragraph in ISO-C. Add posix to this. JAV>Many `standard' functions are already hidden. I don't expect much, if JAV>any, breakage, but testing against the port cluster would be advisable JAV>before committing en masse. Hmm. That means you ensure that the program compiles and links, not that it runs. A question that just occured to me is: how is one expected to find out via autoconf, whether to use a _ in front of the questionable function or not? It will compile and link without a warning in either case and provoking a run-time error may actually not be simple. JAV>Actually, even if we had consensus to go this route, I'm not sure that JAV>one would want to do it en masse? I have no clue how to do it except do it and watch out for people to complain. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 10:08:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7F2337B401; Tue, 6 May 2003 10:08:33 -0700 (PDT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96B5143F75; Tue, 6 May 2003 10:08:29 -0700 (PDT) (envelope-from netch@lucky.net) Received: from netch@localhost [127.0.0.1] (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id h46H8NiT058849; Tue, 6 May 2003 20:08:24 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.8p1/8.12.8/Submit) id h46H8NPM058846; Tue, 6 May 2003 20:08:23 +0300 (EEST) (envelope-from netch) Date: Tue, 6 May 2003 20:08:23 +0300 From: Valentin Nechayev To: Dag-Erling Smorgrav Message-ID: <20030506170823.GI83663@lucky.net> References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-42: On X-Verify-Sender: verified cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 17:08:34 -0000 Tue, May 06, 2003 at 04:23:48, des wrote about "Re: `Hiding' libc symbols": >> On Mon, May 05, 2003 at 18:11:35 -0500, Jacques A. Vidrine wrote: > >> I think such fascism would result in us behaving in a very un-UNIX > >> fashion. >> And I think just opposite. > And I think you just don't understand the issue, and should leave it > to those who do while you take time off to read ISO/IEC 9899:1990. Can you please say some extraction from it for those poor guys not having got this standard? -netch- From owner-freebsd-arch@FreeBSD.ORG Tue May 6 10:09:25 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B4BA37B401; Tue, 6 May 2003 10:09:25 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77B4F43FA3; Tue, 6 May 2003 10:09:24 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h46H9Jm2037373; Tue, 6 May 2003 10:09:23 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h46H9JBd037372; Tue, 6 May 2003 10:09:19 -0700 (PDT) Date: Tue, 6 May 2003 10:09:19 -0700 From: "David O'Brien" To: "Jacques A. Vidrine" , freebsd-arch@FreeBSD.org Message-ID: <20030506170919.GD36798@dragon.nuxi.com> References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030505175428.GA19275@madman.celabo.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 17:09:25 -0000 On Mon, May 05, 2003 at 12:54:28PM -0500, Jacques A. Vidrine wrote: > > > I'm backing out the commit in good faith and in the hopes that the > > > big picture comes more clearly into focus. > > > > Thanks. > > Do you also want to `fix' the other ports that define their own strlcpy? Ports have maintainers. Please create a PR for them. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 10:55:57 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 333E537B401 for ; Tue, 6 May 2003 10:55:57 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6059F43F85 for ; Tue, 6 May 2003 10:55:56 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id AE30566; Tue, 6 May 2003 12:55:55 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 468A278C66; Tue, 6 May 2003 12:55:57 -0500 (CDT) Date: Tue, 6 May 2003 12:55:57 -0500 From: "Jacques A. Vidrine" To: David O'Brien Message-ID: <20030506175557.GE79167@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , David O'Brien , freebsd-arch@FreeBSD.org References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506170919.GD36798@dragon.nuxi.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 17:55:57 -0000 On Tue, May 06, 2003 at 10:09:19AM -0700, David O'Brien wrote: > On Mon, May 05, 2003 at 12:54:28PM -0500, Jacques A. Vidrine wrote: > > > > I'm backing out the commit in good faith and in the hopes that the > > > > big picture comes more clearly into focus. > > > > > > Thanks. > > > > Do you also want to `fix' the other ports that define their own strlcpy? > > Ports have maintainers. Please create a PR for them. But gee, the problem is that the ports themselves are not really in error, unless one is a standards fascist that believes that an application can never define any function that might be in some standard's namespace. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 10:56:31 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ECB837B401; Tue, 6 May 2003 10:56:31 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A125243FB1; Tue, 6 May 2003 10:56:29 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 180DA5311; Tue, 6 May 2003 19:56:28 +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: netch@lucky.net References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> From: Dag-Erling Smorgrav Date: Tue, 06 May 2003 19:56:27 +0200 In-Reply-To: <20030506170823.GI83663@lucky.net> (Valentin Nechayev's message of "Tue, 6 May 2003 20:08:23 +0300") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 17:56:31 -0000 Valentin Nechayev writes: > Tue, May 06, 2003 at 04:23:48, des wrote about "Re: `Hiding' libc symbols": > > And I think you just don't understand the issue, and should leave it > > to those who do while you take time off to read ISO/IEC 9899:1990. > Can you please say some extraction from it for those poor guys not having > got this standard? The standard reserves a number of names and namespaces for the implementation while others are reserved for the application. We (as an implementation vendor) regularly trespass into the application namespace, and applications regularly trespass into the implementation namespace. Those are facts of life. There are a couple of things we need to take care of to avoid serious breakage: - The implementation (libc) must yield to the application in areas where it trespasses into the application namespace. The linker handles that since libc is always last on the linker command line. - To the extent that libc relies on symbols in the application namespace which it defines itself, it must behave as if it didn't (because those names belong to the application) meaning that it must ensure that it uses its own versions of those symbols and not the application's. This is handled partly by namespace.h. - The implementation must also guard itself against applications which incorrectly define names in the implementation namespace, because there are just too many of them to realistically expect fixing them all. Moreover, I strongly believe that it is our task as implementation vendors to ensure that our implementation is as robust as possible in the face of non-conforming applications. - One important caveat is that (most) reserved names that do not begin with an underscore are reserved only when the header in which the standard requires them to be defined is included. This is one of the reasons why I advocate building world with -fno-builtin; gcc incorrectly reserves names for builtin functions even when the standard mandates that these names are in the application namespace. For instance, math functions such as sin(3) and cos(3) should not be defined unless is included, but gcc always defines them, thus breaking applications which use these names themselves (sin is a popular name for sockaddr_in structs) (another reason for using -fno-builtin is that gcc's builtins hide bugs, especially those related to missing headers) - If you stayed awake through the previous paragraph you should by now have concluded that it simply is not possible for the linker to enforce namespaces like Andrey wants it to, because a) the linker can't know what headers were included; b) the exact set of reserved names can vary from compilation unit to compilation unit within the same application and c) namespace issues affect portions of the code which are outside the linker's purview (such as the names of function arguments and static or automatic variables). Namespaces are a source code issue and cannot be handled anywhere but at the source code level. - Applications which rely on overriding parts of the implementation are non-conforming and cannot claim a "moral right" to do so. In the few cases where applications have good and useful reasons for overriding parts of the implementation, they can easily be modified to cope with whatever techniques the implementation uses to avoid namespace collisions. In the case of ElectricFence, this means adding _malloc, _calloc etc. as aliases for malloc, calloc etc.; boehm-gc is not an issue because we don't configure it with --enable-redirect-malloc. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:00:50 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FCB837B401; Tue, 6 May 2003 11:00:50 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3732343F85; Tue, 6 May 2003 11:00:46 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h46I0f928475; Tue, 6 May 2003 15:00:41 -0300 Message-ID: <3EB7F85A.5070500@tcoip.com.br> Date: Tue, 06 May 2003 15:00:58 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030505225021.GA43345@nagual.pp.ru> <20030505232012.GC21953@madman.celabo.org> <20030506095424.G838@beagle.fokus.fraunhofer.de> <20030506152542.GC77708@madman.celabo.org> In-Reply-To: <20030506152542.GC77708@madman.celabo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:00:50 -0000 Jacques A. Vidrine wrote: > On Tue, May 06, 2003 at 09:56:06AM +0200, Harti Brandt wrote: >=20 >>There is no guarantee that you 'fix' the port by hiding the symbol. Yo= u >>may as well break it. This depends on the function itself and on the >>internal relationships in libc. You have to go through each individual >>port and see what happens anyway. >=20 >=20 > Please explain. I _am_ guaranteed that keeping the port from hijacking= > strlcpy calls in libc will not break the port. How could the port rely= > on the internals of libc? Well... if I instrument all memory allocating functions (by providing my = own copies) and I call a function that allocates memory by itself and=20 expects my application to free that memory at some point, I expect the=20 kernel to use one of my functions to do it. --=20 Daniel C. Sobral Ger=EAncia de Opera=E7=F5es Divis=E3o de Comunica=E7=E3o de Dados Coordena=E7=E3o de Seguran=E7a VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:02:27 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D641E37B401; Tue, 6 May 2003 11:02:27 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 483CB43F3F; Tue, 6 May 2003 11:02:27 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc53) with ESMTP id <2003050618022605300ou7bte>; Tue, 6 May 2003 18:02:26 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA37309; Tue, 6 May 2003 11:02:25 -0700 (PDT) Date: Tue, 6 May 2003 11:02:24 -0700 (PDT) From: Julian Elischer To: "Jacques A. Vidrine" In-Reply-To: <20030506175557.GE79167@madman.celabo.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: David O'Brien cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:02:28 -0000 On Tue, 6 May 2003, Jacques A. Vidrine wrote: > On Tue, May 06, 2003 at 10:09:19AM -0700, David O'Brien wrote: > > On Mon, May 05, 2003 at 12:54:28PM -0500, Jacques A. Vidrine wrote: > > > > > I'm backing out the commit in good faith and in the hopes that the > > > > > big picture comes more clearly into focus. > > > > > > > > Thanks. > > > > > > Do you also want to `fix' the other ports that define their own strlcpy? > > > > Ports have maintainers. Please create a PR for them. > > But gee, the problem is that the ports themselves are not really > in error, unless one is a standards fascist that believes that an > application can never define any function that might be in some > standard's namespace. If you could do your census again but this time showing which symbols clash we would have a better idea of what we are talking about.. Probably most of these packages have these function 'in case' the system does not. You can also bet that if compiled on Linux they don't include these functions if Linux has them, so I'm willing to bet that many of them have ways to turn off much of the excess stuff. > > Cheers, > -- > Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal > nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:04:20 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E1EA37B401 for ; Tue, 6 May 2003 11:04:20 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9439743F75 for ; Tue, 6 May 2003 11:04:19 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 261DF66 for ; Tue, 6 May 2003 13:04:19 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id B48AB78C66; Tue, 6 May 2003 13:04:20 -0500 (CDT) Date: Tue, 6 May 2003 13:04:20 -0500 From: "Jacques A. Vidrine" To: David O'Brien Message-ID: <20030506180420.GF79167@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , David O'Brien References: <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506112711.K838@beagle.fokus.fraunhofer.de> <20030506153641.GI77708@madman.celabo.org> <20030506175400.F631@beagle.fokus.fraunhofer.de> <20030506161732.GB78486@madman.celabo.org> <20030506165319.GC36798@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506165319.GC36798@dragon.nuxi.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:04:20 -0000 On Tue, May 06, 2003 at 09:53:19AM -0700, David O'Brien wrote: > On Tue, May 06, 2003 at 11:17:33AM -0500, Jacques A. Vidrine wrote: > > Actually, even if we had consensus to go this route, I'm not sure that > > one would want to do it en masse? > > You're not going to get consensus. This thread should just DIE, and be > taken to the TRB/Core if you want it continued. I think there has been at least a little support for the proposal, although certainly not consensus among those who have been vocal. I'm just trying to determine what exactly is distasteful to the vocal minority and to unearth any alternative approaches that might satisfy more of the community. You haven't raised any concrete issues other than ``I don't like it'', so it would be hard to imagine why one would bring it to the TRB. To try to get you to contribute something (since you seem to want to participate constructively), do your objections include objection to the special treatement given to `non-standard' symbols such as err, warn? Why or why not? I'm also pretty sure that one doesn't need TRB/core approval to continue a on-topic, technical thread in this forum. But hey, I could be wrong. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:05:16 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E7B737B401 for ; Tue, 6 May 2003 11:05:16 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EBA843F75 for ; Tue, 6 May 2003 11:05:15 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id D765A66; Tue, 6 May 2003 13:05:14 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id A96F878C66; Tue, 6 May 2003 13:05:16 -0500 (CDT) Date: Tue, 6 May 2003 13:05:16 -0500 From: "Jacques A. Vidrine" To: Harti Brandt Message-ID: <20030506180516.GG79167@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , freebsd-arch@FreeBSD.org References: <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506112711.K838@beagle.fokus.fraunhofer.de> <20030506153641.GI77708@madman.celabo.org> <20030506175400.F631@beagle.fokus.fraunhofer.de> <20030506161732.GB78486@madman.celabo.org> <20030506185026.B965@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506185026.B965@beagle.fokus.fraunhofer.de> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:05:16 -0000 On Tue, May 06, 2003 at 07:00:05PM +0200, Harti Brandt wrote: > Actually fixing the problem at the source would be even better. And if there is no problem at the source? Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:08:23 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B10BB37B401; Tue, 6 May 2003 11:08:23 -0700 (PDT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B9E443F85; Tue, 6 May 2003 11:08:21 -0700 (PDT) (envelope-from netch@lucky.net) Received: from netch@localhost [127.0.0.1] (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id h46I8FiT071154; Tue, 6 May 2003 21:08:16 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.8p1/8.12.8/Submit) id h46I8Elf071150; Tue, 6 May 2003 21:08:14 +0300 (EEST) (envelope-from netch) Date: Tue, 6 May 2003 21:08:14 +0300 From: Valentin Nechayev To: "Jacques A. Vidrine" Message-ID: <20030506180814.GK83663@lucky.net> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506093754.B838@beagle.fokus.fraunhofer.de> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506112711.K838@beagle.fokus.fraunhofer.de> <20030506153641.GI77708@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506153641.GI77708@madman.celabo.org> X-42: On X-Verify-Sender: verified cc: arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:08:24 -0000 Tue, May 06, 2003 at 10:36:41, nectar wrote about "Re: Re: `Hiding' libc symbols": > Renaming the internal implementation of `foo' to `_foo', and creating > a weak symbol alias with the original name (`foo'). Within libc, > use the `_foo' name when the semantics must be known (e.g. when the > behavior must not be overridden by an application accidently, i.e. > almost always). Macros in `namespace.h' help the compiler with > prototypes etc. OK. How will you distinguish accidental replacing of libc symbols from intentional replacing? It is not reasonable (just IMHO) to divide libc symbols into `allowed to override' and 'disallowed to override' groups. Well, one can say: if, e.g., application exposes Posix accordance, it should not see strlcpy() (let's continue to use it as example) from libc. So, define _strlcpy if not _POSIX_SOURCE of analog. Well, consider next Posix will include it. Define non-hidden version and break compatibility of old applications? If I don't understand something, please explain. But I think now is standards@ issue. -netch- From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:08:53 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 656F237B401 for ; Tue, 6 May 2003 11:08:53 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E0843F85 for ; Tue, 6 May 2003 11:08:52 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 0E97166; Tue, 6 May 2003 13:08:52 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id A2C8C78C66; Tue, 6 May 2003 13:08:53 -0500 (CDT) Date: Tue, 6 May 2003 13:08:53 -0500 From: "Jacques A. Vidrine" To: Julian Elischer Message-ID: <20030506180853.GH79167@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Julian Elischer , freebsd-arch@FreeBSD.org References: <20030506175557.GE79167@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:08:53 -0000 On Tue, May 06, 2003 at 11:02:24AM -0700, Julian Elischer wrote: > If you could do your census again but this time showing which symbols > clash we would have a better idea of what we are talking about.. Uh, that is the list I posted. Yes, that long list included clashing symbols only. > Probably most of these packages have these function 'in case' the system > does not. It's a pretty good mix of those that do it `in case' and those that do it for their own reasons. > You can also bet that if compiled on Linux they don't include > these functions if Linux has them, so I'm willing to bet that many of > them have ways to turn off much of the excess stuff. You would lose the bet. These applications compile and run fine on FreeBSD _now_, also. Whether or not something in libc will change in the future to break it is the question (as in the qpopper example). Or maybe the `bad' code path hasn't yet been hit. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:27:59 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C4FD37B401; Tue, 6 May 2003 11:27:59 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C921A43F93; Tue, 6 May 2003 11:27:57 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h46IRurO058362; Tue, 6 May 2003 22:27:56 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h46IRuhg058361; Tue, 6 May 2003 22:27:56 +0400 (MSD) Date: Tue, 6 May 2003 22:27:56 +0400 From: "Andrey A. Chernov" To: Dag-Erling Smorgrav Message-ID: <20030506182756.GA57720@nagual.pp.ru> References: <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:27:59 -0000 On Tue, May 06, 2003 at 19:56:27 +0200, Dag-Erling Smorgrav wrote: > - If you stayed awake through the previous paragraph you should by > now have concluded that it simply is not possible for the linker to > enforce namespaces like Andrey wants it to, because a) the linker > can't know what headers were included; b) the exact set of reserved > names can vary from compilation unit to compilation unit within the > same application and c) namespace issues affect portions of the > code which are outside the linker's purview (such as the names of > function arguments and static or automatic variables). Namespaces > are a source code issue and cannot be handled anywhere but at the > source code level. There is no problem. Each *.h function prototype can be accompanied with some assembler instruction making it strong reference. The same thing can be conditionalized at the header level using _POSIX_SOURCE or other defines. So, linker will know, what headers are included. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 11:40:38 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A181A37B401; Tue, 6 May 2003 11:40:38 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id B770643FBD; Tue, 6 May 2003 11:40:37 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 50901530E; Tue, 6 May 2003 20:40:36 +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: "Andrey A. Chernov" References: <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> <20030506182756.GA57720@nagual.pp.ru> From: Dag-Erling Smorgrav Date: Tue, 06 May 2003 20:40:35 +0200 In-Reply-To: <20030506182756.GA57720@nagual.pp.ru> (Andrey A. Chernov's message of "Tue, 6 May 2003 22:27:56 +0400") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:40:38 -0000 "Andrey A. Chernov" writes: > On Tue, May 06, 2003 at 19:56:27 +0200, Dag-Erling Smorgrav wrote: >> - If you stayed awake through the previous paragraph you should by >> now have concluded that it simply is not possible for the linker to >> enforce namespaces like Andrey wants it to, because a) the linker >> can't know what headers were included; b) the exact set of reserved >> names can vary from compilation unit to compilation unit within the >> same application and c) namespace issues affect portions of the >> code which are outside the linker's purview (such as the names of >> function arguments and static or automatic variables). Namespaces >> are a source code issue and cannot be handled anywhere but at the >> source code level. > There is no problem. Each *.h function prototype can be accompanied with > some assembler instruction making it strong reference. The same thing can > be conditionalized at the header level using _POSIX_SOURCE or other > defines. So, linker will know, what headers are included. I would like to draw your attention to points b) and c) above and ask how you plan to address them. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 12:07:50 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8586C37B401 for ; Tue, 6 May 2003 12:07:50 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4066E43F93 for ; Tue, 6 May 2003 12:07:49 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h46J7lrO059451; Tue, 6 May 2003 23:07:48 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h46J7lm6059450; Tue, 6 May 2003 23:07:47 +0400 (MSD) Date: Tue, 6 May 2003 23:07:47 +0400 From: "Andrey A. Chernov" To: Dag-Erling Smorgrav Message-ID: <20030506190747.GA59160@nagual.pp.ru> References: <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> <20030506182756.GA57720@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 19:07:50 -0000 On Tue, May 06, 2003 at 20:40:35 +0200, Dag-Erling Smorgrav wrote: > "Andrey A. Chernov" writes: > > On Tue, May 06, 2003 at 19:56:27 +0200, Dag-Erling Smorgrav wrote: > >> - If you stayed awake through the previous paragraph you should by > >> now have concluded that it simply is not possible for the linker to > >> enforce namespaces like Andrey wants it to, because a) the linker > >> can't know what headers were included; b) the exact set of reserved > >> names can vary from compilation unit to compilation unit within the > >> same application and c) namespace issues affect portions of the > >> code which are outside the linker's purview (such as the names of > >> function arguments and static or automatic variables). Namespaces > >> are a source code issue and cannot be handled anywhere but at the > >> source code level. > > There is no problem. Each *.h function prototype can be accompanied with > > some assembler instruction making it strong reference. The same thing can > > be conditionalized at the header level using _POSIX_SOURCE or other > > defines. So, linker will know, what headers are included. > > I would like to draw your attention to points b) and c) above and ask > how you plan to address them. About b), I don't quite understand, what you mean. If inside the same application some file includes, say, math.h and use sin() and another file not includes math.h and defines its own sin() it is error. About c), at this moment we discuss functions namespace only, i.e. linker "T" class. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 12:39:55 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC96337B409 for ; Tue, 6 May 2003 12:39:55 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88AEE43F3F for ; Tue, 6 May 2003 12:39:54 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id E2219530E; Tue, 6 May 2003 21:39:52 +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: "Andrey A. Chernov" References: <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> <20030506182756.GA57720@nagual.pp.ru> <20030506190747.GA59160@nagual.pp.ru> From: Dag-Erling Smorgrav Date: Tue, 06 May 2003 21:39:51 +0200 In-Reply-To: <20030506190747.GA59160@nagual.pp.ru> (Andrey A. Chernov's message of "Tue, 6 May 2003 23:07:47 +0400") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 19:39:56 -0000 "Andrey A. Chernov" writes: > On Tue, May 06, 2003 at 20:40:35 +0200, Dag-Erling Smorgrav wrote: > > I would like to draw your attention to points b) and c) above and ask > > how you plan to address them. > About b), I don't quite understand, what you mean. If inside the same > application some file includes, say, math.h and use sin() and another file > not includes math.h and defines its own sin() it is error. No. It will lead to surprising results if the file that includes really does use sin(), but if it doesn't there is no reason why the other file can not define an external symbol named sin because sin is in the application namespace in that file. > About c), at this moment we discuss functions namespace only, i.e. linker > "T" class. So you admit that your solution is incomplete? In that case, why do you insist that it is superior to Jacques Vidrine's solution, which addresses all cases without requiring us take the linker off the vendor branch and make it unusable for non-hosted applications? DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 12:44:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2839C37B401 for ; Tue, 6 May 2003 12:44:04 -0700 (PDT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0EE343FA3 for ; Tue, 6 May 2003 12:44:02 -0700 (PDT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h46Ji1mF089759; Tue, 6 May 2003 23:44:01 +0400 (MSD) Date: Tue, 6 May 2003 23:44:01 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: Terry Lambert In-Reply-To: <3EB7D23D.FD5E4191@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 19:44:04 -0000 On Tue, 6 May 2003, Terry Lambert wrote: >Igor Sysoev wrote: >> On Mon, 5 May 2003, Terry Lambert wrote: >> > Igor Sysoev wrote: >> > > On Mon, 5 May 2003, Terry Lambert wrote: >> > > What is stack glue ? >> > >> > See the code in fork1() in /sys/kern/kern_fork.c. >> >> I do not see any stack manipulation in kern_fork.c except the creating >> alternate kstack for KSE thread in 5.0. And rfork(2) can not create >> such stack - it passes 0 to fork1(). > >You misunderstand. After the rfork() returns, there is >different stack glue required to implement "a threads >library" when you use RFTHREAD than when you don't use >RFTHREAD. I do not see any difference in a stack glue when rfork() called with RFTHREAD and without it. >And I *know* it can't create the stack: you have to do >that in user space with assembly language glue you provide. > >In other words, it's working without RFTHREAD, you're just >using the wrong stack glue in user space. What is difference of these stack glues ? >> > > I use rfork_thread(3) wrapper that allows to setup another stack for >> > > rfork()ed process. >> >> By the way I found the bug in x86 rfork_thread(3)'s error handling: >> >> --- /usr/src/lib/libc/i386/gen/rfork_thread.S Wed Feb 7 03:12:45 2001 >> +++ /usr/src/lib/libc/i386/gen/rfork_thread.S Tue May 6 17:45:14 2003 >> @@ -108,5 +108,8 @@ >> * Branch here if the thread creation fails: >> */ >> 2: >> + popl %esi >> + movl %ebp, %esp >> + popl %ebp >> PIC_PROLOGUE >> jmp PIC_PLT(HIDENAME(cerror)) > > >sendpr the fix to the linuxthreads maintainer, please. I will sendpr but not to the linuxthreads maintainer. linuxthreads port does not use rfork_thread(3). It uses its own similar rfork(2) wrapper to set up the stack and this wrapper handles errors correctly. >> > > By the way linuxthreads port always uses RFTHREAD flag. >> > >> > They don't know any other way than the moral equivalent of >> > the Linux "clone" system call, so that's what they use; it's >> > technically not necessary. See also the source code in the >> >> Now it's necessary. Otherwise rfork() returns EINVAL. > >It only does that if at least one of a set of flags is not >set; I don't see where you think EINVAL is coming from. It's recent changes 1.182 in 5.0 and 1.72.2.12 in 4.8 in kern_fork.c. Now rfork() requires RFTHREAD to be set if RFPROC is set. >But in any case, if RFTHREAD makes something work for you, >then by all means use it. It should not be implied, and >it should not be required by documentation, since, as you >noticed reading the code, all it does is associate sibling >threads under a parent for killing and advisory locking. Well, but I think this change should be documented. Right now rfork(RFPROC|RFMEM) returns EINVAL and rfork_thread(2) causes segmentation fault because it does not handle errors correctly. >> > directory /usr/src/lib/libpthread, which doesn't use rfork() >> > at all. >> >> I know it. > >My point was that the only code that uses it without RFTHREAD >successfully is probably about two years old, and was never >committed to the tree as part of a threads library. You Yes, I belive it, rfork(RFPROC|RFMEM) runs on FreeBSD-4.3. >would need to check the mailing list archives for "Jason Evans" >and "John Dyson", in combination with "rfork", to find the code >that "fixes" needing RFTHREAD. RFTHREAD got to be required recently. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-arch@FreeBSD.ORG Tue May 6 12:44:36 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBD4237B401 for ; Tue, 6 May 2003 12:44:36 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A8BD43FA3 for ; Tue, 6 May 2003 12:44:35 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h46JiMLr057878; Tue, 6 May 2003 21:44:27 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Dag-Erling Smorgrav From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 06 May 2003 21:39:51 +0200." Date: Tue, 06 May 2003 21:44:22 +0200 Message-ID: <57877.1052250262@critter.freebsd.dk> cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 19:44:37 -0000 Guys, can you take this offline and come back with a solution when you have one ? -- 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 incompetenc e. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 12:51:54 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0300937B404 for ; Tue, 6 May 2003 12:51:54 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3B0043F3F for ; Tue, 6 May 2003 12:51:52 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h46JpprO060241; Tue, 6 May 2003 23:51:51 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h46JppiC060240; Tue, 6 May 2003 23:51:51 +0400 (MSD) Date: Tue, 6 May 2003 23:51:51 +0400 From: "Andrey A. Chernov" To: Dag-Erling Smorgrav Message-ID: <20030506195151.GA60115@nagual.pp.ru> References: <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> <20030506182756.GA57720@nagual.pp.ru> <20030506190747.GA59160@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 19:51:54 -0000 On Tue, May 06, 2003 at 21:39:51 +0200, Dag-Erling Smorgrav wrote: > No. It will lead to surprising results if the file that includes > really does use sin(), but if it doesn't there is no reason > why the other file can not define an external symbol named sin because > sin is in the application namespace in that file. If some file includes even not using any functions from it, it declares namespace visibility for whole application. > > About c), at this moment we discuss functions namespace only, i.e. linker > > "T" class. > > So you admit that your solution is incomplete? In that case, why do > you insist that it is superior to Jacques Vidrine's solution, which > addresses all cases without requiring us take the linker off the > vendor branch and make it unusable for non-hosted applications? It is incomplete in the same way as Jacques one since we both discuss only functions so far. The difference is that my approach move us towards standards conformance while Jacques one to opposite direction. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 13:10:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27A5D37B407; Tue, 6 May 2003 13:10:37 -0700 (PDT) Received: from noisebox.cypherpunks.to (adsl-208-201-229-163.sonic.net [208.201.229.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D991443FAF; Tue, 6 May 2003 13:10:35 -0700 (PDT) (envelope-from shamrock@cypherpunks.to) Received: from VAIO650 (adsl-208-201-229-160.sonic.net [208.201.229.160]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noisebox.cypherpunks.to (Postfix) with ESMTP id 85F8B10E; Tue, 6 May 2003 13:10:34 -0700 (PDT) From: "Lucky Green" To: Date: Tue, 6 May 2003 13:10:32 -0700 Message-ID: <007901c3140b$8ccbad20$6601a8c0@VAIO650> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: "'Geoffrey T. Falk'" Subject: Putting gbde to use: changes to fstab(5)? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 20:10:37 -0000 I believe there is a need for a convention specifying where and how gbde(4)(8) encrypted devices should be listed in system configuration files. I don't hugely care what convention will be chosen is as long as there exists a clear convention that will enable authors to write software that will make it easy to deploy gbde. Background: gbde(4)-encrypted devices need to be attached to the kernel before they can be mounted. Attaching the device requires a password, which can either be automatically generated at boot, as would be in the case for encrypted swap, or has to be supplied by the administrator, typically via ssh, as is typically the case for UFS file systems. Even a partial automation of this process requires a configuration file containing a list of bde gbde(4) devices to be attached, their purpose (swap, UFS), a (potentially implied based on file system type) hint how to obtain the password, the type of the decrypted file system, and the ultimate mount point. In other words, what we need is the information usually found in fstab(5) and a little bit more. The configuration file should contain sufficient information to later on enable the following: - swapon(8): either extend the -a option to encrypt the swap file with a random password if the swap file is marked as to be encrypted in the configuration file or perhaps add a new option to swapon(8) to mount swap devices marked as to be encrypted. - add scripts that are executed, potentially manually, though in come cases as part of an extended boot sequence, after the system has come up in multi-user mode and sshd is running that will obtain the password, fsck the FS, and mount the unencrypted FS. - make other parts of the base OS, such as mount(8) aware of encrypted devices. I suspect the most intuitive approach to creating such a config file would be to make slight extensions to fstab(5), which was the preferred, though not unanimous, method mentioned to me in numerous conversations with current and potential gbde users. However, this carries the risk that software that uses fstab at present may get confused when presented with additional options. However, I don't know how big of problem this would really be in practice. Sooner or later, many of the programs that currently make use of fstab may need to become gbde-aware in some form or another for gbde to achieve its full potential. The absence of a formal way to specify gbde partitions in the config files at the moment has two direct consequences: 1) it is delaying the creation of various automation scripts and potential integration of gbde support with system utilities. 2) informal and not necessarily broadly suitable or compatible conventions are bound to appear. For an example of how one might enable encrypted swap at boot see Geoffrey Falk's sample script archived at http://segment7.net/FreeBSD/encrypted_swap.txt Straw man proposal options: 1) extend fstab(5)'s fs_vfstype field to accept a comma-separated list ("ufs,bde") to indicate that the FS system is gbde-encrypted. 2) extend fs_mntops field instead ("rw,bde"). 3) specify the format for an fstab-like file for bde devices "fstab.bde" My preference is for 1) or 2), because it is the most intuitive solution for your average FreeBSD administrator, but others may be able to think of more/better options. Note that I am not asking to solve the general, and at this time largely undetermined, problem domain of how to specify future gbde-encrypted devices that may not correspond to commonly-used FreeBSD file systems. Thanks for your guidance, --Lucky From owner-freebsd-arch@FreeBSD.ORG Tue May 6 13:12:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75AD237B404 for ; Tue, 6 May 2003 13:12:13 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7999443F75 for ; Tue, 6 May 2003 13:12:12 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4701 invoked from network); 6 May 2003 20:12:18 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 6 May 2003 20:12:18 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h46KC8p0001371; Tue, 6 May 2003 16:12:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 06 May 2003 16:12:15 -0400 (EDT) From: John Baldwin To: Igor Sysoev cc: peter@FreeBSD.org cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 20:12:13 -0000 On 06-May-2003 Igor Sysoev wrote: > On Mon, 5 May 2003, Terry Lambert wrote: > >> Igor Sysoev wrote: >> > On Mon, 5 May 2003, Terry Lambert wrote: >> > What is stack glue ? >> >> See the code in fork1() in /sys/kern/kern_fork.c. > > I do not see any stack manipulation in kern_fork.c except the creating > alternate kstack for KSE thread in 5.0. And rfork(2) can not create > such stack - it passes 0 to fork1(). > In 4.x there's no stack code at all. > >> > I use rfork_thread(3) wrapper that allows to setup another stack for >> > rfork()ed process. > > By the way I found the bug in x86 rfork_thread(3)'s error handling: > > --- /usr/src/lib/libc/i386/gen/rfork_thread.S Wed Feb 7 03:12:45 2001 > +++ /usr/src/lib/libc/i386/gen/rfork_thread.S Tue May 6 17:45:14 2003 > @@ -108,5 +108,8 @@ > * Branch here if the thread creation fails: > */ > 2: > + popl %esi > + movl %ebp, %esp > + popl %ebp > PIC_PROLOGUE > jmp PIC_PLT(HIDENAME(cerror)) Shouldn't this be: 2: + addl $8, %esp + popl %esi + movl %ebp, %esp + popl %ebp PIC_PROLOGUE jmp PIC_PLT(HIDENAME(cerror)) To match the parent return case above the 1: label? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Tue May 6 13:16:55 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76C7337B404 for ; Tue, 6 May 2003 13:16:55 -0700 (PDT) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A99143F85 for ; Tue, 6 May 2003 13:16:53 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id h56KGnxr086253; Tue, 6 May 2003 23:16:49 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.8p1/8.12.8) id h46KF3Id007855; Tue, 6 May 2003 23:15:03 +0300 (EEST) (envelope-from netch) Date: Tue, 6 May 2003 23:15:03 +0300 From: Valentin Nechayev To: Dag-Erling Smorgrav Message-ID: <20030506201503.GB313@iv.nn.kiev.ua> References: <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-42: On Organization: Dark side of coredump cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 20:16:55 -0000 Tue, May 06, 2003 at 19:56:27, des (Dag-Erling Smorgrav) wrote about "Re: `Hiding' libc symbols": > - Applications which rely on overriding parts of the implementation > are non-conforming and cannot claim a "moral right" to do so. In > the few cases where applications have good and useful reasons for > overriding parts of the implementation, they can easily be modified > to cope with whatever techniques the implementation uses to avoid > namespace collisions. OK, this is possibly the main discussion stone. If application wants to override some library function, a mechanism to do it should exist (in any case application can get function address and install machine jump command to its, so it is not desirable to make unreasonable barriers;)) But this mechanism should be used explicitly, if policy requires. Thanks for good clarification. > The standard reserves a number of names and namespaces for the > implementation while others are reserved for the application. We (as Hmm, the first thing I want to see in C is namespaces, similar to C++ ones or better. > Namespaces > are a source code issue and cannot be handled anywhere but at the > source code level. I thought identically but hadn't enough words to say it. But what form of source code level support should be used? Some namespaces are defined using Posix|X/Open|SUS macros, but too few applications use it and properly define restriction macros in their sources; moreover, average open-source application is written with requesting of maximal namespace importing (as #define _GNU_SOURCE for GNU libc headers). C header file traditions adds its own hell: one can't include without strlcpy() not defining Posix restrictions, and there is no /usr/include/string/strlcpy.h which defines only it and size_t for its prototype;( Continuing this style, one can't separate declarations in subsets (Posix subset, SUS subset, BSD subset...) and the same problems will continue. (This wasn't positive position, but too skeptic...) -netch- From owner-freebsd-arch@FreeBSD.ORG Tue May 6 13:31:01 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D00C37B401 for ; Tue, 6 May 2003 13:31:01 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E36943F93 for ; Tue, 6 May 2003 13:31:00 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h46KUrLr058761; Tue, 6 May 2003 22:30:54 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: "Lucky Green" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 06 May 2003 13:10:32 PDT." <007901c3140b$8ccbad20$6601a8c0@VAIO650> Date: Tue, 06 May 2003 22:30:53 +0200 Message-ID: <58760.1052253053@critter.freebsd.dk> cc: "'Geoffrey T. Falk'" cc: freebsd-arch@freebsd.org Subject: Re: Putting gbde to use: changes to fstab(5)? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 20:31:01 -0000 In message <007901c3140b$8ccbad20$6601a8c0@VAIO650>, "Lucky Green" writes: >I believe there is a need for a convention specifying where and how >gbde(4)(8) encrypted devices should be listed in system configuration >files. I don't hugely care what convention will be chosen is as long as >there exists a clear convention that will enable authors to write >software that will make it easy to deploy gbde. I fully agree this far. The point where I start to get uneasy is where people think this will only be about GBDE. I hope to soon unleash a GEOM class I'm playing with here, which allows configuration of multi-path to a device. This will mainly be useful for SAN environments where it enables use of dual FC adapters and redundant fibres, but it can also be used with plain SCSI. A number of other GEOM classes still only at the conceptual or very early "proof of concept" level may also require "manual configuration" (as opposed to "autoconfiguration"). In from the left comes the issue of removable devices and an interface to devd(8) or if that is impossible: the creation of a vold(8)/geomd(8) or possibly hi-jacking of amd(8) I am not saying that you should not go ahead, in fact, if you have time you should, but I really would prefer if we can avoid seeing an explosion of config files along the lines of: /etc/gbde.cf /etc/gmirror.cf /etc/graid5.cf /etc/gxxx.cf ... There got to be some way we can do this in sufficiently general way, that it can be reused for other GEOM classes ? I'm sorry I cannot take an active lead in this, but my TODO list has recently eaten my pencil and the judge rule that it was a clear and justified act of self-defence. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 13:42:34 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 116CB37B401 for ; Tue, 6 May 2003 13:42:34 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F7B543F75 for ; Tue, 6 May 2003 13:42:33 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id EAD8C530E; Tue, 6 May 2003 22:42:31 +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: "Andrey A. Chernov" References: <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> <20030506182756.GA57720@nagual.pp.ru> <20030506190747.GA59160@nagual.pp.ru> <20030506195151.GA60115@nagual.pp.ru> From: Dag-Erling Smorgrav Date: Tue, 06 May 2003 22:42:31 +0200 In-Reply-To: <20030506195151.GA60115@nagual.pp.ru> (Andrey A. Chernov's message of "Tue, 6 May 2003 23:51:51 +0400") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 20:42:34 -0000 "Andrey A. Chernov" writes: > It is incomplete in the same way as Jacques one since we both discuss only > functions so far. The difference is that my approach move us towards > standards conformance while Jacques one to opposite direction. You're the one advocating breaking the linker. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Tue May 6 14:20:32 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA1C37B407 for ; Tue, 6 May 2003 14:20:31 -0700 (PDT) Received: from noisebox.cypherpunks.to (adsl-208-201-229-163.sonic.net [208.201.229.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35D7543FBD for ; Tue, 6 May 2003 14:20:30 -0700 (PDT) (envelope-from shamrock@cypherpunks.to) Received: from VAIO650 (adsl-208-201-229-160.sonic.net [208.201.229.160]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noisebox.cypherpunks.to (Postfix) with ESMTP id 48EEA10E; Tue, 6 May 2003 14:20:29 -0700 (PDT) From: "Lucky Green" To: "'Poul-Henning Kamp'" Date: Tue, 6 May 2003 14:20:27 -0700 Message-ID: <007a01c31415$511623a0$6601a8c0@VAIO650> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <58760.1052253053@critter.freebsd.dk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: "'Geoffrey T. Falk'" cc: freebsd-arch@freebsd.org Subject: RE: Putting gbde to use: changes to fstab(5)? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 21:20:32 -0000 Poul-Henning wrote: > In message <007901c3140b$8ccbad20$6601a8c0@VAIO650>, "Lucky > Green" writes: > > >I believe there is a need for a convention specifying where and how > >gbde(4)(8) encrypted devices should be listed in system > configuration > >files. I don't hugely care what convention will be chosen is > as long as > >there exists a clear convention that will enable authors to write > >software that will make it easy to deploy gbde. > > I fully agree this far. > > The point where I start to get uneasy is where people think > this will only be about GBDE. [excellent examples illustrating why there is a need to provide for additional disk-related configuration information elided] > There got to be some way we can do this in sufficiently > general way, that it can be reused for other GEOM classes ? > > I'm sorry I cannot take an active lead in this, but my TODO > list has recently eaten my pencil and the judge rule that it > was a clear and justified act of self-defence. Understood, which is one of the reasons why I posted this question to -arch. Perhaps what is required is a config file format and/or config file tree for disks and file systems that is aware that disks many come and go. I just happen to need a determination on a config file format for gbde devices, because I would like to both deploy and contribute back gbde automation tools. Reading PHK's comments, it appears that file systems can perhaps be categorized based on when they become available after boot. The following rough list of categories may not be complete, but the total number of categories may well be manageably small. Immediately after boot: /, swap, /usr [Though some day in my life I would like to see everything in /usr not required by sshd and gbde to be encrypted]. Some undetermined time after boot: Encrypted file systems that require a password to be entered by remote either via sshd or perhaps in the future via a remote authentication server. Other network- connected storage that requires some type of interaction. File systems that may appear and disappear at any time: Floppies, USB pen drives, etc. I agree that when looking at the configuration file structure problem from this perspective, fstab might become too complex should it be expanded to meet all these needs. However, unless the solution would be to remove fstab in its entirety, replacing it with "fstab.boot", "fstab.later", and "fstab.removable" or the like, I believe that the file systems should still be listed in fstab, which in turn perhaps could contain one or more options indicating "for more configuration information, look in [fstab.bde, fstab.removable, etc.] For example, an option might read "rw,removable". Whatever the solution might be, I believe determining a config file structure or hierarchy on which we'll be able to build tools ultimately comes down to an architectural question. Thanks, --Lucky From owner-freebsd-arch@FreeBSD.ORG Tue May 6 14:39:01 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0D5737B404 for ; Tue, 6 May 2003 14:39:00 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E90E43FB1 for ; Tue, 6 May 2003 14:38:59 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h46LcrVo066485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2003 17:38:54 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h46LcrnB066484; Tue, 6 May 2003 17:38:53 -0400 (EDT) (envelope-from wollman) Date: Tue, 6 May 2003 17:38:53 -0400 (EDT) From: Garrett Wollman Message-Id: <200305062138.h46LcrnB066484@khavrinen.lcs.mit.edu> To: shamrock@cypherpunks.to In-Reply-To: <20030506212133$0c75@grapevine.lcs.mit.edu> References: <58760.1052253053@critter.freebsd.dk> Organization: MIT Laboratory for Computer Science X-Spam-Score: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: arch@FreeBSD.org Subject: Re: Putting gbde to use: changes to fstab(5)? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 21:39:02 -0000 In article <20030506212133$0c75@grapevine.lcs.mit.edu> you write: >I just happen to need a determination on a config file format >for gbde devices, because I would like to both deploy and contribute >back gbde automation tools. I think the right answer is as follows: In the `fstype' field, if the value begins with a special character (TBD), the program indicated there will be run with the following arguments: - type of operation (mount, unmount, dump, swap, anything else?) - name of underlying device - mount point - mount flags It shall generate on standard output an fstab line which is to be interpreted in place of the original entry. This allows for maximum flexibility: you can have it construct arbitrarily GEOM topologies, prompt for any passwords as may seem necessary, even automatically inspect the media and choose an appropriate filesystem type. -GAWollman From owner-freebsd-arch@FreeBSD.ORG Tue May 6 21:41:09 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09F9637B40A; Tue, 6 May 2003 21:41:09 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48A7643FA3; Tue, 6 May 2003 21:41:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DGjr-0006St-00; Tue, 06 May 2003 21:41:07 -0700 Message-ID: <3EB88E0D.D8AA9B2F@mindspring.com> Date: Tue, 06 May 2003 21:39:41 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030505225021.GA43345@nagual.pp.ru> <20030505232012.GC21953@madman.celabo.org> <20030506152542.GC77708@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a476c10568b29f5f064e8d1e8ad765b843a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: "Andrey A. Chernov" cc: Daniel Eischen cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 04:41:09 -0000 "Jacques A. Vidrine" wrote: > On Tue, May 06, 2003 at 09:56:06AM +0200, Harti Brandt wrote: > > There is no guarantee that you 'fix' the port by hiding the symbol. You > > may as well break it. This depends on the function itself and on the > > internal relationships in libc. You have to go through each individual > > port and see what happens anyway. > > Please explain. I _am_ guaranteed that keeping the port from hijacking > strlcpy calls in libc will not break the port. How could the port rely > on the internals of libc? Have you looked at the "electric fence" port lately? -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue May 6 21:50:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A23437B401; Tue, 6 May 2003 21:50:37 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67EB843FA3; Tue, 6 May 2003 21:50:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DGt0-0007k6-00; Tue, 06 May 2003 21:50:35 -0700 Message-ID: <3EB89046.F7128C8A@mindspring.com> Date: Tue, 06 May 2003 21:49:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> <3EB7CC73.9C61C27E@mindspring.com> <20030506152557.GD77708@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42b992a946c257371dd0c2e29e38ec613a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 04:50:37 -0000 "Jacques A. Vidrine" wrote: > On Tue, May 06, 2003 at 07:53:39AM -0700, Terry Lambert wrote: > > Perhaps instead of asking how to prevent symbol replacement, one > > should be asking how to get rid of incestuous functions in the > > library implementation for standard library functions. > > > > No, I do not expect "_fmt" (or whatever) to go away from common > > code in printf/sprintf/whatever. But I do expect it to be "_fmt" > > instead of "fmt", i.e. in implementation space, rather than in > > the symbol space legal for users to use. > > This is exactly what I wish to achieve. This is exactly the approach > that I took with strlcpy [1]: the internal implementation is called > `_strlcpy', while the exported symbol remains `strlcpy'. I have no problem at all, so long as _strlcpy() isn't an exposed function, i.e., there is no strlcpy() that calls _strlcpy(), doing nothing else. I.e.: if there are internal functions in the library, they should not have external implementation. For A(), B(), and C(), all of which use the functionality of C(), I think the correct thing to do is to either repeat the code in each function, or make the code depend on some inline function, i.e. __A() and __B() call _libc_C(), and __C() has a seperate implementation; then A() is weakly bound to __A(), B() to __B(), and C() to __C(). Then you *remove* _libc_C() from the symbol table (it's either an inline, or you have to use explicit symbol sets and the linker). Then you can override the function, no problem. Otherwise you are screwed when it comes to profiling. -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue May 6 22:20:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D46E137B401 for ; Tue, 6 May 2003 22:20:26 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F70143F3F for ; Tue, 6 May 2003 22:20:26 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by attbi.com (sccrmhc03) with SMTP id <20030507052024003005n4ome>; Wed, 7 May 2003 05:20:25 +0000 Date: Tue, 6 May 2003 22:20:22 -0700 (PDT) From: Doug Barton To: Poul-Henning Kamp In-Reply-To: <58760.1052253053@critter.freebsd.dk> Message-ID: <20030506220503.W5620@znfgre.qbhto.arg> References: <58760.1052253053@critter.freebsd.dk> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Lucky Green cc: "'Geoffrey T. Falk'" cc: freebsd-arch@freebsd.org Subject: Re: Putting gbde to use: changes to fstab(5)? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 05:20:27 -0000 On Tue, 6 May 2003, Poul-Henning Kamp wrote: > In message <007901c3140b$8ccbad20$6601a8c0@VAIO650>, "Lucky Green" writes: > > >I believe there is a need for a convention specifying where and how > >gbde(4)(8) encrypted devices should be listed in system configuration > >files. I don't hugely care what convention will be chosen is as long as > >there exists a clear convention that will enable authors to write > >software that will make it easy to deploy gbde. > > I fully agree this far. As do I, even if lucky's penchant for writing really long "position papers" that do nothing other than state really obvious conclusions is starting to get annoying. :) > The point where I start to get uneasy is where people think this will > only be about GBDE. We've started discussing ways to implement gbde initialization within rc (which is obviously my preferred solution), and a user has submitted one implementation of this. I'm hoping to polish and test that asap, it's high on my list now that I've cleared a bunch of other small WIP's that I wanted to get done before the freeze. I'm sensitive to the issue Poul-Henning raised about making a solution that will encompass more than gbde, which is why I didn't just jump in on the committing the gbde script that was sent in. Of course, if someone else comes up with another solution, I'm all ears. > I am not saying that you should not go ahead, in fact, if you have > time you should, but I really would prefer if we can avoid seeing > an explosion of config files along the lines of: > /etc/gbde.cf > /etc/gmirror.cf > /etc/graid5.cf > /etc/gxxx.cf > ... Yeah, that'd be bad. If anything, /etc/geom.d/*.cf would be better, but it would be nice if we could find a more general solution. Poul-Henning, have you taken a look at the new devfs.conf file that I just committed? Would something like that be scalable with what you have in mind? > I'm sorry I cannot take an active lead in this, but my TODO list > has recently eaten my pencil and the judge rule that it was a clear > and justified act of self-defence. No problem... not only is your time most valuable actually programming the stuff, but my experience is that people who write really good low level software aren't always the best people to translate that into user experience. :) -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Tue May 6 22:39:56 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCE7037B401; Tue, 6 May 2003 22:39:56 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2247543F3F; Tue, 6 May 2003 22:39:54 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DHei-0000eS-00; Tue, 06 May 2003 22:39:53 -0700 Message-ID: <3EB89BD6.4F1C0807@mindspring.com> Date: Tue, 06 May 2003 22:38:30 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506175557.GE79167@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a463878834c50389609f5005f41b0c182f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: David O'Brien cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 05:39:57 -0000 "Jacques A. Vidrine" wrote: > > > Do you also want to `fix' the other ports that define their own strlcpy? > > > > Ports have maintainers. Please create a PR for them. > > But gee, the problem is that the ports themselves are not really > in error, unless one is a standards fascist that believes that an > application can never define any function that might be in some > standard's namespace. I'm a standards faciest, though I'm usually pretty lenient about it, unless it comes to obvious bugs like code not using pthreads_mutex'es where required by the standard. And I think the problem can happen, even though the ports may not be in error. Consider: the linker sees symbols defined in libc, even if the compiler doesn't because of all the namespace voodoo having been done precisely correctly in the application. There are also a number of libc functions which are defined by a newer standard but not an older one, which are used internally to implement functions defined in both the older and newer standards, such that if the port is compliant with the older standard, has it's namespace ducks all in a row, and carries around it's own copy of the newer function, it will cause functions in the standard with which it complies to fail. In other words, just because the compiler can't see it, does not mean the linker won't. It's probably impossible to resolve this completely, without more linker-foo and compiler-foo than I'm willing to contemplate to make the linker aware of the standards used by the compiler. God help you, if you have a program that depends on a third party library that depends on a system library... -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue May 6 22:40:53 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CC3837B401; Tue, 6 May 2003 22:40:53 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EA8743F75; Tue, 6 May 2003 22:40:52 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h475emLr065005; Wed, 7 May 2003 07:40:48 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Doug Barton From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 06 May 2003 22:20:22 PDT." <20030506220503.W5620@znfgre.qbhto.arg> Date: Wed, 07 May 2003 07:40:48 +0200 Message-ID: <65004.1052286048@critter.freebsd.dk> cc: Lucky Green cc: "'Geoffrey T. Falk'" cc: freebsd-arch@freebsd.org Subject: Re: Putting gbde to use: changes to fstab(5)? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 05:40:53 -0000 In message <20030506220503.W5620@znfgre.qbhto.arg>, Doug Barton writes: >Yeah, that'd be bad. If anything, /etc/geom.d/*.cf would be better, but it >would be nice if we could find a more general solution. Poul-Henning, have >you taken a look at the new devfs.conf file that I just committed? Would >something like that be scalable with what you have in mind? I have only briefly looked at devfs.conf, and not gotten around to check if you just execute those changes at boot time, or if you also load them into devfs(8) as default rules ? I don't really have anything specific in mind, that's more or less the trouble from my point of view, if I knew what we would need I'd be the first to tell you guys, but at this time I simply don't think I know where we'll end... >> I'm sorry I cannot take an active lead in this, but my TODO list >> has recently eaten my pencil and the judge rule that it was a clear >> and justified act of self-defence. > >No problem... not only is your time most valuable actually programming the >stuff, but my experience is that people who write really good low level >software aren't always the best people to translate that into user >experience. :) I plead the fifth! :-) -- 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. From owner-freebsd-arch@FreeBSD.ORG Tue May 6 22:52:09 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6B4B37B401 for ; Tue, 6 May 2003 22:52:09 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id F215D43F85 for ; Tue, 6 May 2003 22:52:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DHpw-0001l8-00; Tue, 06 May 2003 22:51:29 -0700 Message-ID: <3EB89E8C.FD00B065@mindspring.com> Date: Tue, 06 May 2003 22:50:04 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav References: <20030501182820.GA53641@madman.celabo.org> <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4397de1aea7b5b86652c9b1477b1247d8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 05:52:09 -0000 Dag-Erling Smorgrav wrote: > - If you stayed awake through the previous paragraph you should by > now have concluded that it simply is not possible for the linker to > enforce namespaces like Andrey wants it to, because a) the linker > can't know what headers were included; b) the exact set of reserved > names can vary from compilation unit to compilation unit within the > same application and c) namespace issues affect portions of the > code which are outside the linker's purview (such as the names of > function arguments and static or automatic variables). Namespaces > are a source code issue and cannot be handled anywhere but at the > source code level. Technically, this is not true. However, tiered dependencies will still enable this to break (A(standard 1) depends on lib containing B(standard 1+) depends on libc(standard 1++)). Other than that, you could, using an ELF section, attribute the object files by the standards which were in effect when they were compiled, and do one heck of a lot of work in the linker and with symbol decoration to deal with this. This can be made to work with #pragma, if you are using a compiler with an external preprocessor. In effect, this is what Linux does, when it versions it's ABI in the current glibc ABI, and in its kernel modules symbol stuff. Its why I object so strongly to changing FreeBSD to do the same thing, even though there are clever tricks you can do if you have it. Doing this would be almost incredibly painful, since it would involve namespace attributed symbols, and import and export lists. But it's *possible*. -- Terry From owner-freebsd-arch@FreeBSD.ORG Tue May 6 22:59:22 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DD9037B401 for ; Tue, 6 May 2003 22:59:22 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 681E143FA3 for ; Tue, 6 May 2003 22:59:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DHxO-0002iZ-00; Tue, 06 May 2003 22:59:10 -0700 Message-ID: <3EB8A058.E3F1D452@mindspring.com> Date: Tue, 06 May 2003 22:57:44 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav References: <20030501191027.GA53801@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030505205051.GA40572@nagual.pp.ru> <20030505231135.GA21953@madman.celabo.org> <20030505231837.GA44533@nagual.pp.ru> <20030506170823.GI83663@lucky.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e71fce681e859ea296e5ccdb6407c607387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 05:59:22 -0000 Dag-Erling Smorgrav wrote: > "Andrey A. Chernov" writes: > > There is no problem. Each *.h function prototype can be accompanied with > > some assembler instruction making it strong reference. The same thing can > > be conditionalized at the header level using _POSIX_SOURCE or other > > defines. So, linker will know, what headers are included. > > I would like to draw your attention to points b) and c) above and ask > how you plan to address them. Forget that, I want to see his "make it a strong reference in the header file for multiple object files in the same binary"-foo! -- Terry From owner-freebsd-arch@FreeBSD.ORG Wed May 7 00:03:10 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA93237B401 for ; Wed, 7 May 2003 00:03:09 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F1E143F85 for ; Wed, 7 May 2003 00:03:09 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DIxE-0007OD-00; Wed, 07 May 2003 00:03:05 -0700 Message-ID: <3EB8AF30.B25A18CD@mindspring.com> Date: Wed, 07 May 2003 00:01:04 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Sysoev References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4cb838842e4a11963c0eaa8b93a2d4bf8548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 07:03:10 -0000 Igor Sysoev wrote: > >It only does that if at least one of a set of flags is not > >set; I don't see where you think EINVAL is coming from. > > It's recent changes 1.182 in 5.0 and 1.72.2.12 in 4.8 in kern_fork.c. > Now rfork() requires RFTHREAD to be set if RFPROC is set. I still don't see it. I'm looking at 1.197: if ((uap->flags & (RFPROC | RFTHREAD | RFFDG | RFCFDG)) == RFPROC) return(EINVAL); The only thing this does is prevent you from using RFPROC without at least one of the other flags. > >But in any case, if RFTHREAD makes something work for you, > >then by all means use it. It should not be implied, and > >it should not be required by documentation, since, as you > >noticed reading the code, all it does is associate sibling > >threads under a parent for killing and advisory locking. > > Well, but I think this change should be documented. > Right now rfork(RFPROC|RFMEM) returns EINVAL and rfork_thread(2) causes > segmentation fault because it does not handle errors correctly. I wish you had said these were your flags earlier; I have been (incorrectly) assuming you were passing in one of the existing RF*FDG flags, and as a result, that you had rolled your own "helper" code. So, with that in mind... This is correct behaviour. You must set a flag in the set of (RFTHREAD | RFFDG | RFCFDG) when you set RFPROC. It could be rewritten (less efficiently) as: if ((uap->flags & RFPROC) == RFPROC && (uap_flags & (RFTHREAD | RFFDG | RFCFDG)) == 0) return(EINVAL); ...Basically, if you use RFPROC, you have to do something about the file descriptor table, so that it's in one of 3 states: RFTHREAD I know the open file table is shared, so I will act accordingly (I promise to communicate state between processes so that if one closes a file, the other does not attempt to use it). RFFDG I want the file table copied, so that if one process screws it up, it won't break the other processes (I promise to very carefully examine all the descriptors I think are still open to see if they were closed on me by the O_EXCL bit having been set before rfork() was called). RFCFDG I want the file table cleared, so that the new process starts out with a clean slate Maybe it would be more correct to seperate RFTHREAD into an RFSFDG and a seperate RFTHREAD, for the P_WEXIT/SIGKILL stuff. But the bottom line is that this is not a bug, it's a change to a system interface that no one realized was being used. Worst case, the interface should be versioned, but I think that's overkill. You might want to #ifdef out the "if" statement, as a local hack. > >My point was that the only code that uses it without RFTHREAD > >successfully is probably about two years old, and was never > >committed to the tree as part of a threads library. You > > Yes, I belive it, rfork(RFPROC|RFMEM) runs on FreeBSD-4.3. You could just correct the code to pass the flag to the helper function; this is probably the correct thing to do. > >would need to check the mailing list archives for "Jason Evans" > >and "John Dyson", in combination with "rfork", to find the code > >that "fixes" needing RFTHREAD. > > RFTHREAD got to be required recently. It changed an implied bit into a real bit. Personally, I prefer real bits. Probably, though it should be seperated, since the RFTHREAD side effect in fork1() doesn't happen if you don't want it to... I don't personally see it as something undesirable, though it might surprise someone who expects to explicitly shutdown their own rfork'ed processes, and finds them disappeared... that would still leave you in the same boat, though. -- Terry From owner-freebsd-arch@FreeBSD.ORG Wed May 7 01:10:01 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B99BE37B401 for ; Wed, 7 May 2003 01:10:01 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B077543F3F for ; Wed, 7 May 2003 01:10:00 -0700 (PDT) (envelope-from ilmar@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h478AC9R085638 for ; Wed, 7 May 2003 04:10:12 -0400 (EDT) (envelope-from ilmar@watson.org) Received: from localhost (ilmar@localhost)h478ACm2085635 for ; Wed, 7 May 2003 04:10:12 -0400 (EDT) (envelope-from ilmar@watson.org) X-Authentication-Warning: fledge.watson.org: ilmar owned process doing -bs Date: Wed, 7 May 2003 04:10:11 -0400 (EDT) From: "Ilmar S. Habibulin" To: freebsd-arch@freebsd.org Message-ID: <20030507040750.H84964@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: machine dependant functions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 08:10:02 -0000 Is there any well described set of md kernel functions one should implement in order to port kernel to new architecture? Or i should brows through sys/ subdirs? Thanks. From owner-freebsd-arch@FreeBSD.ORG Wed May 7 01:15:27 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2831C37B404; Wed, 7 May 2003 01:15:27 -0700 (PDT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7052643F85; Wed, 7 May 2003 01:15:25 -0700 (PDT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id h478FOmF099453; Wed, 7 May 2003 12:15:24 +0400 (MSD) Date: Wed, 7 May 2003 12:15:24 +0400 (MSD) From: Igor Sysoev X-Sender: is@is To: John Baldwin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: peter@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: rfork(RFPROC|RFMEM) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 08:15:27 -0000 On Tue, 6 May 2003, John Baldwin wrote: > On 06-May-2003 Igor Sysoev wrote: > > On Mon, 5 May 2003, Terry Lambert wrote: > > > >> Igor Sysoev wrote: > >> > I use rfork_thread(3) wrapper that allows to setup another stack for > >> > rfork()ed process. > > > > By the way I found the bug in x86 rfork_thread(3)'s error handling: > > > > --- /usr/src/lib/libc/i386/gen/rfork_thread.S Wed Feb 7 03:12:45 2001 > > +++ /usr/src/lib/libc/i386/gen/rfork_thread.S Tue May 6 17:45:14 2003 > > @@ -108,5 +108,8 @@ > > * Branch here if the thread creation fails: > > */ > > 2: > > + popl %esi > > + movl %ebp, %esp > > + popl %ebp > > PIC_PROLOGUE > > jmp PIC_PLT(HIDENAME(cerror)) > > Shouldn't this be: > > 2: > + addl $8, %esp > + popl %esi > + movl %ebp, %esp > + popl %ebp > PIC_PROLOGUE > jmp PIC_PLT(HIDENAME(cerror)) > > To match the parent return case above the 1: label? Yes, you are right. My patch does not restore %esi but set it to 0. It seems that my code that I used to test the patch does not depend on %esi in an error case. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-arch@FreeBSD.ORG Wed May 7 01:35:30 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEFD637B401 for ; Wed, 7 May 2003 01:35:30 -0700 (PDT) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57D4043F93 for ; Wed, 7 May 2003 01:35:30 -0700 (PDT) (envelope-from hmp@perrin.int.nxad.com) Received: by perrin.int.nxad.com (Postfix, from userid 1072) id 4D2022105C; Wed, 7 May 2003 01:35:29 -0700 (PDT) Date: Wed, 7 May 2003 01:35:29 -0700 From: Hiten Pandya To: freebsd-arch@FreeBSD.ORG Message-ID: <20030507083529.GA73613@perrin.int.nxad.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: FreeBSD FreeBSD 4.7-STABLE Subject: Using weak referencing for uuid routines X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 08:35:31 -0000 --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello gang. I am sending a patch for changing the uuid part of libc to use weak referencing. This was originally requested by Alexander Kabaev . If this patch is accepted, than I would like one of src committers to commit it for me. Cheers. -- Hiten (hmp@FreeBSD.ORG) --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uuid-weak-ref.patch" Index: lib/libc/uuid/uuid_compare.c =================================================================== RCS file: /home/ncvs/src/lib/libc/uuid/uuid_compare.c,v retrieving revision 1.1 diff -u -r1.1 uuid_compare.c --- lib/libc/uuid/uuid_compare.c 30 Oct 2002 03:51:00 -0000 1.1 +++ lib/libc/uuid/uuid_compare.c 6 May 2003 17:27:21 -0000 @@ -40,7 +40,7 @@ * than any non-nil UUID. */ int32_t -uuid_compare(uuid_t *a, uuid_t *b, uint32_t *status) +__uuid_compare(uuid_t *a, uuid_t *b, uint32_t *status) { int res; @@ -74,3 +74,5 @@ return ((res < 0) ? -1 : 1); return (memcmp(a->node, b->node, sizeof(uuid_t))); } + +__weak_reference(__uuid_compare, uuid_compare); Index: lib/libc/uuid/uuid_create.c =================================================================== RCS file: /home/ncvs/src/lib/libc/uuid/uuid_create.c,v retrieving revision 1.1 diff -u -r1.1 uuid_create.c --- lib/libc/uuid/uuid_create.c 30 Oct 2002 03:51:00 -0000 1.1 +++ lib/libc/uuid/uuid_create.c 6 May 2003 17:29:24 -0000 @@ -36,7 +36,7 @@ * http://www.transarc.ibm.com/Library/documentation/dce/1.1/uuid_create.html */ void -uuid_create(uuid_t *u, uint32_t *status) +__uuid_create(uuid_t *u, uint32_t *status) { if (status) @@ -44,3 +44,5 @@ uuidgen(u, 1); } + +__weak_reference(__uuid_create, uuid_create); Index: lib/libc/uuid/uuid_create_nil.c =================================================================== RCS file: /home/ncvs/src/lib/libc/uuid/uuid_create_nil.c,v retrieving revision 1.1 diff -u -r1.1 uuid_create_nil.c --- lib/libc/uuid/uuid_create_nil.c 30 Oct 2002 03:51:00 -0000 1.1 +++ lib/libc/uuid/uuid_create_nil.c 6 May 2003 17:30:15 -0000 @@ -37,7 +37,7 @@ * http://www.transarc.ibm.com/Library/documentation/dce/1.1/uuid_create_nil.html */ void -uuid_create_nil(uuid_t *u, uint32_t *status) +__uuid_create_nil(uuid_t *u, uint32_t *status) { if (status) @@ -45,3 +45,5 @@ bzero(u, sizeof(*u)); } + +__weak_reference(__uuid_create_nil, uuid_create_nil); Index: lib/libc/uuid/uuid_equal.c =================================================================== RCS file: /home/ncvs/src/lib/libc/uuid/uuid_equal.c,v retrieving revision 1.1 diff -u -r1.1 uuid_equal.c --- lib/libc/uuid/uuid_equal.c 30 Oct 2002 03:51:00 -0000 1.1 +++ lib/libc/uuid/uuid_equal.c 6 May 2003 17:27:01 -0000 @@ -37,7 +37,7 @@ * http://www.transarc.ibm.com/Library/documentation/dce/1.1/uuid_equal.html */ int32_t -uuid_equal(uuid_t *a, uuid_t *b, uint32_t *status) +__uuid_equal(uuid_t *a, uuid_t *b, uint32_t *status) { if (status != NULL) @@ -54,3 +54,5 @@ /* Do a byte for byte comparison. */ return ((memcmp(a, b, sizeof(uuid_t))) ? 0 : 1); } + +__weak_reference(__uuid_equal, uuid_equal); Index: lib/libc/uuid/uuid_from_string.c =================================================================== RCS file: /home/ncvs/src/lib/libc/uuid/uuid_from_string.c,v retrieving revision 1.1 diff -u -r1.1 uuid_from_string.c --- lib/libc/uuid/uuid_from_string.c 30 Oct 2002 03:51:00 -0000 1.1 +++ lib/libc/uuid/uuid_from_string.c 6 May 2003 17:27:40 -0000 @@ -42,7 +42,7 @@ * native byte order. */ void -uuid_from_string(const char *s, uuid_t *u, uint32_t *status) +__uuid_from_string(const char *s, uuid_t *u, uint32_t *status) { int n; @@ -91,3 +91,5 @@ *status = uuid_s_ok; } } + +__weak_reference(__uuid_from_string, uuid_from_string); Index: lib/libc/uuid/uuid_hash.c =================================================================== RCS file: /home/ncvs/src/lib/libc/uuid/uuid_hash.c,v retrieving revision 1.1 diff -u -r1.1 uuid_hash.c --- lib/libc/uuid/uuid_hash.c 30 Oct 2002 03:51:00 -0000 1.1 +++ lib/libc/uuid/uuid_hash.c 6 May 2003 17:28:17 -0000 @@ -36,7 +36,7 @@ * http://www.transarc.ibm.com/Library/documentation/dce/1.1/uuid_hash.html */ uint16_t -uuid_hash(uuid_t *u, uint32_t *status) +__uuid_hash(uuid_t *u, uint32_t *status) { if (status) @@ -48,3 +48,5 @@ */ return ((u) ? u->time_low & 0xffff : 0); } + +__weak_reference(__uuid_hash, uuid_hash); Index: lib/libc/uuid/uuid_is_nil.c =================================================================== RCS file: /home/ncvs/src/lib/libc/uuid/uuid_is_nil.c,v retrieving revision 1.1 diff -u -r1.1 uuid_is_nil.c --- lib/libc/uuid/uuid_is_nil.c 30 Oct 2002 03:51:00 -0000 1.1 +++ lib/libc/uuid/uuid_is_nil.c 6 May 2003 17:28:36 -0000 @@ -36,7 +36,7 @@ * http://www.transarc.ibm.com/Library/documentation/dce/1.1/uuid_is_nil.html */ int32_t -uuid_is_nil(uuid_t *u, uint32_t *status) +__uuid_is_nil(uuid_t *u, uint32_t *status) { uint32_t *p; @@ -53,3 +53,5 @@ p = (uint32_t*)u; return ((p[0] == 0 && p[1] == 0 && p[2] == 0 && p[3] == 0) ? 1 : 0); } + +__weak_reference(__uuid_is_nil, uuid_is_nil); Index: lib/libc/uuid/uuid_to_string.c =================================================================== RCS file: /home/ncvs/src/lib/libc/uuid/uuid_to_string.c,v retrieving revision 1.1 diff -u -r1.1 uuid_to_string.c --- lib/libc/uuid/uuid_to_string.c 30 Oct 2002 03:51:00 -0000 1.1 +++ lib/libc/uuid/uuid_to_string.c 6 May 2003 17:28:00 -0000 @@ -42,7 +42,7 @@ * taken from the Hewlett-Packard implementation. */ void -uuid_to_string(uuid_t *u, char **s, uint32_t *status) +__uuid_to_string(uuid_t *u, char **s, uint32_t *status) { uuid_t nil; @@ -66,3 +66,5 @@ if (*s == NULL && status != NULL) *status = uuid_s_no_memory; } + +__weak_reference(__uuid_to_string, uuid_to_string); --PmA2V3Z32TCmWXqI-- From owner-freebsd-arch@FreeBSD.ORG Wed May 7 02:08:54 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15B4337B401; Wed, 7 May 2003 02:08:54 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EB8F43F75; Wed, 7 May 2003 02:08:52 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h4798pE20577; Wed, 7 May 2003 11:08:51 +0200 (MEST) Date: Wed, 7 May 2003 11:08:51 +0200 (CEST) From: Harti Brandt To: "Jacques A. Vidrine" In-Reply-To: <20030506180516.GG79167@madman.celabo.org> Message-ID: <20030507110802.F3008@beagle.fokus.fraunhofer.de> References: <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> <20030506153641.GI77708@madman.celabo.org> <20030506161732.GB78486@madman.celabo.org> <20030506180516.GG79167@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@FreeBSD.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 09:08:54 -0000 On Tue, 6 May 2003, Jacques A. Vidrine wrote: JAV>On Tue, May 06, 2003 at 07:00:05PM +0200, Harti Brandt wrote: JAV>> Actually fixing the problem at the source would be even better. JAV> JAV>And if there is no problem at the source? An application defining a str*() function has a problem expcept when it does it specifically to override a libc function. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Wed May 7 02:13:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4202D37B401 for ; Wed, 7 May 2003 02:13:26 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07DD843F85 for ; Wed, 7 May 2003 02:13:25 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h479DKE21219; Wed, 7 May 2003 11:13:20 +0200 (MEST) Date: Wed, 7 May 2003 11:13:20 +0200 (CEST) From: Harti Brandt To: "Andrey A. Chernov" In-Reply-To: <20030506190747.GA59160@nagual.pp.ru> Message-ID: <20030507111208.D3008@beagle.fokus.fraunhofer.de> References: <20030505175426.GA19352@madman.celabo.org> <20030505231135.GA21953@madman.celabo.org> <20030506190747.GA59160@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 09:13:26 -0000 On Tue, 6 May 2003, Andrey A. Chernov wrote: AAC>On Tue, May 06, 2003 at 20:40:35 +0200, Dag-Erling Smorgrav wrote: AAC>> "Andrey A. Chernov" writes: AAC>> > On Tue, May 06, 2003 at 19:56:27 +0200, Dag-Erling Smorgrav wrote: AAC>> >> - If you stayed awake through the previous paragraph you should by AAC>> >> now have concluded that it simply is not possible for the linker to AAC>> >> enforce namespaces like Andrey wants it to, because a) the linker AAC>> >> can't know what headers were included; b) the exact set of reserved AAC>> >> names can vary from compilation unit to compilation unit within the AAC>> >> same application and c) namespace issues affect portions of the AAC>> >> code which are outside the linker's purview (such as the names of AAC>> >> function arguments and static or automatic variables). Namespaces AAC>> >> are a source code issue and cannot be handled anywhere but at the AAC>> >> source code level. AAC>> > There is no problem. Each *.h function prototype can be accompanied with AAC>> > some assembler instruction making it strong reference. The same thing can AAC>> > be conditionalized at the header level using _POSIX_SOURCE or other AAC>> > defines. So, linker will know, what headers are included. AAC>> AAC>> I would like to draw your attention to points b) and c) above and ask AAC>> how you plan to address them. AAC> AAC>About b), I don't quite understand, what you mean. If inside the same AAC>application some file includes, say, math.h and use sin() and another file AAC>not includes math.h and defines its own sin() it is error. It is not an error if the second sin() is static. Most symbols from headers are only reserved in external scope and when the corresponding header is included. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Wed May 7 02:18:08 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E45F37B401 for ; Wed, 7 May 2003 02:18:08 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22C7343F3F for ; Wed, 7 May 2003 02:18:07 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h479I4E21805; Wed, 7 May 2003 11:18:04 +0200 (MEST) Date: Wed, 7 May 2003 11:18:04 +0200 (CEST) From: Harti Brandt To: Dag-Erling Smorgrav In-Reply-To: Message-ID: <20030507111600.H3008@beagle.fokus.fraunhofer.de> References: <20030505175426.GA19352@madman.celabo.org> <20030505231135.GA21953@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 09:18:08 -0000 On Tue, 6 May 2003, Dag-Erling Smorgrav wrote: DS>"Andrey A. Chernov" writes: DS>> On Tue, May 06, 2003 at 20:40:35 +0200, Dag-Erling Smorgrav wrote: DS>> > I would like to draw your attention to points b) and c) above and ask DS>> > how you plan to address them. DS>> About b), I don't quite understand, what you mean. If inside the same DS>> application some file includes, say, math.h and use sin() and another file DS>> not includes math.h and defines its own sin() it is error. DS> DS>No. It will lead to surprising results if the file that includes DS> really does use sin(), but if it doesn't there is no reason DS>why the other file can not define an external symbol named sin because DS>sin is in the application namespace in that file. No. The non-macro names in the headers that are defined by C are reserved for external linkage. You may defined a static sin() given that you don't include math.h, but you may never define an external sin(). (This is point 4 in 7.1.3 (at least in my 8/98 draft)). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Wed May 7 02:32:47 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E2AE37B401; Wed, 7 May 2003 02:32:47 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BD7D43F75; Wed, 7 May 2003 02:32:46 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h479WedN015820; Wed, 7 May 2003 02:32:40 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h479WeXP015819; Wed, 7 May 2003 02:32:40 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 7 May 2003 02:32:40 -0700 From: David Schultz To: "Jacques A. Vidrine" , Harti Brandt , Terry Lambert , freebsd-arch@FreeBSD.ORG Message-ID: <20030507093240.GA15754@HAL9000.homeunix.com> Mail-Followup-To: "Jacques A. Vidrine" , Harti Brandt , Terry Lambert , freebsd-arch@FreeBSD.org References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030506093754.B838@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com> <20030506165850.Y601@beagle.fokus.fraunhofer.de> <20030506152605.GE77708@madman.celabo.org> <20030506175017.C631@beagle.fokus.fraunhofer.de> <20030506162352.GC78486@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506162352.GC78486@madman.celabo.org> Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 09:32:47 -0000 On Tue, May 06, 2003, Jacques A. Vidrine wrote: > On Tue, May 06, 2003 at 05:53:16PM +0200, Harti Brandt wrote: > > JAV>Or stated more agressively, the day the FreeBSD toolchain refuses > > JAV>to allow me to define my own version of strlcpy _for use by my > > JAV>application_ is the day I find another development platform. > > > > So if you 'hide' all the libc symbols you will to exactly that. > > Of course not. I can define strlcpy like so > > void > strlcpy(struct string *a, struct string *b) > { > if (a->size == 0) { > b->size = 0; > return; > } > /* really copy the string */ > } Hmm...but that program is broken. If someone overrides a symbol reserved by the C standard, he deserves whatever he gets. It is not unreasonable to expect applications to avoid using reserved symbols for thier own purposes. On the other hand, if someone who knows what he is doing wants to override malloc() or printf() or *any* other standard function for a specialized purpose, it is desirable that he be able to do that in a semi-portable way (i.e. without having to know about the underscores). Note that my definition of knowing what you're doing includes making sure that the new function has the same external API as the old one. For instance, I might override malloc() to maintain statistics for me, or printf() (not sprintf()!) to do some specialized formatting. From owner-freebsd-arch@FreeBSD.ORG Wed May 7 06:33:36 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FB8737B401; Wed, 7 May 2003 06:33:36 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF92543FB1; Wed, 7 May 2003 06:33:35 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h47DUBZ00610; Wed, 7 May 2003 06:30:11 -0700 Received: from btc.adaptec.com (ws10103-60.otc.adaptec.com [10.10.3.60]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id GAA03694; Wed, 7 May 2003 06:33:28 -0700 (PDT) Message-ID: <3EB90B17.7070104@btc.adaptec.com> Date: Wed, 07 May 2003 07:33:11 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hiten Pandya References: <20030507083529.GA73613@perrin.int.nxad.com> In-Reply-To: <20030507083529.GA73613@perrin.int.nxad.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Using weak referencing for uuid routines X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 13:33:36 -0000 Hiten Pandya wrote: > Hello gang. > > I am sending a patch for changing the uuid part of libc to use weak > referencing. This was originally requested by Alexander Kabaev > . > > If this patch is accepted, than I would like one of src committers to > commit it for me. > > Cheers. > > -- Hiten (hmp@FreeBSD.ORG) > What does this give us, and is it something that you are hoping to get into 5.1? Scott From owner-freebsd-arch@FreeBSD.ORG Wed May 7 06:36:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47D6B37B401; Wed, 7 May 2003 06:36:17 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2C1E43FBF; Wed, 7 May 2003 06:36:13 -0700 (PDT) (envelope-from hch@infradead.org) Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 19DP5f-0006Oy-00; Wed, 07 May 2003 14:36:11 +0100 Date: Wed, 7 May 2003 14:36:11 +0100 From: Christoph Hellwig To: "Jacques A. Vidrine" , Harti Brandt , Terry Lambert , freebsd-arch@FreeBSD.org Message-ID: <20030507143611.A23293@infradead.org> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030506093754.B838@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com> <20030506165850.Y601@beagle.fokus.fraunhofer.de> <20030506152605.GE77708@madman.celabo.org> <20030506175017.C631@beagle.fokus.fraunhofer.de> <20030506162352.GC78486@madman.celabo.org> <20030507093240.GA15754@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030507093240.GA15754@HAL9000.homeunix.com>; from das@FreeBSD.ORG on Wed, May 07, 2003 at 02:32:40AM -0700 Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 13:36:17 -0000 On Wed, May 07, 2003 at 02:32:40AM -0700, David Schultz wrote: > > strlcpy(struct string *a, struct string *b) > > { > > if (a->size == 0) { > > b->size = 0; > > return; > > } > > /* really copy the string */ > > } > > Hmm...but that program is broken. If someone overrides a symbol > reserved by the C standard, he deserves whatever he gets. It is > not unreasonable to expect applications to avoid using reserved > symbols for thier own purposes. strlcpy is not in any standard.. From owner-freebsd-arch@FreeBSD.ORG Wed May 7 06:41:56 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A793037B401; Wed, 7 May 2003 06:41:56 -0700 (PDT) Received: from h132-197-179-27.gte.com (h132-197-179-27.gte.com [132.197.179.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9908543F3F; Wed, 7 May 2003 06:41:55 -0700 (PDT) (envelope-from ak03@gte.com) Received: from kanpc.gte.com (ak03@localhost [127.0.0.1]) h47Dfr3D065426; Wed, 7 May 2003 09:41:53 -0400 (EDT) (envelope-from ak03@kanpc.gte.com) Received: (from ak03@localhost) by kanpc.gte.com (8.12.9/8.12.9/Submit) id h47Dfren065425; Wed, 7 May 2003 09:41:53 -0400 (EDT) Date: Wed, 7 May 2003 09:41:53 -0400 From: Alexander Kabaev To: Scott Long Message-Id: <20030507094153.240d734c.ak03@gte.com> In-Reply-To: <3EB90B17.7070104@btc.adaptec.com> References: <20030507083529.GA73613@perrin.int.nxad.com> <3EB90B17.7070104@btc.adaptec.com> Organization: Verizon Data Services X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Hiten Pandya cc: freebsd-arch@freebsd.org Subject: Re: Using weak referencing for uuid routines X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 13:41:57 -0000 X-List-Received-Date: Wed, 07 May 2003 13:41:57 -0000 I requested it, but then just rearranged the Makefile in a projects I had problems with to work around the problem. What I really wanted to do is to remove libuuid from libc altogether and make it a separate library. around On Wed, 07 May 2003 07:33:11 -0600 Scott Long wrote: > Hiten Pandya wrote: > > Hello gang. > > > > I am sending a patch for changing the uuid part of libc to use weak > > referencing. This was originally requested by Alexander Kabaev > > . > > > > If this patch is accepted, than I would like one of src committers > > to commit it for me. > > > > Cheers. > > > > -- Hiten (hmp@FreeBSD.ORG) > > > > What does this give us, and is it something that you are hoping to get > into 5.1? > > Scott > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" -- Alexander Kabaev From owner-freebsd-arch@FreeBSD.ORG Wed May 7 06:42:00 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 067C637B404; Wed, 7 May 2003 06:42:00 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CAE743F85; Wed, 7 May 2003 06:41:58 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h47DftE02554; Wed, 7 May 2003 15:41:55 +0200 (MEST) Date: Wed, 7 May 2003 15:41:55 +0200 (CEST) From: Harti Brandt To: Christoph Hellwig In-Reply-To: <20030507143611.A23293@infradead.org> Message-ID: <20030507154105.A3282@beagle.fokus.fraunhofer.de> References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <3EB7CC73.9C61C27E@mindspring.com> <20030506152605.GE77708@madman.celabo.org> <20030506162352.GC78486@madman.celabo.org> <20030507143611.A23293@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Jacques A. Vidrine" cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 13:42:00 -0000 On Wed, 7 May 2003, Christoph Hellwig wrote: CH>On Wed, May 07, 2003 at 02:32:40AM -0700, David Schultz wrote: CH>> > strlcpy(struct string *a, struct string *b) CH>> > { CH>> > if (a->size == 0) { CH>> > b->size = 0; CH>> > return; CH>> > } CH>> > /* really copy the string */ CH>> > } CH>> CH>> Hmm...but that program is broken. If someone overrides a symbol CH>> reserved by the C standard, he deserves whatever he gets. It is CH>> not unreasonable to expect applications to avoid using reserved CH>> symbols for thier own purposes. CH> CH>strlcpy is not in any standard.. It is in ANSI's standard namespace... harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Wed May 7 13:51:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C3E337B401; Wed, 7 May 2003 13:51:17 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95DC243F75; Wed, 7 May 2003 13:51:15 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h47KpEwk009737; Wed, 7 May 2003 13:51:14 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h47KpDFg000830; Wed, 7 May 2003 13:51:13 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h47KpDIx000829; Wed, 7 May 2003 13:51:13 -0700 (PDT) Date: Wed, 7 May 2003 13:51:13 -0700 From: Marcel Moolenaar To: Alexander Kabaev Message-ID: <20030507205113.GA687@athlon.pn.xcllnt.net> References: <20030507083529.GA73613@perrin.int.nxad.com> <3EB90B17.7070104@btc.adaptec.com> <20030507094153.240d734c.ak03@gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030507094153.240d734c.ak03@gte.com> User-Agent: Mutt/1.5.3i cc: Hiten Pandya cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: Using weak referencing for uuid routines X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 20:51:17 -0000 On Wed, May 07, 2003 at 09:41:53AM -0400, Alexander Kabaev wrote: > > What I really wanted to do is to remove libuuid from libc altogether and > make it a separate library. Be aware that there are reasons for putting the UUID functions in libc. It is not gratuitous. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu May 8 01:02:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C724637B401 for ; Thu, 8 May 2003 01:02:37 -0700 (PDT) Received: from ns2.gnf.org (ns2.gnf.org [63.196.132.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 729D143FB1 for ; Thu, 8 May 2003 01:02:36 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch02.lj.gnf.org [172.25.10.20]) by ns2.gnf.org (8.12.6p2/8.12.3) with ESMTP id h4882U8V057096 for ; Thu, 8 May 2003 01:02:30 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 May 2003 01:02:35 -0700 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.9/8.12.9) with ESMTP id h4882ZSY093218 for ; Thu, 8 May 2003 01:02:35 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.9/8.12.9/Submit) id h4882YY5093217 for arch@FreeBSD.org; Thu, 8 May 2003 01:02:34 -0700 (PDT) (envelope-from gtetlow) Date: Thu, 8 May 2003 01:02:34 -0700 From: Gordon Tetlow To: arch@FreeBSD.org Message-ID: <20030508080234.GI76376@roark.gnf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VkVuOCYP9O7H3CXI" Content-Disposition: inline User-Agent: Mutt/1.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-OriginalArrivalTime: 08 May 2003 08:02:35.0811 (UTC) FILETIME=[2FA39F30:01C31538] Subject: PATCH: Dynamic /bin support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 08:02:38 -0000 --VkVuOCYP9O7H3CXI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I just hacked together support to have /bin dynamically linked. This is the first step on the way to having everything play nicely with nectar's work on getting NSS into the system. Here's the patch: http://people.freebsd.org/~gordon/patches/dynamic.patch WARNING: Don't install this on a system you care about, you'll probably hose it beyond belief. My testbed was a pxe booted diskless client. YMMV. Here's the quick instructions: Patch using the diff provided Make a /lib directory Compile and install src/libexec/rtld-elf Make sure it installed into /lib/ld-elf.so.1 with a symlink from /usr/libexec/ld-elf.so.1 Do a full buildworld Build a kernel (not sure if needed) Do an installworld Delete the old libs from /usr/lib, try the following shell script: cd /lib for i in *; do chflags noschg /usr/lib/$i rm /usr/lib/$i done Your /lib should look like: ld-elf.so.1 libc.so.5 libcrypt.so.2 libkvm.so.2 libncurses.so.5 ld-elf.so.1.old libcipher.so.2 libedit.so.4 libm.so.2 libutil.so.3 I've kind of abused SHLIBDIR in the Makefiles. If someone with more make-foo could look it over. I've probably violated style all over the place. Comments are welcome. I'm working on /sbin support, but there are alot of additional libraries that are needed for that one. I'll get to it. Anyway, I'm really tired, but I wanted to post the patch. Please email me with suggestions. -gordon --VkVuOCYP9O7H3CXI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+ug8aRu2t9DV9ZfsRAua1AJ41juQTMYKRwcVXZXwML7BKFc6xWwCfZCvy smw0CcOCE2lFPE0JcGI5yV0= =pT74 -----END PGP SIGNATURE----- --VkVuOCYP9O7H3CXI-- From owner-freebsd-arch@FreeBSD.ORG Thu May 8 01:28:46 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A213C37B401; Thu, 8 May 2003 01:28:46 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4281543F93; Thu, 8 May 2003 01:28:45 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id SAA15378; Thu, 8 May 2003 18:28:35 +1000 Date: Thu, 8 May 2003 18:28:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick In-Reply-To: <20030505205914.D8183@gamplex.bde.org> Message-ID: <20030508175350.S59316@gamplex.bde.org> References: <200305050617.h456HNTh017652@beastie.mckusick.com> <20030505205914.D8183@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 08:28:47 -0000 I'm replying to an earlier article in this thread since I lost your last reply. On Sun, 4 May 2003, Kirk McKusick wrote: > Still, I think that VOP_READ is likely to be more efficient and work in > a higher percentage of the times (always on the local filesystem and > most of the time on NFS). Thus, I enclose my (new) proposed change below. > Index: sys/kern_exec.c > =================================================================== > RCS file: /usr/ncvs/src/sys/kern/kern_exec.c,v > retrieving revision 1.218 > diff -c -r1.218 kern_exec.c > *** kern_exec.c 1 Apr 2003 01:26:20 -0000 1.218 > --- kern_exec.c 5 May 2003 06:15:21 -0000 > *************** > *** 598,603 **** > --- 598,626 ---- > exec_setregs(td, imgp->entry_addr, > (u_long)(uintptr_t)stack_base, imgp->ps_strings); > > + /* > + * At this point, it counts as an access. > + * Ensure that atime gets updated if needed. > + */ > + if (!(textvp->v_mount->mnt_flag & MNT_NOATIME)) { > + struct uio auio; > + struct iovec aiov; > + char ch; > + > + auio.uio_iov = &aiov; > + auio.uio_iovcnt = 1; > + aiov.iov_base = &ch; > + aiov.iov_len = 1; > + auio.uio_resid = 1; > + auio.uio_offset = 0; > + auio.uio_segflg = UIO_SYSSPACE; > + auio.uio_rw = UIO_READ; > + auio.uio_td = td; > + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); > + (void) VOP_READ(textvp, &auio, 0, p->p_ucred); > + VOP_UNLOCK(textvp, 0, td); > + } > + > done1: > /* > * Free any resources malloc'd earlier that we didn't use. I ran some benchmarks after fixing some bugs in the above (textvp is stale (maybe NULL the first time?), and as jhb pointed out, p->p_ucred should be td->td_ucred). I benchmarked the following methods: - method 1: my original method using VOP_SETATTR() updated - method 2: fixed version of above - method 3: version of the above that just calls vn_rdwr(). %%% Index: kern_exec.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.208 diff -u -2 -r1.208 kern_exec.c --- kern_exec.c 13 Jan 2003 23:04:31 -0000 1.208 +++ kern_exec.c 8 May 2003 07:11:05 -0000 @@ -1,2 +1,4 @@ +int exec_atime_method = -1; + /* * Copyright (c) 1993, David Greenman @@ -611,4 +599,49 @@ (u_long)(uintptr_t)stack_base, imgp->ps_strings); + /* + * At this point, it counts as an access. + * Ensure that atime gets updated if needed. + */ + if (!(ndp->ni_vp->v_mount->mnt_flag & MNT_NOATIME)) { + if (exec_atime_method == 1) { + struct vattr vattr; + struct mount *mp; + + if (vn_start_write(ndp->ni_vp, &mp, V_WAIT | PCATCH) != 0) + goto out; + VATTR_NULL(&vattr); + vfs_timestamp(&vattr.va_atime); + vattr.va_vaflags |= VA_EXECVE_ATIME; + VOP_LEASE(ndp->ni_vp, td, td->td_ucred, LEASE_WRITE); + vn_lock(ndp->ni_vp, LK_EXCLUSIVE | LK_RETRY, td); + (void) VOP_SETATTR(ndp->ni_vp, &vattr, td->td_ucred, td); + VOP_UNLOCK(ndp->ni_vp, 0, td); + vn_finished_write(mp); +out: ; + } else if (exec_atime_method == 2) { + struct iovec aiov; + struct uio auio; + char ch; + + auio.uio_iov = &aiov; + auio.uio_iovcnt = 1; + aiov.iov_base = &ch; + aiov.iov_len = 1; + auio.uio_resid = 1; + auio.uio_offset = 0; + auio.uio_segflg = UIO_SYSSPACE; + auio.uio_rw = UIO_READ; + auio.uio_td = td; + vn_lock(ndp->ni_vp, LK_EXCLUSIVE | LK_RETRY, td); + (void) VOP_READ(ndp->ni_vp, &auio, 0, p->p_ucred); + VOP_UNLOCK(ndp->ni_vp, 0, td); + } else if (exec_atime_method == 3) { + char ch; + + (void) vn_rdwr(UIO_READ, ndp->ni_vp, &ch, 1, 0, UIO_SYSSPACE, + 0, td->td_ucred, td->td_ucred, NULL, td); + } + } + done1: /* %%% The VOP_READ() methods had much more overhead than I expected or like (about 25% for a tiny statically linked program (`main() {}'). Even the VOP_SETATTR() method was faster. Raw output: %%% ufs-static-noexec 4.32 real 0.04 user 4.13 sys 4.23 real 0.07 user 4.01 sys 4.30 real 0.06 user 4.10 sys ufs-static-static method -1 7.02 real 0.06 user 6.77 sys 7.10 real 0.07 user 6.83 sys 7.09 real 0.06 user 6.83 sys 7.03 real 0.19 user 6.65 sys 7.11 real 0.22 user 6.68 sys 7.00 real 0.04 user 6.77 sys 7.12 real 0.19 user 6.75 sys 7.07 real 0.22 user 6.66 sys 7.07 real 0.07 user 6.81 sys method 1 7.72 real 0.23 user 7.29 sys 7.76 real 0.25 user 7.31 sys 7.71 real 0.30 user 7.21 sys 7.69 real 0.29 user 7.21 sys 7.70 real 0.31 user 7.18 sys 7.71 real 0.19 user 7.32 sys method 2 7.83 real 0.07 user 7.56 sys 7.84 real 0.27 user 7.37 sys 7.82 real 0.28 user 7.34 sys method 3 7.90 real 0.26 user 7.43 sys 7.89 real 0.05 user 7.62 sys 7.92 real 0.05 user 7.66 sys 7.86 real 0.05 user 7.61 sys 7.88 real 0.18 user 7.49 sys 7.84 real 0.21 user 7.43 sys 7.88 real 0.31 user 7.36 sys 7.82 real 0.28 user 7.34 sys 7.86 real 0.24 user 7.42 sys nfs-static-noexec 4.13 real 0.05 user 3.95 sys 4.20 real 0.17 user 3.89 sys 4.25 real 0.25 user 3.87 sys nfs-static-static method -1 11.43 real 0.04 user 9.18 sys 11.41 real 0.21 user 8.96 sys 11.43 real 0.27 user 8.94 sys method 1 11.54 real 0.28 user 8.88 sys 11.64 real 0.19 user 9.08 sys 11.53 real 0.17 user 8.97 sys method 2 11.77 real 0.09 user 9.49 sys 11.78 real 0.25 user 9.31 sys 11.80 real 0.33 user 9.26 sys method 3 11.94 real 0.24 user 9.46 sys 11.86 real 0.32 user 9.35 sys 11.81 real 0.28 user 9.35 sys %%% *fs-static-noexec tests 10000 forks with no exec of a statically linked program on *fs. *fs-static-static tests 10000 forks with exec of statically linked programs on *fs. The system is an old Celeron (the speed doesn't matter much; only compare the relative times). All file systems were mounted -async. The exec part of the fork-exec takes an average of about 270 usec for the ufs case. Setting the atime adds about 60 usec to this for method 1. Method 2 adds another 10 usec. Method 3 adds another 4 usec to method 2. Plain read() takes much less than 60 usec on this machine: $ dd if=/kernel of=/dev/null bs=1 count=1000000 1000000+0 records in 1000000+0 records out 1000000 bytes transferred in 17.703695 secs (56485 bytes/sec) so most of the overheads for exec must be indirect. I think they are just close() forcing update marks to timestamps. This happens after every exec, but not after every read in the dd benchmark. I think method 1 turns out to be fastest since it forces the update marks to timestamps directly. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu May 8 01:31:04 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6595037B401 for ; Thu, 8 May 2003 01:31:04 -0700 (PDT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50DC743FDF for ; Thu, 8 May 2003 01:31:02 -0700 (PDT) (envelope-from netch@lucky.net) Received: from netch@localhost [127.0.0.1] (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id h488UqiT092043; Thu, 8 May 2003 11:30:53 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.8p1/8.12.8/Submit) id h488Uqxn092040; Thu, 8 May 2003 11:30:52 +0300 (EEST) (envelope-from netch) Date: Thu, 8 May 2003 11:30:52 +0300 From: Valentin Nechayev To: arch@freebsd.org Message-ID: <20030508083052.GL83663@lucky.net> References: <20030508080234.GI76376@roark.gnf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030508080234.GI76376@roark.gnf.org> X-42: On X-Verify-Sender: verified Subject: Re: PATCH: Dynamic /bin support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 08:31:04 -0000 Thu, May 08, 2003 at 01:02:34, gordont wrote about "PATCH: Dynamic /bin support": Question not to Gordon himself: does it mean that idea to make correct sharing of dynamic loading functionality between ld.so (ld-*.so.*) and libdl is considered useless? -netch- From owner-freebsd-arch@FreeBSD.ORG Thu May 8 02:28:18 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61D9D37B401 for ; Thu, 8 May 2003 02:28:18 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4081E43FB1 for ; Thu, 8 May 2003 02:28:17 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id TAA22522; Thu, 8 May 2003 19:28:11 +1000 Date: Thu, 8 May 2003 19:28:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Gordon Tetlow In-Reply-To: <20030508080234.GI76376@roark.gnf.org> Message-ID: <20030508191931.S59610@gamplex.bde.org> References: <20030508080234.GI76376@roark.gnf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: PATCH: Dynamic /bin support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 09:28:18 -0000 On Thu, 8 May 2003, Gordon Tetlow wrote: > I've kind of abused SHLIBDIR in the Makefiles. If someone with more > make-foo could look it over. I've probably violated style all over > the place. Comments are welcome. SHLIBDIR's main use was to support a dynamically linked /bin and /sbin. I used it for this for many years until I learned what a bad idea shared libraries are. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu May 8 08:35:39 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71E6537B401; Thu, 8 May 2003 08:35:39 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5594A43F3F; Thu, 8 May 2003 08:35:38 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h48FZVTl019822; Thu, 8 May 2003 09:35:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 08 May 2003 09:35:13 -0600 (MDT) Message-Id: <20030508.093513.17267435.imp@bsdimp.com> To: hch@infradead.org From: "M. Warner Losh" In-Reply-To: <20030507143611.A23293@infradead.org> References: <20030506162352.GC78486@madman.celabo.org> <20030507093240.GA15754@HAL9000.homeunix.com> <20030507143611.A23293@infradead.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: nectar@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 15:35:39 -0000 In message: <20030507143611.A23293@infradead.org> Christoph Hellwig writes: : On Wed, May 07, 2003 at 02:32:40AM -0700, David Schultz wrote: : > > strlcpy(struct string *a, struct string *b) : > > { : > > if (a->size == 0) { : > > b->size = 0; : > > return; : > > } : > > /* really copy the string */ : > > } : > : > Hmm...but that program is broken. If someone overrides a symbol : > reserved by the C standard, he deserves whatever he gets. It is : > not unreasonable to expect applications to avoid using reserved : > symbols for thier own purposes. : : strlcpy is not in any standard.. str* symbols are reserved to the implementation symbols. Any program that defines them is non-conforming to the standard. Geeze people, can't you read the whole thread before posting the same old crap? Warner From owner-freebsd-arch@FreeBSD.ORG Thu May 8 08:39:32 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4DF237B401 for ; Thu, 8 May 2003 08:39:32 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5551C43F3F for ; Thu, 8 May 2003 08:39:30 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h48FdTTl019894 for ; Thu, 8 May 2003 09:39:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 08 May 2003 09:39:11 -0600 (MDT) Message-Id: <20030508.093911.48456930.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_May__8_09:39:11_2003_697)--" Content-Transfer-Encoding: 7bit Subject: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 15:39:32 -0000 ----Next_Part(Thu_May__8_09:39:11_2003_697)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tim posted this a while ago to hackers@. It looked like it was further along than what's been posted here. Warner ----Next_Part(Thu_May__8_09:39:11_2003_697)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: owner-freebsd-hackers@FreeBSD.ORG Delivery-Date: Tue, 14 Jan 2003 15:22:52 -0700 Received: from rover.village.org (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0EMMg1e024905 for ; Tue, 14 Jan 2003 15:22:42 -0700 (MST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by rover.village.org (8.12.5/8.12.3) with ESMTP id h0EMMd7G080996 for ; Tue, 14 Jan 2003 15:22:40 -0700 (MST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id CF61655477; Tue, 14 Jan 2003 14:22:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: by hub.freebsd.org (Postfix, from userid 538) id 8220C37B405; Tue, 14 Jan 2003 14:22:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 6379B2E800C; Tue, 14 Jan 2003 14:22:29 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Tue, 14 Jan 2003 14:22:29 -0800 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 320A237B401 for ; Tue, 14 Jan 2003 14:22:01 -0800 (PST) Received: from clover.kientzle.com (user-112uh9a.biz.mindspring.com [66.47.69.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8F4743F1E for ; Tue, 14 Jan 2003 14:21:58 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org (c43 [66.47.69.43]) by clover.kientzle.com (8.11.3/8.11.3) with ESMTP id h0EMLwE78894 for ; Tue, 14 Jan 2003 14:21:58 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3E248D85.10201@acm.org> Date: Tue, 14 Jan 2003 14:21:57 -0800 From: Tim Kientzle Reply-To: kientzle@acm.org User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers Subject: /rescue Content-Type: multipart/mixed; boundary="------------090401000102090001060504" Sender: owner-freebsd-hackers@FreeBSD.ORG List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Precedence: bulk X-Spam-Status: No, hits=-4.7 required=5.0 tests=BALANCE_FOR_LONG_20K,PATCH_CONTEXT_DIFF,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,TO_LOCALPART_EQ_REAL,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG,X_LOOP version=2.41 X-Spam-Level: This is a multi-part message in MIME format. --------------090401000102090001060504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Warner suggested: > Also, be sure to post a diff for review prior to commit. So, here it is. /rescue contains most of /bin and /sbin, along with a few choice selections from /usr/bin and /usr/sbin. All are statically linked and compiled to occupy a minimum of disk space (About 4MB). For those who missed some earlier threads, this is a step towards a fully dynamic FreeBSD. The next step is to create /lib and move certain critical shared libs there, then /bin and /sbin can be switched to fully dynamic linking. Once that's done, the door is open to use dlopen() within the standard libraries, which should simplify pam, nsswitch, locales, and probably a few other things. But first, /rescue. There are no doubt a few refinements that could be made, but this seems good enough to start using. I'm also in dire need of a reality check; I've been working on this solo for too long. ;-) Note that 'proper' building requires first applying patches, then updating some tools: cd /usr/src/share/mk && make install cd /usr/src/include && make install cd /usr/src/usr.sbin/crunch && make && make install You can then build /rescue itself: mkdir /rescue cd /usr/src/rescue && make obj && make && make install Tim P.S. Hope the attached diff is intelligible; I wasn't entirely sure how to include new files in a diff. P.P.S. For reference, here's a list of all affected files: M Makefile.inc1 M bin/csh/Makefile M bin/mv/mv.c M bin/mv/pathnames.h M bin/sh/var.c M contrib/isc-dhcp/client/clparse.c M contrib/isc-dhcp/includes/cf/freebsd.h M contrib/tar/src/buffer.c M etc/mtree/BSD.root.dist M include/paths.h A rescue/Makefile A rescue/README A rescue/librescue/Makefile A rescue/librescue/exec.c A rescue/librescue/getusershell.c A rescue/librescue/login_class.c A rescue/librescue/popen.c A rescue/librescue/rcmdsh.c A rescue/librescue/sysctl.c A rescue/librescue/system.c A rescue/rescue/Makefile M sbin/dhclient/Makefile M sbin/dhclient/client/Makefile M sbin/fsck/fsck.c M sbin/fsck/pathnames.h M sbin/mdmfs/pathnames.h M sbin/mount/mount.c M sbin/mount/pathnames.h M sbin/shutdown/pathnames.h M sbin/startslip/startslip.c M sbin/vinum/commands.c M share/mk/bsd.lib.mk M share/mk/bsd.prog.mk M usr.bin/vi/pathnames.h M usr.sbin/crunch/crunchgen/crunchgen.c --------------090401000102090001060504 Content-Type: text/plain; name="kientzle_rescue.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kientzle_rescue.diff" Index: Makefile.inc1 =================================================================== RCS file: /usr/cvs/src/Makefile.inc1,v retrieving revision 1.314 diff -c -r1.314 Makefile.inc1 *** Makefile.inc1 30 Dec 2002 10:01:25 -0000 1.314 --- Makefile.inc1 7 Jan 2003 05:52:24 -0000 *************** *** 51,56 **** --- 51,60 ---- SUBDIR+= lib .endif + .if exists(${.CURDIR}/rescue) + SUBDIR+= rescue + .endif + .if exists(${.CURDIR}/bin) SUBDIR+= bin .endif Index: bin/csh/Makefile =================================================================== RCS file: /usr/cvs/src/bin/csh/Makefile,v retrieving revision 1.29 diff -c -r1.29 Makefile *** bin/csh/Makefile 24 Jul 2002 22:26:44 -0000 1.29 --- bin/csh/Makefile 7 Jan 2003 02:07:46 -0000 *************** *** 10,16 **** --- 10,20 ---- .PATH: ${TCSHDIR} PROG= csh + .if defined(RESCUE) + DFLAGS= -D_PATH_TCSHELL='"/rescue/${PROG}"' + .else DFLAGS= -D_PATH_TCSHELL='"/bin/${PROG}"' + .endif CFLAGS+= -I. -I${.CURDIR} -I${TCSHDIR} ${DFLAGS} SRCS= sh.c sh.dir.c sh.dol.c sh.err.c sh.exec.c sh.char.c \ sh.exp.c sh.file.c sh.func.c sh.glob.c sh.hist.c sh.init.c \ Index: bin/mv/mv.c =================================================================== RCS file: /usr/cvs/src/bin/mv/mv.c,v retrieving revision 1.39 diff -c -r1.39 mv.c *** bin/mv/mv.c 9 Jul 2002 17:45:13 -0000 1.39 --- bin/mv/mv.c 7 Jan 2003 18:13:50 -0000 *************** *** 67,74 **** #include #include - #include "pathnames.h" - int fflg, iflg, nflg, vflg; int copy(char *, char *); --- 67,72 ---- Index: bin/mv/pathnames.h =================================================================== RCS file: /usr/cvs/src/bin/mv/pathnames.h,v retrieving revision 1.6 diff -c -r1.6 pathnames.h *** bin/mv/pathnames.h 17 May 2002 11:38:48 -0000 1.6 --- bin/mv/pathnames.h 9 Jan 2003 02:34:27 -0000 *************** *** 34,37 **** * $FreeBSD: src/bin/mv/pathnames.h,v 1.6 2002/05/17 11:38:48 jmallett Exp $ */ ! #define _PATH_RM "/bin/rm" --- 34,37 ---- * $FreeBSD: src/bin/mv/pathnames.h,v 1.6 2002/05/17 11:38:48 jmallett Exp $ */ ! /* This file is empty and can be safely deleted */ Index: bin/sh/var.c =================================================================== RCS file: /usr/cvs/src/bin/sh/var.c,v retrieving revision 1.23 diff -c -r1.23 var.c *** bin/sh/var.c 1 Oct 2002 00:54:14 -0000 1.23 --- bin/sh/var.c 1 Jan 2003 23:35:53 -0000 *************** *** 44,49 **** --- 44,50 ---- #include #include + #include /* * Shell variables. *************** *** 105,111 **** NULL }, { &vmpath, VSTRFIXED|VTEXTFIXED|VUNSET, "MAILPATH=", NULL }, ! { &vpath, VSTRFIXED|VTEXTFIXED, "PATH=/bin:/usr/bin", changepath }, { &vppid, VSTRFIXED|VTEXTFIXED|VUNSET, "PPID=", NULL }, --- 106,112 ---- NULL }, { &vmpath, VSTRFIXED|VTEXTFIXED|VUNSET, "MAILPATH=", NULL }, ! { &vpath, VSTRFIXED|VTEXTFIXED, "PATH=" _PATH_DEFPATH, changepath }, { &vppid, VSTRFIXED|VTEXTFIXED|VUNSET, "PPID=", NULL }, Index: contrib/isc-dhcp/client/clparse.c =================================================================== RCS file: /usr/cvs/src/contrib/isc-dhcp/client/clparse.c,v retrieving revision 1.8 diff -c -r1.8 clparse.c *** contrib/isc-dhcp/client/clparse.c 1 Apr 2002 07:59:50 -0000 1.8 --- contrib/isc-dhcp/client/clparse.c 1 Jan 2003 23:24:12 -0000 *************** *** 53,59 **** struct client_config top_level_config; ! char client_script_name [] = "/sbin/dhclient-script"; u_int32_t default_requested_options [] = { DHO_SUBNET_MASK, --- 53,59 ---- struct client_config top_level_config; ! char client_script_name [] = _PATH_DHCLIENT_SCRIPT; u_int32_t default_requested_options [] = { DHO_SUBNET_MASK, Index: contrib/isc-dhcp/includes/cf/freebsd.h =================================================================== RCS file: /usr/cvs/src/contrib/isc-dhcp/includes/cf/freebsd.h,v retrieving revision 1.5 diff -c -r1.5 freebsd.h *** contrib/isc-dhcp/includes/cf/freebsd.h 30 Sep 2002 08:45:34 -0000 1.5 --- contrib/isc-dhcp/includes/cf/freebsd.h 9 Jan 2003 02:35:47 -0000 *************** *** 103,108 **** --- 103,112 ---- #define SOCKLEN_T int #endif + #ifdef RESCUE + #define _PATH_DHCLIENT_SCRIPT "/rescue/dhclient-script" + #endif + #if defined (USE_DEFAULT_NETWORK) # define USE_BPF #endif *************** *** 113,118 **** --- 117,125 ---- #endif /* HAVE_DEV_RANDOM */ const char *cmds[] = { + #ifndef RESCUE + /* rescue environment can't rely on these ... */ + /* Actually, /sbin/dhclient shouldn't use these, either. */ "/bin/ps -axlw 2>&1", "/usr/sbin/arp -an 2>&1", "/usr/bin/netstat -an 2>&1", *************** *** 123,132 **** --- 130,141 ---- "/usr/sbin/iostat 2>&1", "/usr/bin/vmstat 2>&1", "/usr/bin/w 2>&1", + #endif NULL }; const char *dirs[] = { + #ifndef RESCUE "/tmp", "/usr/tmp", ".", *************** *** 136,148 **** --- 145,160 ---- "/var/mail", "/home", "/usr/home", + #endif NULL }; const char *files[] = { + #ifndef RESCUE "/var/log/messages", "/var/log/wtmp", "/var/log/lastlog", + #endif NULL }; #endif /* NEED_PRAND_CONF */ Index: contrib/tar/src/buffer.c =================================================================== RCS file: /usr/cvs/src/contrib/tar/src/buffer.c,v retrieving revision 1.5 diff -c -r1.5 buffer.c *** contrib/tar/src/buffer.c 9 Oct 2002 07:33:29 -0000 1.5 --- contrib/tar/src/buffer.c 22 Nov 2002 21:37:10 -0000 *************** *** 25,30 **** --- 25,36 ---- #include + #if __FreeBSD__ + # include + #else + # define _PATH_BSHELL "/bin/sh" + #endif + #if MSDOS # include #endif *************** *** 1549,1555 **** pid_t child; const char *shell = getenv ("SHELL"); if (! shell) ! shell = "/bin/sh"; child = xfork (); if (child == 0) { --- 1555,1561 ---- pid_t child; const char *shell = getenv ("SHELL"); if (! shell) ! shell = _PATH_BSHELL; child = xfork (); if (child == 0) { Index: etc/mtree/BSD.root.dist =================================================================== RCS file: /usr/cvs/src/etc/mtree/BSD.root.dist,v retrieving revision 1.58 diff -c -r1.58 BSD.root.dist *** etc/mtree/BSD.root.dist 10 Jun 2002 04:47:26 -0000 1.58 --- etc/mtree/BSD.root.dist 7 Jan 2003 05:57:14 -0000 *************** *** 67,72 **** --- 67,74 ---- .. proc mode=0555 .. + rescue + .. root .. sbin Index: include/paths.h =================================================================== RCS file: /usr/cvs/src/include/paths.h,v retrieving revision 1.17 diff -c -r1.17 paths.h *** include/paths.h 14 Jul 2002 13:04:15 -0000 1.17 --- include/paths.h 7 Jan 2003 06:34:34 -0000 *************** *** 40,57 **** --- 40,84 ---- #include /* Default search path. */ + #ifdef RESCUE + #define _PATH_DEFPATH "/rescue:/usr/bin:/bin" + #else #define _PATH_DEFPATH "/usr/bin:/bin" + #endif + /* All standard utilities path. */ + #ifdef RESCUE + #define _PATH_STDPATH \ + "/rescue:/usr/bin:/bin:/usr/sbin:/sbin" + #else #define _PATH_STDPATH \ "/usr/bin:/bin:/usr/sbin:/sbin:" + #endif #define _PATH_AUTHCONF "/etc/auth.conf" + + #ifdef RESCUE + #define _PATH_BSHELL "/rescue/sh" + #else #define _PATH_BSHELL "/bin/sh" + #endif + #define _PATH_CAPABILITY "/etc/capability" #define _PATH_CAPABILITY_DB "/etc/capability.db" #define _PATH_CONSOLE "/dev/console" + + #ifdef RESCUE + #define _PATH_CP "/rescue/cp" + #else #define _PATH_CP "/bin/cp" + #endif + + #ifdef RESCUE + #define _PATH_CSHELL "/rescue/csh" + #else #define _PATH_CSHELL "/bin/csh" + #endif + #define _PATH_DEFTAPE "/dev/sa0" #define _PATH_DEVDB "/var/run/dev.db" #define _PATH_DEVNULL "/dev/null" *************** *** 59,79 **** --- 86,136 ---- #define _PATH_DRUM "/dev/drum" #define _PATH_ETC "/etc" #define _PATH_FTPUSERS "/etc/ftpusers" + + #ifdef RESCUE + #define _PATH_IFCONFIG "/rescue/ifconfig" + #else + #define _PATH_IFCONFIG "/sbin/ifconfig" + #endif + #define _PATH_KMEM "/dev/kmem" #define _PATH_LOGIN "/usr/bin/login" #define _PATH_MAILDIR "/var/mail" #define _PATH_MAN "/usr/share/man" #define _PATH_MEM "/dev/mem" #define _PATH_NOLOGIN "/var/run/nologin" + + #ifdef RESCUE + #define _PATH_RCP "/rescue/rcp" + #else #define _PATH_RCP "/bin/rcp" + #endif + #define _PATH_RLOGIN "/usr/bin/rlogin" + + #ifdef RESCUE + #define _PATH_RM "/rescue/rm" + #else + #define _PATH_RM "/bin/rm" + #endif + #define _PATH_RSH "/usr/bin/rsh" #define _PATH_SENDMAIL "/usr/sbin/sendmail" #define _PATH_SHELLS "/etc/shells" #define _PATH_TTY "/dev/tty" #define _PATH_UNIX "don't use _PATH_UNIX" + + #ifdef RESCUE + #define _PATH_VI "/rescue/vi" + #else #define _PATH_VI "/usr/bin/vi" + #endif + + #ifdef RESCUE + #define _PATH_WALL "/rescue/wall" + #else #define _PATH_WALL "/usr/bin/wall" + #endif /* Provide trailing slash, since mostly used for building pathnames. */ #define _PATH_DEV "/dev/" Index: sbin/dhclient/Makefile =================================================================== RCS file: /usr/cvs/src/sbin/dhclient/Makefile,v retrieving revision 1.17 diff -c -r1.17 Makefile *** sbin/dhclient/Makefile 28 Feb 2002 16:17:18 -0000 1.17 --- sbin/dhclient/Makefile 9 Jan 2003 02:38:00 -0000 *************** *** 47,54 **** # though, so we must run ``make all'' instead when we are asked to # generate an individual object file. ${OBJS}: all ! .endif .include --- 47,55 ---- # though, so we must run ``make all'' instead when we are asked to # generate an individual object file. + # Note: Must have some commands here to override the default build action ${OBJS}: all ! @true .endif .include Index: sbin/dhclient/client/Makefile =================================================================== RCS file: /usr/cvs/src/sbin/dhclient/client/Makefile,v retrieving revision 1.2 diff -c -r1.2 Makefile *** sbin/dhclient/client/Makefile 19 Feb 2002 22:23:49 -0000 1.2 --- sbin/dhclient/client/Makefile 7 Jan 2003 05:43:08 -0000 *************** *** 8,14 **** PROG= dhclient SRCS= clparse.c dhclient.c ! CFLAGS+= -DCLIENT_PATH='"PATH=/sbin:/bin:/usr/sbin:/usr/bin"' -Dwarn=dhcp_warn DPADD= ${LIBDHCP} ${LIBRES} ${LIBOMAPI} ${LIBDST} LDADD= ${LIBDHCP} ${LIBRES} ${LIBOMAPI} ${LIBDST} --- 8,19 ---- PROG= dhclient SRCS= clparse.c dhclient.c ! .if defined(RESCUE) ! CFLAGS+= -DCLIENT_PATH='"PATH=/rescue:/sbin:/bin:/usr/sbin:/usr/bin"' ! .else ! CFLAGS+= -DCLIENT_PATH='"PATH=/sbin:/bin:/usr/sbin:/usr/bin"' ! .endif ! CFLAGS+= -Dwarn=dhcp_warn DPADD= ${LIBDHCP} ${LIBRES} ${LIBOMAPI} ${LIBDST} LDADD= ${LIBDHCP} ${LIBRES} ${LIBOMAPI} ${LIBDST} Index: sbin/fsck/fsck.c =================================================================== RCS file: /usr/cvs/src/sbin/fsck/fsck.c,v retrieving revision 1.12 diff -c -r1.12 fsck.c *** sbin/fsck/fsck.c 31 Oct 2002 15:32:39 -0000 1.12 --- sbin/fsck/fsck.c 7 Jan 2003 05:43:26 -0000 *************** *** 283,288 **** --- 283,291 ---- { /* List of directories containing fsck_xxx subcommands. */ static const char *edirs[] = { + #ifdef RESCUE + _PATH_RESCUE, /* /rescue/fsck tries /rescue first */ + #endif _PATH_SBIN, _PATH_USRSBIN, NULL Index: sbin/fsck/pathnames.h =================================================================== RCS file: /usr/cvs/src/sbin/fsck/pathnames.h,v retrieving revision 1.1 diff -c -r1.1 pathnames.h *** sbin/fsck/pathnames.h 9 Oct 2000 10:23:08 -0000 1.1 --- sbin/fsck/pathnames.h 10 Dec 2002 05:43:11 -0000 *************** *** 31,35 **** --- 31,36 ---- * $FreeBSD: src/sbin/fsck/pathnames.h,v 1.1 2000/10/09 10:23:08 adrian Exp $ */ + #define _PATH_RESCUE "/rescue" #define _PATH_SBIN "/sbin" #define _PATH_USRSBIN "/usr/sbin" Index: sbin/mdmfs/pathnames.h =================================================================== RCS file: /usr/cvs/src/sbin/mdmfs/pathnames.h,v retrieving revision 1.2 diff -c -r1.2 pathnames.h *** sbin/mdmfs/pathnames.h 22 Sep 2002 09:46:28 -0000 1.2 --- sbin/mdmfs/pathnames.h 9 Jan 2003 04:20:16 -0000 *************** *** 2,9 **** --- 2,16 ---- #ifndef MDMFS_PATHNAMES_H #define MDMFS_PATHNAMES_H + /* Shouldn't all of these be moved into /usr/include/paths.h?? */ + #ifndef RESCUE #define PATH_MDCONFIG "/sbin/mdconfig" #define PATH_NEWFS "/sbin/newfs" #define PATH_MOUNT "/sbin/mount" + #else + #define PATH_MDCONFIG "/rescue/mdconfig" + #define PATH_NEWFS "/rescue/newfs" + #define PATH_MOUNT "/rescue/mount" + #endif #endif /* !MDMFS_PATHNAMES_H */ Index: sbin/mount/mount.c =================================================================== RCS file: /usr/cvs/src/sbin/mount/mount.c,v retrieving revision 1.50 diff -c -r1.50 mount.c *** sbin/mount/mount.c 14 Oct 2002 19:40:00 -0000 1.50 --- sbin/mount/mount.c 7 Jan 2003 05:44:01 -0000 *************** *** 391,396 **** --- 391,399 ---- { /* List of directories containing mount_xxx subcommands. */ static const char *edirs[] = { + #ifdef RESCUE + _PATH_RESCUE, /* /rescue/mount tries /rescue first */ + #endif _PATH_SBIN, _PATH_USRSBIN, NULL Index: sbin/mount/pathnames.h =================================================================== RCS file: /usr/cvs/src/sbin/mount/pathnames.h,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 pathnames.h *** sbin/mount/pathnames.h 26 May 1994 06:34:21 -0000 1.1.1.1 --- sbin/mount/pathnames.h 10 Dec 2002 05:34:02 -0000 *************** *** 33,38 **** --- 33,39 ---- * @(#)pathnames.h 8.2 (Berkeley) 3/27/94 */ + #define _PATH_RESCUE "/rescue" #define _PATH_SBIN "/sbin" #define _PATH_USRSBIN "/usr/sbin" #define _PATH_MOUNTDPID "/var/run/mountd.pid" Index: sbin/shutdown/pathnames.h =================================================================== RCS file: /usr/cvs/src/sbin/shutdown/pathnames.h,v retrieving revision 1.2 diff -c -r1.2 pathnames.h *** sbin/shutdown/pathnames.h 17 May 2002 11:47:12 -0000 1.2 --- sbin/shutdown/pathnames.h 9 Jan 2003 04:21:08 -0000 *************** *** 36,41 **** #include ! #define _PATH_FASTBOOT "/fastboot" #define _PATH_HALT "/sbin/halt" #define _PATH_REBOOT "/sbin/reboot" --- 36,49 ---- #include ! /* No longer used? */ ! /* #define _PATH_FASTBOOT "/fastboot" */ ! ! /* Shouldn't these be moved into /usr/include/paths.h?? */ ! #ifndef RESCUE #define _PATH_HALT "/sbin/halt" #define _PATH_REBOOT "/sbin/reboot" + #else + #define _PATH_HALT "/rescue/halt" + #define _PATH_REBOOT "/rescue/reboot" + #endif Index: sbin/startslip/startslip.c =================================================================== RCS file: /usr/cvs/src/sbin/startslip/startslip.c,v retrieving revision 1.34 diff -c -r1.34 startslip.c *** sbin/startslip/startslip.c 21 Mar 2002 13:20:48 -0000 1.34 --- sbin/startslip/startslip.c 1 Jan 2003 22:04:30 -0000 *************** *** 256,262 **** username, (long)conn_time); sprintf(buf, "LINE=%d %s %s down", diali ? (dialc - 1) % diali : 0, ! downscript ? downscript : "/sbin/ifconfig" , unitname); (void) system(buf); logged_in = 0; } --- 256,262 ---- username, (long)conn_time); sprintf(buf, "LINE=%d %s %s down", diali ? (dialc - 1) % diali : 0, ! downscript ? downscript : _PATH_IFCONFIG , unitname); (void) system(buf); logged_in = 0; } *************** *** 458,464 **** sprintf(buf, "LINE=%d %s %s up", diali ? (dialc - 1) % diali : 0, ! upscript ? upscript : "/sbin/ifconfig" , unitname); (void) system(buf); printd(", ready\n"); --- 458,464 ---- sprintf(buf, "LINE=%d %s %s up", diali ? (dialc - 1) % diali : 0, ! upscript ? upscript : _PATH_IFCONFIG , unitname); (void) system(buf); printd(", ready\n"); Index: sbin/vinum/commands.c =================================================================== RCS file: /usr/cvs/src/sbin/vinum/commands.c,v retrieving revision 1.43 diff -c -r1.43 commands.c *** sbin/vinum/commands.c 26 Apr 2002 04:21:59 -0000 1.43 --- sbin/vinum/commands.c 22 Nov 2002 21:42:56 -0000 *************** *** 83,89 **** editor = getenv("EDITOR"); if (editor == NULL) ! editor = "/usr/bin/vi"; sprintf(tempfile, "/var/tmp/" VINUMMOD ".create.%d", getpid()); /* create a temp file */ tf = fopen(tempfile, "w"); /* open it */ if (tf == NULL) { --- 83,89 ---- editor = getenv("EDITOR"); if (editor == NULL) ! editor = _PATH_VI; sprintf(tempfile, "/var/tmp/" VINUMMOD ".create.%d", getpid()); /* create a temp file */ tf = fopen(tempfile, "w"); /* open it */ if (tf == NULL) { Index: share/mk/bsd.lib.mk =================================================================== RCS file: /usr/cvs/src/share/mk/bsd.lib.mk,v retrieving revision 1.138 diff -c -r1.138 bsd.lib.mk *** share/mk/bsd.lib.mk 20 Sep 2002 19:32:51 -0000 1.138 --- share/mk/bsd.lib.mk 7 Jan 2003 02:01:16 -0000 *************** *** 21,26 **** --- 21,28 ---- SONAME?= ${SHLIB_NAME} .endif + CFLAGS+= ${CRUNCH_CFLAGS} + .if defined(DEBUG_FLAGS) CFLAGS+= ${DEBUG_FLAGS} .endif Index: share/mk/bsd.prog.mk =================================================================== RCS file: /usr/cvs/src/share/mk/bsd.prog.mk,v retrieving revision 1.129 diff -c -r1.129 bsd.prog.mk *** share/mk/bsd.prog.mk 17 Oct 2002 13:48:13 -0000 1.129 --- share/mk/bsd.prog.mk 7 Jan 2003 02:01:20 -0000 *************** *** 6,11 **** --- 6,12 ---- .SUFFIXES: .out .o .c .cc .cpp .cxx .C .m .y .l .ln .s .S .asm CFLAGS+=${COPTS} ${DEBUG_FLAGS} + CFLAGS+= ${CRUNCH_CFLAGS} .if !defined(DEBUG_FLAGS) STRIP?= -s Index: usr.bin/vi/pathnames.h =================================================================== RCS file: /usr/cvs/src/usr.bin/vi/pathnames.h,v retrieving revision 1.2 diff -c -r1.2 pathnames.h *** usr.bin/vi/pathnames.h 4 Nov 1996 02:28:31 -0000 1.2 --- usr.bin/vi/pathnames.h 22 Nov 2002 21:50:47 -0000 *************** *** 1,5 **** --- 1,8 ---- /* @(#)pathnames.h.in 8.4 (Berkeley) 6/26/96 */ + /* Read standard system paths first */ + #include + #ifndef _PATH_BSHELL #define _PATH_BSHELL "/bin/sh" #endif Index: usr.sbin/crunch/crunchgen/crunchgen.c =================================================================== RCS file: /usr/cvs/src/usr.sbin/crunch/crunchgen/crunchgen.c,v retrieving revision 1.31 diff -c -r1.31 crunchgen.c *** usr.sbin/crunch/crunchgen/crunchgen.c 30 Mar 2002 16:48:30 -0000 1.31 --- usr.sbin/crunch/crunchgen/crunchgen.c 20 Nov 2002 04:07:07 -0000 *************** *** 691,705 **** fprintf(f, ".endif\n"); fprintf(f, "loop:\n\t@echo 'OBJS= '${%s}\n", objvar); ! fprintf(f, "crunchgen_objs:\n\t@make -f %s $(BUILDOPTS) $(%s_OPTS)", ! tempfname, p->ident); for (s = p->buildopts; s != NULL; s = s->next) fprintf(f, " %s", s->str); fprintf(f, " loop\n"); fclose(f); ! snprintf(line, MAXLINELEN, "make -f %s crunchgen_objs 2>&1", tempfname); if ((f = popen(line, "r")) == NULL) { warn("submake pipe"); goterror = 1; --- 691,708 ---- fprintf(f, ".endif\n"); fprintf(f, "loop:\n\t@echo 'OBJS= '${%s}\n", objvar); ! fprintf(f, "crunchgen_objs:\n\t@cd %s && make -f %s $(BUILDOPTS) $(%s_OPTS)", ! p->srcdir, tempfname, p->ident); for (s = p->buildopts; s != NULL; s = s->next) fprintf(f, " %s", s->str); fprintf(f, " loop\n"); fclose(f); ! snprintf(line, MAXLINELEN, "cd %s && make -f %s crunchgen_objs 2>&1", ! p->srcdir, ! tempfname); ! if ((f = popen(line, "r")) == NULL) { warn("submake pipe"); goterror = 1; *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/README Thu Jan 2 21:44:29 2003 *************** *** 0 **** --- 1,42 ---- + The /rescue build system here has three goals: + + 1) Produce a reliable standalone set of /rescue tools. + + The contents of /rescue are all statically linked and do not depend on + anything in /bin or /sbin. In particular, they'll continue to + function even if you've hosed your dynamic /bin and /sbin. For + example, note that /rescue/mount runs /rescue/mount_nfs and not + /sbin/mount_nfs. This is more subtle than it looks. + + As an added bonus, /rescue is fairly small (thanks to crunchgen) and + includes a number of tools (such as gzip, bzip2, vi) that are not + normally found in /bin and /sbin. + + 2) Demonstrate robust use of crunchgen. + + These Makefiles recompile each of the crunchgen components and include + support for overriding specific library entries. Such techniques + should be useful elsewhere. For example, boot floppies could use this + to conditionally compile out features to reduce executable size. + + 3) Produce a toolkit suitable for small distributions. + + Install /rescue on a CD or CompactFlash disk, and symlink /bin and + /sbin to /rescue to produce a small and fairly complete FreeBSD + system. + + These tools have one big disadvantage: being statically linked, they + cannot use some advanced library functions that rely on dynamic + linking. In particular, nsswitch, locales, and pam are likely to all + rely on dynamic linking in the near future. + + + To compile: + + # cd /usr/src/rescue + # make obj + # make + # make install + + Note that rebuilds don't always work correctly; if you run into + trouble, try 'make clean' before recompiling. *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/Makefile Wed Jan 8 18:41:52 2003 *************** *** 0 **** --- 1,3 ---- + SUBDIR=librescue rescue + + .include *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/Makefile Wed Jan 8 20:10:34 2003 *************** *** 0 **** --- 1,34 ---- + # + # $FreeBSD: src/rescue/librescue/Makefile,v Exp $ + # + + # Certain library entries have hard-coded references to + # /bin, /sbin, etc, that require those entries to be + # recompiled for use in /rescue. This Makefile + # accomplishes that. Note that this is pure build hackery. + # This library should never be installed, and isn't even linked + # with in the normal way. (See ../rescue/Makefile for details.) + + LIB= rescue + NOPROFILE= yes # Don't generate profile version + INTERNALLIB= yes # Don't install this library + + CFLAGS+= -DRESCUE + # Flags copied from src/lib/libc and src/lib/libutil + CFLAGS+= -I${.CURDIR}/../../lib/libc/include + CFLAGS+= -I${.CURDIR}/../../include + CFLAGS+= -D__DBINTERFACE_PRIVATE + CFLAGS+= -DINET6 + CFLAGS+= -I${.OBJDIR}/../../lib/libc + CFLAGS+= -DPOSIX_MISTAKE + CFLAGS+= -I${.CURDIR}/../../lib/libc/locale + CFLAGS+= -DBROKEN_DES + CFLAGS+= -DPORTMAP + CFLAGS+= -DDES_BUILTIN + CFLAGS+= -DYP + CFLAGS+= -DHESIOD + CFLAGS+= -Wall -Wwrite-strings -Wpointer-arith + + SRCS = exec.c getusershell.c login_class.c popen.c rcmdsh.c sysctl.c system.c + + .include *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/exec.c Mon Dec 9 21:56:20 2002 *************** *** 0 **** --- 1 ---- + #include "../../lib/libc/gen/exec.c" *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/getusershell.c Fri Dec 27 17:38:14 2002 *************** *** 0 **** --- 1 ---- + #include "../../lib/libc/gen/getusershell.c" *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/login_class.c Thu Jan 2 22:50:40 2003 *************** *** 0 **** --- 1 ---- + #include "../../lib/libutil/login_class.c" *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/popen.c Fri Dec 27 17:38:35 2002 *************** *** 0 **** --- 1 ---- + #include "../../lib/libc/gen/popen.c" *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/rcmdsh.c Fri Dec 27 17:38:49 2002 *************** *** 0 **** --- 1 ---- + #include "../../lib/libc/net/rcmdsh.c" *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/sysctl.c Wed Jan 8 19:39:38 2003 *************** *** 0 **** --- 1 ---- + #include "../../lib/libc/gen/sysctl.c" *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/librescue/system.c Fri Dec 27 17:37:49 2002 *************** *** 0 **** --- 1 ---- + #include "../../lib/libc/stdlib/system.c" *** /dev/null Wed Jan 8 20:22:00 2003 --- rescue/rescue/Makefile Wed Jan 8 20:25:05 2003 *************** *** 0 **** --- 1,259 ---- + # $FreeBSD: src/rescue/Makefile Exp $ + # @(#)Makefile 8.1 (Berkeley) 6/2/93 + + PROG= rescue + BINDIR?= /rescue + + # Uncomment to exclude tcsh + #NO_TCSH=1 + + # Shell scripts need #! line to be edited from /bin/sh to /rescue/sh + SCRIPTS= nextboot_FIXED + SCRIPTSNAME_nextboot_FIXED= nextboot.sh + nextboot_FIXED: ../../sbin/reboot/nextboot.sh + sed '1s/\/bin\//\/rescue\//' ${.ALLSRC} > ${.TARGET} + CLEANFILES+= nextboot_FIXED + + SCRIPTS+= dhclient_FIXED + SCRIPTSNAME_dhclient_FIXED= dhclient-script + dhclient_FIXED: ../../contrib/isc-dhcp/client/scripts/freebsd + sed '1s/\/bin\//\/rescue\//' ${.ALLSRC} > ${.TARGET} + CLEANFILES+= dhclient_FIXED + + ################################################################# + # + # General notes: + # + # A number of Make variables are used to generate the crunchgen config file. + # + # CRUNCH_SRCDIRS: lists directories to search for included programs + # CRUNCH_PROGS: lists programs to be included + # CRUNCH_LIBS: libraries to link with + # CRUNCH_BUILDOPTS: generic build options to be added to every program + # + # Special options can be specified for individual programs + # CRUNCH_SRCDIR_$(P): base source directory for program $(P) + # CRUNCH_BUILDOPTS_$(P): additional build options for $(P) + # CRUNCH_ALIAS_$(P): additional names to be used for $(P) + # + # By default, any name appearing in CRUNCH_PROGS or CRUNCH_ALIAS_${P} + # will be used to generate a hard link to the resulting binary. + # Specific links can be suppressed by setting + # CRUNCH_SUPPRESS_LINK_$(NAME) to 1. + # + + # Define Makefile variable RESCUE + CRUNCH_BUILDOPTS+= -DRESCUE + # Define compile-time RESCUE symbol when compiling components + CRUNCH_BUILDOPTS+= CRUNCH_CFLAGS=-DRESCUE + + # Hackery: 'librescue' exists merely as a tool for appropriately + # recompiling specific library entries. We _know_ they're needed, and + # regular archive searching creates ugly library ordering problems. + # Easiest fix: tell the linker to include them into the executable + # first, so they are guaranteed to override the regular lib entries. + # Note that if 'librescue' hasn't been compiled, we'll just get the + # regular lib entries from libc and friends. + CRUNCH_LIBS+= ${.OBJDIR}/../librescue/*.o + + ################################################################### + # Programs from stock /bin + # + # WARNING: Changing this list may require adjusting + # /usr/include/paths.h as well! You were warned! + # + CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin $(.CURDIR)/../../usr.bin + CRUNCH_PROGS=cat chflags chio chmod cp date dd df domainname echo ed \ + expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \ + realpath rm rmdir setfacl sh sleep stty sync test + CRUNCH_LIBS+=-lcrypt -ledit -lkvm -ll -lm -ltermcap -lutil + + # Additional options for specific programs + CRUNCH_ALIAS_test= [ + CRUNCH_ALIAS_sh= -sh + # The -sh alias shouldn't appear in /rescue as a hard link + CRUNCH_SUPPRESS_LINK_-sh=1 + CRUNCH_ALIAS_ln= link + CRUNCH_ALIAS_rm= unlink + CRUNCH_ALIAS_ed= red + + .if !defined(NO_RCMNDS) + CRUNCH_PROGS+= rcp + .endif + + .if !defined(NO_TCSH) + CRUNCH_PROGS+= csh + CRUNCH_ALIAS_csh= -csh tcsh -tcsh + CRUNCH_SUPPRESS_LINK_-csh=1 + CRUNCH_SUPPRESS_LINK_-tcsh=1 + .endif + + #Is rmail of any use at all here? I think not. + #CRUNCH_PROGS+= rmail + + ################################################################### + # Programs from standard /sbin + # + # WARNING: Changing this list may require adjusting + # /usr/include/paths.h as well! You were warned! + # + # Note that mdmfs and shutdown have their own private 'pathnames.h' + # headers in addition to the standard 'paths.h' header. + # + CRUNCH_SRCDIRS+=$(.CURDIR)/../../sbin + CRUNCH_PROGS+=atm adjkerntz atacontrol badsect camcontrol ccdconfig \ + clri comcontrol conscontrol devfs disklabel dmesg dump \ + dumpfs dumpon fdisk fore_dnld fsck fsck_ffs fsck_msdosfs fsdb \ + fsirand gbde growfs ifconfig ilmid init ip6fw ipf ipfs ipfstat \ + ipfw ipmon ipnat kldconfig kldload kldstat kldunload ldconfig \ + md5 mdconfig mdmfs mknod mount mount_cd9660 mount_ext2fs \ + mount_msdosfs mount_nfs mount_ntfs mount_nullfs mount_portalfs \ + mount_std mount_udf mount_umapfs mount_unionfs natd newfs \ + newfs_msdos nfsiod nos-tun ping ping6 quotacheck raidctl reboot \ + restore rcorder route routed rtquery rtsol savecore shutdown \ + slattach spppcontrol startslip swapon sysctl tunefs umount vinum + + # crunchgen does not like C++ programs; this should be fixed someday + # CRUNCH_PROGS+= devd + + CRUNCH_LIBS+=-lalias -latm -lcam -lcurses -ldevstat -lipsec -lipx -lmd \ + -lncp -lreadline -lsbuf -lsmb -lufs -lz + + .if ${MACHINE_ARCH} == "i386" + CRUNCH_PROGS+= cxconfig mount_nwfs mount_smbfs + .endif + + .if ${MACHINE} == "pc98" + CRUNCH_PROGS+= fdisk_pc98 + .endif + + .if ${MACHINE_ARCH} == "ia64" + CRUNCH_PROGS+= mca gpt + .endif + + .if ${MACHINE_ARCH} == "sparc" + .endif + + .if ${MACHINE_ARCH} == "alpha" + .endif + + CRUNCH_SRCDIR_atm=$(.CURDIR)/../../sbin/atm/atm + CRUNCH_SRCDIR_fore_dnld=$(.CURDIR)/../../sbin/atm/fore_dnld + CRUNCH_SRCDIR_ilmid=$(.CURDIR)/../../sbin/atm/ilmid + CRUNCH_SRCDIR_rtquery=$(.CURDIR)/../../sbin/routed/rtquery + CRUNCH_ALIAS_reboot= fastboot halt fasthalt + CRUNCH_ALIAS_restore=rrestore + CRUNCH_ALIAS_dump= rdump + CRUNCH_ALIAS_fsck_ffs=fsck_4.2bsd fsck_ufs + CRUNCH_ALIAS_mount_std= mount_devfs mount_fdescfs mount_linprocfs mount_procfs + + # dhclient has historically been troublesome... + CRUNCH_PROGS+=dhclient + CRUNCH_BUILDOPTS_dhclient=-DRELEASE_CRUNCH -Dlint + + ################################################################## + # Programs from stock /usr/bin + # + CRUNCH_SRCDIRS+=$(.CURDIR)/../../usr.bin + CRUNCH_SRCDIRS+=$(.CURDIR)/../../gnu/usr.bin + + CRUNCH_PROGS+=wall + + CRUNCH_PROGS+=gzip + CRUNCH_ALIAS_gzip=gunzip gzcat zcat + + CRUNCH_PROGS+=bzip2 + CRUNCH_ALIAS_bzip2=bunzip2 bzcat + CRUNCH_LIBS+=-lbz2 + + CRUNCH_PROGS+=tar + CRUNCH_PROGS+=vi + CRUNCH_ALIAS_vi=ex + + ################################################################## + # The following is pretty nearly a generic crunchgen-handling makefile + # + + CONF= $(PROG).conf + OUTMK= $(PROG).mk + OUTC= $(PROG).c + OUTPUTS= $(OUTMK) $(OUTC) $(PROG).cache + CRUNCHOBJS= ${.OBJDIR} + .if defined(MAKEOBJDIRPREFIX) + CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR} + .else + CANONICALOBJDIR:=/usr/obj${.CURDIR} + .endif + + NOMAN= true + CLEANFILES+= $(CONF) *.o *.lo *.c *.mk *.cache *.a *.h + + # Program names and their aliases contribute hardlinks to 'rescue' executable, + # except for those that get suppressed. + .for P in $(CRUNCH_PROGS) + .ifndef CRUNCH_SUPPRESS_LINK_${P} + LINKS += $(BINDIR)/$(PROG) $(BINDIR)/$(P) + .endif + .for A in $(CRUNCH_ALIAS_$(P)) + .ifndef CRUNCH_SUPPRESS_LINK_${A} + LINKS += $(BINDIR)/$(PROG) $(BINDIR)/$(A) + .endif + .endfor + .endfor + + all: $(PROG) + exe: $(PROG) + + $(CONF): Makefile + echo \# Auto-generated, do not edit >$(.TARGET) + .for D in $(CRUNCH_SRCDIRS) + echo srcdirs $(D) >>$(.TARGET) + .endfor + .ifdef CRUNCH_BUILDOPTS + echo buildopts $(CRUNCH_BUILDOPTS) >>$(.TARGET) + .endif + .ifdef CRUNCH_BUILDOPTS + echo libs $(CRUNCH_LIBS) >>$(.TARGET) + .endif + .for P in $(CRUNCH_PROGS) + echo progs $(P) >>$(.TARGET) + .ifdef CRUNCH_SRCDIR_${P} + echo special $(P) srcdir $(CRUNCH_SRCDIR_${P}) >>$(.TARGET) + .endif + .ifdef CRUNCH_BUILDOPTS_${P} + echo special $(P) buildopts $(CRUNCH_BUILDOPTS_${P}) >>$(.TARGET) + .endif + .for A in $(CRUNCH_ALIAS_$(P)) + echo ln $(P) $(A) >>$(.TARGET) + .endfor + .endfor + + + $(OUTPUTS): $(CONF) + MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) $(CONF) + + $(PROG): $(OUTPUTS) + MAKEOBJDIRPREFIX=${CRUNCHOBJS} make -f $(OUTMK) + + objs: + MAKEOBJDIRPREFIX=${CRUNCHOBJS} make -f $(OUTMK) objs + + # Use a separate build tree to hold files compiled for this crunchgen binary + # Yes, this does seem to partly duplicate bsd.subdir.mk, but I can't + # get that to cooperate with bsd.prog.mk. Besides, many of the standard + # targets should NOT be propagated into the components. + cleandepend cleandir obj objlink: + .for D in $(CRUNCH_SRCDIRS) + cd ${D} && MAKEOBJDIRPREFIX=${CANONICALOBJDIR} make ${.TARGET} + .endfor + + clean: + if [ -e ${.OBJDIR}/$(OUTMK) ]; then \ + MAKEOBJDIRPREFIX=${CRUNCHOBJS} make -f $(OUTMK) clean; \ + fi + .for D in $(CRUNCH_SRCDIRS) $(EXTRA_SRCDIRS) + cd ${D} && MAKEOBJDIRPREFIX=${CRUNCHOBJS} make clean + .endfor + rm -f ${CLEANFILES} + + .include --------------090401000102090001060504-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ----Next_Part(Thu_May__8_09:39:11_2003_697)---- From owner-freebsd-arch@FreeBSD.ORG Thu May 8 08:40:38 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74EA537B401 for ; Thu, 8 May 2003 08:40:38 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6470C43FB1 for ; Thu, 8 May 2003 08:40:36 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h48FeZTl019913; Thu, 8 May 2003 09:40:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 08 May 2003 09:40:17 -0600 (MDT) Message-Id: <20030508.094017.85932600.imp@bsdimp.com> To: gordont@gnf.org From: "M. Warner Losh" In-Reply-To: <20030508080234.GI76376@roark.gnf.org> References: <20030508080234.GI76376@roark.gnf.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: PATCH: Dynamic /bin support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 15:40:39 -0000 In message: <20030508080234.GI76376@roark.gnf.org> Gordon Tetlow writes: : I'm working on /sbin support, but there are alot of additional libraries : that are needed for that one. I'll get to it. Yes. Now would be a good time to rewrite vinum's management program to use libedit() rather than libreadline() to eliminate one or two of the offending libraries. It is the odd-man out. However, Tim Kientzle posted something similar a while ago that takes the idea one step further by having a statically linked rescue binary in case one of the shared libraries dies. I've forwarded that to hackers@. It may be an older version of his patches, but it was the one I saved in my mailbox. Warner From owner-freebsd-arch@FreeBSD.ORG Thu May 8 08:42:28 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0BA737B401 for ; Thu, 8 May 2003 08:42:27 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A73943FA3 for ; Thu, 8 May 2003 08:42:26 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h48FgPTl019934 for ; Thu, 8 May 2003 09:42:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 08 May 2003 09:42:06 -0600 (MDT) Message-Id: <20030508.094206.68986125.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_May__8_09:42:06_2003_428)--" Content-Transfer-Encoding: 7bit Subject: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 15:42:28 -0000 ----Next_Part(Thu_May__8_09:42:06_2003_428)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dang. I posted the wrong version of the patch. Here's the latest one he sent me/hackers@ Warner ----Next_Part(Thu_May__8_09:42:06_2003_428)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: owner-freebsd-hackers@FreeBSD.ORG Delivery-Date: Thu, 23 Jan 2003 23:41:44 -0700 Received: from rover.village.org (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0O6fZ1e007221 for ; Thu, 23 Jan 2003 23:41:35 -0700 (MST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by rover.village.org (8.12.5/8.12.3) with ESMTP id h0O6fW7G029921 for ; Thu, 23 Jan 2003 23:41:32 -0700 (MST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 841FD5576F; Thu, 23 Jan 2003 22:41:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: by hub.freebsd.org (Postfix, from userid 538) id 5639837B405; Thu, 23 Jan 2003 22:41:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 378182E8009; Thu, 23 Jan 2003 22:41:22 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Thu, 23 Jan 2003 22:41:22 -0800 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 547BC37B401 for ; Thu, 23 Jan 2003 22:40:56 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E71C943ED8 for ; Thu, 23 Jan 2003 22:40:54 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.51]) by kientzle.com (8.11.3/8.11.3) with ESMTP id h0O6eeR04331; Thu, 23 Jan 2003 22:40:40 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3E30DFE7.50401@acm.org> Date: Thu, 23 Jan 2003 22:40:39 -0800 From: Tim Kientzle Reply-To: kientzle@acm.org User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" Cc: freebsd-hackers@FreeBSD.ORG, Nate Lawson Subject: Re: /rescue References: <3E248D85.10201@acm.org> <20030114.231723.49603038.imp@bsdimp.com> Content-Type: multipart/mixed; boundary="------------030407000308050805040706" Sender: owner-freebsd-hackers@FreeBSD.ORG List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Precedence: bulk X-Spam-Status: No, hits=-11.8 required=5.0 tests=BALANCE_FOR_LONG_20K,EMAIL_ATTRIBUTION,PATCH_CONTEXT_DIFF, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, TO_BE_REMOVED_REPLY,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG,X_LOOP version=2.41 X-Spam-Level: This is a multi-part message in MIME format. --------------030407000308050805040706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit M. Warner Losh wrote: > I'm curious why you did things this way, rather then with .PATH in the > makefile? > > *** /dev/null Wed Jan 8 20:22:00 2003 > --- rescue/librescue/exec.c Mon Dec 9 21:56:20 2002 > *************** > *** 0 **** > --- 1 ---- > + #include "../../lib/libc/gen/exec.c" Yep, .PATH does simplify things. Revised diff attached. Thanks for the suggestion. Tim --------------030407000308050805040706 Content-Type: text/plain; name="kientzle_rescue_2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kientzle_rescue_2.diff" Index: Makefile.inc1 =================================================================== RCS file: /mnt/cvs/src/Makefile.inc1,v retrieving revision 1.314 diff -c -r1.314 Makefile.inc1 *** Makefile.inc1 30 Dec 2002 10:01:25 -0000 1.314 --- Makefile.inc1 7 Jan 2003 05:52:24 -0000 *************** *** 51,56 **** --- 51,60 ---- SUBDIR+= lib .endif + .if exists(${.CURDIR}/rescue) + SUBDIR+= rescue + .endif + .if exists(${.CURDIR}/bin) SUBDIR+= bin .endif Index: bin/csh/Makefile =================================================================== RCS file: /mnt/cvs/src/bin/csh/Makefile,v retrieving revision 1.29 diff -c -r1.29 Makefile *** bin/csh/Makefile 24 Jul 2002 22:26:44 -0000 1.29 --- bin/csh/Makefile 7 Jan 2003 02:07:46 -0000 *************** *** 10,16 **** --- 10,20 ---- .PATH: ${TCSHDIR} PROG= csh + .if defined(RESCUE) + DFLAGS= -D_PATH_TCSHELL='"/rescue/${PROG}"' + .else DFLAGS= -D_PATH_TCSHELL='"/bin/${PROG}"' + .endif CFLAGS+= -I. -I${.CURDIR} -I${TCSHDIR} ${DFLAGS} SRCS= sh.c sh.dir.c sh.dol.c sh.err.c sh.exec.c sh.char.c \ sh.exp.c sh.file.c sh.func.c sh.glob.c sh.hist.c sh.init.c \ Index: bin/mv/mv.c =================================================================== RCS file: /mnt/cvs/src/bin/mv/mv.c,v retrieving revision 1.39 diff -c -r1.39 mv.c *** bin/mv/mv.c 9 Jul 2002 17:45:13 -0000 1.39 --- bin/mv/mv.c 7 Jan 2003 18:13:50 -0000 *************** *** 67,74 **** #include #include - #include "pathnames.h" - int fflg, iflg, nflg, vflg; int copy(char *, char *); --- 67,72 ---- Index: bin/mv/pathnames.h =================================================================== RCS file: /mnt/cvs/src/bin/mv/pathnames.h,v retrieving revision 1.6 diff -c -r1.6 pathnames.h *** bin/mv/pathnames.h 17 May 2002 11:38:48 -0000 1.6 --- bin/mv/pathnames.h 9 Jan 2003 02:34:27 -0000 *************** *** 34,37 **** * $FreeBSD: src/bin/mv/pathnames.h,v 1.6 2002/05/17 11:38:48 jmallett Exp $ */ ! #define _PATH_RM "/bin/rm" --- 34,37 ---- * $FreeBSD: src/bin/mv/pathnames.h,v 1.6 2002/05/17 11:38:48 jmallett Exp $ */ ! /* This file is empty and can be safely deleted */ Index: bin/sh/var.c =================================================================== RCS file: /mnt/cvs/src/bin/sh/var.c,v retrieving revision 1.23 diff -c -r1.23 var.c *** bin/sh/var.c 1 Oct 2002 00:54:14 -0000 1.23 --- bin/sh/var.c 1 Jan 2003 23:35:53 -0000 *************** *** 44,49 **** --- 44,50 ---- #include #include + #include /* * Shell variables. *************** *** 105,111 **** NULL }, { &vmpath, VSTRFIXED|VTEXTFIXED|VUNSET, "MAILPATH=", NULL }, ! { &vpath, VSTRFIXED|VTEXTFIXED, "PATH=/bin:/usr/bin", changepath }, { &vppid, VSTRFIXED|VTEXTFIXED|VUNSET, "PPID=", NULL }, --- 106,112 ---- NULL }, { &vmpath, VSTRFIXED|VTEXTFIXED|VUNSET, "MAILPATH=", NULL }, ! { &vpath, VSTRFIXED|VTEXTFIXED, "PATH=" _PATH_DEFPATH, changepath }, { &vppid, VSTRFIXED|VTEXTFIXED|VUNSET, "PPID=", NULL }, Index: contrib/isc-dhcp/client/clparse.c =================================================================== RCS file: /mnt/cvs/src/contrib/isc-dhcp/client/clparse.c,v retrieving revision 1.9 diff -c -r1.9 clparse.c *** contrib/isc-dhcp/client/clparse.c 16 Jan 2003 07:22:32 -0000 1.9 --- contrib/isc-dhcp/client/clparse.c 24 Jan 2003 06:01:43 -0000 *************** *** 53,59 **** struct client_config top_level_config; ! char client_script_name [] = "/sbin/dhclient-script"; u_int32_t default_requested_options [] = { DHO_SUBNET_MASK, --- 53,59 ---- struct client_config top_level_config; ! char client_script_name [] = _PATH_DHCLIENT_SCRIPT; u_int32_t default_requested_options [] = { DHO_SUBNET_MASK, Index: contrib/isc-dhcp/includes/cf/freebsd.h =================================================================== RCS file: /mnt/cvs/src/contrib/isc-dhcp/includes/cf/freebsd.h,v retrieving revision 1.5 diff -c -r1.5 freebsd.h *** contrib/isc-dhcp/includes/cf/freebsd.h 30 Sep 2002 08:45:34 -0000 1.5 --- contrib/isc-dhcp/includes/cf/freebsd.h 9 Jan 2003 02:35:47 -0000 *************** *** 103,108 **** --- 103,112 ---- #define SOCKLEN_T int #endif + #ifdef RESCUE + #define _PATH_DHCLIENT_SCRIPT "/rescue/dhclient-script" + #endif + #if defined (USE_DEFAULT_NETWORK) # define USE_BPF #endif *************** *** 113,118 **** --- 117,125 ---- #endif /* HAVE_DEV_RANDOM */ const char *cmds[] = { + #ifndef RESCUE + /* rescue environment can't rely on these ... */ + /* Actually, /sbin/dhclient shouldn't use these, either. */ "/bin/ps -axlw 2>&1", "/usr/sbin/arp -an 2>&1", "/usr/bin/netstat -an 2>&1", *************** *** 123,132 **** --- 130,141 ---- "/usr/sbin/iostat 2>&1", "/usr/bin/vmstat 2>&1", "/usr/bin/w 2>&1", + #endif NULL }; const char *dirs[] = { + #ifndef RESCUE "/tmp", "/usr/tmp", ".", *************** *** 136,148 **** --- 145,160 ---- "/var/mail", "/home", "/usr/home", + #endif NULL }; const char *files[] = { + #ifndef RESCUE "/var/log/messages", "/var/log/wtmp", "/var/log/lastlog", + #endif NULL }; #endif /* NEED_PRAND_CONF */ Index: contrib/tar/src/buffer.c =================================================================== RCS file: /mnt/cvs/src/contrib/tar/src/buffer.c,v retrieving revision 1.5 diff -c -r1.5 buffer.c *** contrib/tar/src/buffer.c 9 Oct 2002 07:33:29 -0000 1.5 --- contrib/tar/src/buffer.c 22 Nov 2002 21:37:10 -0000 *************** *** 25,30 **** --- 25,36 ---- #include + #if __FreeBSD__ + # include + #else + # define _PATH_BSHELL "/bin/sh" + #endif + #if MSDOS # include #endif *************** *** 1549,1555 **** pid_t child; const char *shell = getenv ("SHELL"); if (! shell) ! shell = "/bin/sh"; child = xfork (); if (child == 0) { --- 1555,1561 ---- pid_t child; const char *shell = getenv ("SHELL"); if (! shell) ! shell = _PATH_BSHELL; child = xfork (); if (child == 0) { Index: etc/mtree/BSD.root.dist =================================================================== RCS file: /mnt/cvs/src/etc/mtree/BSD.root.dist,v retrieving revision 1.58 diff -c -r1.58 BSD.root.dist *** etc/mtree/BSD.root.dist 10 Jun 2002 04:47:26 -0000 1.58 --- etc/mtree/BSD.root.dist 7 Jan 2003 05:57:14 -0000 *************** *** 67,72 **** --- 67,74 ---- .. proc mode=0555 .. + rescue + .. root .. sbin Index: include/paths.h =================================================================== RCS file: /mnt/cvs/src/include/paths.h,v retrieving revision 1.17 diff -c -r1.17 paths.h *** include/paths.h 14 Jul 2002 13:04:15 -0000 1.17 --- include/paths.h 7 Jan 2003 06:34:34 -0000 *************** *** 40,57 **** --- 40,84 ---- #include /* Default search path. */ + #ifdef RESCUE + #define _PATH_DEFPATH "/rescue:/usr/bin:/bin" + #else #define _PATH_DEFPATH "/usr/bin:/bin" + #endif + /* All standard utilities path. */ + #ifdef RESCUE + #define _PATH_STDPATH \ + "/rescue:/usr/bin:/bin:/usr/sbin:/sbin" + #else #define _PATH_STDPATH \ "/usr/bin:/bin:/usr/sbin:/sbin:" + #endif #define _PATH_AUTHCONF "/etc/auth.conf" + + #ifdef RESCUE + #define _PATH_BSHELL "/rescue/sh" + #else #define _PATH_BSHELL "/bin/sh" + #endif + #define _PATH_CAPABILITY "/etc/capability" #define _PATH_CAPABILITY_DB "/etc/capability.db" #define _PATH_CONSOLE "/dev/console" + + #ifdef RESCUE + #define _PATH_CP "/rescue/cp" + #else #define _PATH_CP "/bin/cp" + #endif + + #ifdef RESCUE + #define _PATH_CSHELL "/rescue/csh" + #else #define _PATH_CSHELL "/bin/csh" + #endif + #define _PATH_DEFTAPE "/dev/sa0" #define _PATH_DEVDB "/var/run/dev.db" #define _PATH_DEVNULL "/dev/null" *************** *** 59,79 **** --- 86,136 ---- #define _PATH_DRUM "/dev/drum" #define _PATH_ETC "/etc" #define _PATH_FTPUSERS "/etc/ftpusers" + + #ifdef RESCUE + #define _PATH_IFCONFIG "/rescue/ifconfig" + #else + #define _PATH_IFCONFIG "/sbin/ifconfig" + #endif + #define _PATH_KMEM "/dev/kmem" #define _PATH_LOGIN "/usr/bin/login" #define _PATH_MAILDIR "/var/mail" #define _PATH_MAN "/usr/share/man" #define _PATH_MEM "/dev/mem" #define _PATH_NOLOGIN "/var/run/nologin" + + #ifdef RESCUE + #define _PATH_RCP "/rescue/rcp" + #else #define _PATH_RCP "/bin/rcp" + #endif + #define _PATH_RLOGIN "/usr/bin/rlogin" + + #ifdef RESCUE + #define _PATH_RM "/rescue/rm" + #else + #define _PATH_RM "/bin/rm" + #endif + #define _PATH_RSH "/usr/bin/rsh" #define _PATH_SENDMAIL "/usr/sbin/sendmail" #define _PATH_SHELLS "/etc/shells" #define _PATH_TTY "/dev/tty" #define _PATH_UNIX "don't use _PATH_UNIX" + + #ifdef RESCUE + #define _PATH_VI "/rescue/vi" + #else #define _PATH_VI "/usr/bin/vi" + #endif + + #ifdef RESCUE + #define _PATH_WALL "/rescue/wall" + #else #define _PATH_WALL "/usr/bin/wall" + #endif /* Provide trailing slash, since mostly used for building pathnames. */ #define _PATH_DEV "/dev/" Index: sbin/dhclient/Makefile =================================================================== RCS file: /mnt/cvs/src/sbin/dhclient/Makefile,v retrieving revision 1.17 diff -c -r1.17 Makefile *** sbin/dhclient/Makefile 28 Feb 2002 16:17:18 -0000 1.17 --- sbin/dhclient/Makefile 9 Jan 2003 02:38:00 -0000 *************** *** 47,54 **** # though, so we must run ``make all'' instead when we are asked to # generate an individual object file. ${OBJS}: all ! .endif .include --- 47,55 ---- # though, so we must run ``make all'' instead when we are asked to # generate an individual object file. + # Note: Must have some commands here to override the default build action ${OBJS}: all ! @true .endif .include Index: sbin/dhclient/client/Makefile =================================================================== RCS file: /mnt/cvs/src/sbin/dhclient/client/Makefile,v retrieving revision 1.2 diff -c -r1.2 Makefile *** sbin/dhclient/client/Makefile 19 Feb 2002 22:23:49 -0000 1.2 --- sbin/dhclient/client/Makefile 7 Jan 2003 05:43:08 -0000 *************** *** 8,14 **** PROG= dhclient SRCS= clparse.c dhclient.c ! CFLAGS+= -DCLIENT_PATH='"PATH=/sbin:/bin:/usr/sbin:/usr/bin"' -Dwarn=dhcp_warn DPADD= ${LIBDHCP} ${LIBRES} ${LIBOMAPI} ${LIBDST} LDADD= ${LIBDHCP} ${LIBRES} ${LIBOMAPI} ${LIBDST} --- 8,19 ---- PROG= dhclient SRCS= clparse.c dhclient.c ! .if defined(RESCUE) ! CFLAGS+= -DCLIENT_PATH='"PATH=/rescue:/sbin:/bin:/usr/sbin:/usr/bin"' ! .else ! CFLAGS+= -DCLIENT_PATH='"PATH=/sbin:/bin:/usr/sbin:/usr/bin"' ! .endif ! CFLAGS+= -Dwarn=dhcp_warn DPADD= ${LIBDHCP} ${LIBRES} ${LIBOMAPI} ${LIBDST} LDADD= ${LIBDHCP} ${LIBRES} ${LIBOMAPI} ${LIBDST} Index: sbin/fsck/fsck.c =================================================================== RCS file: /mnt/cvs/src/sbin/fsck/fsck.c,v retrieving revision 1.12 diff -c -r1.12 fsck.c *** sbin/fsck/fsck.c 31 Oct 2002 15:32:39 -0000 1.12 --- sbin/fsck/fsck.c 7 Jan 2003 05:43:26 -0000 *************** *** 283,288 **** --- 283,291 ---- { /* List of directories containing fsck_xxx subcommands. */ static const char *edirs[] = { + #ifdef RESCUE + _PATH_RESCUE, /* /rescue/fsck tries /rescue first */ + #endif _PATH_SBIN, _PATH_USRSBIN, NULL Index: sbin/fsck/pathnames.h =================================================================== RCS file: /mnt/cvs/src/sbin/fsck/pathnames.h,v retrieving revision 1.1 diff -c -r1.1 pathnames.h *** sbin/fsck/pathnames.h 9 Oct 2000 10:23:08 -0000 1.1 --- sbin/fsck/pathnames.h 10 Dec 2002 05:43:11 -0000 *************** *** 31,35 **** --- 31,36 ---- * $FreeBSD: src/sbin/fsck/pathnames.h,v 1.1 2000/10/09 10:23:08 adrian Exp $ */ + #define _PATH_RESCUE "/rescue" #define _PATH_SBIN "/sbin" #define _PATH_USRSBIN "/usr/sbin" Index: sbin/mdmfs/pathnames.h =================================================================== RCS file: /mnt/cvs/src/sbin/mdmfs/pathnames.h,v retrieving revision 1.2 diff -c -r1.2 pathnames.h *** sbin/mdmfs/pathnames.h 22 Sep 2002 09:46:28 -0000 1.2 --- sbin/mdmfs/pathnames.h 9 Jan 2003 04:20:16 -0000 *************** *** 2,9 **** --- 2,16 ---- #ifndef MDMFS_PATHNAMES_H #define MDMFS_PATHNAMES_H + /* Shouldn't all of these be moved into /usr/include/paths.h?? */ + #ifndef RESCUE #define PATH_MDCONFIG "/sbin/mdconfig" #define PATH_NEWFS "/sbin/newfs" #define PATH_MOUNT "/sbin/mount" + #else + #define PATH_MDCONFIG "/rescue/mdconfig" + #define PATH_NEWFS "/rescue/newfs" + #define PATH_MOUNT "/rescue/mount" + #endif #endif /* !MDMFS_PATHNAMES_H */ Index: sbin/mount/mount.c =================================================================== RCS file: /mnt/cvs/src/sbin/mount/mount.c,v retrieving revision 1.50 diff -c -r1.50 mount.c *** sbin/mount/mount.c 14 Oct 2002 19:40:00 -0000 1.50 --- sbin/mount/mount.c 7 Jan 2003 05:44:01 -0000 *************** *** 391,396 **** --- 391,399 ---- { /* List of directories containing mount_xxx subcommands. */ static const char *edirs[] = { + #ifdef RESCUE + _PATH_RESCUE, /* /rescue/mount tries /rescue first */ + #endif _PATH_SBIN, _PATH_USRSBIN, NULL Index: sbin/mount/pathnames.h =================================================================== RCS file: /mnt/cvs/src/sbin/mount/pathnames.h,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 pathnames.h *** sbin/mount/pathnames.h 26 May 1994 06:34:21 -0000 1.1.1.1 --- sbin/mount/pathnames.h 10 Dec 2002 05:34:02 -0000 *************** *** 33,38 **** --- 33,39 ---- * @(#)pathnames.h 8.2 (Berkeley) 3/27/94 */ + #define _PATH_RESCUE "/rescue" #define _PATH_SBIN "/sbin" #define _PATH_USRSBIN "/usr/sbin" #define _PATH_MOUNTDPID "/var/run/mountd.pid" Index: sbin/shutdown/pathnames.h =================================================================== RCS file: /mnt/cvs/src/sbin/shutdown/pathnames.h,v retrieving revision 1.2 diff -c -r1.2 pathnames.h *** sbin/shutdown/pathnames.h 17 May 2002 11:47:12 -0000 1.2 --- sbin/shutdown/pathnames.h 9 Jan 2003 04:21:08 -0000 *************** *** 36,41 **** #include ! #define _PATH_FASTBOOT "/fastboot" #define _PATH_HALT "/sbin/halt" #define _PATH_REBOOT "/sbin/reboot" --- 36,49 ---- #include ! /* No longer used? */ ! /* #define _PATH_FASTBOOT "/fastboot" */ ! ! /* Shouldn't these be moved into /usr/include/paths.h?? */ ! #ifndef RESCUE #define _PATH_HALT "/sbin/halt" #define _PATH_REBOOT "/sbin/reboot" + #else + #define _PATH_HALT "/rescue/halt" + #define _PATH_REBOOT "/rescue/reboot" + #endif Index: sbin/startslip/startslip.c =================================================================== RCS file: /mnt/cvs/src/sbin/startslip/startslip.c,v retrieving revision 1.34 diff -c -r1.34 startslip.c *** sbin/startslip/startslip.c 21 Mar 2002 13:20:48 -0000 1.34 --- sbin/startslip/startslip.c 1 Jan 2003 22:04:30 -0000 *************** *** 256,262 **** username, (long)conn_time); sprintf(buf, "LINE=%d %s %s down", diali ? (dialc - 1) % diali : 0, ! downscript ? downscript : "/sbin/ifconfig" , unitname); (void) system(buf); logged_in = 0; } --- 256,262 ---- username, (long)conn_time); sprintf(buf, "LINE=%d %s %s down", diali ? (dialc - 1) % diali : 0, ! downscript ? downscript : _PATH_IFCONFIG , unitname); (void) system(buf); logged_in = 0; } *************** *** 458,464 **** sprintf(buf, "LINE=%d %s %s up", diali ? (dialc - 1) % diali : 0, ! upscript ? upscript : "/sbin/ifconfig" , unitname); (void) system(buf); printd(", ready\n"); --- 458,464 ---- sprintf(buf, "LINE=%d %s %s up", diali ? (dialc - 1) % diali : 0, ! upscript ? upscript : _PATH_IFCONFIG , unitname); (void) system(buf); printd(", ready\n"); Index: sbin/vinum/commands.c =================================================================== RCS file: /mnt/cvs/src/sbin/vinum/commands.c,v retrieving revision 1.44 diff -c -r1.44 commands.c *** sbin/vinum/commands.c 16 Jan 2003 23:49:34 -0000 1.44 --- sbin/vinum/commands.c 24 Jan 2003 06:07:50 -0000 *************** *** 83,89 **** editor = getenv("EDITOR"); if (editor == NULL) ! editor = "/usr/bin/vi"; sprintf(tempfile, "/var/tmp/" VINUMMOD ".create.%d", getpid()); /* create a temp file */ tf = fopen(tempfile, "w"); /* open it */ if (tf == NULL) { --- 83,89 ---- editor = getenv("EDITOR"); if (editor == NULL) ! editor = _PATH_VI; sprintf(tempfile, "/var/tmp/" VINUMMOD ".create.%d", getpid()); /* create a temp file */ tf = fopen(tempfile, "w"); /* open it */ if (tf == NULL) { Index: share/mk/bsd.lib.mk =================================================================== RCS file: /mnt/cvs/src/share/mk/bsd.lib.mk,v retrieving revision 1.138 diff -c -r1.138 bsd.lib.mk *** share/mk/bsd.lib.mk 20 Sep 2002 19:32:51 -0000 1.138 --- share/mk/bsd.lib.mk 7 Jan 2003 02:01:16 -0000 *************** *** 21,26 **** --- 21,28 ---- SONAME?= ${SHLIB_NAME} .endif + CFLAGS+= ${CRUNCH_CFLAGS} + .if defined(DEBUG_FLAGS) CFLAGS+= ${DEBUG_FLAGS} .endif Index: share/mk/bsd.prog.mk =================================================================== RCS file: /mnt/cvs/src/share/mk/bsd.prog.mk,v retrieving revision 1.129 diff -c -r1.129 bsd.prog.mk *** share/mk/bsd.prog.mk 17 Oct 2002 13:48:13 -0000 1.129 --- share/mk/bsd.prog.mk 7 Jan 2003 02:01:20 -0000 *************** *** 6,11 **** --- 6,12 ---- .SUFFIXES: .out .o .c .cc .cpp .cxx .C .m .y .l .ln .s .S .asm CFLAGS+=${COPTS} ${DEBUG_FLAGS} + CFLAGS+= ${CRUNCH_CFLAGS} .if !defined(DEBUG_FLAGS) STRIP?= -s Index: usr.bin/vi/pathnames.h =================================================================== RCS file: /mnt/cvs/src/usr.bin/vi/pathnames.h,v retrieving revision 1.2 diff -c -r1.2 pathnames.h *** usr.bin/vi/pathnames.h 4 Nov 1996 02:28:31 -0000 1.2 --- usr.bin/vi/pathnames.h 22 Nov 2002 21:50:47 -0000 *************** *** 1,5 **** --- 1,8 ---- /* @(#)pathnames.h.in 8.4 (Berkeley) 6/26/96 */ + /* Read standard system paths first */ + #include + #ifndef _PATH_BSHELL #define _PATH_BSHELL "/bin/sh" #endif Index: usr.sbin/crunch/crunchgen/crunchgen.c =================================================================== RCS file: /mnt/cvs/src/usr.sbin/crunch/crunchgen/crunchgen.c,v retrieving revision 1.31 diff -c -r1.31 crunchgen.c *** usr.sbin/crunch/crunchgen/crunchgen.c 30 Mar 2002 16:48:30 -0000 1.31 --- usr.sbin/crunch/crunchgen/crunchgen.c 20 Nov 2002 04:07:07 -0000 *************** *** 691,705 **** fprintf(f, ".endif\n"); fprintf(f, "loop:\n\t@echo 'OBJS= '${%s}\n", objvar); ! fprintf(f, "crunchgen_objs:\n\t@make -f %s $(BUILDOPTS) $(%s_OPTS)", ! tempfname, p->ident); for (s = p->buildopts; s != NULL; s = s->next) fprintf(f, " %s", s->str); fprintf(f, " loop\n"); fclose(f); ! snprintf(line, MAXLINELEN, "make -f %s crunchgen_objs 2>&1", tempfname); if ((f = popen(line, "r")) == NULL) { warn("submake pipe"); goterror = 1; --- 691,708 ---- fprintf(f, ".endif\n"); fprintf(f, "loop:\n\t@echo 'OBJS= '${%s}\n", objvar); ! fprintf(f, "crunchgen_objs:\n\t@cd %s && make -f %s $(BUILDOPTS) $(%s_OPTS)", ! p->srcdir, tempfname, p->ident); for (s = p->buildopts; s != NULL; s = s->next) fprintf(f, " %s", s->str); fprintf(f, " loop\n"); fclose(f); ! snprintf(line, MAXLINELEN, "cd %s && make -f %s crunchgen_objs 2>&1", ! p->srcdir, ! tempfname); ! if ((f = popen(line, "r")) == NULL) { warn("submake pipe"); goterror = 1; *** /dev/null Thu Jan 23 22:33:00 2003 --- rescue/README Thu Jan 2 21:44:29 2003 *************** *** 0 **** --- 1,42 ---- + The /rescue build system here has three goals: + + 1) Produce a reliable standalone set of /rescue tools. + + The contents of /rescue are all statically linked and do not depend on + anything in /bin or /sbin. In particular, they'll continue to + function even if you've hosed your dynamic /bin and /sbin. For + example, note that /rescue/mount runs /rescue/mount_nfs and not + /sbin/mount_nfs. This is more subtle than it looks. + + As an added bonus, /rescue is fairly small (thanks to crunchgen) and + includes a number of tools (such as gzip, bzip2, vi) that are not + normally found in /bin and /sbin. + + 2) Demonstrate robust use of crunchgen. + + These Makefiles recompile each of the crunchgen components and include + support for overriding specific library entries. Such techniques + should be useful elsewhere. For example, boot floppies could use this + to conditionally compile out features to reduce executable size. + + 3) Produce a toolkit suitable for small distributions. + + Install /rescue on a CD or CompactFlash disk, and symlink /bin and + /sbin to /rescue to produce a small and fairly complete FreeBSD + system. + + These tools have one big disadvantage: being statically linked, they + cannot use some advanced library functions that rely on dynamic + linking. In particular, nsswitch, locales, and pam are likely to all + rely on dynamic linking in the near future. + + + To compile: + + # cd /usr/src/rescue + # make obj + # make + # make install + + Note that rebuilds don't always work correctly; if you run into + trouble, try 'make clean' before recompiling. *** /dev/null Thu Jan 23 22:33:00 2003 --- rescue/Makefile Wed Jan 8 18:41:52 2003 *************** *** 0 **** --- 1,3 ---- + SUBDIR=librescue rescue + + .include *** /dev/null Thu Jan 23 22:33:00 2003 --- rescue/librescue/Makefile Thu Jan 23 21:48:13 2003 *************** *** 0 **** --- 1,36 ---- + # + # $FreeBSD: src/rescue/librescue/Makefile,v Exp $ + # + + # Certain library entries have hard-coded references to + # /bin, /sbin, etc, that require those entries to be + # recompiled for use in /rescue. This Makefile + # accomplishes that. Note that this is pure build hackery. + # This library should never be installed, and isn't even linked + # with in the normal way. (See ../rescue/Makefile for details.) + + LIB= rescue + NOPROFILE= yes # Don't generate profile version + INTERNALLIB= yes # Don't install this library + + CFLAGS+= -DRESCUE + # Flags copied from src/lib/libc and src/lib/libutil + CFLAGS+= -I${.CURDIR}/../../lib/libc/include + CFLAGS+= -I${.CURDIR}/../../include + CFLAGS+= -D__DBINTERFACE_PRIVATE + CFLAGS+= -DINET6 + CFLAGS+= -I${.OBJDIR}/../../lib/libc + CFLAGS+= -DPOSIX_MISTAKE + CFLAGS+= -I${.CURDIR}/../../lib/libc/locale + CFLAGS+= -DBROKEN_DES + CFLAGS+= -DPORTMAP + CFLAGS+= -DDES_BUILTIN + CFLAGS+= -DYP + CFLAGS+= -DHESIOD + CFLAGS+= -Wall -Wwrite-strings -Wpointer-arith + + .PATH: ${.CURDIR}/../../lib/libc/gen ${.CURDIR}/../../lib/libutil ${.CURDIR}/../../lib/libc/net ${.CURDIR}/../../lib/libc/stdlib + + SRCS = exec.c getusershell.c login_class.c popen.c rcmdsh.c sysctl.c system.c + + .include *** /dev/null Thu Jan 23 22:33:00 2003 --- rescue/rescue/Makefile Wed Jan 8 20:25:05 2003 *************** *** 0 **** --- 1,259 ---- + # $FreeBSD: src/rescue/Makefile Exp $ + # @(#)Makefile 8.1 (Berkeley) 6/2/93 + + PROG= rescue + BINDIR?= /rescue + + # Uncomment to exclude tcsh + #NO_TCSH=1 + + # Shell scripts need #! line to be edited from /bin/sh to /rescue/sh + SCRIPTS= nextboot_FIXED + SCRIPTSNAME_nextboot_FIXED= nextboot.sh + nextboot_FIXED: ../../sbin/reboot/nextboot.sh + sed '1s/\/bin\//\/rescue\//' ${.ALLSRC} > ${.TARGET} + CLEANFILES+= nextboot_FIXED + + SCRIPTS+= dhclient_FIXED + SCRIPTSNAME_dhclient_FIXED= dhclient-script + dhclient_FIXED: ../../contrib/isc-dhcp/client/scripts/freebsd + sed '1s/\/bin\//\/rescue\//' ${.ALLSRC} > ${.TARGET} + CLEANFILES+= dhclient_FIXED + + ################################################################# + # + # General notes: + # + # A number of Make variables are used to generate the crunchgen config file. + # + # CRUNCH_SRCDIRS: lists directories to search for included programs + # CRUNCH_PROGS: lists programs to be included + # CRUNCH_LIBS: libraries to link with + # CRUNCH_BUILDOPTS: generic build options to be added to every program + # + # Special options can be specified for individual programs + # CRUNCH_SRCDIR_$(P): base source directory for program $(P) + # CRUNCH_BUILDOPTS_$(P): additional build options for $(P) + # CRUNCH_ALIAS_$(P): additional names to be used for $(P) + # + # By default, any name appearing in CRUNCH_PROGS or CRUNCH_ALIAS_${P} + # will be used to generate a hard link to the resulting binary. + # Specific links can be suppressed by setting + # CRUNCH_SUPPRESS_LINK_$(NAME) to 1. + # + + # Define Makefile variable RESCUE + CRUNCH_BUILDOPTS+= -DRESCUE + # Define compile-time RESCUE symbol when compiling components + CRUNCH_BUILDOPTS+= CRUNCH_CFLAGS=-DRESCUE + + # Hackery: 'librescue' exists merely as a tool for appropriately + # recompiling specific library entries. We _know_ they're needed, and + # regular archive searching creates ugly library ordering problems. + # Easiest fix: tell the linker to include them into the executable + # first, so they are guaranteed to override the regular lib entries. + # Note that if 'librescue' hasn't been compiled, we'll just get the + # regular lib entries from libc and friends. + CRUNCH_LIBS+= ${.OBJDIR}/../librescue/*.o + + ################################################################### + # Programs from stock /bin + # + # WARNING: Changing this list may require adjusting + # /usr/include/paths.h as well! You were warned! + # + CRUNCH_SRCDIRS+=$(.CURDIR)/../../bin $(.CURDIR)/../../usr.bin + CRUNCH_PROGS=cat chflags chio chmod cp date dd df domainname echo ed \ + expr getfacl hostname kenv kill ln ls mkdir mv pax ps pwd \ + realpath rm rmdir setfacl sh sleep stty sync test + CRUNCH_LIBS+=-lcrypt -ledit -lkvm -ll -lm -ltermcap -lutil + + # Additional options for specific programs + CRUNCH_ALIAS_test= [ + CRUNCH_ALIAS_sh= -sh + # The -sh alias shouldn't appear in /rescue as a hard link + CRUNCH_SUPPRESS_LINK_-sh=1 + CRUNCH_ALIAS_ln= link + CRUNCH_ALIAS_rm= unlink + CRUNCH_ALIAS_ed= red + + .if !defined(NO_RCMNDS) + CRUNCH_PROGS+= rcp + .endif + + .if !defined(NO_TCSH) + CRUNCH_PROGS+= csh + CRUNCH_ALIAS_csh= -csh tcsh -tcsh + CRUNCH_SUPPRESS_LINK_-csh=1 + CRUNCH_SUPPRESS_LINK_-tcsh=1 + .endif + + #Is rmail of any use at all here? I think not. + #CRUNCH_PROGS+= rmail + + ################################################################### + # Programs from standard /sbin + # + # WARNING: Changing this list may require adjusting + # /usr/include/paths.h as well! You were warned! + # + # Note that mdmfs and shutdown have their own private 'pathnames.h' + # headers in addition to the standard 'paths.h' header. + # + CRUNCH_SRCDIRS+=$(.CURDIR)/../../sbin + CRUNCH_PROGS+=atm adjkerntz atacontrol badsect camcontrol ccdconfig \ + clri comcontrol conscontrol devfs disklabel dmesg dump \ + dumpfs dumpon fdisk fore_dnld fsck fsck_ffs fsck_msdosfs fsdb \ + fsirand gbde growfs ifconfig ilmid init ip6fw ipf ipfs ipfstat \ + ipfw ipmon ipnat kldconfig kldload kldstat kldunload ldconfig \ + md5 mdconfig mdmfs mknod mount mount_cd9660 mount_ext2fs \ + mount_msdosfs mount_nfs mount_ntfs mount_nullfs mount_portalfs \ + mount_std mount_udf mount_umapfs mount_unionfs natd newfs \ + newfs_msdos nfsiod nos-tun ping ping6 quotacheck raidctl reboot \ + restore rcorder route routed rtquery rtsol savecore shutdown \ + slattach spppcontrol startslip swapon sysctl tunefs umount vinum + + # crunchgen does not like C++ programs; this should be fixed someday + # CRUNCH_PROGS+= devd + + CRUNCH_LIBS+=-lalias -latm -lcam -lcurses -ldevstat -lipsec -lipx -lmd \ + -lncp -lreadline -lsbuf -lsmb -lufs -lz + + .if ${MACHINE_ARCH} == "i386" + CRUNCH_PROGS+= cxconfig mount_nwfs mount_smbfs + .endif + + .if ${MACHINE} == "pc98" + CRUNCH_PROGS+= fdisk_pc98 + .endif + + .if ${MACHINE_ARCH} == "ia64" + CRUNCH_PROGS+= mca gpt + .endif + + .if ${MACHINE_ARCH} == "sparc" + .endif + + .if ${MACHINE_ARCH} == "alpha" + .endif + + CRUNCH_SRCDIR_atm=$(.CURDIR)/../../sbin/atm/atm + CRUNCH_SRCDIR_fore_dnld=$(.CURDIR)/../../sbin/atm/fore_dnld + CRUNCH_SRCDIR_ilmid=$(.CURDIR)/../../sbin/atm/ilmid + CRUNCH_SRCDIR_rtquery=$(.CURDIR)/../../sbin/routed/rtquery + CRUNCH_ALIAS_reboot= fastboot halt fasthalt + CRUNCH_ALIAS_restore=rrestore + CRUNCH_ALIAS_dump= rdump + CRUNCH_ALIAS_fsck_ffs=fsck_4.2bsd fsck_ufs + CRUNCH_ALIAS_mount_std= mount_devfs mount_fdescfs mount_linprocfs mount_procfs + + # dhclient has historically been troublesome... + CRUNCH_PROGS+=dhclient + CRUNCH_BUILDOPTS_dhclient=-DRELEASE_CRUNCH -Dlint + + ################################################################## + # Programs from stock /usr/bin + # + CRUNCH_SRCDIRS+=$(.CURDIR)/../../usr.bin + CRUNCH_SRCDIRS+=$(.CURDIR)/../../gnu/usr.bin + + CRUNCH_PROGS+=wall + + CRUNCH_PROGS+=gzip + CRUNCH_ALIAS_gzip=gunzip gzcat zcat + + CRUNCH_PROGS+=bzip2 + CRUNCH_ALIAS_bzip2=bunzip2 bzcat + CRUNCH_LIBS+=-lbz2 + + CRUNCH_PROGS+=tar + CRUNCH_PROGS+=vi + CRUNCH_ALIAS_vi=ex + + ################################################################## + # The following is pretty nearly a generic crunchgen-handling makefile + # + + CONF= $(PROG).conf + OUTMK= $(PROG).mk + OUTC= $(PROG).c + OUTPUTS= $(OUTMK) $(OUTC) $(PROG).cache + CRUNCHOBJS= ${.OBJDIR} + .if defined(MAKEOBJDIRPREFIX) + CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR} + .else + CANONICALOBJDIR:=/usr/obj${.CURDIR} + .endif + + NOMAN= true + CLEANFILES+= $(CONF) *.o *.lo *.c *.mk *.cache *.a *.h + + # Program names and their aliases contribute hardlinks to 'rescue' executable, + # except for those that get suppressed. + .for P in $(CRUNCH_PROGS) + .ifndef CRUNCH_SUPPRESS_LINK_${P} + LINKS += $(BINDIR)/$(PROG) $(BINDIR)/$(P) + .endif + .for A in $(CRUNCH_ALIAS_$(P)) + .ifndef CRUNCH_SUPPRESS_LINK_${A} + LINKS += $(BINDIR)/$(PROG) $(BINDIR)/$(A) + .endif + .endfor + .endfor + + all: $(PROG) + exe: $(PROG) + + $(CONF): Makefile + echo \# Auto-generated, do not edit >$(.TARGET) + .for D in $(CRUNCH_SRCDIRS) + echo srcdirs $(D) >>$(.TARGET) + .endfor + .ifdef CRUNCH_BUILDOPTS + echo buildopts $(CRUNCH_BUILDOPTS) >>$(.TARGET) + .endif + .ifdef CRUNCH_BUILDOPTS + echo libs $(CRUNCH_LIBS) >>$(.TARGET) + .endif + .for P in $(CRUNCH_PROGS) + echo progs $(P) >>$(.TARGET) + .ifdef CRUNCH_SRCDIR_${P} + echo special $(P) srcdir $(CRUNCH_SRCDIR_${P}) >>$(.TARGET) + .endif + .ifdef CRUNCH_BUILDOPTS_${P} + echo special $(P) buildopts $(CRUNCH_BUILDOPTS_${P}) >>$(.TARGET) + .endif + .for A in $(CRUNCH_ALIAS_$(P)) + echo ln $(P) $(A) >>$(.TARGET) + .endfor + .endfor + + + $(OUTPUTS): $(CONF) + MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) $(CONF) + + $(PROG): $(OUTPUTS) + MAKEOBJDIRPREFIX=${CRUNCHOBJS} make -f $(OUTMK) + + objs: + MAKEOBJDIRPREFIX=${CRUNCHOBJS} make -f $(OUTMK) objs + + # Use a separate build tree to hold files compiled for this crunchgen binary + # Yes, this does seem to partly duplicate bsd.subdir.mk, but I can't + # get that to cooperate with bsd.prog.mk. Besides, many of the standard + # targets should NOT be propagated into the components. + cleandepend cleandir obj objlink: + .for D in $(CRUNCH_SRCDIRS) + cd ${D} && MAKEOBJDIRPREFIX=${CANONICALOBJDIR} make ${.TARGET} + .endfor + + clean: + if [ -e ${.OBJDIR}/$(OUTMK) ]; then \ + MAKEOBJDIRPREFIX=${CRUNCHOBJS} make -f $(OUTMK) clean; \ + fi + .for D in $(CRUNCH_SRCDIRS) $(EXTRA_SRCDIRS) + cd ${D} && MAKEOBJDIRPREFIX=${CRUNCHOBJS} make clean + .endfor + rm -f ${CLEANFILES} + + .include --------------030407000308050805040706-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ----Next_Part(Thu_May__8_09:42:06_2003_428)---- From owner-freebsd-arch@FreeBSD.ORG Thu May 8 09:12:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ACBE37B401; Thu, 8 May 2003 09:12:26 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E5FC43FA3; Thu, 8 May 2003 09:12:25 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id 499E01B212; Thu, 8 May 2003 17:12:24 +0100 (BST) Date: Thu, 8 May 2003 17:12:24 +0100 From: Paul Richards To: "Jacques A. Vidrine" , David O'Brien , freebsd-arch@FreeBSD.org Message-ID: <20030508161223.GL1869@survey.codeburst.net> References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030506175557.GE79167@madman.celabo.org> User-Agent: Mutt/1.4.1i Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 16:12:26 -0000 On Tue, May 06, 2003 at 12:55:57PM -0500, Jacques A. Vidrine wrote: > On Tue, May 06, 2003 at 10:09:19AM -0700, David O'Brien wrote: > > On Mon, May 05, 2003 at 12:54:28PM -0500, Jacques A. Vidrine wrote: > > > > > I'm backing out the commit in good faith and in the hopes that the > > > > > big picture comes more clearly into focus. > > > > > > > > Thanks. > > > > > > Do you also want to `fix' the other ports that define their own strlcpy? > > > > Ports have maintainers. Please create a PR for them. > > But gee, the problem is that the ports themselves are not really > in error, unless one is a standards fascist that believes that an > application can never define any function that might be in some > standard's namespace. Any C code that isn't written according to the standard that defines C is broken. There's just no argument to be made that FreeBSD should be hacked to support C code that is written by programmers who haven't bothered to learn the rules of C properly. That's not to say there aren't a lot of crap programmers out there who don't know what they're doing but FreeBSD should not be bending over backwards to make their code work, we should just leave it be broken. In the case you've cited throughout this thread, where libc calls into an application's implementation of a reserved symbol, this breaks nothing except the application, which was where the real bug existed. The only benefit that your solution offers is that broken code *may* work better. The downside, is people who really know what they're doing and deliberately want to override a standard function need to jump through extra hoops that they won't even be aware of. My opinion is that FreeBSD should cater to the people who know their stuff and let the crap programmers out their be shown the bugs that exist in their code when they try to use it on FreeBSD. I want FreeBSD to be the environment where I can develop my code with a high degree of confidence that I'm doing things right and for FreeBSD to show up the problems if I'm doing it wrong. I don't want to find that FreeBSD was hiding my own inadequacies from me :-) In that light, if I implement a broken strlcpy and my application falls over in a heap because libc calls it then I should have learnt an important lesson about how to write C correctly. If FreeBSD hides/protects me from this sort of mistake in my coding then I don't think it's upholding and encouraging a high standard of coding. -- Paul Richards From owner-freebsd-arch@FreeBSD.ORG Thu May 8 09:30:19 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8524637B404; Thu, 8 May 2003 09:30:06 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7F6343F93; Thu, 8 May 2003 09:30:05 -0700 (PDT) (envelope-from archie@dellroad.org) 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 JAA58753; Thu, 8 May 2003 09:17:38 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h48GHcNU008634; Thu, 8 May 2003 09:17:38 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h48GHcZT008633; Thu, 8 May 2003 09:17:38 -0700 (PDT) From: Archie Cobbs Message-Id: <200305081617.h48GHcZT008633@arch20m.dellroad.org> In-Reply-To: <20030508161223.GL1869@survey.codeburst.net> To: Paul Richards Date: Thu, 8 May 2003 09:17:38 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: "Jacques A. Vidrine" cc: David O'Brien cc: freebsd-arch@FreeBSD.ORG Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 16:30:20 -0000 Paul Richards wrote: > > But gee, the problem is that the ports themselves are not really > > in error, unless one is a standards fascist that believes that an > > application can never define any function that might be in some > > standard's namespace. > > Any C code that isn't written according to the standard that defines > C is broken. > > There's just no argument to be made that FreeBSD should be hacked > to support C code that is written by programmers who haven't bothered > to learn the rules of C properly. Agreed... and even if you *do* believe FreeBSD should accomodate such broken applications, the place to put the hack is in the port, not in the base system. -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-arch@FreeBSD.ORG Thu May 8 09:56:42 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB08537B401 for ; Thu, 8 May 2003 09:56:42 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39DF543F85 for ; Thu, 8 May 2003 09:56:42 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h48GuUm2055305 for ; Thu, 8 May 2003 09:56:35 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h48GuUvr055304 for arch@freebsd.org; Thu, 8 May 2003 09:56:30 -0700 (PDT) Date: Thu, 8 May 2003 09:56:30 -0700 From: "David O'Brien" To: arch@freebsd.org Message-ID: <20030508165630.GA55207@dragon.nuxi.com> Mail-Followup-To: David O'Brien References: <20030508.094206.68986125.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030508.094206.68986125.imp@bsdimp.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 16:56:43 -0000 On Thu, May 08, 2003 at 09:42:06AM -0600, M. Warner Losh wrote: > Yep, .PATH does simplify things. Revised diff > attached. Thanks for the suggestion. It was mostly decided to use /stand rather than /rescue as sticking with FreeBSD's 10 year precidence is better than going with NetBSD's <1 yr one. It was also felt this patch puts way too much into /stand -- like vi (rather than edit) and dhclient for instance. /stand should be just enough to recover a system by a *skilled* person. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu May 8 09:58:46 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 619BB37B401 for ; Thu, 8 May 2003 09:58:46 -0700 (PDT) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71F9643F3F for ; Thu, 8 May 2003 09:58:45 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch02.lj.gnf.org [172.25.10.20]) by ns1.gnf.org (8.12.6p2/8.12.3) with ESMTP id h48GwiZu098909 for ; Thu, 8 May 2003 09:58:44 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 May 2003 09:58:45 -0700 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.9/8.12.9) with ESMTP id h48GwiSY098032; Thu, 8 May 2003 09:58:44 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.9/8.12.9/Submit) id h48GwioD098031; Thu, 8 May 2003 09:58:44 -0700 (PDT) (envelope-from gtetlow) Date: Thu, 8 May 2003 09:58:44 -0700 From: Gordon Tetlow To: "M. Warner Losh" Message-ID: <20030508165844.GO76376@roark.gnf.org> References: <20030508.093911.48456930.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aTCJOP0qgkSGqHWA" Content-Disposition: inline In-Reply-To: <20030508.093911.48456930.imp@bsdimp.com> User-Agent: Mutt/1.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-OriginalArrivalTime: 08 May 2003 16:58:45.0223 (UTC) FILETIME=[161A5770:01C31583] cc: arch@freebsd.org Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 16:58:46 -0000 --aTCJOP0qgkSGqHWA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 08, 2003 at 09:39:11AM -0600, M. Warner Losh wrote: >=20 > Tim posted this a while ago to hackers@. It looked like it was > further along than what's been posted here. Actually, Tim's and my work are complimentary. I hadn't worked on getting a /rescue, /stand, /ohcrap directory. Personally, I agree with David O'Brien that it should be called /stand since we have precedence (and documentation in hier(7)) for that. -gordon --aTCJOP0qgkSGqHWA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+uozERu2t9DV9ZfsRAk8oAJ4u+2DZmMhDRW2qdst/GyYvcDlLnQCgry9k QT6plMxdr2ZodiTDWT316Xo= =q+UK -----END PGP SIGNATURE----- --aTCJOP0qgkSGqHWA-- From owner-freebsd-arch@FreeBSD.ORG Thu May 8 10:09:28 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B15537B401 for ; Thu, 8 May 2003 10:09:28 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E2AF43F75 for ; Thu, 8 May 2003 10:09:27 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h48H9QTl020616; Thu, 8 May 2003 11:09:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 08 May 2003 11:08:58 -0600 (MDT) Message-Id: <20030508.110858.91024289.imp@bsdimp.com> To: gordont@gnf.org From: "M. Warner Losh" In-Reply-To: <20030508165844.GO76376@roark.gnf.org> References: <20030508.093911.48456930.imp@bsdimp.com> <20030508165844.GO76376@roark.gnf.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 17:09:28 -0000 In message: <20030508165844.GO76376@roark.gnf.org> Gordon Tetlow writes: : On Thu, May 08, 2003 at 09:39:11AM -0600, M. Warner Losh wrote: : > : > Tim posted this a while ago to hackers@. It looked like it was : > further along than what's been posted here. : : Actually, Tim's and my work are complimentary. I hadn't worked on : getting a /rescue, /stand, /ohcrap directory. Personally, I agree : with David O'Brien that it should be called /stand since we have : precedence (and documentation in hier(7)) for that. NetBSD put them in /rescue. /stand has been phased out over the past few years. There's precident many ways. Can we please not argue of stupid shit like this? That's why we get into these damn bikesheds. Warner From owner-freebsd-arch@FreeBSD.ORG Thu May 8 10:17:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E041137B401 for ; Thu, 8 May 2003 10:17:26 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 238C943FB1 for ; Thu, 8 May 2003 10:17:26 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h48HHPTl020707 for ; Thu, 8 May 2003 11:17:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200305081717.h48HHPTl020707@harmony.village.org> To: arch@freebsd.org In-reply-to: Your message of "Thu, 08 May 2003 09:56:30 PDT." <20030508165630.GA55207@dragon.nuxi.com> References: <20030508165630.GA55207@dragon.nuxi.com> <20030508.094206.68986125.imp@bsdimp.com> Date: Thu, 08 May 2003 11:17:25 -0600 From: Warner Losh Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 17:17:27 -0000 In message <20030508165630.GA55207@dragon.nuxi.com> "David O'Brien" writes: : On Thu, May 08, 2003 at 09:42:06AM -0600, M. Warner Losh wrote: : > Yep, .PATH does simplify things. Revised diff : > attached. Thanks for the suggestion. : : It was mostly decided to use /stand rather than /rescue as sticking with : FreeBSD's 10 year precidence is better than going with NetBSD's <1 yr : one. We've been phasing out /stand for a long time. What is in there now on 5.x? Nothing. I killed /stand before my last installworld because it hasn't been updated since I did the initial install on my system. There's no reason to keep it around, and it is needlessly different than NetBSD. : It was also felt this patch puts way too much into /stand -- like vi : (rather than edit) and dhclient for instance. /stand should be just : enough to recover a system by a *skilled* person. I disagree. I think it keeps a good amount of stuff in there. Sure, I can do an echo * rather than an ls, but the binary is so small and disk space so cheap it makes no sense to have to force it so that only uber-studs can use it. I think we should have all the binaries in /sbin or /bin, but with an appended -rescue. Can we please not get into the bikesheds over this? Warner From owner-freebsd-arch@FreeBSD.ORG Thu May 8 10:20:42 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2C6937B401; Thu, 8 May 2003 10:20:42 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E739343F85; Thu, 8 May 2003 10:20:41 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h48HKTBg004818; Thu, 8 May 2003 13:20:29 -0400 (EDT) Received: from localhost (eischen@localhost)h48HKS7Q004814; Thu, 8 May 2003 13:20:28 -0400 (EDT) Date: Thu, 8 May 2003 13:20:28 -0400 (EDT) From: Daniel Eischen To: Archie Cobbs In-Reply-To: <200305081617.h48GHcZT008633@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Jacques A. Vidrine" cc: freebsd-arch@freebsd.org Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 17:20:43 -0000 On Thu, 8 May 2003, Archie Cobbs wrote: > Paul Richards wrote: > > > But gee, the problem is that the ports themselves are not really > > > in error, unless one is a standards fascist that believes that an > > > application can never define any function that might be in some > > > standard's namespace. > > > > Any C code that isn't written according to the standard that defines > > C is broken. > > > > There's just no argument to be made that FreeBSD should be hacked > > to support C code that is written by programmers who haven't bothered > > to learn the rules of C properly. > > Agreed... and even if you *do* believe FreeBSD should accomodate > such broken applications, the place to put the hack is in the port, > not in the base system. I don't see it as a hack; I see it as cleaning up our library and removing loose ends. We are a vendor and we should provide a libc that is internally consistent regardless of what an application does (to the extent that we can). We already have weak symbols in libc, all the syscalls are that way, plus some others. Someone makes strlcpy and strlcat weak symbols, something that NetBSD already does, and we have an endless thread on it??? (Sorry to add to it). If applications really want to override our use of standard functions within libc, then they can still do that. And there are very few ports that really need to do this. It's not rocket science trying to figure out what the actual symbols are -- nm will most likely give you what you want. At any rate, can we please put this thread to rest until Jacques comes back from vacation? It doesn't make sense arguing about it when the main proponent of it is not here. -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Thu May 8 10:23:27 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB5B637B401 for ; Thu, 8 May 2003 10:23:27 -0700 (PDT) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id E16CD43FA3 for ; Thu, 8 May 2003 10:23:26 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch02.lj.gnf.org [172.25.10.20]) by ns1.gnf.org (8.12.6p2/8.12.3) with ESMTP id h48HNPZu099251 for ; Thu, 8 May 2003 10:23:25 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 May 2003 10:23:26 -0700 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.9/8.12.9) with ESMTP id h48HNQSY098467; Thu, 8 May 2003 10:23:26 -0700 (PDT) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.9/8.12.9/Submit) id h48HNQXW098466; Thu, 8 May 2003 10:23:26 -0700 (PDT) (envelope-from gtetlow) Date: Thu, 8 May 2003 10:23:26 -0700 From: Gordon Tetlow To: "M. Warner Losh" Message-ID: <20030508172326.GP76376@roark.gnf.org> References: <20030508.093911.48456930.imp@bsdimp.com> <20030508165844.GO76376@roark.gnf.org> <20030508.110858.91024289.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zfao1/4IORAeFOVj" Content-Disposition: inline In-Reply-To: <20030508.110858.91024289.imp@bsdimp.com> User-Agent: Mutt/1.4i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-OriginalArrivalTime: 08 May 2003 17:23:26.0492 (UTC) FILETIME=[89020DC0:01C31586] cc: arch@freebsd.org Subject: Re: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 17:23:28 -0000 --Zfao1/4IORAeFOVj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 08, 2003 at 11:08:58AM -0600, M. Warner Losh wrote: > In message: <20030508165844.GO76376@roark.gnf.org> > Gordon Tetlow writes: > : On Thu, May 08, 2003 at 09:39:11AM -0600, M. Warner Losh wrote: > : >=20 > : > Tim posted this a while ago to hackers@. It looked like it was > : > further along than what's been posted here. > :=20 > : Actually, Tim's and my work are complimentary. I hadn't worked on > : getting a /rescue, /stand, /ohcrap directory. Personally, I agree > : with David O'Brien that it should be called /stand since we have > : precedence (and documentation in hier(7)) for that. >=20 > NetBSD put them in /rescue. /stand has been phased out over the past > few years. There's precident many ways. Can we please not argue of > stupid shit like this? That's why we get into these damn bikesheds. Bikeshed? I wouldn't call it a bikeshed yet, and let's not get to that point if we can avoid it. If we want a clean break, so be it. I don't particularly care one way or the other. I just expressed my preference. -gordon --Zfao1/4IORAeFOVj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+upKORu2t9DV9ZfsRAm9XAJ9WMxpcTTlhMCy/xE/fxH55XnkWegCeKVKg xihCEMfj4UYSyCYl3Ie+Sqo= =zGiZ -----END PGP SIGNATURE----- --Zfao1/4IORAeFOVj-- From owner-freebsd-arch@FreeBSD.ORG Thu May 8 10:25:58 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D10437B42C for ; Thu, 8 May 2003 10:25:58 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4865343FEC for ; Thu, 8 May 2003 10:25:55 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h48HPsTl020782; Thu, 8 May 2003 11:25:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 08 May 2003 11:25:26 -0600 (MDT) Message-Id: <20030508.112526.68226550.imp@bsdimp.com> To: gordont@gnf.org From: "M. Warner Losh" In-Reply-To: <20030508172326.GP76376@roark.gnf.org> References: <20030508165844.GO76376@roark.gnf.org> <20030508.110858.91024289.imp@bsdimp.com> <20030508172326.GP76376@roark.gnf.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 17:25:58 -0000 In message: <20030508172326.GP76376@roark.gnf.org> Gordon Tetlow writes: : On Thu, May 08, 2003 at 11:08:58AM -0600, M. Warner Losh wrote: : > In message: <20030508165844.GO76376@roark.gnf.org> : > Gordon Tetlow writes: : > : On Thu, May 08, 2003 at 09:39:11AM -0600, M. Warner Losh wrote: : > : > : > : > Tim posted this a while ago to hackers@. It looked like it was : > : > further along than what's been posted here. : > : : > : Actually, Tim's and my work are complimentary. I hadn't worked on : > : getting a /rescue, /stand, /ohcrap directory. Personally, I agree : > : with David O'Brien that it should be called /stand since we have : > : precedence (and documentation in hier(7)) for that. : > : > NetBSD put them in /rescue. /stand has been phased out over the past : > few years. There's precident many ways. Can we please not argue of : > stupid shit like this? That's why we get into these damn bikesheds. : : Bikeshed? I wouldn't call it a bikeshed yet, and let's not get to that : point if we can avoid it. If we want a clean break, so be it. I don't : particularly care one way or the other. I just expressed my preference. I guess the recent name hiding thread has gotten my bikeshed trigger on 'hair' no. Warner From owner-freebsd-arch@FreeBSD.ORG Thu May 8 10:29:12 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6C3337B401 for ; Thu, 8 May 2003 10:29:12 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A9F643F75 for ; Thu, 8 May 2003 10:29:11 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9/8.12.9) with ESMTP id h48HT8O9099178; Thu, 8 May 2003 19:29:08 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9/8.12.9/Submit) id h48HT8cN099177; Thu, 8 May 2003 19:29:08 +0200 (CEST) Date: Thu, 8 May 2003 19:29:08 +0200 From: Wilko Bulte To: "M. Warner Losh" Message-ID: <20030508172907.GB99104@freebie.xs4all.nl> References: <20030508165844.GO76376@roark.gnf.org> <20030508.110858.91024289.imp@bsdimp.com> <20030508172326.GP76376@roark.gnf.org> <20030508.112526.68226550.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030508.112526.68226550.imp@bsdimp.com> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.8-STABLE X-PGP: finger wilko@freebsd.org cc: arch@FreeBSD.ORG Subject: Re: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 17:29:13 -0000 On Thu, May 08, 2003 at 11:25:26AM -0600, M. Warner Losh wrote: > In message: <20030508172326.GP76376@roark.gnf.org> > Gordon Tetlow writes: > : On Thu, May 08, 2003 at 11:08:58AM -0600, M. Warner Losh wrote: > : > In message: <20030508165844.GO76376@roark.gnf.org> > : > Gordon Tetlow writes: > : > : On Thu, May 08, 2003 at 09:39:11AM -0600, M. Warner Losh wrote: > : > : > > : > : > Tim posted this a while ago to hackers@. It looked like it was > : > : > further along than what's been posted here. > : > : > : > : Actually, Tim's and my work are complimentary. I hadn't worked on > : > : getting a /rescue, /stand, /ohcrap directory. Personally, I agree > : > : with David O'Brien that it should be called /stand since we have > : > : precedence (and documentation in hier(7)) for that. > : > > : > NetBSD put them in /rescue. /stand has been phased out over the past > : > few years. There's precident many ways. Can we please not argue of > : > stupid shit like this? That's why we get into these damn bikesheds. > : > : Bikeshed? I wouldn't call it a bikeshed yet, and let's not get to that > : point if we can avoid it. If we want a clean break, so be it. I don't > : particularly care one way or the other. I just expressed my preference. > > I guess the recent name hiding thread has gotten my bikeshed trigger > on 'hair' no. Lets put everything in /bikeshed and be done with it. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-arch@FreeBSD.ORG Thu May 8 11:19:01 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D3DD37B401; Thu, 8 May 2003 11:19:01 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8876A43FF2; Thu, 8 May 2003 11:18:56 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h48IItTh026354; Thu, 8 May 2003 11:18:55 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305081818.h48IItTh026354@beastie.mckusick.com> To: Bruce Evans In-Reply-To: Your message of "Thu, 08 May 2003 18:28:33 +1000." <20030508175350.S59316@gamplex.bde.org> Date: Thu, 08 May 2003 11:18:55 -0700 From: Kirk McKusick cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 18:19:01 -0000 Thanks for your very through analysis of the options! Since most filesystems are not mounted with -async, I am curious how the numbers change when you run them normally (ufs with soft updates and NFS client/server just normally) since that is what folks are likely to really do. Also, does option 1 actually result in access times being set on NFS, or are the times rejected because the binaries are not owned by the user? Kirk McKusick =-=-=-=-=-= Date: Thu, 8 May 2003 18:28:33 +1000 (EST) From: Bruce Evans To: Kirk McKusick cc: Jens Schweikhardt , arch@FreeBSD.org, Brian Buhrow Subject: Re: Access times on executables (kern/25777) In-Reply-To: <20030505205914.D8183@gamplex.bde.org> X-ASK-Info: Whitelist match I'm replying to an earlier article in this thread since I lost your last reply. On Sun, 4 May 2003, Kirk McKusick wrote: > Still, I think that VOP_READ is likely to be more efficient and work in > a higher percentage of the times (always on the local filesystem and > most of the time on NFS). Thus, I enclose my (new) proposed change below. > Index: sys/kern_exec.c > =================================================================== > RCS file: /usr/ncvs/src/sys/kern/kern_exec.c,v > retrieving revision 1.218 > diff -c -r1.218 kern_exec.c > *** kern_exec.c 1 Apr 2003 01:26:20 -0000 1.218 > --- kern_exec.c 5 May 2003 06:15:21 -0000 > *************** > *** 598,603 **** > --- 598,626 ---- > exec_setregs(td, imgp->entry_addr, > (u_long)(uintptr_t)stack_base, imgp->ps_strings); > > + /* > + * At this point, it counts as an access. > + * Ensure that atime gets updated if needed. > + */ > + if (!(textvp->v_mount->mnt_flag & MNT_NOATIME)) { > + struct uio auio; > + struct iovec aiov; > + char ch; > + > + auio.uio_iov = &aiov; > + auio.uio_iovcnt = 1; > + aiov.iov_base = &ch; > + aiov.iov_len = 1; > + auio.uio_resid = 1; > + auio.uio_offset = 0; > + auio.uio_segflg = UIO_SYSSPACE; > + auio.uio_rw = UIO_READ; > + auio.uio_td = td; > + vn_lock(textvp, LK_EXCLUSIVE | LK_RETRY, td); > + (void) VOP_READ(textvp, &auio, 0, p->p_ucred); > + VOP_UNLOCK(textvp, 0, td); > + } > + > done1: > /* > * Free any resources malloc'd earlier that we didn't use. I ran some benchmarks after fixing some bugs in the above (textvp is stale (maybe NULL the first time?), and as jhb pointed out, p->p_ucred should be td->td_ucred). I benchmarked the following methods: - method 1: my original method using VOP_SETATTR() updated - method 2: fixed version of above - method 3: version of the above that just calls vn_rdwr(). %%% Index: kern_exec.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.208 diff -u -2 -r1.208 kern_exec.c --- kern_exec.c 13 Jan 2003 23:04:31 -0000 1.208 +++ kern_exec.c 8 May 2003 07:11:05 -0000 @@ -1,2 +1,4 @@ +int exec_atime_method = -1; + /* * Copyright (c) 1993, David Greenman @@ -611,4 +599,49 @@ (u_long)(uintptr_t)stack_base, imgp->ps_strings); + /* + * At this point, it counts as an access. + * Ensure that atime gets updated if needed. + */ + if (!(ndp->ni_vp->v_mount->mnt_flag & MNT_NOATIME)) { + if (exec_atime_method == 1) { + struct vattr vattr; + struct mount *mp; + + if (vn_start_write(ndp->ni_vp, &mp, V_WAIT | PCATCH) != 0) + goto out; + VATTR_NULL(&vattr); + vfs_timestamp(&vattr.va_atime); + vattr.va_vaflags |= VA_EXECVE_ATIME; + VOP_LEASE(ndp->ni_vp, td, td->td_ucred, LEASE_WRITE); + vn_lock(ndp->ni_vp, LK_EXCLUSIVE | LK_RETRY, td); + (void) VOP_SETATTR(ndp->ni_vp, &vattr, td->td_ucred, td); + VOP_UNLOCK(ndp->ni_vp, 0, td); + vn_finished_write(mp); +out: ; + } else if (exec_atime_method == 2) { + struct iovec aiov; + struct uio auio; + char ch; + + auio.uio_iov = &aiov; + auio.uio_iovcnt = 1; + aiov.iov_base = &ch; + aiov.iov_len = 1; + auio.uio_resid = 1; + auio.uio_offset = 0; + auio.uio_segflg = UIO_SYSSPACE; + auio.uio_rw = UIO_READ; + auio.uio_td = td; + vn_lock(ndp->ni_vp, LK_EXCLUSIVE | LK_RETRY, td); + (void) VOP_READ(ndp->ni_vp, &auio, 0, p->p_ucred); + VOP_UNLOCK(ndp->ni_vp, 0, td); + } else if (exec_atime_method == 3) { + char ch; + + (void) vn_rdwr(UIO_READ, ndp->ni_vp, &ch, 1, 0, UIO_SYSSPACE, + 0, td->td_ucred, td->td_ucred, NULL, td); + } + } + done1: /* %%% The VOP_READ() methods had much more overhead than I expected or like (about 25% for a tiny statically linked program (`main() {}'). Even the VOP_SETATTR() method was faster. Raw output: %%% ufs-static-noexec 4.32 real 0.04 user 4.13 sys 4.23 real 0.07 user 4.01 sys 4.30 real 0.06 user 4.10 sys ufs-static-static method -1 7.02 real 0.06 user 6.77 sys 7.10 real 0.07 user 6.83 sys 7.09 real 0.06 user 6.83 sys 7.03 real 0.19 user 6.65 sys 7.11 real 0.22 user 6.68 sys 7.00 real 0.04 user 6.77 sys 7.12 real 0.19 user 6.75 sys 7.07 real 0.22 user 6.66 sys 7.07 real 0.07 user 6.81 sys method 1 7.72 real 0.23 user 7.29 sys 7.76 real 0.25 user 7.31 sys 7.71 real 0.30 user 7.21 sys 7.69 real 0.29 user 7.21 sys 7.70 real 0.31 user 7.18 sys 7.71 real 0.19 user 7.32 sys method 2 7.83 real 0.07 user 7.56 sys 7.84 real 0.27 user 7.37 sys 7.82 real 0.28 user 7.34 sys method 3 7.90 real 0.26 user 7.43 sys 7.89 real 0.05 user 7.62 sys 7.92 real 0.05 user 7.66 sys 7.86 real 0.05 user 7.61 sys 7.88 real 0.18 user 7.49 sys 7.84 real 0.21 user 7.43 sys 7.88 real 0.31 user 7.36 sys 7.82 real 0.28 user 7.34 sys 7.86 real 0.24 user 7.42 sys nfs-static-noexec 4.13 real 0.05 user 3.95 sys 4.20 real 0.17 user 3.89 sys 4.25 real 0.25 user 3.87 sys nfs-static-static method -1 11.43 real 0.04 user 9.18 sys 11.41 real 0.21 user 8.96 sys 11.43 real 0.27 user 8.94 sys method 1 11.54 real 0.28 user 8.88 sys 11.64 real 0.19 user 9.08 sys 11.53 real 0.17 user 8.97 sys method 2 11.77 real 0.09 user 9.49 sys 11.78 real 0.25 user 9.31 sys 11.80 real 0.33 user 9.26 sys method 3 11.94 real 0.24 user 9.46 sys 11.86 real 0.32 user 9.35 sys 11.81 real 0.28 user 9.35 sys %%% *fs-static-noexec tests 10000 forks with no exec of a statically linked program on *fs. *fs-static-static tests 10000 forks with exec of statically linked programs on *fs. The system is an old Celeron (the speed doesn't matter much; only compare the relative times). All file systems were mounted -async. The exec part of the fork-exec takes an average of about 270 usec for the ufs case. Setting the atime adds about 60 usec to this for method 1. Method 2 adds another 10 usec. Method 3 adds another 4 usec to method 2. Plain read() takes much less than 60 usec on this machine: $ dd if=/kernel of=/dev/null bs=1 count=1000000 1000000+0 records in 1000000+0 records out 1000000 bytes transferred in 17.703695 secs (56485 bytes/sec) so most of the overheads for exec must be indirect. I think they are just close() forcing update marks to timestamps. This happens after every exec, but not after every read in the dd benchmark. I think method 1 turns out to be fastest since it forces the update marks to timestamps directly. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu May 8 11:36:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ADE637B401 for ; Thu, 8 May 2003 11:36:35 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C70C643FAF for ; Thu, 8 May 2003 11:36:34 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h48IaDm2056299; Thu, 8 May 2003 11:36:17 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h48IaC75056298; Thu, 8 May 2003 11:36:12 -0700 (PDT) Date: Thu, 8 May 2003 11:36:12 -0700 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20030508183612.GA56264@dragon.nuxi.com> Mail-Followup-To: David O'Brien , "M. Warner Losh" References: <20030508.093911.48456930.imp@bsdimp.com> <20030508165844.GO76376@roark.gnf.org> <20030508.110858.91024289.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030508.110858.91024289.imp@bsdimp.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: arch@freebsd.org Subject: Re: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 18:36:35 -0000 On Thu, May 08, 2003 at 11:08:58AM -0600, M. Warner Losh wrote: > : On Thu, May 08, 2003 at 09:39:11AM -0600, M. Warner Losh wrote: > : > > : > Tim posted this a while ago to hackers@. It looked like it was > : > further along than what's been posted here. > : > : Actually, Tim's and my work are complimentary. I hadn't worked on > : getting a /rescue, /stand, /ohcrap directory. Personally, I agree > : with David O'Brien that it should be called /stand since we have > : precedence (and documentation in hier(7)) for that. > > NetBSD put them in /rescue. /stand has been phased out over the past > few years. There's precident many ways. How has it been phased out?? My 5.0-RELEASE install certainly has a /stand with the contents of: sh arp camcontrol cpio dhclient find fsck_ffs hostname ifconfig minigzip mount_nfs newfs ppp pwd rm route rtsol sed slattach test tunefs usbd usbdevs zcat I've used /stand several times to recover from bad events. I would call it phased out or useless. The fact that we don't update it during 'make world' no one has felt the need until now. From owner-freebsd-arch@FreeBSD.ORG Thu May 8 11:42:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F329437B401 for ; Thu, 8 May 2003 11:42:02 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5100243F75 for ; Thu, 8 May 2003 11:42:02 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h48Iflm2056930; Thu, 8 May 2003 11:41:47 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h48IflnV056929; Thu, 8 May 2003 11:41:47 -0700 (PDT) Date: Thu, 8 May 2003 11:41:47 -0700 From: "David O'Brien" To: Warner Losh Message-ID: <20030508184147.GA56336@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Warner Losh References: <20030508165630.GA55207@dragon.nuxi.com> <20030508.094206.68986125.imp@bsdimp.com> <200305081717.h48HHPTl020707@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305081717.h48HHPTl020707@harmony.village.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: arch@freebsd.org Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 18:42:03 -0000 On Thu, May 08, 2003 at 11:17:25AM -0600, Warner Losh wrote: > : It was also felt this patch puts way too much into /stand -- like vi > : (rather than edit) and dhclient for instance. /stand should be just > : enough to recover a system by a *skilled* person. > > I disagree. I think it keeps a good amount of stuff in there. Sure, > I can do an echo * rather than an ls, but the binary is so small and You're going to an extreme -- I didn't mention ls, I mentioned nvi (about 1MB static). > disk space so cheap it makes no sense to have to force it so that only Don't forget we aren't talking about the size of the *entire* disk, the size of / is the issue (especially for source upgrades from 4.x) . Maybe I should change sysinstall to use a 2GB / and have it include /usr -- that certainly makes things easier for a dynamic /. From owner-freebsd-arch@FreeBSD.ORG Thu May 8 11:45:21 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D3FE37B401 for ; Thu, 8 May 2003 11:45:21 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5867F43F3F for ; Thu, 8 May 2003 11:45:20 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h48IjJTl021250 for ; Thu, 8 May 2003 12:45:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 08 May 2003 12:44:51 -0600 (MDT) Message-Id: <20030508.124451.109704557.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" In-Reply-To: <20030508183612.GA56264@dragon.nuxi.com> References: <20030508165844.GO76376@roark.gnf.org> <20030508.110858.91024289.imp@bsdimp.com> <20030508183612.GA56264@dragon.nuxi.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 18:45:21 -0000 In message: <20030508183612.GA56264@dragon.nuxi.com> "David O'Brien" writes: : On Thu, May 08, 2003 at 11:08:58AM -0600, M. Warner Losh wrote: : > : On Thu, May 08, 2003 at 09:39:11AM -0600, M. Warner Losh wrote: : > : > : > : > Tim posted this a while ago to hackers@. It looked like it was : > : > further along than what's been posted here. : > : : > : Actually, Tim's and my work are complimentary. I hadn't worked on : > : getting a /rescue, /stand, /ohcrap directory. Personally, I agree : > : with David O'Brien that it should be called /stand since we have : > : precedence (and documentation in hier(7)) for that. : > : > NetBSD put them in /rescue. /stand has been phased out over the past : > few years. There's precident many ways. : : How has it been phased out?? My 5.0-RELEASE install certainly has a : /stand with the contents of: /stand never is updated after the initial install, so it slowly rots away :-( Warner From owner-freebsd-arch@FreeBSD.ORG Thu May 8 13:15:46 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C68FD37B401 for ; Thu, 8 May 2003 13:15:46 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33B9143F75 for ; Thu, 8 May 2003 13:15:46 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19361 invoked from network); 8 May 2003 20:15:52 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 8 May 2003 20:15:52 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h48KFTp0009590 for ; Thu, 8 May 2003 16:15:32 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030508165630.GA55207@dragon.nuxi.com> Date: Thu, 08 May 2003 16:15:32 -0400 (EDT) From: John Baldwin To: "David O'Brien" Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 20:15:47 -0000 On 08-May-2003 David O'Brien wrote: > On Thu, May 08, 2003 at 09:42:06AM -0600, M. Warner Losh wrote: >> Yep, .PATH does simplify things. Revised diff >> attached. Thanks for the suggestion. > > It was mostly decided to use /stand rather than /rescue as sticking with > FreeBSD's 10 year precidence is better than going with NetBSD's <1 yr > one. Nah. /stand is what we can fit into a mfsroot on a floppy. There are probably several other useful things that can be added if you remove that size constraint. Also, /stand historically has never been updated by world. /rescuse would be kept up to date. These are really two different things. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu May 8 14:30:22 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D1B337B401; Thu, 8 May 2003 14:30:22 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AE6543F93; Thu, 8 May 2003 14:30:21 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 6DC3B530E; Thu, 8 May 2003 23:30:19 +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: Paul Richards References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> From: Dag-Erling Smorgrav Date: Thu, 08 May 2003 23:30:18 +0200 In-Reply-To: <20030508161223.GL1869@survey.codeburst.net> (Paul Richards's message of "Thu, 8 May 2003 17:12:24 +0100") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: "Jacques A. Vidrine" cc: David O'Brien cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 21:30:22 -0000 Paul Richards writes: > Any C code that isn't written according to the standard that defines > C is broken. That includes most of the FreeBSD source tree. > There's just no argument to be made that FreeBSD should be hacked > to support C code that is written by programmers who haven't bothered > to learn the rules of C properly. > [...] > My opinion is that FreeBSD should cater to the people who know their > stuff and let the crap programmers out their be shown the bugs that > exist in their code when they try to use it on FreeBSD. Now I know why people accuse us of elitism... Let's please not favor pedantry over robustness. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Thu May 8 15:38:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA69737B401; Thu, 8 May 2003 15:38:33 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0215143F3F; Thu, 8 May 2003 15:38:33 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: from [192.168.7.2] (freebsd.gotadsl.co.uk [81.6.249.198]) by mx0.freebsd-services.com (Postfix) with ESMTP id 971AD1B211; Thu, 8 May 2003 23:38:31 +0100 (BST) From: Paul Richards To: Dag-Erling Smorgrav In-Reply-To: References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> Content-Type: text/plain Organization: FreeBSD Services Ltd Message-Id: <1052433233.619.27.camel@cf.freebsd-services.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 08 May 2003 23:33:54 +0100 Content-Transfer-Encoding: 7bit cc: "Jacques A. Vidrine" cc: David O'Brien cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 22:38:34 -0000 On Thu, 2003-05-08 at 22:30, Dag-Erling Smorgrav wrote: > Paul Richards writes: > > Any C code that isn't written according to the standard that defines > > C is broken. > > That includes most of the FreeBSD source tree. To some extent true, but we don't deliberately break the rules or flagrantly disregard them. It's more a case of the code having a long lineage and things having changed, or deliberately breaking the rules but being fully aware of the reason for doing so (we're not pedants, good programming practices result in solid code, but if there's a good reason for breaking the rules and you know what you're doing it's sometimes appropriate to do so). > > There's just no argument to be made that FreeBSD should be hacked > > to support C code that is written by programmers who haven't bothered > > to learn the rules of C properly. > > [...] > > My opinion is that FreeBSD should cater to the people who know their > > stuff and let the crap programmers out their be shown the bugs that > > exist in their code when they try to use it on FreeBSD. > > Now I know why people accuse us of elitism... > > Let's please not favor pedantry over robustness. This isn't elitism. A professor or teacher is not elitist when they correct the mistakes of less experienced pupils. FreeBSD should highlight bad habits so people can see that they are making mistakes and improve their skills. A poor teacher is one who ignores the bad habits developing in their pupils, and I'd like FreeBSD to foster a community where good programming skills are developed. -- Paul Richards FreeBSD Services Ltd From owner-freebsd-arch@FreeBSD.ORG Thu May 8 15:44:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B56A737B401; Thu, 8 May 2003 15:44:03 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F78843F93; Thu, 8 May 2003 15:44:03 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: from [192.168.7.2] (freebsd.gotadsl.co.uk [81.6.249.198]) by mx0.freebsd-services.com (Postfix) with ESMTP id 3F8D81B211; Thu, 8 May 2003 23:44:02 +0100 (BST) From: Paul Richards To: John Baldwin In-Reply-To: References: Content-Type: text/plain Organization: FreeBSD Services Ltd Message-Id: <1052433564.619.32.camel@cf.freebsd-services.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 08 May 2003 23:39:24 +0100 Content-Transfer-Encoding: 7bit cc: David O'Brien Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 22:44:04 -0000 On Thu, 2003-05-08 at 21:15, John Baldwin wrote: > On 08-May-2003 David O'Brien wrote: > > On Thu, May 08, 2003 at 09:42:06AM -0600, M. Warner Losh wrote: > >> Yep, .PATH does simplify things. Revised diff > >> attached. Thanks for the suggestion. > > > > It was mostly decided to use /stand rather than /rescue as sticking with > > FreeBSD's 10 year precidence is better than going with NetBSD's <1 yr > > one. > > Nah. /stand is what we can fit into a mfsroot on a floppy. There > are probably several other useful things that can be added if you > remove that size constraint. Also, /stand historically has never > been updated by world. /rescuse would be kept up to date. These > are really two different things. Well, there's an argument for making /stand (or /rescue) small enough to still fit on a floppy because it then represents the minimal set of tools that are available to restore a hosed box, one where perhaps /stand is also hosed and you need to recover from your minimal recovery floppy. If people get used to nvi being available as a recovery tool then they'll never learn the skills necessary to recover from severe system failures. I think we're beginning to dumb down the expected skill levels a bit too much. -- Paul Richards FreeBSD Services Ltd From owner-freebsd-arch@FreeBSD.ORG Thu May 8 15:57:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48B5337B401; Thu, 8 May 2003 15:57:02 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C436743F75; Thu, 8 May 2003 15:57:01 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h48MuhQg016990; Thu, 8 May 2003 15:56:43 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h48MuhGj016989; Thu, 8 May 2003 15:56:43 -0700 (PDT) (envelope-from rizzo) Date: Thu, 8 May 2003 15:56:43 -0700 From: Luigi Rizzo To: Paul Richards Message-ID: <20030508155643.A16895@xorpc.icir.org> References: <1052433564.619.32.camel@cf.freebsd-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1052433564.619.32.camel@cf.freebsd-services.com>; from paul@freebsd-services.com on Thu, May 08, 2003 at 11:39:24PM +0100 cc: David O'Brien Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 22:57:02 -0000 On Thu, May 08, 2003 at 11:39:24PM +0100, Paul Richards wrote: ... > If people get used to nvi being available as a recovery tool then > they'll never learn the skills necessary to recover from severe system > failures. I think we're beginning to dumb down the expected skill levels > a bit too much. oh come on... an editor is just a convenience thing, plus there is a reasonable (though limited) emulation of vi in the "e3" editor (in ports/editors/e3) which is some 25k (yes twentyfive) statically linked. cheers luigi From owner-freebsd-arch@FreeBSD.ORG Thu May 8 16:21:55 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B46FB37B401; Thu, 8 May 2003 16:21:55 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9E443F93; Thu, 8 May 2003 16:21:52 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: from [192.168.7.2] (freebsd.gotadsl.co.uk [81.6.249.198]) by mx0.freebsd-services.com (Postfix) with ESMTP id 7FA9A1B211; Fri, 9 May 2003 00:21:51 +0100 (BST) From: Paul Richards To: Luigi Rizzo In-Reply-To: <20030508155643.A16895@xorpc.icir.org> References: <1052433564.619.32.camel@cf.freebsd-services.com> <20030508155643.A16895@xorpc.icir.org> Content-Type: text/plain Organization: FreeBSD Services Ltd Message-Id: <1052435833.619.49.camel@cf.freebsd-services.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 09 May 2003 00:17:14 +0100 Content-Transfer-Encoding: 7bit cc: David O'Brien Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 23:21:56 -0000 On Thu, 2003-05-08 at 23:56, Luigi Rizzo wrote: > On Thu, May 08, 2003 at 11:39:24PM +0100, Paul Richards wrote: > ... > > If people get used to nvi being available as a recovery tool then > > they'll never learn the skills necessary to recover from severe system > > failures. I think we're beginning to dumb down the expected skill levels > > a bit too much. > > oh come on... an editor is just a convenience thing, plus there is > a reasonable (though limited) emulation of vi in the "e3" editor > (in ports/editors/e3) which is some 25k (yes twentyfive) statically > linked. Well, at least when I went through college, which granted is a while ago now, learning ed was a basic skill required as part of the Unix course. You're only going to need to do this sort of recovery in exceptional circumstances, a luxury like vi is not a *required* tool. If you don't know ed then you're not going to be any use at all on some of the commercial systems so I still think it's a basic skill all sysadmins will/should have. As has already been pointed out, not all FreeBSD boxes have big root partitions, it would be bad if future releases didn't work on existing installations without reformatting the disk, or even upgrading it. I have a live system that only has a 256M root partition, and that's only as far back as the 4.3 era, with earlier versions I only had 64M root partitions. I upped my / size for new systems when /boot arrived. If a screen oriented editor fits then great, but a fixit floppy will still be an essential tool in the future and so minimising the recovery toolset so it fits on a floppy would, I think, be a good idea. -- Paul Richards FreeBSD Services Ltd From owner-freebsd-arch@FreeBSD.ORG Thu May 8 16:34:36 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8BD337B401; Thu, 8 May 2003 16:34:36 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3087743F3F; Thu, 8 May 2003 16:34:35 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h48NYWwk018028; Thu, 8 May 2003 16:34:32 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h48NYW5t001517; Thu, 8 May 2003 16:34:32 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h48NYWWf001516; Thu, 8 May 2003 16:34:32 -0700 (PDT) Date: Thu, 8 May 2003 16:34:31 -0700 From: Marcel Moolenaar To: Paul Richards Message-ID: <20030508233431.GA1461@athlon.pn.xcllnt.net> References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> <1052433233.619.27.camel@cf.freebsd-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1052433233.619.27.camel@cf.freebsd-services.com> User-Agent: Mutt/1.5.3i cc: "Jacques A. Vidrine" cc: David O'Brien cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 23:34:37 -0000 On Thu, May 08, 2003 at 11:33:54PM +0100, Paul Richards wrote: > > > [...] > > > My opinion is that FreeBSD should cater to the people who know their > > > stuff and let the crap programmers out their be shown the bugs that > > > exist in their code when they try to use it on FreeBSD. > > > > Now I know why people accuse us of elitism... > > > > Let's please not favor pedantry over robustness. > > This isn't elitism. A professor or teacher is not elitist when they > correct the mistakes of less experienced pupils. FreeBSD should > highlight bad habits so people can see that they are making mistakes and > improve their skills. The arrogance and elitism is in the presumption that 1) you can teach and 2) people want to be taught by you (the universal you). Never assume the role of teacher merely on the grounds that your believes make you think you're right and you arrogance has made you believe that people should know about it. Your desire to enlighten may be nothing more than a demonstration of blindness in the light of rejection. Teach only to people you want to be taught by you. /me being arrogant and blind, :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu May 8 17:47:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB23E37B401; Thu, 8 May 2003 17:47:13 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F8F043F3F; Thu, 8 May 2003 17:47:12 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: from [192.168.7.2] (freebsd.gotadsl.co.uk [81.6.249.198]) by mx0.freebsd-services.com (Postfix) with ESMTP id E89B11B211; Fri, 9 May 2003 01:47:10 +0100 (BST) From: Paul Richards To: Marcel Moolenaar In-Reply-To: <20030508233431.GA1461@athlon.pn.xcllnt.net> References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> <1052433233.619.27.camel@cf.freebsd-services.com> <20030508233431.GA1461@athlon.pn.xcllnt.net> Content-Type: text/plain Organization: FreeBSD Services Ltd Message-Id: <1052440952.619.59.camel@cf.freebsd-services.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 09 May 2003 01:42:33 +0100 Content-Transfer-Encoding: 7bit cc: "Jacques A. Vidrine" cc: David O'Brien cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 00:47:17 -0000 On Fri, 2003-05-09 at 00:34, Marcel Moolenaar wrote: > On Thu, May 08, 2003 at 11:33:54PM +0100, Paul Richards wrote: > > > > [...] > > > > My opinion is that FreeBSD should cater to the people who know their > > > > stuff and let the crap programmers out their be shown the bugs that > > > > exist in their code when they try to use it on FreeBSD. > > > > > > Now I know why people accuse us of elitism... > > > > > > Let's please not favor pedantry over robustness. > > > > This isn't elitism. A professor or teacher is not elitist when they > > correct the mistakes of less experienced pupils. FreeBSD should > > highlight bad habits so people can see that they are making mistakes and > > improve their skills. > > The arrogance and elitism is in the presumption that 1) you can teach > and 2) people want to be taught by you (the universal you). Never assume > the role of teacher merely on the grounds that your believes make you > think you're right and you arrogance has made you believe that people > should know about it. Your desire to enlighten may be nothing more than > a demonstration of blindness in the light of rejection. > > Teach only to people you want to be taught by you. Well, perhaps FreeBSD should be elitist. If I wanted to be part of a crowd that wrote mediocre code and where I was unable to learn, through the experiences of others how to be a good programmer then I'd probably have chosed Linux 10 years ago and not FreeBSD :-) Eliticism can have both a positive and negative connotation. In the context I use it I mean it as a positive thing, where people who write good code uphold high standards and encourage less experienced people to grow in their ability. The negative connotation is one of exclusion. If we remain open to new developers and are patient in developing their code writing skils (or even more experienced people who have developed bad habits) then we're eliticist in the positive sense, just like an elite athlete can be a positive force in helping out less experienced athletes. To get this back in context, we're talking about a decision where a) FreeBSD gets hacked to accomodate bad programmers or b) we show up bad coding practices where they exist in third party ports. I'd much prefer to take the latter path and encourage quality code writing. If that makes us eliticist then I'm happy with that and as long as we don't exclude people who are willing to learn then that's not a bad approach for the project. -- Paul Richards FreeBSD Services Ltd From owner-freebsd-arch@FreeBSD.ORG Thu May 8 19:03:10 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01F4C37B401; Thu, 8 May 2003 19:03:10 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0FBC43F93; Thu, 8 May 2003 19:03:08 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h49232wk018770; Thu, 8 May 2003 19:03:02 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h49232qv006664; Thu, 8 May 2003 19:03:02 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h49232EG006660; Thu, 8 May 2003 19:03:02 -0700 (PDT) Date: Thu, 8 May 2003 19:03:01 -0700 From: Marcel Moolenaar To: Paul Richards Message-ID: <20030509020301.GA2323@athlon.pn.xcllnt.net> References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> <1052433233.619.27.camel@cf.freebsd-services.com> <20030508233431.GA1461@athlon.pn.xcllnt.net> <1052440952.619.59.camel@cf.freebsd-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1052440952.619.59.camel@cf.freebsd-services.com> User-Agent: Mutt/1.5.3i cc: "Jacques A. Vidrine" cc: David O'Brien cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 02:03:10 -0000 On Fri, May 09, 2003 at 01:42:33AM +0100, Paul Richards wrote: > > Eliticism can have both a positive and negative connotation. In the > context I use it I mean it as a positive thing, where people who write > good code uphold high standards and encourage less experienced people to > grow in their ability. Amendable. I'm all for it... > The negative connotation is one of exclusion. Precisely. The promotion of good practice is not elitism, except where it results in the automatic rejection of (what is perceived to be) bad practice. > To get this back in context, we're talking about a decision where a) > FreeBSD gets hacked to accomodate bad programmers or b) we show up bad > coding practices where they exist in third party ports. I'd much prefer > to take the latter path and encourage quality code writing. Encouragement by way of having the "bad" application fail in some way or another is not encouragement. It's enforcement. In this case there is not even good and bad. People have written applications that work (one way or the other). If we suddenly don't like what people did, then we cannot label them bad. We are just as guilty for allowing it to work in the first place. All we can do is come to some compromise as to what we think is the way to go and reimplement libc in a way that reflect the compromise, taking into account all possible scenarios. Whatever we do, we cannot do it 5.x for it's probably an ABI breakage. We better implement it in libc.so.6 so that we have a version bump to prevent FUBAR. Hence, we have at least until 5.x becomes -stable to figure out what we want to do. Which leaves us enough time to address the issue with the detail and care it deserves, rather than to scratch the surface and kludge something for inclusion in 5.1. > If that > makes us eliticist then I'm happy with that and as long as we don't > exclude people who are willing to learn then that's not a bad approach > for the project. To quote Hamlet: To exclude or being excluded. What's the difference?... :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu May 8 20:17:11 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84BB637B401 for ; Thu, 8 May 2003 20:17:11 -0700 (PDT) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDF1D43F75 for ; Thu, 8 May 2003 20:17:10 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id BB8D31C250; Thu, 8 May 2003 20:17:08 -0700 (PDT) From: Wes Peters Organization: Softweyr To: "Ilmar S. Habibulin" , freebsd-arch@freebsd.org Date: Thu, 8 May 2003 20:17:07 -0700 User-Agent: KMail/1.5 References: <20030507040750.H84964@fledge.watson.org> In-Reply-To: <20030507040750.H84964@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305082017.07999.wes@softweyr.com> Subject: Re: machine dependant functions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 03:17:11 -0000 On Wednesday 07 May 2003 01:10, Ilmar S. Habibulin wrote: > Is there any well described set of md kernel functions one should > implement in order to port kernel to new architecture? Or i should > brows through sys/ subdirs? The SPARC64 logs should be particularly informative, since they're recent as well as done fairly quickly. The amd64 port is so close to the i386 that it probably won't be as informative. The ia64 (unobtanium) port might be similarly helpful, but I haven't followed it that closely. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-arch@FreeBSD.ORG Thu May 8 23:32:21 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8F5E37B401 for ; Thu, 8 May 2003 23:32:21 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B6A043FCB for ; Thu, 8 May 2003 23:32:21 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h496WAm2016361 for ; Thu, 8 May 2003 23:32:14 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h496WA51016360; Thu, 8 May 2003 23:32:10 -0700 (PDT) Date: Thu, 8 May 2003 23:32:10 -0700 From: "David O'Brien" To: John Baldwin Message-ID: <20030509063210.GA16323@dragon.nuxi.com> Mail-Followup-To: David O'Brien , John Baldwin References: <20030508165630.GA55207@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: David O'Brien Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: arch@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 06:32:22 -0000 On Thu, May 08, 2003 at 04:15:32PM -0400, John Baldwin wrote: > Nah. /stand is what we can fit into a mfsroot on a floppy. There > are probably several other useful things that can be added if you > remove that size constraint. Also, /stand historically has never > been updated by world. /rescuse would be kept up to date. These > are really two different things. Why?? /stand is the static bits you start with. 'make world' is free to expand and update them. If not, then please have sysinstall rm -rf /stand. From owner-freebsd-arch@FreeBSD.ORG Thu May 8 23:34:25 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B1D537B401 for ; Thu, 8 May 2003 23:34:25 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D86A43F75 for ; Thu, 8 May 2003 23:34:24 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h496Y1m2016420; Thu, 8 May 2003 23:34:01 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h496Y0X8016419; Thu, 8 May 2003 23:34:00 -0700 (PDT) Date: Thu, 8 May 2003 23:34:00 -0700 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20030509063400.GB16323@dragon.nuxi.com> Mail-Followup-To: David O'Brien , "M. Warner Losh" References: <20030508165844.GO76376@roark.gnf.org> <20030508.110858.91024289.imp@bsdimp.com> <20030508183612.GA56264@dragon.nuxi.com> <20030508.124451.109704557.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030508.124451.109704557.imp@bsdimp.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: arch@freebsd.org Subject: Re: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 06:34:25 -0000 On Thu, May 08, 2003 at 12:44:51PM -0600, M. Warner Losh wrote: > : > : Actually, Tim's and my work are complimentary. I hadn't worked on > : > : getting a /rescue, /stand, /ohcrap directory. Personally, I agree > : > : with David O'Brien that it should be called /stand since we have > : > : precedence (and documentation in hier(7)) for that. > : > > : > NetBSD put them in /rescue. /stand has been phased out over the past > : > few years. There's precident many ways. > : > : How has it been phased out?? My 5.0-RELEASE install certainly has a > : /stand with the contents of: > > /stand never is updated after the initial install, so it slowly rots > away :-( and 'make world' can update it. Or will we have /resuce that is never updated by 'make world'? From owner-freebsd-arch@FreeBSD.ORG Thu May 8 23:42:25 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45FEF37B401 for ; Thu, 8 May 2003 23:42:25 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 424B943F3F for ; Thu, 8 May 2003 23:42:24 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h496gNTl025804 for ; Fri, 9 May 2003 00:42:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 09 May 2003 00:41:59 -0600 (MDT) Message-Id: <20030509.004159.108785388.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" In-Reply-To: <20030509063400.GB16323@dragon.nuxi.com> References: <20030508183612.GA56264@dragon.nuxi.com> <20030508.124451.109704557.imp@bsdimp.com> <20030509063400.GB16323@dragon.nuxi.com> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 06:42:25 -0000 In message: <20030509063400.GB16323@dragon.nuxi.com> "David O'Brien" writes: : On Thu, May 08, 2003 at 12:44:51PM -0600, M. Warner Losh wrote: : > : > : Actually, Tim's and my work are complimentary. I hadn't worked on : > : > : getting a /rescue, /stand, /ohcrap directory. Personally, I agree : > : > : with David O'Brien that it should be called /stand since we have : > : > : precedence (and documentation in hier(7)) for that. : > : > : > : > NetBSD put them in /rescue. /stand has been phased out over the past : > : > few years. There's precident many ways. : > : : > : How has it been phased out?? My 5.0-RELEASE install certainly has a : > : /stand with the contents of: : > : > /stand never is updated after the initial install, so it slowly rots : > away :-( : : and 'make world' can update it. Or will we have /resuce that is never : updated by 'make world'? /rescue would be updated every time. Warner From owner-freebsd-arch@FreeBSD.ORG Fri May 9 00:23:50 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 844AD37B401; Fri, 9 May 2003 00:23:50 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE6EF43FBD; Fri, 9 May 2003 00:23:48 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA27881; Fri, 9 May 2003 17:23:42 +1000 Date: Fri, 9 May 2003 17:23:41 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick In-Reply-To: <200305081818.h48IItTh026354@beastie.mckusick.com> Message-ID: <20030509162725.N80145@gamplex.bde.org> References: <200305081818.h48IItTh026354@beastie.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 07:23:50 -0000 On Thu, 8 May 2003, Kirk McKusick wrote: > Since most filesystems are not mounted with -async, I am curious > how the numbers change when you run them normally (ufs with soft > updates and NFS client/server just normally) since that is what > folks are likely to really do. I wasn't very careful about this because it shouldn't matter since timestamps are always written with delayed writes in at least the non-soft updates case. Soft updates is not normal for me so I didn't have any file systems configured with it. My nfs server file system was actually mounted -noasync. I thought that this didn't matter either since the nfs case was broken. However ... > Also, does option 1 actually result > in access times being set on NFS, or are the times rejected because > the binaries are not owned by the user? ... Yes; they were under my home directory and I owned them all. method 1 seems to work perfectly in this case. tcpdump shows a nfs setattr request and reply for every transaction. The ping times to the server is 230 usec (100 Mbps ethernet), but the overhead isn't anywhere near that much, at least for doing back to back execs of the same file, since there is some magic (buffering of coalescing of transactions?): for 10000 execs without atime updates, tcpdump shows 10000 access transactions and no setattr transactions; with atime updates, it shows 10000 setattr transactions and only 6 or 7 access transactions. > ... > Raw output: > > %%% > ufs-static-noexec > 4.32 real 0.04 user 4.13 sys > 4.23 real 0.07 user 4.01 sys > 4.30 real 0.06 user 4.10 sys > ufs-static-static > method -1 > 7.02 real 0.06 user 6.77 sys > 7.10 real 0.07 user 6.83 sys > 7.09 real 0.06 user 6.83 sys >... > method 1 > 7.72 real 0.23 user 7.29 sys > 7.76 real 0.25 user 7.31 sys > 7.71 real 0.30 user 7.21 sys >... > method 2 > 7.83 real 0.07 user 7.56 sys > 7.84 real 0.27 user 7.37 sys > 7.82 real 0.28 user 7.34 sys > method 3 > 7.90 real 0.26 user 7.43 sys > 7.89 real 0.05 user 7.62 sys > 7.92 real 0.05 user 7.66 sys >... Some more times with -noasync (but not soft updates). The configuration has changed a little with larger effects than I can explain, so I repeated some tests with -async too. %%% ufs-static-noexec 4.29 real 0.22 user 3.93 sys 4.26 real 0.23 user 3.88 sys 4.25 real 0.18 user 3.93 sys ufs-static-static method -1 7.74 real 0.11 user 7.41 sys 7.70 real 0.18 user 7.29 sys 7.69 real 0.08 user 7.39 sys method 1/async 8.38 real 0.29 user 7.85 sys 8.34 real 0.11 user 8.00 sys 8.38 real 0.10 user 8.04 sys method 1/noasync 8.32 real 0.29 user 7.80 sys 8.36 real 0.26 user 7.86 sys 8.37 real 0.32 user 7.80 sys method 2/async 8.45 real 0.36 user 7.85 sys 8.49 real 0.28 user 7.97 sys 8.44 real 0.29 user 7.91 sys method 2/noasync 8.51 real 0.19 user 8.07 sys 8.44 real 0.06 user 8.13 sys 8.47 real 0.08 user 8.15 sys method 3/async 8.52 real 0.30 user 7.98 sys 8.53 real 0.30 user 7.99 sys 8.51 real 0.28 user 7.98 sys method 3/noasync 8.43 real 0.27 user 7.92 sys 8.44 real 0.23 user 7.96 sys 8.49 real 0.08 user 8.16 sys %%% Bruce From owner-freebsd-arch@FreeBSD.ORG Fri May 9 02:27:56 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B46B37B401; Fri, 9 May 2003 02:27:56 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BE6043F3F; Fri, 9 May 2003 02:27:55 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 5B7F3530F; Fri, 9 May 2003 11:27:53 +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: Paul Richards References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> <1052433233.619.27.camel@cf.freebsd-services.com> From: Dag-Erling Smorgrav Date: Fri, 09 May 2003 11:27:52 +0200 In-Reply-To: <1052433233.619.27.camel@cf.freebsd-services.com> (Paul Richards's message of "08 May 2003 23:33:54 +0100") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: "Jacques A. Vidrine" cc: David O'Brien cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 09:27:56 -0000 Paul Richards writes: > On Thu, 2003-05-08 at 22:30, Dag-Erling Smorgrav wrote: > > Paul Richards writes: > > > Any C code that isn't written according to the standard that defines > > > C is broken. > > That includes most of the FreeBSD source tree. > To some extent true, but we don't deliberately break the rules or > flagrantly disregard them. Yes, we do, because there are things that can't be done (at least not easily) within the standard. Using the same struct iovec for readv(2) and writev(2) results in const warnings, yet using different structs, or union tricks to make the same pointer be both const and not const, would result in significantly (and probably unacceptably) increased complexity and fragility. > > Now I know why people accuse us of elitism... > > > > Let's please not favor pedantry over robustness. > This isn't elitism. A professor or teacher is not elitist when they > correct the mistakes of less experienced pupils. FreeBSD should > highlight bad habits so people can see that they are making mistakes and > improve their skills. Our role is not to be the professor or teacher of the open source world, but rather to be the research technician who builds the tools that professors use in their research and teaching. As such, we should be aware that the professor is not solely interested in academically correct tools but also in tools that get the work done a little faster and a little cheaper, even if that means cutting corners or making concessions, so he can publish that paper and get that grant. DES -- Dag-Erling Smorgrav - des@ofug.org From owner-freebsd-arch@FreeBSD.ORG Fri May 9 02:58:59 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA67C37B401; Fri, 9 May 2003 02:58:59 -0700 (PDT) Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C28243FE3; Fri, 9 May 2003 02:58:58 -0700 (PDT) (envelope-from ache@pobrecita.freebsd.ru) Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h499wt1Z019981; Fri, 9 May 2003 13:58:55 +0400 (MSD) (envelope-from ache@pobrecita.freebsd.ru) Received: (from ache@localhost) by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h499wtKK019980; Fri, 9 May 2003 13:58:55 +0400 (MSD) Date: Fri, 9 May 2003 13:58:54 +0400 From: "Andrey A. Chernov" To: Dag-Erling Smorgrav Message-ID: <20030509095854.GA19899@nagual.pp.ru> References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> <1052433233.619.27.camel@cf.freebsd-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: "Jacques A. Vidrine" cc: freebsd-arch@freebsd.org cc: David O'Brien Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 09:59:00 -0000 On Fri, May 09, 2003 at 11:27:52 +0200, Dag-Erling Smorgrav wrote: > Our role is not to be the professor or teacher of the open source > world, but rather to be the research technician who builds the tools > that professors use in their research and teaching. As such, we > should be aware that the professor is not solely interested in > academically correct tools but also in tools that get the work done a > little faster and a little cheaper, even if that means cutting corners > or making concessions, so he can publish that paper and get that > grant. Please don't say "our" when you mean yourself only. FreeBSD is large community with very different members. Speaking of me, for example, I never get any money working on FreeBSD (excepting one time small payment for early sysinstall), so my goal is to build ideal world in that area as much as it possible and convenient for me. From owner-freebsd-arch@FreeBSD.ORG Fri May 9 03:05:15 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19BF137B401; Fri, 9 May 2003 03:05:15 -0700 (PDT) Received: from mx0.freebsd-services.com (survey.codeburst.net [195.149.39.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F29D43FBF; Fri, 9 May 2003 03:05:14 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: by mx0.freebsd-services.com (Postfix, from userid 1002) id 42C1C1B211; Fri, 9 May 2003 11:05:13 +0100 (BST) Date: Fri, 9 May 2003 11:05:13 +0100 From: Paul Richards To: Dag-Erling Smorgrav Message-ID: <20030509100512.GM1869@survey.codeburst.net> References: <20030501182820.GA53641@madman.celabo.org> <20030503201409.GA41554@dragon.nuxi.com> <20030505175428.GA19275@madman.celabo.org> <20030506170919.GD36798@dragon.nuxi.com> <20030506175557.GE79167@madman.celabo.org> <20030508161223.GL1869@survey.codeburst.net> <1052433233.619.27.camel@cf.freebsd-services.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: "Jacques A. Vidrine" cc: David O'Brien cc: freebsd-arch@FreeBSD.org Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 10:05:15 -0000 On Fri, May 09, 2003 at 11:27:52AM +0200, Dag-Erling Smorgrav wrote: > > Our role is not to be the professor or teacher of the open source > world, but rather to be the research technician who builds the tools > that professors use in their research and teaching. As such, we > should be aware that the professor is not solely interested in > academically correct tools but also in tools that get the work done a > little faster and a little cheaper, even if that means cutting corners > or making concessions, so he can publish that paper and get that > grant. The academic research community is a lot more rigourous than that. At least it was when I was there, perhaps things have declined since I left. -- Paul Richards From owner-freebsd-arch@FreeBSD.ORG Fri May 9 08:43:12 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 120F937B401 for ; Fri, 9 May 2003 08:43:12 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 523D843F93 for ; Fri, 9 May 2003 08:43:09 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h49Fh5m2062308 for ; Fri, 9 May 2003 08:43:05 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h49Fh4e1062307 for freebsd-arch@freebsd.org; Fri, 9 May 2003 08:43:04 -0700 (PDT) Date: Fri, 9 May 2003 08:43:04 -0700 From: "David O'Brien" To: freebsd-arch@freebsd.org Message-ID: <20030509154304.GC61844@dragon.nuxi.com> References: <200305081617.h48GHcZT008633@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Re: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 15:43:12 -0000 On Thu, May 08, 2003 at 01:20:28PM -0400, Daniel Eischen wrote: > At any rate, can we please put this thread to rest until > Jacques comes back from vacation? It doesn't make sense > arguing about it when the main proponent of it is not > here. This thread doesn't make sense regardless of who is on vacation. Those of us opposed to this change have shown enough opposition that there will not be a consisenses on this issue. (at least not this go around) This thread should just die period. From owner-freebsd-arch@FreeBSD.ORG Fri May 9 10:32:21 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2380B37B401; Fri, 9 May 2003 10:32:21 -0700 (PDT) Received: from lothlorien.nfbcal.org (ns.NFBCAL.ORG [157.22.230.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 698CD43F75; Fri, 9 May 2003 10:32:20 -0700 (PDT) (envelope-from buhrow@lothlorien.nfbcal.org) Received: (from buhrow@localhost) by lothlorien.nfbcal.org (8.11.6p2/8.8.4.nfbcal.org) id h49HW9x11035; Fri, 9 May 2003 10:32:09 -0700 (PDT) Message-Id: <200305091732.h49HW9x11035@lothlorien.nfbcal.org> From: buhrow@lothlorien.nfbcal.org (Brian Buhrow) Date: Fri, 9 May 2003 10:32:09 -0700 In-Reply-To: Bruce Evans "Re: Access times on executables (kern/25777)" (May 9, 5:23pm) X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: Bruce Evans , Kirk McKusick cc: arch@FreeBSD.org cc: buhrow@lothlorien.nfbcal.org cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 17:32:21 -0000 I hope you forgive my naive question, but I fail to understand how the NFS case can fail under any circumstance. If a user tries to execute an nfs-mounted binary which is not readable by him, doesn't the system "read" the binary as the user root in order to execute the program, assuming the proper execute bit is set? And, once that is done, wouldn't the system continue to read (page) that file as root? If that doesn't work, then I would assume that the system would fail to execute the program at all and fail with a permission denied error. In other words, when a user executes a remote file which has execute permission set, but not read permission set, whose credentials does the system use to read the file? And, wouldn't those credentials work for the duration of the program's execution, assuming you're not running Kerberized NFS or AFS? -Brian From owner-freebsd-arch@FreeBSD.ORG Fri May 9 10:49:28 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48DED37B401 for ; Fri, 9 May 2003 10:49:27 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id A04AB43FA3 for ; Fri, 9 May 2003 10:49:25 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 911 invoked from network); 9 May 2003 17:49:31 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 9 May 2003 17:49:31 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h49HnJp0012597 for ; Fri, 9 May 2003 13:49:22 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030509063210.GA16323@dragon.nuxi.com> Date: Fri, 09 May 2003 13:49:21 -0400 (EDT) From: John Baldwin To: arch@FreeBSD.org Subject: Re: Fw: /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 17:49:29 -0000 On 09-May-2003 David O'Brien wrote: > On Thu, May 08, 2003 at 04:15:32PM -0400, John Baldwin wrote: >> Nah. /stand is what we can fit into a mfsroot on a floppy. There >> are probably several other useful things that can be added if you >> remove that size constraint. Also, /stand historically has never >> been updated by world. /rescuse would be kept up to date. These >> are really two different things. > > Why?? /stand is the static bits you start with. 'make world' is free to > expand and update them. make world doesn't even know it exists. /stand isn't present in /etc/mtree/BSD.root.dist and only exists for systems installed with sysinstall. If you have your own install script that newfs's a disk and untars the base dist, you won't have a /stand directory. > If not, then please have sysinstall rm -rf /stand. *shrug*, it is an artifact that has proved useful in the past for system recovery. If /rescue becomes a reality then I would have no problem with /stand being removed after a successful install. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Fri May 9 11:29:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89C3337B401; Fri, 9 May 2003 11:29:37 -0700 (PDT) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id D898D43F93; Fri, 9 May 2003 11:29:34 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id h49ITXTh028743; Fri, 9 May 2003 11:29:34 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200305091829.h49ITXTh028743@beastie.mckusick.com> To: Bruce Evans In-Reply-To: Your message of "Fri, 09 May 2003 17:23:41 +1000." <20030509162725.N80145@gamplex.bde.org> Date: Fri, 09 May 2003 11:29:33 -0700 From: Kirk McKusick cc: arch@FreeBSD.org cc: Brian Buhrow cc: Jens Schweikhardt Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 18:29:37 -0000 Well, -async or -noasync, it looks like method 1 is the winning strategy. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Fri May 9 14:50:48 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48FA237B401 for ; Fri, 9 May 2003 14:50:48 -0700 (PDT) Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id A896C43FAF for ; Fri, 9 May 2003 14:50:47 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 8085 invoked from network); 9 May 2003 21:50:54 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 9 May 2003 21:50:54 -0000 Received: from laptop.baldwin.cx ([216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h49Loep0013414 for ; Fri, 9 May 2003 17:50:40 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 09 May 2003 17:50:46 -0400 (EDT) From: John Baldwin To: arch@FreeBSD.org Subject: [Bikeshed] sigacts locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 21:50:48 -0000 As part of the locking for the proc structure, I needed to lock the procsig and sigacts stuctures so that kill(), killpg(), sigaction() and a few other system calls can be pulled out from under Giant. After talking with Peter some, I decided to pull the sigacts structure out of the u-area and merge it with the procsig structure under the sigacts name. I then added a mutex to each sigacts and added locking where appropriate. With this change, the aforementioned system calls are now MP safe along with sendsig(), *signal(), cursig(), etc. The patch for all this is at http://www.FreeBSD.org/~jhb/patches/sigacts.patch I would appreciate comments, review, etc. that people may have. If all goes well I hope to get this into 5.1. Thanks. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Fri May 9 21:47:42 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 249E337B401; Fri, 9 May 2003 21:47:42 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B5D343F85; Fri, 9 May 2003 21:47:40 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id OAA24636; Sat, 10 May 2003 14:47:25 +1000 Date: Sat, 10 May 2003 14:47:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Brian Buhrow In-Reply-To: <200305091732.h49HW9x11035@lothlorien.nfbcal.org> Message-ID: <20030510142105.H2968@gamplex.bde.org> References: <200305091732.h49HW9x11035@lothlorien.nfbcal.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org cc: Jens Schweikhardt cc: Kirk McKusick Subject: Re: Access times on executables (kern/25777) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 04:47:42 -0000 On Fri, 9 May 2003, Brian Buhrow wrote: > I hope you forgive my naive question, but I fail to understand how the > NFS case can fail under any circumstance. If a user tries to execute an > nfs-mounted binary which is not readable by him, doesn't the system "read" > the binary as the user root in order to execute the program, assuming the > proper execute bit is set? And, once that is done, wouldn't the system > continue to read (page) that file as root? If that doesn't work, then I This lets the VOP_READ() method but not the VOP_SETATTR() method work. For both methods, we have a readable vp which corresponds to a readable fd in userland. This requires getting past the access checks on the pathname to the file being executed. The execute bit works like the read bit in the context of exec() -- VOP_READ() doesn't check either and its callers check the appropriate one. The VOP_SETTATR() method needs write access instead of read access, and it checks for this internally so execve() can't just grant this access by not checking it. Bruce From owner-freebsd-arch@FreeBSD.ORG Sat May 10 07:21:42 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7786537B417 for ; Sat, 10 May 2003 07:21:42 -0700 (PDT) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [193.162.153.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E2F343FCB for ; Sat, 10 May 2003 07:21:41 -0700 (PDT) (envelope-from nicolai@catpipe.net) Received: from 80.164.85.206 (unknown [80.164.85.206]) by pfepa.post.tele.dk (Postfix) with ESMTP id 1352647FFBE for ; Sat, 10 May 2003 16:21:39 +0200 (CEST) From: Nicolai Petri Organization: catpipe Systems ApS To: freebsd-arch@freebsd.org Date: Sat, 10 May 2003 16:21:34 +0200 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305101621.34478.nicolai@catpipe.net> Subject: kld-framework suggestions. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 14:21:42 -0000 I'm currently trying to do some kernel hacking with focus on the KLD-framework. My goals is to come up with some bugfixes for 5.X and some new ideas and patches for 6.X. I have created a site at http://hobbes.bsd-dk.dk/~npp/ where I put my current work. I also uploaded my ongoing kld-todo.txt draft that I update each time I get a new idea or rm's some of the old ideas. My current goal is to get some new macros into the src-tree for associating sysctls and sysinits with a module instead of a .ko file. Below I pasted in some lines from my todo that quite well explains what I propose (I hope) For a bit more detailed text please look at the above mentioned website. Comments are welcome : The future ---------- * A state storing framework * A future goal would be to extend the kld framework to be a core part of the "reload or upgrade kernel without booting or losing state" project. First phase would be to allow real-time updates of modules without losing state. (this could be used for eg. disk drivers and similar). Generation of a state-storing framework for doing dynamic RT (runtime) upgrades. It could be a mechanism like : RTStoreValueInt(rtobj, BLAH_RING_BUFFER_SIZE, 1234); RTGetValueInt(newrtobj, BLAH_RING_BUFFER_SIZE. &bufsize); if (bufsize < MIN_NEW_BUF_SIZE) realloc(buffer); blah. and if (RTGetDSVersion(ifnet) != 2) goto abort; The above is a quick "it-could-maybe-be-done-like-this-if-the-wind -blows-from-east-and-we-all-agree", it's NOT a well thought idea in any way. * Adding new macros for registering SYSCTL's and SYSINIT's * To be able to associate SYSCTL's and SYSINITS with modules instead of .ko files, I propose to add some new macros named MODULE_*. These should be used for registering sysctl's and sysinit's where it is relevent. In the sysctl case it should be possible to give a flag that defines how to handle conflicts while loading (eg. should the sysctl be replaced or ignored). * Other ideas * Addition of MOD_ISLOADABLE to mod_event(). Addition of MOD_RTUPDATE and MOD_RTUPDATEABLE (Maybe this should be done like SYSINIT's) From owner-freebsd-arch@FreeBSD.ORG Sat May 10 10:26:11 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59EF637B401; Sat, 10 May 2003 10:26:11 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9712E43FA3; Sat, 10 May 2003 10:26:10 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h4AHQ9Q0031149; Sat, 10 May 2003 10:26:09 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h4AHQ9ms031148; Sat, 10 May 2003 10:26:09 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 10 May 2003 10:26:09 -0700 From: David Schultz To: John Baldwin Message-ID: <20030510172609.GA29039@HAL9000.homeunix.com> Mail-Followup-To: John Baldwin , arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: arch@FreeBSD.ORG Subject: Re: [Bikeshed] sigacts locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 17:26:11 -0000 On Fri, May 09, 2003, John Baldwin wrote: > As part of the locking for the proc structure, I needed to lock > the procsig and sigacts stuctures so that kill(), killpg(), > sigaction() and a few other system calls can be pulled out from > under Giant. After talking with Peter some, I decided to > pull the sigacts structure out of the u-area and merge it with > the procsig structure under the sigacts name. I then added a > mutex to each sigacts and added locking where appropriate. With > this change, the aforementioned system calls are now MP safe > along with sendsig(), *signal(), cursig(), etc. The patch for > all this is at http://www.FreeBSD.org/~jhb/patches/sigacts.patch > I would appreciate comments, review, etc. that people may have. > If all goes well I hope to get this into 5.1. Thanks. It occurs to me that this leaves very little in the uarea. You have a struct pstats, which is less than 256 bytes, and you have the kinfo_proc, which shouldn't need to be there anyway. Perhaps now would also be a good time to get rid of uarea swapping and the associated complexity altogether. From owner-freebsd-arch@FreeBSD.ORG Sat May 10 11:18:07 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F304237B401; Sat, 10 May 2003 11:18:06 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C9CF43FE1; Sat, 10 May 2003 11:18:06 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0084.cvx40-bradley.dialup.earthlink.net ([216.244.42.84] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19EYv7-0004FK-00; Sat, 10 May 2003 11:18:06 -0700 Message-ID: <3EBD4214.73CB8B7C@mindspring.com> Date: Sat, 10 May 2003 11:16:52 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz References: <20030510172609.GA29039@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a449a18077e964a8c49bbea987ad575b93a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: arch@FreeBSD.ORG cc: John Baldwin Subject: Re: [Bikeshed] sigacts locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 18:18:07 -0000 David Schultz wrote: > It occurs to me that this leaves very little in the uarea. You > have a struct pstats, which is less than 256 bytes, and you have > the kinfo_proc, which shouldn't need to be there anyway. Perhaps > now would also be a good time to get rid of uarea swapping and the > associated complexity altogether. The swapping of the uarea doesn't really introduce a lot of extra complexity, since all it does is allocate swappable pages, just like the swappable pages in user space. Change that mode stuff out of the uarea are probably a bad idea, since it increases KVA pressure by moving them to wired kernel pages. -- Terry From owner-freebsd-arch@FreeBSD.ORG Sat May 10 12:14:45 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D70CA37B401; Sat, 10 May 2003 12:14:45 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBADB43FB1; Sat, 10 May 2003 12:13:53 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h4AJDq7d000293; Sat, 10 May 2003 12:13:52 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h4AJDq77000292; Sat, 10 May 2003 12:13:52 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 10 May 2003 12:13:52 -0700 From: David Schultz To: Terry Lambert Message-ID: <20030510191352.GA225@HAL9000.homeunix.com> Mail-Followup-To: Terry Lambert , John Baldwin , arch@FreeBSD.ORG References: <20030510172609.GA29039@HAL9000.homeunix.com> <3EBD4214.73CB8B7C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EBD4214.73CB8B7C@mindspring.com> cc: arch@FreeBSD.ORG cc: John Baldwin Subject: Re: [Bikeshed] sigacts locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 19:14:46 -0000 On Sat, May 10, 2003, Terry Lambert wrote: > David Schultz wrote: > > It occurs to me that this leaves very little in the uarea. You > > have a struct pstats, which is less than 256 bytes, and you have > > the kinfo_proc, which shouldn't need to be there anyway. Perhaps > > now would also be a good time to get rid of uarea swapping and the > > associated complexity altogether. > > The swapping of the uarea doesn't really introduce a lot of > extra complexity, since all it does is allocate swappable > pages, just like the swappable pages in user space. > > Change that mode stuff out of the uarea are probably a bad > idea, since it increases KVA pressure by moving them to > wired kernel pages. No, they're already wired kernel pages that are unwired and unmapped when the process is swapped out. Moreover, there's probably *more* KVA pressure with upages swapping, because each tiny struct upages gets a 4K or larger page all to itself unless it's swapped out. From owner-freebsd-arch@FreeBSD.ORG Sat May 10 12:26:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35ADF37B401; Sat, 10 May 2003 12:26:37 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93EBF43F85; Sat, 10 May 2003 12:26:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0084.cvx40-bradley.dialup.earthlink.net ([216.244.42.84] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19EZzO-0006mO-00; Sat, 10 May 2003 12:26:36 -0700 Message-ID: <3EBD5212.225AC129@mindspring.com> Date: Sat, 10 May 2003 12:25:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz References: <20030510172609.GA29039@HAL9000.homeunix.com> <3EBD4214.73CB8B7C@mindspring.com> <20030510191352.GA225@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a458bed8b69e3e694ea767706062570ee42601a10902912494350badd9bab72f9c350badd9bab72f9c cc: arch@FreeBSD.ORG cc: John Baldwin Subject: Re: [Bikeshed] sigacts locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 19:26:37 -0000 David Schultz wrote: > No, they're already wired kernel pages that are unwired and > unmapped when the process is swapped out. Moreover, there's > probably *more* KVA pressure with upages swapping, because each > tiny struct upages gets a 4K or larger page all to itself unless > it's swapped out. The wiring and unwiring doesn't change the fundamental nature of the page. I can think of a lot of useful things to put in that page, if you are willing to map it read-only into user space. The pid, uid, gid, ppid, etc. could all be made zero system call functions, for example. So I'm not as concerned about it being 4K in size. I'm more concerned with the idea of being able to migrate a process to another node in a cluster, and having all of the information needed to do this outside nominally kernel data structures, instead of having to do a lot of work to extricate the process from a given node's kernel data. (Well, you *did* wan us in the "Subject:"... 8-) 8-)). -- Terry From owner-freebsd-arch@FreeBSD.ORG Sat May 10 22:32:03 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAD4C37B401; Sat, 10 May 2003 22:32:03 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C38A43FE1; Sat, 10 May 2003 22:32:02 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id PAA19099; Sun, 11 May 2003 15:31:58 +1000 Date: Sun, 11 May 2003 15:31:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20030510172609.GA29039@HAL9000.homeunix.com> Message-ID: <20030511152818.Q74382@gamplex.bde.org> References: <20030510172609.GA29039@HAL9000.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: [Bikeshed] sigacts locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2003 05:32:04 -0000 On Sat, 10 May 2003, David Schultz wrote: > On Fri, May 09, 2003, John Baldwin wrote: > > As part of the locking for the proc structure, I needed to lock > > the procsig and sigacts stuctures so that kill(), killpg(), > > sigaction() and a few other system calls can be pulled out from > > under Giant. After talking with Peter some, I decided to > > pull the sigacts structure out of the u-area and merge it with > > the procsig structure under the sigacts name. I then added a > > ... > > It occurs to me that this leaves very little in the uarea. You > have a struct pstats, which is less than 256 bytes, and you have > the kinfo_proc, which shouldn't need to be there anyway. Perhaps > now would also be a good time to get rid of uarea swapping and the > associated complexity altogether. I think this was planned. See an old thread about not swapping either the uarea or the stack. It was agreed (?) that the uarea could go but not swapping of the stack. Bruce