From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 02:16:03 2004 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 59FD316A4CE for ; Sun, 27 Jun 2004 02:16:03 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFDCF43D1F for ; Sun, 27 Jun 2004 02:16:02 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5R2F9Yf066536; Sat, 26 Jun 2004 22:15:09 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5R2F9Yv066533; Sat, 26 Jun 2004 22:15:09 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 26 Jun 2004 22:15:09 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nicolas Souchu In-Reply-To: <20040626234219.A7461@armor.freesurf.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: condvar and mutexes 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, 27 Jun 2004 02:16:03 -0000 On Sat, 26 Jun 2004, Nicolas Souchu wrote: > Why is condvar(9) API not part of the mutex(9) one? A condvar is nothing > more than a mutex with a queue of waiting threads. > > I would simply imagine some wait calls applied to mutexes with the queue > in the mutex struct. A few observations: - Combining it all into one man page would lead to an awfully long man page :-). - If you use a condition variable, you must use a mutex. However, if you use a mutex, there's no obligation to use a condition variable. Most of our mutexes don't involve using condition variables, actually, I suspect. Note that the wait queue for a mutex is not the same as a wait queue for a condition variable associated with the mutex. As it stands, we get to choose when we do (and don't) want the additional overhead. - I've used Mach's wait queue and mutex APIs, which seems to have a split more like what you're suggesting, and I have to say they are abysmal in terms of usability and avoiding races. In fact, in some recent work to port some FreeBSD piecess to Darwin, which uses Mach's mutexes and wait queues, I implemented the FreeBSD condition variable API in terms of the Mach primitives rather than use the Mach primitives directly. In particular, the cv_wait() interface in our API is much easier to use: void cv_wait(struct cv *cvp, mutex_t *mp) { int ret; mutex_unlock(mp); ret = wait_queue_assert_wait(cvp->cv_wait_queue, 0, THREAD_UNINT); if (ret != THREAD_WAITING) panic("cv_wait: wait_queue_assert_wait failed"); ret = thread_block(THREAD_CONTINUE_NULL); if (ret != THREAD_AWAKENED) panic("cv_wait: thread_block failed"); mutex_lock(mp); } - By using an API that's congurent to the POSIX threads API in user space, we make it easier for developers familiar with existing synchronization primitives in user space to adapt to kernel synchronization. And when someone says "How should I perform synchronization in kernel?", we can point them at the volumes of documentation on pthreads. Note that our API is quite a bit simpler than pthreads, but most of the same issues apply (how to use condition variables, for example). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 06:57:23 2004 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 8E1EC16A4CE; Sun, 27 Jun 2004 06:57:23 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A301A43D2D; Sun, 27 Jun 2004 06:57:22 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i5R6v990089159; Sat, 26 Jun 2004 23:57:09 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <40DE6FBA.1010801@freebsd.org> Date: Sat, 26 Jun 2004 23:56:58 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org, re@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: RFC: bsdtar in 5.3 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, 27 Jun 2004 06:57:23 -0000 I would like to make bsdtar the default FreeBSD system tar for -CURRENT within the next week or so. That should give it broad enough usage over the next couple of months to prove that it's ready for 5-STABLE. My plan: * Make /usr/bin/tar default to a symlink to /usr/bin/bsdtar as soon as possible. (Currently, it defaults to /usr/bin/gtar unless you build WITH_BSDTAR.) * Leave /usr/bin/gtar in the base system through the 5.x cycle. * For 6.0, remove /usr/bin/gtar and rename /usr/bin/bsdtar to /usr/bin/tar. Any objections, suggestions, or comments? Tim Kientzle From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 12:53:56 2004 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 47FC116A4CE; Sun, 27 Jun 2004 12:53:56 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9952D43D1F; Sun, 27 Jun 2004 12:53:55 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id C131C530F; Sun, 27 Jun 2004 14:52:04 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 79A59530C; Sun, 27 Jun 2004 14:51:43 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 5DCACB86C; Sun, 27 Jun 2004 14:51:43 +0200 (CEST) To: Robert Watson References: From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sun, 27 Jun 2004 14:51:43 +0200 In-Reply-To: (Robert Watson's message of "Sat, 26 Jun 2004 12:38:43 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: arch@FreeBSD.org Subject: Re: Confusion about process states and invariants 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, 27 Jun 2004 12:53:56 -0000 Robert Watson writes: > FYI, two of the reported problems were in sysctl_kern_proc() and > linprocfs. pseudofs, not linprocfs. > One of those has been patched by checking p_ucred for NULL; > the other has not. No. The proposed patch for sysctl_kern_proc() wouldn't have worked, and I would have backed it out if it had been committed. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 13:13:31 2004 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 74E0816A4CE; Sun, 27 Jun 2004 13:13:31 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 221E543D2F; Sun, 27 Jun 2004 13:13:31 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 32BEFACAE3; Sun, 27 Jun 2004 15:13:18 +0200 (CEST) Date: Sun, 27 Jun 2004 15:13:18 +0200 From: Pawel Jakub Dawidek To: Robert Watson Message-ID: <20040627131318.GK12007@darkness.comp.waw.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rymfx6HOR/0f6nvJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: arch@FreeBSD.org Subject: Re: Confusion about process states and invariants 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, 27 Jun 2004 13:13:31 -0000 --rymfx6HOR/0f6nvJ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 26, 2004 at 12:38:43PM -0400, Robert Watson wrote: +> Over the last two weeks, I've seen several reports of panics relating to +> code making incorrect assumptions about process state, generally relating +> to the "p_ucred" pointer in new and dying processes. In particular, a +> number of pieces of code assume that if a process is reachable by the all +> process list (or other process lists), p_ucred will be valid and non-NULL +> if the process lock is held on the process. This results in possible NU= LL +> pointer dereferences in the PRS_NEW state, and also during the tear-down +> in kern_wait(). At first glance, the easy answer would appear to be +> "check for p_ucred to be NULL", but I'm actually of the opinion that I'd +> prefer we have the non-NULL p_ucred invariant actually hold true. This +> would permit security checks to be performed properly during those +> windows. I'm not very familiar with our process state and locking, but = if +> someone with a more qualified background in that area could comment on t= he +> current issue, that would be useful. Couldn't we move crhold() for p_ucred before it is placed on allproc list? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --rymfx6HOR/0f6nvJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA3sfuForvXbEpPzQRAmoiAKCBJWFW9iEu5mjI9FR9jr5P8P6bTwCgtrNK OIkOYVJ3NgjEPaXurLivwto= =j9g9 -----END PGP SIGNATURE----- --rymfx6HOR/0f6nvJ-- From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 13:32:09 2004 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 BC3F216A4CE; Sun, 27 Jun 2004 13:32:09 +0000 (GMT) Received: from robbins.dropbear.id.au (041.a.010.mel.iprimus.net.au [210.50.200.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id B823143D31; Sun, 27 Jun 2004 13:32:07 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 2E9A04214; Sun, 27 Jun 2004 23:34:21 +1000 (EST) Date: Sun, 27 Jun 2004 23:34:21 +1000 From: Tim Robbins To: Pawel Jakub Dawidek Message-ID: <20040627133421.GA15812@cat.robbins.dropbear.id.au> References: <20040627131318.GK12007@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040627131318.GK12007@darkness.comp.waw.pl> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org cc: Robert Watson Subject: Re: Confusion about process states and invariants 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, 27 Jun 2004 13:32:09 -0000 On Sun, Jun 27, 2004 at 03:13:18PM +0200, Pawel Jakub Dawidek wrote: > On Sat, Jun 26, 2004 at 12:38:43PM -0400, Robert Watson wrote: > +> Over the last two weeks, I've seen several reports of panics relating to > +> code making incorrect assumptions about process state, generally relating > +> to the "p_ucred" pointer in new and dying processes. In particular, a > +> number of pieces of code assume that if a process is reachable by the all > +> process list (or other process lists), p_ucred will be valid and non-NULL > +> if the process lock is held on the process. This results in possible NULL > +> pointer dereferences in the PRS_NEW state, and also during the tear-down > +> in kern_wait(). At first glance, the easy answer would appear to be > +> "check for p_ucred to be NULL", but I'm actually of the opinion that I'd > +> prefer we have the non-NULL p_ucred invariant actually hold true. This > +> would permit security checks to be performed properly during those > +> windows. I'm not very familiar with our process state and locking, but if > +> someone with a more qualified background in that area could comment on the > +> current issue, that would be useful. > > Couldn't we move crhold() for p_ucred before it is placed on allproc list? p_ucred is just the tip of the iceberg -- a lot of code assumes that processes on allproc are fully set up. We should either delay putting the process onto allproc until it's correctly initialized (taking care to avoid races in PID allocation), or not drop the allproc sx until initialization is done. Tim From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 14:31:59 2004 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 451DF16A4CE; Sun, 27 Jun 2004 14:31:59 +0000 (GMT) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4DA243D2F; Sun, 27 Jun 2004 14:31:58 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 4D70E119A4; Sun, 27 Jun 2004 16:31:57 +0200 (CEST) Date: Sun, 27 Jun 2004 16:31:57 +0200 From: "Simon L. Nielsen" To: Tim Kientzle Message-ID: <20040627143156.GA1219@zaphod.nitro.dk> References: <40DE6FBA.1010801@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <40DE6FBA.1010801@freebsd.org> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: re@freebsd.org Subject: Re: RFC: bsdtar in 5.3 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, 27 Jun 2004 14:31:59 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.06.26 23:56:58 -0700, Tim Kientzle wrote: > I would like to make bsdtar the default > FreeBSD system tar for -CURRENT within > the next week or so. [...] > Any objections, suggestions, or comments? I have been running with bsdtar as my default tar on my laptop since shortly after the WITH_BSDTAR option was introduced, and I have yet to see any problems, so I think you plan sounds good. Keep up the good work! :-). --=20 Simon L. Nielsen FreeBSD Documentation Team --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA3tpch9pcDSc1mlERAtALAKDDKYEBciMu0egb8T9i7WJ5cZEDNACcDn5v KzWr7fzoKjkvuZvFhYIAxjk= =5S8L -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 15:53:33 2004 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 D25C116A4CF; Sun, 27 Jun 2004 15:53:33 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8655743D2F; Sun, 27 Jun 2004 15:53:33 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5RFrLRx074680; Sun, 27 Jun 2004 11:53:21 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5RFrLad074677; Sun, 27 Jun 2004 11:53:21 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 27 Jun 2004 11:53:21 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Tim Robbins In-Reply-To: <20040627133421.GA15812@cat.robbins.dropbear.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Pawel Jakub Dawidek Subject: Re: Confusion about process states and invariants 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, 27 Jun 2004 15:53:34 -0000 On Sun, 27 Jun 2004, Tim Robbins wrote: > > Couldn't we move crhold() for p_ucred before it is placed on allproc > > list? > > p_ucred is just the tip of the iceberg -- a lot of code assumes that > processes on allproc are fully set up. We should either delay putting > the process onto allproc until it's correctly initialized (taking care > to avoid races in PID allocation), or not drop the allproc sx until > initialization is done. Yeah, it seems there are only two reasonable strategies: (1) Guard all accesses to proc references to make sure they are aware of the process state machine and when they can expect certain fields to be valid or usable. This might include causing pfind() not to return improper processes. (2) Don't expose processes in "poor" states to the various consumers of processes, allowing the invariants expected by those consumers to be stronger. Some magic would be required here in ways you and I have discussed previously, such as managing to avoid collisions on pids, etc. I prefer (2) since it avoids putting "Hmm, is it real" logic all over the kernel, but am unwilling to make the change without a proper understanding of what should be going on. I also don't have time to make the change immediately, so was trolling for someone willing to work on it :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-arch@FreeBSD.ORG Tue Jun 29 00:47:00 2004 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 8617016A4CE; Tue, 29 Jun 2004 00:47:00 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B85D943D2F; Tue, 29 Jun 2004 00:46:57 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from samsco.org (p58.n-nypop02.stsn.com [199.106.89.58]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i5T0oYj9064105; Mon, 28 Jun 2004 18:50:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <40E0BBE1.50600@samsco.org> Date: Mon, 28 Jun 2004 18:46:25 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Kientzle References: <40DE6FBA.1010801@freebsd.org> In-Reply-To: <40DE6FBA.1010801@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org cc: re@freebsd.org Subject: Re: RFC: bsdtar in 5.3 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, 29 Jun 2004 00:47:00 -0000 Tim Kientzle wrote: > I would like to make bsdtar the default > FreeBSD system tar for -CURRENT within > the next week or so. > > That should give it broad enough usage > over the next couple of months to prove > that it's ready for 5-STABLE. > > My plan: > > * Make /usr/bin/tar default to a symlink > to /usr/bin/bsdtar as soon as possible. > (Currently, it defaults to /usr/bin/gtar > unless you build WITH_BSDTAR.) > > * Leave /usr/bin/gtar in the base system > through the 5.x cycle. > > * For 6.0, remove /usr/bin/gtar and rename > /usr/bin/bsdtar to /usr/bin/tar. > > Any objections, suggestions, or comments? > > Tim Kientzle > I'm a little hesitant about making bsdtar be the default in 5.3, but I'm not against it. Let's try this: once bsdtar can make it through a full bento package run without obvious problems, we make it be the default in HEAD (before the 5.3 code freeze). During the code freeze and the BETA/RC cycle, we put a strong emphasis on testing it, but we also prepare ourselves to switch back to gtar for 5.3-R if needed. In other words, having it be the default for 5.3 and 5-STABLE is a good and interesting goal, but we reserve the right to defer that goal if it starts holding up the release. Does that sound acceptable? Scott From owner-freebsd-arch@FreeBSD.ORG Tue Jun 29 04:47:22 2004 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 F0EF716A4CE; Tue, 29 Jun 2004 04:47:22 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B2B243D41; Tue, 29 Jun 2004 04:47:22 +0000 (GMT) (envelope-from tim@kientzle.com) Received: from kientzle.com (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i5T4lF90098883; Mon, 28 Jun 2004 21:47:17 -0700 (PDT) (envelope-from tim@kientzle.com) Message-ID: <40E0F443.6050204@kientzle.com> Date: Mon, 28 Jun 2004 21:46:59 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <40DE6FBA.1010801@freebsd.org> <40E0BBE1.50600@samsco.org> In-Reply-To: <40E0BBE1.50600@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: Tim Kientzle cc: re@freebsd.org Subject: Re: RFC: bsdtar in 5.3 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, 29 Jun 2004 04:47:23 -0000 Scott Long wrote: > Tim Kientzle wrote: > >> I would like to make bsdtar the default >> FreeBSD system tar for -CURRENT within >> the next week or so. ... > > I'm a little hesitant about making bsdtar be the default in 5.3, but I'm > not against it. Let's try this: once bsdtar can make it through a full > bento package run without obvious problems, ... We're pretty close. Kris Kennaway has been using bsdtar for package builds for a while now. We've been steadily working through the list of issues as they arise, mostly by adding features to bsdtar. I believe I finished the last items on that last this past weekend, and am currently waiting to hear from Kris if there are any further problems. > ... make it be the default in HEAD (before the 5.3 code freeze) ... Hopefully, within the week, unless something new pops up in the package builds before then. > .. prepare ourselves to switch back to gtar for 5.3-R if needed. My plan all along has been to leave both bsdtar and gtar in the base system for a lengthy transition period. (Maybe even until 6.0?) The only difference is the one "tar" symlink that gets repointed. If it's necessary, switching back will be very simple, indeed. > having [bsdtar] be the default for 5.3 and 5-STABLE is a good and > interesting goal, but we reserve the right to defer that goal if it > starts holding up the release. Does that sound acceptable? That sounds entirely reasonable. Thanks for giving me a chance on this! Tim From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 10:02:56 2004 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 AD14816A4CE; Wed, 30 Jun 2004 10:02:56 +0000 (GMT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B3D243D58; Wed, 30 Jun 2004 10:02:56 +0000 (GMT) (envelope-from tlambert2@mindspring.com) Received: from [192.168.167.46] (helo=wamui08.slb.atl.earthlink.net) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BfbvT-0006Ry-00; Wed, 30 Jun 2004 06:02:47 -0400 Message-ID: <9697234.1088589767326.JavaMail.root@wamui08.slb.atl.earthlink.net> Date: Wed, 30 Jun 2004 03:02:46 -0700 (GMT-07:00) From: Terry Lambert To: Tim Robbins , Poul-Henning Kamp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 cc: arch@freebsd.org cc: David Schultz cc: marcel@xcllnt.net cc: freebsd-arch@freebsd.org Subject: Re: COMPAT_43 tty processing ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Terry Lambert List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2004 10:02:56 -0000 Tim Robbins wrote: > On Fri, Jun 25, 2004 at 12:22:01PM +0200, Poul-Henning Kamp wrote: > > In message <200406241859.54810.peter@wemm.org>, Peter Wemm writes: > > >On Wednesday 23 June 2004 04:27 pm, David Schultz wrote: > > >> On Mon, Jun 21, 2004, Poul-Henning Kamp wrote: > > >> > Do we need the COMPAT_43 tty processing in 5-STABLE ? > > >> > > >> FWIW, I used to run with COMPAT_43 disabled entirely. I think the > > >> only breakage I noticed was that the Linuxolator didn't work > > >> anymore because of a number of `#ifdef COMPAT_43's in the socket > > >> code that linux.ko depends on. > > > > > >These should probably be broken out as COMPAT_OLDSOCK, whih is implied > > >by the linuxulator or COMPAT_43 or the like. > > > > Or better yet: made unncessary in the linuxolator ? > > This is what NetBSD has done. At one stage I had patches derived from > their code that removed the need for the COMPAT_43 socket functions, > but COMPAT_43 was still necessary for ostat(), etc. Please do not remove any code protected by COMPAT_43 which provides any of the functionality listed on either of the following two standards document references: http://www.opengroup.org/onlinepubs/009695399/basedefs/termios.h.html http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap11.html#tag_11 (Yes, I know that this code should not be inside COMPAT_43 protection, but as far as I can tell, no on has disentagled it). -- Terr From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 10:02:56 2004 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 AD14816A4CE; Wed, 30 Jun 2004 10:02:56 +0000 (GMT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B3D243D58; Wed, 30 Jun 2004 10:02:56 +0000 (GMT) (envelope-from tlambert2@mindspring.com) Received: from [192.168.167.46] (helo=wamui08.slb.atl.earthlink.net) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BfbvT-0006Ry-00; Wed, 30 Jun 2004 06:02:47 -0400 Message-ID: <9697234.1088589767326.JavaMail.root@wamui08.slb.atl.earthlink.net> Date: Wed, 30 Jun 2004 03:02:46 -0700 (GMT-07:00) From: Terry Lambert To: Tim Robbins , Poul-Henning Kamp Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 cc: arch@freebsd.org cc: David Schultz cc: marcel@xcllnt.net cc: freebsd-arch@freebsd.org Subject: Re: COMPAT_43 tty processing ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Terry Lambert List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2004 10:02:56 -0000 Tim Robbins wrote: > On Fri, Jun 25, 2004 at 12:22:01PM +0200, Poul-Henning Kamp wrote: > > In message <200406241859.54810.peter@wemm.org>, Peter Wemm writes: > > >On Wednesday 23 June 2004 04:27 pm, David Schultz wrote: > > >> On Mon, Jun 21, 2004, Poul-Henning Kamp wrote: > > >> > Do we need the COMPAT_43 tty processing in 5-STABLE ? > > >> > > >> FWIW, I used to run with COMPAT_43 disabled entirely. I think the > > >> only breakage I noticed was that the Linuxolator didn't work > > >> anymore because of a number of `#ifdef COMPAT_43's in the socket > > >> code that linux.ko depends on. > > > > > >These should probably be broken out as COMPAT_OLDSOCK, whih is implied > > >by the linuxulator or COMPAT_43 or the like. > > > > Or better yet: made unncessary in the linuxolator ? > > This is what NetBSD has done. At one stage I had patches derived from > their code that removed the need for the COMPAT_43 socket functions, > but COMPAT_43 was still necessary for ostat(), etc. Please do not remove any code protected by COMPAT_43 which provides any of the functionality listed on either of the following two standards document references: http://www.opengroup.org/onlinepubs/009695399/basedefs/termios.h.html http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap11.html#tag_11 (Yes, I know that this code should not be inside COMPAT_43 protection, but as far as I can tell, no on has disentagled it). -- Terr From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 07:22:37 2004 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 54CC416A4CE for ; Thu, 1 Jul 2004 07:22:37 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1925043D2F for ; Thu, 1 Jul 2004 07:22:37 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from [192.160.235.2] (cs242743-143.austin.rr.com [24.27.43.143]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 09DB914313 for ; Thu, 1 Jul 2004 02:22:15 -0500 (CDT) From: Mark Linimon Organization: Lonesome Dove Computing Services To: freebsd-arch@FreeBSD.org Date: Thu, 1 Jul 2004 02:19:44 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200407010219.44628.linimon@lonesome.com> Subject: does FreeBSD still support CPUs without math coprocessors? 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, 01 Jul 2004 07:22:37 -0000 The FAQ claims that it does, but ISTR recent discussion about removing the software emulation. However, a search of the mailing lists, and Google, fails to show anything, so it is completely possible that my memory is playing tricks on me. If that support has gone by the wayside, I'll go ahead and change that part of the FAQ, oth4erwise, I'll leave it alone. (And yes, I just saw the 386 announcement, so I know about that.) mcl From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 09:02:57 2004 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 141A016A4CE for ; Thu, 1 Jul 2004 09:02:57 +0000 (GMT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D39DB43D3F for ; Thu, 1 Jul 2004 09:02:56 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd11.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1BfxSu-0004AY-06; Thu, 01 Jul 2004 11:02:44 +0200 Received: from Andro-Beta.Leidinger.net (S8GWyMZGoeEdW96FDc8n267ysNPeCJsT05R5D+Y7fz4CpxtacoX8Zt@[84.128.206.29]) by fmrl11.sul.t-online.com with esmtp id 1BfxSi-10m6Ea0; Thu, 1 Jul 2004 11:02:32 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i6192V4D017319 for ; Thu, 1 Jul 2004 11:02:31 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Thu, 1 Jul 2004 11:02:31 +0200 From: Alexander Leidinger To: arch@freebsd.org Message-Id: <20040701110231.1d3a4c70@Magellan.Leidinger.net> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: S8GWyMZGoeEdW96FDc8n267ysNPeCJsT05R5D+Y7fz4CpxtacoX8Zt@t-dialin.net Subject: RFC: feature tests instead of compiler tests 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, 01 Jul 2004 09:02:57 -0000 Hi, the 106k large patch at http://www.leidinger.net/FreeBSD/current-patches/compiler_independence.diff introduces feature tests instead of checks for a particular compiler in the kernel source. The only checks for a particular compiler are in cdefs.h now. As per suggestion from bde I also removed parts of the backward compatibility to old gcc versions because the rest of the kernel can't be compiled anymore with those old versions. Interested parties may look at the cdefs.h part first and suggest some fixes (e.g. better names for the feature defines). The patch survives a run through the universe. Various revisions of this patch run fine on my desktop system since some months. Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 11:37:00 2004 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 0CEDB16A4CF for ; Thu, 1 Jul 2004 11:37:00 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A59743D1F for ; Thu, 1 Jul 2004 11:36:59 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 655855310; Thu, 1 Jul 2004 13:36:37 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id E7F62530E; Thu, 1 Jul 2004 13:36:28 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 9ED26B860; Thu, 1 Jul 2004 13:36:28 +0200 (CEST) To: Mark Linimon References: <200407010219.44628.linimon@lonesome.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 01 Jul 2004 13:36:28 +0200 In-Reply-To: <200407010219.44628.linimon@lonesome.com> (Mark Linimon's message of "Thu, 1 Jul 2004 02:19:44 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-arch@FreeBSD.org Subject: Re: does FreeBSD still support CPUs without math coprocessors? 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, 01 Jul 2004 11:37:00 -0000 Mark Linimon writes: > The FAQ claims that it does, but ISTR recent discussion about removing > the software emulation. However, a search of the mailing lists, and > Google, fails to show anything, so it is completely possible that my > memory is playing tricks on me. It was removed last July (src/sys/i386/conf/NOTES rev 1.1091) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 19:45:06 2004 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 EDF6916A4CE for ; Thu, 1 Jul 2004 19:45:06 +0000 (GMT) Received: from pinky.otenet.gr (pinky.otenet.gr [195.170.0.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE13143D45 for ; Thu, 1 Jul 2004 19:45:04 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-a033.otenet.gr [212.205.215.33]) i61JiEGu001024; Thu, 1 Jul 2004 22:44:22 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.12.11/8.12.11) with ESMTP id i61Ji2st001233; Thu, 1 Jul 2004 22:44:02 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.12.11/8.12.11/Submit) id i61JhwmG001219; Thu, 1 Jul 2004 22:43:58 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 1 Jul 2004 22:43:58 +0300 From: Giorgos Keramidas To: Dag-Erling =?iso-8859-7?Q?Sm=F8rgrav?= Message-ID: <20040701194357.GA1115@gothmog.gr> References: <200407010219.44628.linimon@lonesome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: Mark Linimon cc: freebsd-arch@freebsd.org Subject: Re: does FreeBSD still support CPUs without math coprocessors? 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, 01 Jul 2004 19:45:07 -0000 On 2004-07-01 13:36, Dag-Erling Sm?rgrav wrote: > Mark Linimon writes: > > The FAQ claims that it does, but ISTR recent discussion about removing > > the software emulation. However, a search of the mailing lists, and > > Google, fails to show anything, so it is completely possible that my > > memory is playing tricks on me. > > It was removed last July (src/sys/i386/conf/NOTES rev 1.1091) We should probably update this comment then, right? # The Numeric Processing eXtension driver. In addition to this, you # may configure a math emulator (see above). If your machine has a # hardware FPU and the kernel configuration includes the npx device # *and* a math emulator compiled into the kernel, the hardware FPU # will be used, unless it is found to be broken or unless "flags" to # npx0 includes "0x08", which requests preference for the emulator. Taken from a recent src/sys/i386/conf/NOTES file: $ ident /usr/src/sys/i386/conf/NOTES /usr/src/sys/i386/conf/NOTES: $FreeBSD: src/sys/i386/conf/NOTES,v 1.1162 2004/06/23 17:33:24 brooks Exp $ - Giorgos From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 20:28:36 2004 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 2AE9516A4CE for ; Thu, 1 Jul 2004 20:28:36 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 894DD43D1F for ; Thu, 1 Jul 2004 20:28:35 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 788B8530A; Thu, 1 Jul 2004 22:27:43 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id F0C3C5309; Thu, 1 Jul 2004 22:27:34 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id D63BEB860; Thu, 1 Jul 2004 22:27:34 +0200 (CEST) To: Giorgos Keramidas References: <200407010219.44628.linimon@lonesome.com> <20040701194357.GA1115@gothmog.gr> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 01 Jul 2004 22:27:34 +0200 In-Reply-To: <20040701194357.GA1115@gothmog.gr> (Giorgos Keramidas's message of "Thu, 1 Jul 2004 22:43:58 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: Mark Linimon cc: freebsd-arch@freebsd.org Subject: Re: does FreeBSD still support CPUs without math coprocessors? 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, 01 Jul 2004 20:28:36 -0000 Giorgos Keramidas writes: > On 2004-07-01 13:36, Dag-Erling Sm?rgrav wrote: > > It was removed last July (src/sys/i386/conf/NOTES rev 1.1091) > We should probably update this comment then, right? I guess so... DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Fri Jul 2 01:33:25 2004 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 1384A16A4CE for ; Fri, 2 Jul 2004 01:33:25 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B63DA43D2F for ; Fri, 2 Jul 2004 01:33:24 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i621apRN076788; Thu, 1 Jul 2004 19:36:51 -0600 (MDT) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)i621anSM076785; Thu, 1 Jul 2004 19:36:50 -0600 (MDT) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Thu, 1 Jul 2004 19:36:49 -0600 (MDT) From: Scott Long Sender: scottl@pooker.samsco.org To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: Message-ID: <20040701193521.E76767@pooker.samsco.org> References: <200407010219.44628.linimon@lonesome.com> <20040701194357.GA1115@gothmog.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Giorgos Keramidas cc: Mark Linimon cc: freebsd-arch@freebsd.org Subject: Re: does FreeBSD still support CPUs without math coprocessors? 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, 02 Jul 2004 01:33:25 -0000 On Thu, 1 Jul 2004, [iso-8859-1] Dag-Erling Sm=F8rgrav wrote: > Giorgos Keramidas writes: > > On 2004-07-01 13:36, Dag-Erling Sm?rgrav wrote: > > > It was removed last July (src/sys/i386/conf/NOTES rev 1.1091) > > We should probably update this comment then, right? > > I guess so... > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no Done Scott From owner-freebsd-arch@FreeBSD.ORG Fri Jul 2 22:17:56 2004 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 4862E16A4EB for ; Fri, 2 Jul 2004 22:17:56 +0000 (GMT) Received: from quark.cs.earlham.edu (cs.earlham.edu [159.28.230.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D32D43EAA for ; Fri, 2 Jul 2004 21:57:29 +0000 (GMT) (envelope-from skylar@cs.earlham.edu) Received: from quark.cs.earlham.edu (localhost.cs.earlham.edu [127.0.0.1]) by quark.cs.earlham.edu (8.12.11/8.12.9) with ESMTP id i62LpxOc077562 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 2 Jul 2004 16:51:59 -0500 (EST) (envelope-from skylar@cs.earlham.edu) Received: (from skylar@localhost) by quark.cs.earlham.edu (8.12.11/8.12.9/Submit) id i62LpxB3077561; Fri, 2 Jul 2004 16:51:59 -0500 (CDT) (envelope-from skylar@cs.earlham.edu) X-Authentication-Warning: quark.cs.earlham.edu: skylar set sender to skylar@quark.cs.earlham.edu using -f Date: Fri, 2 Jul 2004 16:51:59 -0500 From: Skylar Thompson To: Mark Linimon Message-ID: <20040702215159.GF76361@quark.cs.earlham.edu> References: <200407010219.44628.linimon@lonesome.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Oiv9uiLrevHtW1RS" Content-Disposition: inline In-Reply-To: <200407010219.44628.linimon@lonesome.com> User-Agent: Mutt/1.4.2.1i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es SMTP-Mailing-Host: quark.cs.earlham.edu X-Operating-System: FreeBSD 4.10-STABLE X-Uptime: 4:39PM up 14 days, 13:24, 12 users, load averages: 0.09, 0.06, 0.07 X-Editor: VIM - Vi IMproved 6.2 (2003 Jun 1, compiled May 19 2004 13:14:50) X-Earlham-CS-Dept-MailScanner-Information: Please contact the ISP for more information X-Earlham-CS-Dept-MailScanner: Found to be clean X-MailScanner-From: skylar@cs.earlham.edu cc: freebsd-arch@freebsd.org Subject: Re: does FreeBSD still support CPUs without math coprocessors? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Skylar Thompson List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2004 22:17:56 -0000 --Oiv9uiLrevHtW1RS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 01, 2004 at 02:19:44AM -0500, Mark Linimon wrote: > The FAQ claims that it does, but ISTR recent discussion about removing > the software emulation. However, a search of the mailing lists, and > Google, fails to show anything, so it is completely possible that my > memory is playing tricks on me. >=20 > If that support has gone by the wayside, I'll go ahead and change that > part of the FAQ, oth4erwise, I'll leave it alone. >=20 > (And yes, I just saw the 386 announcement, so I know about that.) NAFAIK. NetBSD still does, though. --=20 -- Skylar Thompson (skylar@cs.earlham.edu) -- http://www.cs.earlham.edu/~skylar/ --Oiv9uiLrevHtW1RS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA5dj/sc4yyULgN4YRAr/3AJ9MJacDJQtVVpdi/9g7IhCDL4nJkQCZAReb M8RpmbsUXp/0o44CoDXvrwI= =MVJq -----END PGP SIGNATURE----- --Oiv9uiLrevHtW1RS-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 3 12:02:12 2004 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 EB8EA16A4CE; Sat, 3 Jul 2004 12:02:12 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8708B43D5A; Sat, 3 Jul 2004 12:02:12 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-5.local ([172.16.0.5] helo=localhost) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34 (FreeBSD)) id 1BgjDc-000Idj-7l; Sat, 03 Jul 2004 14:02:11 +0200 Date: Sat, 3 Jul 2004 14:02:35 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Tim Kientzle From: Oliver Eikemeier In-Reply-To: <40DE6FBA.1010801@freebsd.org> Message-Id: Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: arch@freebsd.org cc: re@freebsd.org cc: audit@freebsd.org Subject: Re: RFC: bsdtar in 5.3 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, 03 Jul 2004 12:02:13 -0000 Tim Kientzle wrote: > I would like to make bsdtar the default > FreeBSD system tar for -CURRENT within > the next week or so. > > That should give it broad enough usage > over the next couple of months to prove > that it's ready for 5-STABLE. > > My plan: > > * Make /usr/bin/tar default to a symlink > to /usr/bin/bsdtar as soon as possible. > (Currently, it defaults to /usr/bin/gtar > unless you build WITH_BSDTAR.) > > * Leave /usr/bin/gtar in the base system > through the 5.x cycle. > > * For 6.0, remove /usr/bin/gtar and rename > /usr/bin/bsdtar to /usr/bin/tar. > > Any objections, suggestions, or comments? I support making bsdtar the default, and plan to integrate libtar into the package tools. Are there any plans to do an security audit of bsdtar? This may be an important issue, since tar is often used running as root to unpack downloaded archives. -Oliver