From owner-freebsd-arch@FreeBSD.ORG Tue Nov 8 12:37:33 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3262C106564A for ; Tue, 8 Nov 2011 12:37:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC4AD8FC08 for ; Tue, 8 Nov 2011 12:37:32 +0000 (UTC) Received: by wyg36 with SMTP id 36so584289wyg.13 for ; Tue, 08 Nov 2011 04:37:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bVInmB15V5d/S/QFTdomLYJ4cUCoE4bV+Mv6bfmm850=; b=eqgwxZB/x6SLQTQynygVL0H+lCvlvTQlgrKlzSUZaoYVOY+/OFtrlGQFQwALYJrkYI RZfVmVMr5K10U3AnMRnkVlJQpXNRtOKdw4BEHC1w8SOdIBM7U5X0Jr5+fBEc7jftdv4T h6zSPBbIpem6i7kjvu+YiXf34aiK9a050HFTs= MIME-Version: 1.0 Received: by 10.227.198.140 with SMTP id eo12mr32596432wbb.20.1320754405096; Tue, 08 Nov 2011 04:13:25 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Tue, 8 Nov 2011 04:13:25 -0800 (PST) In-Reply-To: <201111081018.pA8AI7ha027020@svn.freebsd.org> References: <201111081018.pA8AI7ha027020@svn.freebsd.org> Date: Tue, 8 Nov 2011 13:13:25 +0100 X-Google-Sender-Auth: AeKyKV7w0IkfNv45encLOKw1atM Message-ID: From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, FreeBSD FS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: svn commit: r227333 - in head: . sys/amd64/conf sys/arm/conf sys/conf sys/i386/conf sys/ia64/conf sys/kern sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 12:37:33 -0000 2011/11/8 Attilio Rao : > Author: attilio > Date: Tue Nov =C2=A08 10:18:07 2011 > New Revision: 227333 > URL: http://svn.freebsd.org/changeset/base/227333 > > Log: > =C2=A0Introduce the option VFS_ALLOW_NONMPSAFE and turn it on by default = on > =C2=A0all the architectures. > =C2=A0The option allows to mount non-MPSAFE filesystem. Without it, the > =C2=A0kernel will refuse to mount a non-MPSAFE filesytem. > > =C2=A0This patch is part of the effort of killing non-MPSAFE filesystems > =C2=A0from the tree. This is just a gentle reminder in order to point you further to the "official" page: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS and encourage once again people in adopting a dying FS if it really matters to them. So far, unfortunately, I didn't see a lot of activity in this area but I hope that this would change soon. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Nov 8 13:28:41 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77895106564A; Tue, 8 Nov 2011 13:28:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8E18FC1A; Tue, 8 Nov 2011 13:28:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EDE4246B09; Tue, 8 Nov 2011 08:28:40 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 862418A02E; Tue, 8 Nov 2011 08:28:40 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 8 Nov 2011 08:00:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> In-Reply-To: <20111104160319.GD6110@elvis.mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111080800.32717.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 08 Nov 2011 08:28:40 -0500 (EST) Cc: Bruce Cran , Ed Schouten , Alfred Perlstein , Jilles Tjoelker , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 13:28:41 -0000 On Friday, November 04, 2011 12:03:20 pm Alfred Perlstein wrote: > * John Baldwin [111103 19:38] wrote: > > On 11/2/11 1:20 PM, Alfred Perlstein wrote: > > >* John Baldwin [111102 11:05] wrote: > > >>On Tuesday, November 01, 2011 7:56:48 pm Bruce Cran wrote: > > >>>On 01/11/2011 17:08, John Baldwin wrote: > > >>>>I had found it via the web: http://linux.die.net/man/2/fadvise > > >>>>However, after further searching it appears to be stale (if you follow > > >>>>it's cross-reference to madvise(2), that page only has links to > > >>>>posix_fadvise() and not fadvise()). > > >>> > > >>>There's > > >>>http://www.speedware.com/HPe3000_resources/MPE_to_HP-UX_cross- > > >>reference/system_administration_cross-reference/cmd.html?cmdid=MS_1800 > > >>>for HP-UX ("*fadvise()* was derived by HP from the IEEE POSIX > > >>>1003.1-2001 Standard"), though it also has posix_fadvise. > > >> > > >>Hmm, that one actually has an extra argument. I'll just go with > > >>posix_fadvise() for now. Interesting that HP lets you OR together > > >>two policies (so you can say both "I will access this file sequentially > > >>and with noreuse"). > > > > > >Makes sense for gzip/tar. > > > > Ehh, quite possibly not for something that generic. I think you only > > want to do this if you have very specific knowledge about your access > > pattern, and I do not think they are generically applicable. > > You often spend time untarring the same tarball over and over > in your workflow John? No, but many people will do a 'tar tvf' of a file after they generate it. Would be rather silly to force that to go to disk every time, especially given tar's format where it does not have a header like zip so you have to read the whole darn thing for a 'tar tvf'. I think it would be fine to add flags to applications like 'tar' to allow users to alter their behavior in specific use cases when it makes sense. However, I think there are more workloads for 'tar' than the ones you are thinking of and we should be hesitant to change applications to use non- default settings. I do think FADV_SEQUENTIAL would be easy to add hints for, it is more FADV_NOREUSE and FADV_DONTNEED that I think warrant more caution as you can end up greatly hampering performance if you are not careful. I think for the general case we should let pagedaemon manage this instead. This is similar to the discussions about NUMA and the various notes from people who have worked with it in the past that having the kernel try to employ heuristisc often ends up breaking many things vs letting non-default behavior being driven by hints from users. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Nov 8 13:28:41 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77895106564A; Tue, 8 Nov 2011 13:28:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8E18FC1A; Tue, 8 Nov 2011 13:28:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EDE4246B09; Tue, 8 Nov 2011 08:28:40 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 862418A02E; Tue, 8 Nov 2011 08:28:40 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 8 Nov 2011 08:00:32 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> In-Reply-To: <20111104160319.GD6110@elvis.mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111080800.32717.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 08 Nov 2011 08:28:40 -0500 (EST) Cc: Bruce Cran , Ed Schouten , Alfred Perlstein , Jilles Tjoelker , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 13:28:41 -0000 On Friday, November 04, 2011 12:03:20 pm Alfred Perlstein wrote: > * John Baldwin [111103 19:38] wrote: > > On 11/2/11 1:20 PM, Alfred Perlstein wrote: > > >* John Baldwin [111102 11:05] wrote: > > >>On Tuesday, November 01, 2011 7:56:48 pm Bruce Cran wrote: > > >>>On 01/11/2011 17:08, John Baldwin wrote: > > >>>>I had found it via the web: http://linux.die.net/man/2/fadvise > > >>>>However, after further searching it appears to be stale (if you follow > > >>>>it's cross-reference to madvise(2), that page only has links to > > >>>>posix_fadvise() and not fadvise()). > > >>> > > >>>There's > > >>>http://www.speedware.com/HPe3000_resources/MPE_to_HP-UX_cross- > > >>reference/system_administration_cross-reference/cmd.html?cmdid=MS_1800 > > >>>for HP-UX ("*fadvise()* was derived by HP from the IEEE POSIX > > >>>1003.1-2001 Standard"), though it also has posix_fadvise. > > >> > > >>Hmm, that one actually has an extra argument. I'll just go with > > >>posix_fadvise() for now. Interesting that HP lets you OR together > > >>two policies (so you can say both "I will access this file sequentially > > >>and with noreuse"). > > > > > >Makes sense for gzip/tar. > > > > Ehh, quite possibly not for something that generic. I think you only > > want to do this if you have very specific knowledge about your access > > pattern, and I do not think they are generically applicable. > > You often spend time untarring the same tarball over and over > in your workflow John? No, but many people will do a 'tar tvf' of a file after they generate it. Would be rather silly to force that to go to disk every time, especially given tar's format where it does not have a header like zip so you have to read the whole darn thing for a 'tar tvf'. I think it would be fine to add flags to applications like 'tar' to allow users to alter their behavior in specific use cases when it makes sense. However, I think there are more workloads for 'tar' than the ones you are thinking of and we should be hesitant to change applications to use non- default settings. I do think FADV_SEQUENTIAL would be easy to add hints for, it is more FADV_NOREUSE and FADV_DONTNEED that I think warrant more caution as you can end up greatly hampering performance if you are not careful. I think for the general case we should let pagedaemon manage this instead. This is similar to the discussions about NUMA and the various notes from people who have worked with it in the past that having the kernel try to employ heuristisc often ends up breaking many things vs letting non-default behavior being driven by hints from users. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 00:13:30 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF94D106566B; Wed, 9 Nov 2011 00:13:30 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id ADF318FC13; Wed, 9 Nov 2011 00:13:30 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id pA90DNpf049225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Nov 2011 16:13:24 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id pA90DNRp049224; Tue, 8 Nov 2011 16:13:23 -0800 (PST) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA06272; Tue, 8 Nov 11 16:12:17 PST Date: Tue, 08 Nov 2011 23:12:12 -0800 From: perryh@pluto.rain.com To: jhb@freebsd.org Message-Id: <4eba27cc.VLW98qRWfEHj78pE%perryh@pluto.rain.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> In-Reply-To: <201111080800.32717.jhb@freebsd.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bruce@cran.org.uk, ed@80386.nl, alfred@freebsd.org, jilles@stack.nl, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 00:13:31 -0000 John Baldwin wrote: > ... many people will do a 'tar tvf' of a file after they generate it. or before they extract it. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 03:35:05 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 748BD106564A; Wed, 9 Nov 2011 03:35:05 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4248FC13; Wed, 9 Nov 2011 03:35:05 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id E03F61A3C68; Tue, 8 Nov 2011 19:35:04 -0800 (PST) Date: Tue, 8 Nov 2011 19:35:04 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20111109033504.GS6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111080800.32717.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Ed Schouten , arch@freebsd.org, Jilles Tjoelker , freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:35:05 -0000 * John Baldwin [111108 05:29] wrote: > On Friday, November 04, 2011 12:03:20 pm Alfred Perlstein wrote: > > * John Baldwin [111103 19:38] wrote: > > > On 11/2/11 1:20 PM, Alfred Perlstein wrote: > > > >* John Baldwin [111102 11:05] wrote: > > > >>On Tuesday, November 01, 2011 7:56:48 pm Bruce Cran wrote: > > > >>>On 01/11/2011 17:08, John Baldwin wrote: > > > >>>>I had found it via the web: http://linux.die.net/man/2/fadvise > > > >>>>However, after further searching it appears to be stale (if you follow > > > >>>>it's cross-reference to madvise(2), that page only has links to > > > >>>>posix_fadvise() and not fadvise()). > > > >>> > > > >>>There's > > > >>>http://www.speedware.com/HPe3000_resources/MPE_to_HP-UX_cross- > > > >>reference/system_administration_cross-reference/cmd.html?cmdid=MS_1800 > > > >>>for HP-UX ("*fadvise()* was derived by HP from the IEEE POSIX > > > >>>1003.1-2001 Standard"), though it also has posix_fadvise. > > > >> > > > >>Hmm, that one actually has an extra argument. I'll just go with > > > >>posix_fadvise() for now. Interesting that HP lets you OR together > > > >>two policies (so you can say both "I will access this file sequentially > > > >>and with noreuse"). > > > > > > > >Makes sense for gzip/tar. > > > > > > Ehh, quite possibly not for something that generic. I think you only > > > want to do this if you have very specific knowledge about your access > > > pattern, and I do not think they are generically applicable. > > > > You often spend time untarring the same tarball over and over > > in your workflow John? > > No, but many people will do a 'tar tvf' of a file after they generate it. That's not the use case I was speaking of. I was speaking of actually extracting the file as I said. One other optimization would be to set the bit when tar or other such apps notice that the file exceeds the memory of the system, effectively noting that it would be blowing out the entire cache. I don't think there's a need to respond to the rest of this so I will not. > Would be rather silly to force that to go to disk every time, especially given > tar's format where it does not have a header like zip so you have to read the > whole darn thing for a 'tar tvf'. > > I think it would be fine to add flags to applications like 'tar' to allow > users to alter their behavior in specific use cases when it makes sense. > However, I think there are more workloads for 'tar' than the ones you are > thinking of and we should be hesitant to change applications to use non- > default settings. I do think FADV_SEQUENTIAL would be easy to add hints for, > it is more FADV_NOREUSE and FADV_DONTNEED that I think warrant more caution as > you can end up greatly hampering performance if you are not careful. I think > for the general case we should let pagedaemon manage this instead. This is > similar to the discussions about NUMA and the various notes from people who > have worked with it in the past that having the kernel try to employ > heuristisc often ends up breaking many things vs letting non-default behavior > being driven by hints from users. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 03:51:56 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 982B4106564A for ; Wed, 9 Nov 2011 03:51:56 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0CD8FC0A for ; Wed, 9 Nov 2011 03:51:56 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id E03F61A3C68; Tue, 8 Nov 2011 19:35:04 -0800 (PST) Date: Tue, 8 Nov 2011 19:35:04 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20111109033504.GS6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111080800.32717.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Ed Schouten , arch@freebsd.org, Jilles Tjoelker , freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:51:56 -0000 * John Baldwin [111108 05:29] wrote: > On Friday, November 04, 2011 12:03:20 pm Alfred Perlstein wrote: > > * John Baldwin [111103 19:38] wrote: > > > On 11/2/11 1:20 PM, Alfred Perlstein wrote: > > > >* John Baldwin [111102 11:05] wrote: > > > >>On Tuesday, November 01, 2011 7:56:48 pm Bruce Cran wrote: > > > >>>On 01/11/2011 17:08, John Baldwin wrote: > > > >>>>I had found it via the web: http://linux.die.net/man/2/fadvise > > > >>>>However, after further searching it appears to be stale (if you follow > > > >>>>it's cross-reference to madvise(2), that page only has links to > > > >>>>posix_fadvise() and not fadvise()). > > > >>> > > > >>>There's > > > >>>http://www.speedware.com/HPe3000_resources/MPE_to_HP-UX_cross- > > > >>reference/system_administration_cross-reference/cmd.html?cmdid=MS_1800 > > > >>>for HP-UX ("*fadvise()* was derived by HP from the IEEE POSIX > > > >>>1003.1-2001 Standard"), though it also has posix_fadvise. > > > >> > > > >>Hmm, that one actually has an extra argument. I'll just go with > > > >>posix_fadvise() for now. Interesting that HP lets you OR together > > > >>two policies (so you can say both "I will access this file sequentially > > > >>and with noreuse"). > > > > > > > >Makes sense for gzip/tar. > > > > > > Ehh, quite possibly not for something that generic. I think you only > > > want to do this if you have very specific knowledge about your access > > > pattern, and I do not think they are generically applicable. > > > > You often spend time untarring the same tarball over and over > > in your workflow John? > > No, but many people will do a 'tar tvf' of a file after they generate it. That's not the use case I was speaking of. I was speaking of actually extracting the file as I said. One other optimization would be to set the bit when tar or other such apps notice that the file exceeds the memory of the system, effectively noting that it would be blowing out the entire cache. I don't think there's a need to respond to the rest of this so I will not. > Would be rather silly to force that to go to disk every time, especially given > tar's format where it does not have a header like zip so you have to read the > whole darn thing for a 'tar tvf'. > > I think it would be fine to add flags to applications like 'tar' to allow > users to alter their behavior in specific use cases when it makes sense. > However, I think there are more workloads for 'tar' than the ones you are > thinking of and we should be hesitant to change applications to use non- > default settings. I do think FADV_SEQUENTIAL would be easy to add hints for, > it is more FADV_NOREUSE and FADV_DONTNEED that I think warrant more caution as > you can end up greatly hampering performance if you are not careful. I think > for the general case we should let pagedaemon manage this instead. This is > similar to the discussions about NUMA and the various notes from people who > have worked with it in the past that having the kernel try to employ > heuristisc often ends up breaking many things vs letting non-default behavior > being driven by hints from users. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 04:24:13 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E369106564A; Wed, 9 Nov 2011 04:24:13 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C93518FC15; Wed, 9 Nov 2011 04:24:12 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pA94BZJr087731; Wed, 9 Nov 2011 04:11:35 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id yqxpgapnzhavc8t4dgdftphb5w; Wed, 09 Nov 2011 04:11:35 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20111109033504.GS6110@elvis.mu.org> Date: Tue, 8 Nov 2011 20:11:35 -0800 Content-Transfer-Encoding: 7bit Message-Id: <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <20111109033504.GS6110@elvis.mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1251.1) Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 04:24:13 -0000 On Nov 8, 2011, at 7:35 PM, Alfred Perlstein wrote: > > One other optimization would be to set the bit when tar or other such apps > notice that the file exceeds the memory of the system, effectively noting > that it would be blowing out the entire cache. Tar does not know the amount of RAM in the system nor the size of the cache. It definitely does not know how the kernel caching policies interact with any particular access pattern. It should be able to provide hints to the kernel about the likely access pattern, though. Tim From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 04:24:13 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E369106564A; Wed, 9 Nov 2011 04:24:13 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C93518FC15; Wed, 9 Nov 2011 04:24:12 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pA94BZJr087731; Wed, 9 Nov 2011 04:11:35 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id yqxpgapnzhavc8t4dgdftphb5w; Wed, 09 Nov 2011 04:11:35 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20111109033504.GS6110@elvis.mu.org> Date: Tue, 8 Nov 2011 20:11:35 -0800 Content-Transfer-Encoding: 7bit Message-Id: <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <20111109033504.GS6110@elvis.mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1251.1) Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 04:24:13 -0000 On Nov 8, 2011, at 7:35 PM, Alfred Perlstein wrote: > > One other optimization would be to set the bit when tar or other such apps > notice that the file exceeds the memory of the system, effectively noting > that it would be blowing out the entire cache. Tar does not know the amount of RAM in the system nor the size of the cache. It definitely does not know how the kernel caching policies interact with any particular access pattern. It should be able to provide hints to the kernel about the likely access pattern, though. Tim From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 04:35:13 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0476C106564A; Wed, 9 Nov 2011 04:35:13 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E31BB8FC0C; Wed, 9 Nov 2011 04:35:12 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 85D101A3C68; Tue, 8 Nov 2011 20:35:12 -0800 (PST) Date: Tue, 8 Nov 2011 20:35:12 -0800 From: Alfred Perlstein To: Tim Kientzle Message-ID: <20111109043512.GT6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <20111109033504.GS6110@elvis.mu.org> <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 04:35:13 -0000 * Tim Kientzle [111108 20:11] wrote: > On Nov 8, 2011, at 7:35 PM, Alfred Perlstein wrote: > > > > One other optimization would be to set the bit when tar or other such apps > > notice that the file exceeds the memory of the system, effectively noting > > that it would be blowing out the entire cache. > > Tar does not know the amount of RAM in the system > nor the size of the cache. It definitely does not know > how the kernel caching policies interact with any particular > access pattern. It would be smart to have a library function to do so, basically state "I'm about to access a file of X bytes, will this fit into cache?" A query to sysctl, perhaps 'vfs.bufspace' (I haven't bothered to look at the actual correct sysctl node to query) would give a real indication of the amount of buffer size there is. If the file to extract is larger than that size, it would be pretty obvious to use the "will not need" flag for file access. > It should be able to provide hints to the kernel > about the likely access pattern, though. There is a difference between "will access sequentially" and "will access sequentially and never again". The kernel can't decide which of those are going to happen, the only thing it might be able to do is put a process in a "penalty box" (where all of its accesses are put near the end of LRU) if it happens to be experiencing little or no cache hits. Unfortunately there is a problem with this were you can wind up putting a process in the penalty box and throttling a process and limiting its speed based on a bad guess by this hueristic. It's quite a bit smarter for an app to ask the kernel "how much cache do I have?", then have the kernel respond and based on that the app can decide to ask for a cache behavior (unless the user overrides it). -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 04:35:13 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0476C106564A; Wed, 9 Nov 2011 04:35:13 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E31BB8FC0C; Wed, 9 Nov 2011 04:35:12 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 85D101A3C68; Tue, 8 Nov 2011 20:35:12 -0800 (PST) Date: Tue, 8 Nov 2011 20:35:12 -0800 From: Alfred Perlstein To: Tim Kientzle Message-ID: <20111109043512.GT6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <20111109033504.GS6110@elvis.mu.org> <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 04:35:13 -0000 * Tim Kientzle [111108 20:11] wrote: > On Nov 8, 2011, at 7:35 PM, Alfred Perlstein wrote: > > > > One other optimization would be to set the bit when tar or other such apps > > notice that the file exceeds the memory of the system, effectively noting > > that it would be blowing out the entire cache. > > Tar does not know the amount of RAM in the system > nor the size of the cache. It definitely does not know > how the kernel caching policies interact with any particular > access pattern. It would be smart to have a library function to do so, basically state "I'm about to access a file of X bytes, will this fit into cache?" A query to sysctl, perhaps 'vfs.bufspace' (I haven't bothered to look at the actual correct sysctl node to query) would give a real indication of the amount of buffer size there is. If the file to extract is larger than that size, it would be pretty obvious to use the "will not need" flag for file access. > It should be able to provide hints to the kernel > about the likely access pattern, though. There is a difference between "will access sequentially" and "will access sequentially and never again". The kernel can't decide which of those are going to happen, the only thing it might be able to do is put a process in a "penalty box" (where all of its accesses are put near the end of LRU) if it happens to be experiencing little or no cache hits. Unfortunately there is a problem with this were you can wind up putting a process in the penalty box and throttling a process and limiting its speed based on a bad guess by this hueristic. It's quite a bit smarter for an app to ask the kernel "how much cache do I have?", then have the kernel respond and based on that the app can decide to ask for a cache behavior (unless the user overrides it). -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 06:18:16 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE771065670; Wed, 9 Nov 2011 06:18:16 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C988A8FC08; Wed, 9 Nov 2011 06:18:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pA96I8OO088574; Wed, 9 Nov 2011 06:18:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id vzw4keh838gh4n74yzvdazjisn; Wed, 09 Nov 2011 06:18:08 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20111109043512.GT6110@elvis.mu.org> Date: Tue, 8 Nov 2011 22:18:07 -0800 Content-Transfer-Encoding: 7bit Message-Id: <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <20111109033504.GS6110@elvis.mu.org> <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> <20111109043512.GT6110@elvis.mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1251.1) Cc: Bruce Cran , Ed Schouten , freebsd-arch@freebsd.org, Jilles Tjoelker , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 06:18:17 -0000 On Nov 8, 2011, at 8:35 PM, Alfred Perlstein wrote: > A query to sysctl, perhaps 'vfs.bufspace' (I haven't bothered to > look at the actual correct sysctl node to query) would give a real > indication of the amount of buffer size there is. The kernel knows the size of the file and knows how much buffer cache there is. So the kernel already knows whether the file will fit. > If the file to > extract is larger than that size, it would be pretty obvious to use > the "will not need" flag for file access. It's not at all obvious. If I have 1GB of cache and I'm going to generate and then read back a 2GB file, the best strategy is to hold the first 1GB in cache. If I'm going to write the file and it will never be read back, then the best strategy is to not cache any of it. Sometimes, a program knows which of these is likely, but if it doesn't know, it shouldn't say. Tim From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 06:18:16 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE771065670; Wed, 9 Nov 2011 06:18:16 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C988A8FC08; Wed, 9 Nov 2011 06:18:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pA96I8OO088574; Wed, 9 Nov 2011 06:18:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id vzw4keh838gh4n74yzvdazjisn; Wed, 09 Nov 2011 06:18:08 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20111109043512.GT6110@elvis.mu.org> Date: Tue, 8 Nov 2011 22:18:07 -0800 Content-Transfer-Encoding: 7bit Message-Id: <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <20111109033504.GS6110@elvis.mu.org> <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> <20111109043512.GT6110@elvis.mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1251.1) Cc: Bruce Cran , Ed Schouten , freebsd-arch@freebsd.org, Jilles Tjoelker , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 06:18:17 -0000 On Nov 8, 2011, at 8:35 PM, Alfred Perlstein wrote: > A query to sysctl, perhaps 'vfs.bufspace' (I haven't bothered to > look at the actual correct sysctl node to query) would give a real > indication of the amount of buffer size there is. The kernel knows the size of the file and knows how much buffer cache there is. So the kernel already knows whether the file will fit. > If the file to > extract is larger than that size, it would be pretty obvious to use > the "will not need" flag for file access. It's not at all obvious. If I have 1GB of cache and I'm going to generate and then read back a 2GB file, the best strategy is to hold the first 1GB in cache. If I'm going to write the file and it will never be read back, then the best strategy is to not cache any of it. Sometimes, a program knows which of these is likely, but if it doesn't know, it shouldn't say. Tim From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 11:08:50 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9679C106564A; Wed, 9 Nov 2011 11:08:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 81BEF8FC0A; Wed, 9 Nov 2011 11:08:50 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 241031A3C55; Wed, 9 Nov 2011 03:08:50 -0800 (PST) Date: Wed, 9 Nov 2011 03:08:49 -0800 From: Alfred Perlstein To: Tim Kientzle Message-ID: <20111109110849.GV6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <20111109033504.GS6110@elvis.mu.org> <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> <20111109043512.GT6110@elvis.mu.org> <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Ed Schouten , freebsd-arch@freebsd.org, Jilles Tjoelker , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 11:08:50 -0000 http://bit.ly/hwm4GC * Tim Kientzle [111108 22:18] wrote: > On Nov 8, 2011, at 8:35 PM, Alfred Perlstein wrote: > > > A query to sysctl, perhaps 'vfs.bufspace' (I haven't bothered to > > look at the actual correct sysctl node to query) would give a real > > indication of the amount of buffer size there is. > > The kernel knows the size of the file and knows how > much buffer cache there is. So the kernel already knows > whether the file will fit. > > > If the file to > > extract is larger than that size, it would be pretty obvious to use > > the "will not need" flag for file access. > > It's not at all obvious. > > If I have 1GB of cache and I'm going > to generate and then read back a 2GB file, > the best strategy is to hold the first > 1GB in cache. > > If I'm going to write the file and it will never be > read back, then the best strategy is to not > cache any of it. > > Sometimes, a program knows which of > these is likely, but if it doesn't know, it shouldn't > say. > > Tim -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 11:08:50 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9679C106564A; Wed, 9 Nov 2011 11:08:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 81BEF8FC0A; Wed, 9 Nov 2011 11:08:50 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 241031A3C55; Wed, 9 Nov 2011 03:08:50 -0800 (PST) Date: Wed, 9 Nov 2011 03:08:49 -0800 From: Alfred Perlstein To: Tim Kientzle Message-ID: <20111109110849.GV6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <20111109033504.GS6110@elvis.mu.org> <840E509B-0D63-41C2-B26A-31655F1D42C2@kientzle.com> <20111109043512.GT6110@elvis.mu.org> <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Ed Schouten , freebsd-arch@freebsd.org, Jilles Tjoelker , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 11:08:50 -0000 http://bit.ly/hwm4GC * Tim Kientzle [111108 22:18] wrote: > On Nov 8, 2011, at 8:35 PM, Alfred Perlstein wrote: > > > A query to sysctl, perhaps 'vfs.bufspace' (I haven't bothered to > > look at the actual correct sysctl node to query) would give a real > > indication of the amount of buffer size there is. > > The kernel knows the size of the file and knows how > much buffer cache there is. So the kernel already knows > whether the file will fit. > > > If the file to > > extract is larger than that size, it would be pretty obvious to use > > the "will not need" flag for file access. > > It's not at all obvious. > > If I have 1GB of cache and I'm going > to generate and then read back a 2GB file, > the best strategy is to hold the first > 1GB in cache. > > If I'm going to write the file and it will never be > read back, then the best strategy is to not > cache any of it. > > Sometimes, a program knows which of > these is likely, but if it doesn't know, it shouldn't > say. > > Tim -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 14:56:28 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B42BB106566C; Wed, 9 Nov 2011 14:56:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 87FCB8FC08; Wed, 9 Nov 2011 14:56:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 22AE346B06; Wed, 9 Nov 2011 09:56:28 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B83A38A050; Wed, 9 Nov 2011 09:56:27 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 9 Nov 2011 09:26:19 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201110281426.00013.jhb@freebsd.org> <20111109043512.GT6110@elvis.mu.org> <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> In-Reply-To: <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111090926.19447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 09 Nov 2011 09:56:27 -0500 (EST) Cc: Bruce Cran , Tim Kientzle , Jilles Tjoelker , Ed Schouten , Alfred Perlstein , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 14:56:28 -0000 On Wednesday, November 09, 2011 1:18:07 am Tim Kientzle wrote: > It's not at all obvious. > > If I have 1GB of cache and I'm going > to generate and then read back a 2GB file, > the best strategy is to hold the first > 1GB in cache. > > If I'm going to write the file and it will never be > read back, then the best strategy is to not > cache any of it. > > Sometimes, a program knows which of > these is likely, but if it doesn't know, it shouldn't > say. Exactly. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 14:56:28 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B42BB106566C; Wed, 9 Nov 2011 14:56:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 87FCB8FC08; Wed, 9 Nov 2011 14:56:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 22AE346B06; Wed, 9 Nov 2011 09:56:28 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B83A38A050; Wed, 9 Nov 2011 09:56:27 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 9 Nov 2011 09:26:19 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201110281426.00013.jhb@freebsd.org> <20111109043512.GT6110@elvis.mu.org> <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> In-Reply-To: <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111090926.19447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 09 Nov 2011 09:56:27 -0500 (EST) Cc: Bruce Cran , Tim Kientzle , Jilles Tjoelker , Ed Schouten , Alfred Perlstein , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 14:56:28 -0000 On Wednesday, November 09, 2011 1:18:07 am Tim Kientzle wrote: > It's not at all obvious. > > If I have 1GB of cache and I'm going > to generate and then read back a 2GB file, > the best strategy is to hold the first > 1GB in cache. > > If I'm going to write the file and it will never be > read back, then the best strategy is to not > cache any of it. > > Sometimes, a program knows which of > these is likely, but if it doesn't know, it shouldn't > say. Exactly. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 17:16:50 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D330106566B; Wed, 9 Nov 2011 17:16:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 291CC8FC12; Wed, 9 Nov 2011 17:16:49 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id F1D0B1A3C64; Wed, 9 Nov 2011 09:16:48 -0800 (PST) Date: Wed, 9 Nov 2011 09:16:48 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20111109171648.GX6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <20111109043512.GT6110@elvis.mu.org> <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> <201111090926.19447.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111090926.19447.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Tim Kientzle , Jilles Tjoelker , Ed Schouten , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:16:50 -0000 * John Baldwin [111109 07:00] wrote: > On Wednesday, November 09, 2011 1:18:07 am Tim Kientzle wrote: > > It's not at all obvious. > > > > If I have 1GB of cache and I'm going > > to generate and then read back a 2GB file, > > the best strategy is to hold the first > > 1GB in cache. > > > > If I'm going to write the file and it will never be > > read back, then the best strategy is to not > > cache any of it. > > > > Sometimes, a program knows which of > > these is likely, but if it doesn't know, it shouldn't > > say. > > Exactly. Exactly what? All I see you and Tim going back and forth on is that "we can't catch 100% of the cases, so it's best to do nothing". Tim's contrived example of: > > If I have 1GB of cache and I'm going > > to generate and then read back a 2GB file, > > the best strategy is to hold the first > > 1GB in cache. How exactly would a user tell tar(1) to do this on the command line? Would your average user be smart enough to do this? Is it worth making tar's default "blow out all the memory in the box" because of some esoteric use case that you and Tim seem to think exist that has not even been explicitly stated? (seems like you want some command line option to tell tar --only-cache-first-nbytes=#???) Do you realize how ridiculous that sounds? Are all heuristics bad because there's a 1% or 0.1% chance that someone will have a use-case that defeats it? The only sense I can make of your and Tim's argument is a desperate grasp to shut down an idea based on some kind of "I'll back you if you back me no matter how dumb this gets" politics rather than anything that makes sense. I'm going to leave it at politics because I actually thought the two of you were smarter than this and that's the only thing that keeps that assumption working in my head. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Nov 9 17:16:50 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D330106566B; Wed, 9 Nov 2011 17:16:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 291CC8FC12; Wed, 9 Nov 2011 17:16:49 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id F1D0B1A3C64; Wed, 9 Nov 2011 09:16:48 -0800 (PST) Date: Wed, 9 Nov 2011 09:16:48 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20111109171648.GX6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <20111109043512.GT6110@elvis.mu.org> <3D0BF37D-0C31-4509-A231-F4D1F81472D8@kientzle.com> <201111090926.19447.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111090926.19447.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Tim Kientzle , Jilles Tjoelker , Ed Schouten , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:16:50 -0000 * John Baldwin [111109 07:00] wrote: > On Wednesday, November 09, 2011 1:18:07 am Tim Kientzle wrote: > > It's not at all obvious. > > > > If I have 1GB of cache and I'm going > > to generate and then read back a 2GB file, > > the best strategy is to hold the first > > 1GB in cache. > > > > If I'm going to write the file and it will never be > > read back, then the best strategy is to not > > cache any of it. > > > > Sometimes, a program knows which of > > these is likely, but if it doesn't know, it shouldn't > > say. > > Exactly. Exactly what? All I see you and Tim going back and forth on is that "we can't catch 100% of the cases, so it's best to do nothing". Tim's contrived example of: > > If I have 1GB of cache and I'm going > > to generate and then read back a 2GB file, > > the best strategy is to hold the first > > 1GB in cache. How exactly would a user tell tar(1) to do this on the command line? Would your average user be smart enough to do this? Is it worth making tar's default "blow out all the memory in the box" because of some esoteric use case that you and Tim seem to think exist that has not even been explicitly stated? (seems like you want some command line option to tell tar --only-cache-first-nbytes=#???) Do you realize how ridiculous that sounds? Are all heuristics bad because there's a 1% or 0.1% chance that someone will have a use-case that defeats it? The only sense I can make of your and Tim's argument is a desperate grasp to shut down an idea based on some kind of "I'll back you if you back me no matter how dumb this gets" politics rather than anything that makes sense. I'm going to leave it at politics because I actually thought the two of you were smarter than this and that's the only thing that keeps that assumption working in my head. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 00:03:48 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35979106566B; Thu, 10 Nov 2011 00:03:48 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id DEC7F8FC12; Thu, 10 Nov 2011 00:03:47 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id EADCAE658E; Wed, 9 Nov 2011 23:44:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=kiby32Jg6f7s WT0S3LVGjRsGzp0=; b=y3L4XNmrZaTTVC2zohGNFrrx3SWBugcJoxgFplwLv48x VWv9ysFANvm5SFA1Jom4QBBF1ZicseT3EmoTOBRJjgFnzg5zMtB4IzF9+aClo+IP ur4G5zNifZVCwJroWy+nzuBJ4LoUUFPUfR6VrAyp2PHd5E1SLhz6zSonUG3Mlxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=aWXJxr +vu38kSeKwAWdhnrhBjX0+vdMlzF59yBDCs0LgQoPHjmDZQRQPAjctM20MMa6Kw0 oWFgsyCw6CGwIheNFM/T8LkwHXAfOYa4+nNk38jVAHHzfqcgII4xKRNoCLHMvJkI +//A6OhghpTfDvK/+X82Try+cckNxyKytG9/Q= Received: from [192.168.1.68] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id A8886E6587; Wed, 9 Nov 2011 23:44:22 +0000 (GMT) Message-ID: <4EBB104F.5010000@cran.org.uk> Date: Wed, 09 Nov 2011 23:44:15 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> In-Reply-To: <201111080800.32717.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Ed Schouten , Alfred Perlstein , Jilles Tjoelker , freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 00:03:48 -0000 On 08/11/2011 13:00, John Baldwin wrote: > I think it would be fine to add flags to applications like 'tar' to > allow users to alter their behavior in specific use cases when it > makes sense. However, I think there are more workloads for 'tar' than > the ones you are thinking of and we should be hesitant to change > applications to use non- default settings. Someone's done that for GNU tar on Linux, adding a --no-oscache switch: http://www.mysqlperformanceblog.com/2010/04/02/fadvise-may-be-not-what-you-expect/ . -- Bruce Cran From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 00:03:48 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35979106566B; Thu, 10 Nov 2011 00:03:48 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id DEC7F8FC12; Thu, 10 Nov 2011 00:03:47 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id EADCAE658E; Wed, 9 Nov 2011 23:44:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=kiby32Jg6f7s WT0S3LVGjRsGzp0=; b=y3L4XNmrZaTTVC2zohGNFrrx3SWBugcJoxgFplwLv48x VWv9ysFANvm5SFA1Jom4QBBF1ZicseT3EmoTOBRJjgFnzg5zMtB4IzF9+aClo+IP ur4G5zNifZVCwJroWy+nzuBJ4LoUUFPUfR6VrAyp2PHd5E1SLhz6zSonUG3Mlxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=aWXJxr +vu38kSeKwAWdhnrhBjX0+vdMlzF59yBDCs0LgQoPHjmDZQRQPAjctM20MMa6Kw0 oWFgsyCw6CGwIheNFM/T8LkwHXAfOYa4+nNk38jVAHHzfqcgII4xKRNoCLHMvJkI +//A6OhghpTfDvK/+X82Try+cckNxyKytG9/Q= Received: from [192.168.1.68] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id A8886E6587; Wed, 9 Nov 2011 23:44:22 +0000 (GMT) Message-ID: <4EBB104F.5010000@cran.org.uk> Date: Wed, 09 Nov 2011 23:44:15 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> In-Reply-To: <201111080800.32717.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Ed Schouten , Alfred Perlstein , Jilles Tjoelker , freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 00:03:48 -0000 On 08/11/2011 13:00, John Baldwin wrote: > I think it would be fine to add flags to applications like 'tar' to > allow users to alter their behavior in specific use cases when it > makes sense. However, I think there are more workloads for 'tar' than > the ones you are thinking of and we should be hesitant to change > applications to use non- default settings. Someone's done that for GNU tar on Linux, adding a --no-oscache switch: http://www.mysqlperformanceblog.com/2010/04/02/fadvise-may-be-not-what-you-expect/ . -- Bruce Cran From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 00:07:26 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E840106566B for ; Thu, 10 Nov 2011 00:07:26 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 22CE88FC0C for ; Thu, 10 Nov 2011 00:07:26 +0000 (UTC) Received: by qyk9 with SMTP id 9so2726194qyk.13 for ; Wed, 09 Nov 2011 16:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=vAH0Dy0By3oPC83d5jazKgj/nKS9F64SxtLQcvUJpfs=; b=J9t83eZOL8fw8jSphJAIjq/KSB5Num1p6hvRIeH7EynEoLZQvmfV0glkvsMnYsSBTo EVIxKqDJ9ARIut3jXY1Cqifo5vop118qKn7bz0QhbFb2q5htEQtP6EsNUP/rryT13G+f rNgvA6sKOUj56mCcSrAWkHlBwMJn+mWl0ANCA= MIME-Version: 1.0 Received: by 10.229.69.195 with SMTP id a3mr701046qcj.179.1320881996203; Wed, 09 Nov 2011 15:39:56 -0800 (PST) Sender: giovanni.trematerra@gmail.com Received: by 10.229.1.216 with HTTP; Wed, 9 Nov 2011 15:39:56 -0800 (PST) Date: Thu, 10 Nov 2011 00:39:56 +0100 X-Google-Sender-Auth: VvrICxyrwdDWNHVAufUudZsfN9s Message-ID: From: Giovanni Trematerra To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 00:07:26 -0000 Are they deprecated enough to be removed, now? FYI FIFO doesn't support them. -- Gianni ================================= --- sys/kern/sys_pipe.c (revision 227233) +++ sys/kern/sys_pipe.c (working copy) @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td) *(int *)data = fgetown(&mpipe->pipe_sigio); break; - /* This is deprecated, FIOSETOWN should be used instead. */ - case TIOCSPGRP: - PIPE_UNLOCK(mpipe); - error = fsetown(-(*(int *)data), &mpipe->pipe_sigio); - goto out_unlocked; - - /* This is deprecated, FIOGETOWN should be used instead. */ - case TIOCGPGRP: - *(int *)data = -fgetown(&mpipe->pipe_sigio); - break; - default: error = ENOTTY; break; From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 00:31:56 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5A881065677; Thu, 10 Nov 2011 00:31:56 +0000 (UTC) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB478FC20; Thu, 10 Nov 2011 00:31:56 +0000 (UTC) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by elvis.mu.org (Postfix) with ESMTPSA id 31CA61A3C39; Wed, 9 Nov 2011 16:16:34 -0800 (PST) Received: by iakl21 with SMTP id l21so900848iak.13 for ; Wed, 09 Nov 2011 16:16:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.82.2 with SMTP id z2mr1197015ibk.67.1320884193488; Wed, 09 Nov 2011 16:16:33 -0800 (PST) Received: by 10.231.17.141 with HTTP; Wed, 9 Nov 2011 16:16:33 -0800 (PST) In-Reply-To: <4EBB104F.5010000@cran.org.uk> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> Date: Wed, 9 Nov 2011 16:16:33 -0800 Message-ID: From: Paul Saab To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Cc: Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 00:31:56 -0000 On Wed, Nov 9, 2011 at 3:44 PM, Bruce Cran wrote: > On 08/11/2011 13:00, John Baldwin wrote: >> >> I think it would be fine to add flags to applications like 'tar' to allow >> users to alter their behavior in specific use cases when it makes sense. >> However, I think there are more workloads for 'tar' than the ones you are >> thinking of and we should be hesitant to change applications to use non- >> default settings. > > Someone's done that for GNU tar on Linux, adding a --no-oscache switch: > http://www.mysqlperformanceblog.com/2010/04/02/fadvise-may-be-not-what-you-expect/ So adding this support is good, but not for general purpose. It's really only good when you're pumping gigs of data through tar. I did this for libarchive (plus other work for O_DIRECT reading and creating the archive) for copying large amounts of data without impacting a running system.. It worked great for this, but then it absolutely fails when extracting a tar archive with millions of little files because of all the sync operations. Anyway, this is a good option to enable and has very practical uses out there, but it should be turned on with an option and not on by default. From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 00:31:56 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5A881065677; Thu, 10 Nov 2011 00:31:56 +0000 (UTC) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB478FC20; Thu, 10 Nov 2011 00:31:56 +0000 (UTC) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by elvis.mu.org (Postfix) with ESMTPSA id 31CA61A3C39; Wed, 9 Nov 2011 16:16:34 -0800 (PST) Received: by iakl21 with SMTP id l21so900848iak.13 for ; Wed, 09 Nov 2011 16:16:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.82.2 with SMTP id z2mr1197015ibk.67.1320884193488; Wed, 09 Nov 2011 16:16:33 -0800 (PST) Received: by 10.231.17.141 with HTTP; Wed, 9 Nov 2011 16:16:33 -0800 (PST) In-Reply-To: <4EBB104F.5010000@cran.org.uk> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> Date: Wed, 9 Nov 2011 16:16:33 -0800 Message-ID: From: Paul Saab To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Cc: Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 00:31:56 -0000 On Wed, Nov 9, 2011 at 3:44 PM, Bruce Cran wrote: > On 08/11/2011 13:00, John Baldwin wrote: >> >> I think it would be fine to add flags to applications like 'tar' to allow >> users to alter their behavior in specific use cases when it makes sense. >> However, I think there are more workloads for 'tar' than the ones you are >> thinking of and we should be hesitant to change applications to use non- >> default settings. > > Someone's done that for GNU tar on Linux, adding a --no-oscache switch: > http://www.mysqlperformanceblog.com/2010/04/02/fadvise-may-be-not-what-you-expect/ So adding this support is good, but not for general purpose. It's really only good when you're pumping gigs of data through tar. I did this for libarchive (plus other work for O_DIRECT reading and creating the archive) for copying large amounts of data without impacting a running system.. It worked great for this, but then it absolutely fails when extracting a tar archive with millions of little files because of all the sync operations. Anyway, this is a good option to enable and has very practical uses out there, but it should be turned on with an option and not on by default. From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 00:57:08 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 082031065670; Thu, 10 Nov 2011 00:57:08 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 812F78FC08; Thu, 10 Nov 2011 00:57:07 +0000 (UTC) Received: by yenl2 with SMTP id l2so420924yen.13 for ; Wed, 09 Nov 2011 16:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pwYm3aNitmzAeAEK3+m9sd9Td2lPTVoSs3yFFwSiUfg=; b=47fOdyvyDlPKhQEBSqfa6k+T1Och1a9+xYNhC+ouswr6uDuu+/Vm/EaNo5VdwG4gXS DUhDdCMwQfdb2MivLdvGTOyuhDt7SjaZbs+L6rQZYJyC+hd4lYsu65JpPuWpcV8m0mxQ MgZ/WbbHUgtsmfNR1lzXRB7ECiQF/RFkIZ/lo= MIME-Version: 1.0 Received: by 10.50.189.231 with SMTP id gl7mr5762438igc.44.1320886626152; Wed, 09 Nov 2011 16:57:06 -0800 (PST) Received: by 10.50.186.233 with HTTP; Wed, 9 Nov 2011 16:57:06 -0800 (PST) In-Reply-To: <201111080800.32717.jhb@freebsd.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> Date: Wed, 9 Nov 2011 16:57:06 -0800 Message-ID: From: Peter Wemm To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 00:57:08 -0000 On Tue, Nov 8, 2011 at 5:00 AM, John Baldwin wrote: > On Friday, November 04, 2011 12:03:20 pm Alfred Perlstein wrote: >> * John Baldwin [111103 19:38] wrote: >> > On 11/2/11 1:20 PM, Alfred Perlstein wrote: >> > >* John Baldwin =A0[111102 11:05] wrote: >> > >>On Tuesday, November 01, 2011 7:56:48 pm Bruce Cran wrote: >> > >>>On 01/11/2011 17:08, John Baldwin wrote: >> > >>>>I had found it via the web: http://linux.die.net/man/2/fadvise >> > >>>>However, after further searching it appears to be stale (if you fo= llow >> > >>>>it's cross-reference to madvise(2), that page only has links to >> > >>>>posix_fadvise() and not fadvise()). >> > >>> >> > >>>There's >> > >>>http://www.speedware.com/HPe3000_resources/MPE_to_HP-UX_cross- >> > >>reference/system_administration_cross-reference/cmd.html?cmdid=3DMS_= 1800 >> > >>>for HP-UX ("*fadvise()* was derived by HP from the IEEE POSIX >> > >>>1003.1-2001 Standard"), though it also has posix_fadvise. >> > >> >> > >>Hmm, that one actually has an extra argument. =A0I'll just go with >> > >>posix_fadvise() for now. =A0Interesting that HP lets you OR together >> > >>two policies (so you can say both "I will access this file sequentia= lly >> > >>and with noreuse"). >> > > >> > >Makes sense for gzip/tar. >> > >> > Ehh, quite possibly not for something that generic. =A0I think you onl= y >> > want to do this if you have very specific knowledge about your access >> > pattern, and I do not think they are generically applicable. >> >> You often spend time untarring the same tarball over and over >> in your workflow John? > > No, but many people will do a 'tar tvf' of a file after they generate it. > Would be rather silly to force that to go to disk every time, especially = given > tar's format where it does not have a header like zip so you have to read= the > whole darn thing for a 'tar tvf'. Did 'tar tvf' stop seeking and doing random seek/reads for raw tar files? I know it can't do this for a stream compressed file and there's no choice but to read it all. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 01:03:53 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 835E91065678 for ; Thu, 10 Nov 2011 01:03:53 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 42E1E8FC0C for ; Thu, 10 Nov 2011 01:03:53 +0000 (UTC) Received: by ggnk3 with SMTP id k3so3308135ggn.13 for ; Wed, 09 Nov 2011 17:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pwYm3aNitmzAeAEK3+m9sd9Td2lPTVoSs3yFFwSiUfg=; b=47fOdyvyDlPKhQEBSqfa6k+T1Och1a9+xYNhC+ouswr6uDuu+/Vm/EaNo5VdwG4gXS DUhDdCMwQfdb2MivLdvGTOyuhDt7SjaZbs+L6rQZYJyC+hd4lYsu65JpPuWpcV8m0mxQ MgZ/WbbHUgtsmfNR1lzXRB7ECiQF/RFkIZ/lo= MIME-Version: 1.0 Received: by 10.50.189.231 with SMTP id gl7mr5762438igc.44.1320886626152; Wed, 09 Nov 2011 16:57:06 -0800 (PST) Received: by 10.50.186.233 with HTTP; Wed, 9 Nov 2011 16:57:06 -0800 (PST) In-Reply-To: <201111080800.32717.jhb@freebsd.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> Date: Wed, 9 Nov 2011 16:57:06 -0800 Message-ID: From: Peter Wemm To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 01:03:53 -0000 On Tue, Nov 8, 2011 at 5:00 AM, John Baldwin wrote: > On Friday, November 04, 2011 12:03:20 pm Alfred Perlstein wrote: >> * John Baldwin [111103 19:38] wrote: >> > On 11/2/11 1:20 PM, Alfred Perlstein wrote: >> > >* John Baldwin =A0[111102 11:05] wrote: >> > >>On Tuesday, November 01, 2011 7:56:48 pm Bruce Cran wrote: >> > >>>On 01/11/2011 17:08, John Baldwin wrote: >> > >>>>I had found it via the web: http://linux.die.net/man/2/fadvise >> > >>>>However, after further searching it appears to be stale (if you fo= llow >> > >>>>it's cross-reference to madvise(2), that page only has links to >> > >>>>posix_fadvise() and not fadvise()). >> > >>> >> > >>>There's >> > >>>http://www.speedware.com/HPe3000_resources/MPE_to_HP-UX_cross- >> > >>reference/system_administration_cross-reference/cmd.html?cmdid=3DMS_= 1800 >> > >>>for HP-UX ("*fadvise()* was derived by HP from the IEEE POSIX >> > >>>1003.1-2001 Standard"), though it also has posix_fadvise. >> > >> >> > >>Hmm, that one actually has an extra argument. =A0I'll just go with >> > >>posix_fadvise() for now. =A0Interesting that HP lets you OR together >> > >>two policies (so you can say both "I will access this file sequentia= lly >> > >>and with noreuse"). >> > > >> > >Makes sense for gzip/tar. >> > >> > Ehh, quite possibly not for something that generic. =A0I think you onl= y >> > want to do this if you have very specific knowledge about your access >> > pattern, and I do not think they are generically applicable. >> >> You often spend time untarring the same tarball over and over >> in your workflow John? > > No, but many people will do a 'tar tvf' of a file after they generate it. > Would be rather silly to force that to go to disk every time, especially = given > tar's format where it does not have a header like zip so you have to read= the > whole darn thing for a 'tar tvf'. Did 'tar tvf' stop seeking and doing random seek/reads for raw tar files? I know it can't do this for a stream compressed file and there's no choice but to read it all. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 01:18:24 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D251106564A; Thu, 10 Nov 2011 01:18:24 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id D2FB48FC0A; Thu, 10 Nov 2011 01:18:23 +0000 (UTC) Received: by ggnk3 with SMTP id k3so3323720ggn.13 for ; Wed, 09 Nov 2011 17:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lzQDNjjA4t+0L5IsD51Xnj2KBQqT5/fplBQxuXb2Kq0=; b=z8NKl1vbBgedZX+6WxGMZguSNu3MnjqTUHcBk6+/bVniQ2yzUZT4+kiASb8UF7rJvD o9xjuYdqxaJojp9I81Azqp25VxLtxCodQcEb/rwVeIaqo/NMg1oGaNlyUYKyQ1xNIgMt Q5UuoaKC0lrL3eXFhnahvBLZKC6AYKHkjmYJc= MIME-Version: 1.0 Received: by 10.50.17.197 with SMTP id q5mr5719457igd.2.1320886177763; Wed, 09 Nov 2011 16:49:37 -0800 (PST) Received: by 10.50.186.233 with HTTP; Wed, 9 Nov 2011 16:49:37 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Nov 2011 16:49:37 -0800 Message-ID: From: Peter Wemm To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 01:18:24 -0000 On Wed, Nov 9, 2011 at 3:39 PM, Giovanni Trematerra wr= ote: > Are they deprecated enough to be removed, now? > FYI FIFO doesn't support them. > > -- > Gianni > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/sys_pipe.c (revision 227233) > +++ sys/kern/sys_pipe.c (working copy) > @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td) > =A0 =A0 =A0 =A0*(int *)data =3D fgetown(&mpipe->pipe_sigio); > =A0 =A0 =A0 =A0break; > > - =A0 /* This is deprecated, FIOSETOWN should be used instead. */ > - =A0 case TIOCSPGRP: > - =A0 =A0 =A0 PIPE_UNLOCK(mpipe); > - =A0 =A0 =A0 error =3D fsetown(-(*(int *)data), &mpipe->pipe_sigio); > - =A0 =A0 =A0 goto out_unlocked; > - > - =A0 /* This is deprecated, FIOGETOWN should be used instead. */ > - =A0 case TIOCGPGRP: > - =A0 =A0 =A0 *(int *)data =3D -fgetown(&mpipe->pipe_sigio); > - =A0 =A0 =A0 break; > - > =A0 =A0default: > =A0 =A0 =A0 =A0error =3D ENOTTY; Be very very careful with this. It's part of the classic BSD job control API. It would be wise to survey whether any ports shells use this. You might also want to consider things like this in libc: int tcsetpgrp(int fd, pid_t pgrp) { int s; s =3D pgrp; return (_ioctl(fd, TIOCSPGRP, &s)); } Our own libc code uses this, albeit on an API intended to be used on a tty. The shell I'd be most concerned about is csh/tcsh in our tree. It has quite an #ifdef legacy layer and I couldn't convince myself it wasn't using this indirectly (or the tc* functions) on pipes. It might also be an idea to see if the linux compat layer can be switched over to using the newer API. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 01:25:43 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 861FB1065677; Thu, 10 Nov 2011 01:25:43 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 72CB58FC12; Thu, 10 Nov 2011 01:25:43 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 2574A1A3C46; Wed, 9 Nov 2011 17:25:43 -0800 (PST) Date: Wed, 9 Nov 2011 17:25:42 -0800 From: Alfred Perlstein To: Paul Saab Message-ID: <20111110012542.GA6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Ed Schouten , freebsd-arch@freebsd.org, Jilles Tjoelker , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 01:25:43 -0000 * Paul Saab [111109 16:32] wrote: > On Wed, Nov 9, 2011 at 3:44 PM, Bruce Cran wrote: > > On 08/11/2011 13:00, John Baldwin wrote: > >> > >> I think it would be fine to add flags to applications like 'tar' to allow > >> users to alter their behavior in specific use cases when it makes sense. > >> However, I think there are more workloads for 'tar' than the ones you are > >> thinking of and we should be hesitant to change applications to use non- > >> default settings. > > > > Someone's done that for GNU tar on Linux, adding a --no-oscache switch: > > http://www.mysqlperformanceblog.com/2010/04/02/fadvise-may-be-not-what-you-expect/ > > So adding this support is good, but not for general purpose. It's > really only good when you're pumping gigs of data through tar. I did > this for libarchive (plus other work for O_DIRECT reading and > creating the archive) for copying large amounts of data without > impacting a running system.. It worked great for this, but then it > absolutely fails when extracting a tar archive with millions of little > files because of all the sync operations. I've thought about this and it almost makes sense to have a secondary LRU that such pages would wind up in that is much smaller than the system one. I'm pretty sure there are a number of papers on this, but I've not looked over them in a long while. > > Anyway, this is a good option to enable and has very practical uses > out there, but it should be turned on with an option and not on by > default. What about the operation of just reading the tar archive itself? -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 01:25:43 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 861FB1065677; Thu, 10 Nov 2011 01:25:43 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 72CB58FC12; Thu, 10 Nov 2011 01:25:43 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 2574A1A3C46; Wed, 9 Nov 2011 17:25:43 -0800 (PST) Date: Wed, 9 Nov 2011 17:25:42 -0800 From: Alfred Perlstein To: Paul Saab Message-ID: <20111110012542.GA6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Bruce Cran , Ed Schouten , freebsd-arch@freebsd.org, Jilles Tjoelker , arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 01:25:43 -0000 * Paul Saab [111109 16:32] wrote: > On Wed, Nov 9, 2011 at 3:44 PM, Bruce Cran wrote: > > On 08/11/2011 13:00, John Baldwin wrote: > >> > >> I think it would be fine to add flags to applications like 'tar' to allow > >> users to alter their behavior in specific use cases when it makes sense. > >> However, I think there are more workloads for 'tar' than the ones you are > >> thinking of and we should be hesitant to change applications to use non- > >> default settings. > > > > Someone's done that for GNU tar on Linux, adding a --no-oscache switch: > > http://www.mysqlperformanceblog.com/2010/04/02/fadvise-may-be-not-what-you-expect/ > > So adding this support is good, but not for general purpose. It's > really only good when you're pumping gigs of data through tar. I did > this for libarchive (plus other work for O_DIRECT reading and > creating the archive) for copying large amounts of data without > impacting a running system.. It worked great for this, but then it > absolutely fails when extracting a tar archive with millions of little > files because of all the sync operations. I've thought about this and it almost makes sense to have a secondary LRU that such pages would wind up in that is much smaller than the system one. I'm pretty sure there are a number of papers on this, but I've not looked over them in a long while. > > Anyway, this is a good option to enable and has very practical uses > out there, but it should be turned on with an option and not on by > default. What about the operation of just reading the tar archive itself? -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 01:47:59 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E61B6106564A; Thu, 10 Nov 2011 01:47:58 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7408FC13; Thu, 10 Nov 2011 01:47:58 +0000 (UTC) Received: by ggnk3 with SMTP id k3so3356527ggn.13 for ; Wed, 09 Nov 2011 17:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8+Ux4IIGfluUEknWx63r6PiRJRoCt/8dmgWqwyDF380=; b=el3XHnJ8PsHgRMH+AhifVNbAQZLLRgUS8jvZGuFCBLE9WLemJxr75bBGgs5D3Y7XNY X/NihSsVVOrvJeVcMcZvGYv3yR2kp7H+swqpv62DvMdLXWQ+A/sycZ+GXoQkWvHn2yZn cxm/hmtf97Cq1dpj1I/71udmCsqr0B6O6alns= MIME-Version: 1.0 Received: by 10.50.161.131 with SMTP id xs3mr5799318igb.23.1320889677469; Wed, 09 Nov 2011 17:47:57 -0800 (PST) Received: by 10.50.186.233 with HTTP; Wed, 9 Nov 2011 17:47:57 -0800 (PST) In-Reply-To: <20111110012542.GA6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> <20111110012542.GA6110@elvis.mu.org> Date: Wed, 9 Nov 2011 17:47:57 -0800 Message-ID: From: Peter Wemm To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , Ed Schouten , Paul Saab , Jilles Tjoelker , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 01:47:59 -0000 On Wed, Nov 9, 2011 at 5:25 PM, Alfred Perlstein wrote= : > * Paul Saab [111109 16:32] wrote: >> On Wed, Nov 9, 2011 at 3:44 PM, Bruce Cran wrote: >> > On 08/11/2011 13:00, John Baldwin wrote: >> >> >> >> I think it would be fine to add flags to applications like 'tar' to a= llow >> >> users to alter their behavior in specific use cases when it makes sen= se. >> >> However, I think there are more workloads for 'tar' than the ones you= are >> >> thinking of and we should be hesitant to change applications to use n= on- >> >> default settings. >> > >> > Someone's done that for GNU tar on Linux, adding a --no-oscache switch= : >> > http://www.mysqlperformanceblog.com/2010/04/02/fadvise-may-be-not-what= -you-expect/ >> >> So adding this support is good, but not for general purpose. =A0It's >> really only good when you're pumping gigs of data through tar. =A0I did >> this for libarchive =A0(plus other work for O_DIRECT reading and >> creating the archive) for copying large amounts of data without >> impacting a running system.. It worked great for this, but then it >> absolutely fails when extracting a tar archive with millions of little >> files because of all the sync operations. > > I've thought about this and it almost makes sense to have a secondary > LRU that such pages would wind up in that is much smaller than the system > one. =A0I'm pretty sure there are a number of papers on this, but I've no= t > looked over them in a long while. We actually do have a fairly extensive anti-swamping mechanisms in place, but they are in somewhat obscure places or are side effects of other policies elsewhere. eg: the vmio kva mapping space is limited and the dirty fraction is enforced there. This provides the file write based anti-swamping back pressure. This of course is completely bypassed with mmap reads/writes. That's why writing to a huge mmap file hits like a truck, but doing write() to the same file does not. >> >> Anyway, this is a good option to enable and has very practical uses >> out there, but it should be turned on with an option and not on by >> default. > > What about the operation of just reading the tar archive itself? Personally, I really don't want to blow away useful cache contents with a tar file unless I explicitly say so. I'm generally more worried about keeping usefully cached random bits of files that are scattered all over the drive than with a sequentially readable tar file that is a best case scenario for file reads. I'd rather read a 2GB file sequentially twice than to kick out 2GB of random access data. In any case, fadvise() is a tool that we should have. Deciding on tar(1) policy is an entirely separate thing. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 01:47:59 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E61B6106564A; Thu, 10 Nov 2011 01:47:58 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7408FC13; Thu, 10 Nov 2011 01:47:58 +0000 (UTC) Received: by ggnk3 with SMTP id k3so3356527ggn.13 for ; Wed, 09 Nov 2011 17:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8+Ux4IIGfluUEknWx63r6PiRJRoCt/8dmgWqwyDF380=; b=el3XHnJ8PsHgRMH+AhifVNbAQZLLRgUS8jvZGuFCBLE9WLemJxr75bBGgs5D3Y7XNY X/NihSsVVOrvJeVcMcZvGYv3yR2kp7H+swqpv62DvMdLXWQ+A/sycZ+GXoQkWvHn2yZn cxm/hmtf97Cq1dpj1I/71udmCsqr0B6O6alns= MIME-Version: 1.0 Received: by 10.50.161.131 with SMTP id xs3mr5799318igb.23.1320889677469; Wed, 09 Nov 2011 17:47:57 -0800 (PST) Received: by 10.50.186.233 with HTTP; Wed, 9 Nov 2011 17:47:57 -0800 (PST) In-Reply-To: <20111110012542.GA6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> <20111110012542.GA6110@elvis.mu.org> Date: Wed, 9 Nov 2011 17:47:57 -0800 Message-ID: From: Peter Wemm To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , Ed Schouten , Paul Saab , Jilles Tjoelker , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 01:47:59 -0000 On Wed, Nov 9, 2011 at 5:25 PM, Alfred Perlstein wrote= : > * Paul Saab [111109 16:32] wrote: >> On Wed, Nov 9, 2011 at 3:44 PM, Bruce Cran wrote: >> > On 08/11/2011 13:00, John Baldwin wrote: >> >> >> >> I think it would be fine to add flags to applications like 'tar' to a= llow >> >> users to alter their behavior in specific use cases when it makes sen= se. >> >> However, I think there are more workloads for 'tar' than the ones you= are >> >> thinking of and we should be hesitant to change applications to use n= on- >> >> default settings. >> > >> > Someone's done that for GNU tar on Linux, adding a --no-oscache switch= : >> > http://www.mysqlperformanceblog.com/2010/04/02/fadvise-may-be-not-what= -you-expect/ >> >> So adding this support is good, but not for general purpose. =A0It's >> really only good when you're pumping gigs of data through tar. =A0I did >> this for libarchive =A0(plus other work for O_DIRECT reading and >> creating the archive) for copying large amounts of data without >> impacting a running system.. It worked great for this, but then it >> absolutely fails when extracting a tar archive with millions of little >> files because of all the sync operations. > > I've thought about this and it almost makes sense to have a secondary > LRU that such pages would wind up in that is much smaller than the system > one. =A0I'm pretty sure there are a number of papers on this, but I've no= t > looked over them in a long while. We actually do have a fairly extensive anti-swamping mechanisms in place, but they are in somewhat obscure places or are side effects of other policies elsewhere. eg: the vmio kva mapping space is limited and the dirty fraction is enforced there. This provides the file write based anti-swamping back pressure. This of course is completely bypassed with mmap reads/writes. That's why writing to a huge mmap file hits like a truck, but doing write() to the same file does not. >> >> Anyway, this is a good option to enable and has very practical uses >> out there, but it should be turned on with an option and not on by >> default. > > What about the operation of just reading the tar archive itself? Personally, I really don't want to blow away useful cache contents with a tar file unless I explicitly say so. I'm generally more worried about keeping usefully cached random bits of files that are scattered all over the drive than with a sequentially readable tar file that is a best case scenario for file reads. I'd rather read a 2GB file sequentially twice than to kick out 2GB of random access data. In any case, fadvise() is a tool that we should have. Deciding on tar(1) policy is an entirely separate thing. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 02:21:35 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74CA7106564A; Thu, 10 Nov 2011 02:21:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 310068FC08; Thu, 10 Nov 2011 02:21:34 +0000 (UTC) Received: by iakl21 with SMTP id l21so1042642iak.13 for ; Wed, 09 Nov 2011 18:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HTHDWi5rIr1qtU1KERsTgOoqjNUYB9/lR1D3Coj+fUc=; b=ND/fpI+7m7zZ7H2xNb9AuynTGT4iP00I2wQud7M05/xerqgu8ccpzVZezteEapI5XA kIBBqCK5IiJd0+zsgiKQZEz6S4fIJF+Gt20jTDwLj6BmsbEKDROewAAAWHVYnG+eZmrh 56x6aVuRizG2TaIUGwM1/5G6uidg76jQelKPo= Received: by 10.231.82.11 with SMTP id z11mr1242707ibk.77.1320889928932; Wed, 09 Nov 2011 17:52:08 -0800 (PST) Received: from kruse-180.4.ixsystems.com (drawbridge.ixsystems.com. [206.40.55.65]) by mx.google.com with ESMTPS id jm11sm9270928ibb.1.2011.11.09.17.52.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Nov 2011 17:52:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Wed, 9 Nov 2011 17:52:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Wemm X-Mailer: Apple Mail (2.1084) Cc: Giovanni Trematerra , freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 02:21:35 -0000 On Nov 9, 2011, at 4:49 PM, Peter Wemm wrote: > On Wed, Nov 9, 2011 at 3:39 PM, Giovanni Trematerra = wrote: >> Are they deprecated enough to be removed, now? >> FYI FIFO doesn't support them. >>=20 >> -- >> Gianni >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/kern/sys_pipe.c (revision 227233) >> +++ sys/kern/sys_pipe.c (working copy) >> @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td) >> *(int *)data =3D fgetown(&mpipe->pipe_sigio); >> break; >>=20 >> - /* This is deprecated, FIOSETOWN should be used instead. */ >> - case TIOCSPGRP: >> - PIPE_UNLOCK(mpipe); >> - error =3D fsetown(-(*(int *)data), &mpipe->pipe_sigio); >> - goto out_unlocked; >> - >> - /* This is deprecated, FIOGETOWN should be used instead. */ >> - case TIOCGPGRP: >> - *(int *)data =3D -fgetown(&mpipe->pipe_sigio); >> - break; >> - >> default: >> error =3D ENOTTY; >=20 > Be very very careful with this. It's part of the classic BSD job > control API. It would be wise to survey whether any ports shells use > this. >=20 > You might also want to consider things like this in libc: > int > tcsetpgrp(int fd, pid_t pgrp) > { > int s; >=20 > s =3D pgrp; > return (_ioctl(fd, TIOCSPGRP, &s)); > } > Our own libc code uses this, albeit on an API intended to be used on a = tty. >=20 > The shell I'd be most concerned about is csh/tcsh in our tree. It has > quite an #ifdef legacy layer and I couldn't convince myself it wasn't > using this indirectly (or the tc* functions) on pipes. >=20 > It might also be an idea to see if the linux compat layer can be > switched over to using the newer API. Move to a compat library perhaps? -Garrett= From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 03:18:29 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 329131065670 for ; Thu, 10 Nov 2011 03:18:29 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 137D78FC12 for ; Thu, 10 Nov 2011 03:18:28 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id A64E41A3C3B; Wed, 9 Nov 2011 19:18:28 -0800 (PST) Date: Wed, 9 Nov 2011 19:18:28 -0800 From: Alfred Perlstein To: Garrett Cooper Message-ID: <20111110031828.GC6110@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Giovanni Trematerra , freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 03:18:29 -0000 This just reeks of gratuitous breakage. Sure it's marked depricated, but there's little reason to break a ton of applications just to remove 11 lines of code. Maybe we can put it under an ifndef IVORY_TOWER. -Alfred * Garrett Cooper [111109 18:22] wrote: > On Nov 9, 2011, at 4:49 PM, Peter Wemm wrote: > > > On Wed, Nov 9, 2011 at 3:39 PM, Giovanni Trematerra wrote: > >> Are they deprecated enough to be removed, now? > >> FYI FIFO doesn't support them. > >> > >> -- > >> Gianni > >> > >> ================================= > >> --- sys/kern/sys_pipe.c (revision 227233) > >> +++ sys/kern/sys_pipe.c (working copy) > >> @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td) > >> *(int *)data = fgetown(&mpipe->pipe_sigio); > >> break; > >> > >> - /* This is deprecated, FIOSETOWN should be used instead. */ > >> - case TIOCSPGRP: > >> - PIPE_UNLOCK(mpipe); > >> - error = fsetown(-(*(int *)data), &mpipe->pipe_sigio); > >> - goto out_unlocked; > >> - > >> - /* This is deprecated, FIOGETOWN should be used instead. */ > >> - case TIOCGPGRP: > >> - *(int *)data = -fgetown(&mpipe->pipe_sigio); > >> - break; > >> - > >> default: > >> error = ENOTTY; > > > > Be very very careful with this. It's part of the classic BSD job > > control API. It would be wise to survey whether any ports shells use > > this. > > > > You might also want to consider things like this in libc: > > int > > tcsetpgrp(int fd, pid_t pgrp) > > { > > int s; > > > > s = pgrp; > > return (_ioctl(fd, TIOCSPGRP, &s)); > > } > > Our own libc code uses this, albeit on an API intended to be used on a tty. > > > > The shell I'd be most concerned about is csh/tcsh in our tree. It has > > quite an #ifdef legacy layer and I couldn't convince myself it wasn't > > using this indirectly (or the tc* functions) on pipes. > > > > It might also be an idea to see if the linux compat layer can be > > switched over to using the newer API. > > Move to a compat library perhaps? > -Garrett_______________________________________________ > 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" -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 04:47:49 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3823106566B; Thu, 10 Nov 2011 04:47:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBA38FC12; Thu, 10 Nov 2011 04:47:49 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAA4lYEG013142 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 21:47:36 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20111110031828.GC6110@elvis.mu.org> Date: Wed, 9 Nov 2011 21:47:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5CCE304D-FF92-45F1-8D1F-7B9EA224E417@bsdimp.com> References: <20111110031828.GC6110@elvis.mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 09 Nov 2011 21:47:37 -0700 (MST) Cc: Garrett Cooper , Giovanni Trematerra , freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 04:47:49 -0000 I tend to agree: aren't there more pressing problems in the project that = will solve actual problems rather than create a lot of work to save a = tiny number of bytes in the object code. Warner On Nov 9, 2011, at 8:18 PM, Alfred Perlstein wrote: > This just reeks of gratuitous breakage. Sure it's=20 > marked depricated, but there's little reason to break a ton > of applications just to remove 11 lines of code. >=20 > Maybe we can put it under an ifndef IVORY_TOWER. >=20 > -Alfred >=20 > * Garrett Cooper [111109 18:22] wrote: >> On Nov 9, 2011, at 4:49 PM, Peter Wemm wrote: >>=20 >>> On Wed, Nov 9, 2011 at 3:39 PM, Giovanni Trematerra = wrote: >>>> Are they deprecated enough to be removed, now? >>>> FYI FIFO doesn't support them. >>>>=20 >>>> -- >>>> Gianni >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- sys/kern/sys_pipe.c (revision 227233) >>>> +++ sys/kern/sys_pipe.c (working copy) >>>> @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td) >>>> *(int *)data =3D fgetown(&mpipe->pipe_sigio); >>>> break; >>>>=20 >>>> - /* This is deprecated, FIOSETOWN should be used instead. */ >>>> - case TIOCSPGRP: >>>> - PIPE_UNLOCK(mpipe); >>>> - error =3D fsetown(-(*(int *)data), &mpipe->pipe_sigio); >>>> - goto out_unlocked; >>>> - >>>> - /* This is deprecated, FIOGETOWN should be used instead. */ >>>> - case TIOCGPGRP: >>>> - *(int *)data =3D -fgetown(&mpipe->pipe_sigio); >>>> - break; >>>> - >>>> default: >>>> error =3D ENOTTY; >>>=20 >>> Be very very careful with this. It's part of the classic BSD job >>> control API. It would be wise to survey whether any ports shells = use >>> this. >>>=20 >>> You might also want to consider things like this in libc: >>> int >>> tcsetpgrp(int fd, pid_t pgrp) >>> { >>> int s; >>>=20 >>> s =3D pgrp; >>> return (_ioctl(fd, TIOCSPGRP, &s)); >>> } >>> Our own libc code uses this, albeit on an API intended to be used on = a tty. >>>=20 >>> The shell I'd be most concerned about is csh/tcsh in our tree. It = has >>> quite an #ifdef legacy layer and I couldn't convince myself it = wasn't >>> using this indirectly (or the tc* functions) on pipes. >>>=20 >>> It might also be an idea to see if the linux compat layer can be >>> switched over to using the newer API. >>=20 >> Move to a compat library perhaps? >> -Garrett_______________________________________________ >> 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" >=20 > --=20 > - Alfred Perlstein > .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 > .- FreeBSD committer > _______________________________________________ > 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" >=20 >=20 From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 06:03:21 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC8AD106566B; Thu, 10 Nov 2011 06:03:21 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 845E18FC08; Thu, 10 Nov 2011 06:03:21 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAA63FDH096918; Thu, 10 Nov 2011 06:03:15 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 67ux5qbxnizkzsu7cyp7hj3q3s; Thu, 10 Nov 2011 06:03:15 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Wed, 9 Nov 2011 22:03:13 -0800 Content-Transfer-Encoding: 7bit Message-Id: <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> To: Peter Wemm X-Mailer: Apple Mail (2.1251.1) Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 06:03:21 -0000 On Nov 9, 2011, at 4:57 PM, Peter Wemm wrote: > Did 'tar tvf' stop seeking and doing random seek/reads for raw tar > files? I know it can't do this for a stream compressed file and > there's no choice but to read it all. bsdtar has for some years optimized 'tar tvf' on uncompressed tar archives by using seek operations to skip over the bodies of large files. Makes a big difference in some situations. The optimization is actually integrated deeply into libarchive; the individual format handlers identify cases where the stream contents will be ignored ("skipped") and the I/O layer can use this as it sees fit. As a result, the optimization works cleanly with tar, cpio, ISO, Zip, and other formats. It sounds like some of the folks on this thread would have fun with the strategy section of libarchive/archive_read_open_filename.c. Anyone know how to properly request a "skip forward" on tape drives? That's one of the missing pieces. Tim From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 06:03:21 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC8AD106566B; Thu, 10 Nov 2011 06:03:21 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 845E18FC08; Thu, 10 Nov 2011 06:03:21 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAA63FDH096918; Thu, 10 Nov 2011 06:03:15 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 67ux5qbxnizkzsu7cyp7hj3q3s; Thu, 10 Nov 2011 06:03:15 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Wed, 9 Nov 2011 22:03:13 -0800 Content-Transfer-Encoding: 7bit Message-Id: <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> To: Peter Wemm X-Mailer: Apple Mail (2.1251.1) Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 06:03:21 -0000 On Nov 9, 2011, at 4:57 PM, Peter Wemm wrote: > Did 'tar tvf' stop seeking and doing random seek/reads for raw tar > files? I know it can't do this for a stream compressed file and > there's no choice but to read it all. bsdtar has for some years optimized 'tar tvf' on uncompressed tar archives by using seek operations to skip over the bodies of large files. Makes a big difference in some situations. The optimization is actually integrated deeply into libarchive; the individual format handlers identify cases where the stream contents will be ignored ("skipped") and the I/O layer can use this as it sees fit. As a result, the optimization works cleanly with tar, cpio, ISO, Zip, and other formats. It sounds like some of the folks on this thread would have fun with the strategy section of libarchive/archive_read_open_filename.c. Anyone know how to properly request a "skip forward" on tape drives? That's one of the missing pieces. Tim From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 06:52:17 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B03B21065674; Thu, 10 Nov 2011 06:52:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9078FC19; Thu, 10 Nov 2011 06:52:14 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAA6kJ59013938 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 23:46:20 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> Date: Wed, 9 Nov 2011 23:46:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 09 Nov 2011 23:46:21 -0700 (MST) Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 06:52:17 -0000 On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: > Anyone know how to properly request a "skip forward" > on tape drives? That's one of the missing pieces. I thought that you couldn't seek(2) on tape drives. You must read(2) = the data. At least for this application, since a tar file would be just = one file on the tape. If you want to see to the next file mark, you = need to use an ioctl to get there, or read a lot. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 06:52:17 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B03B21065674; Thu, 10 Nov 2011 06:52:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9078FC19; Thu, 10 Nov 2011 06:52:14 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAA6kJ59013938 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 23:46:20 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> Date: Wed, 9 Nov 2011 23:46:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 09 Nov 2011 23:46:21 -0700 (MST) Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 06:52:17 -0000 On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: > Anyone know how to properly request a "skip forward" > on tape drives? That's one of the missing pieces. I thought that you couldn't seek(2) on tape drives. You must read(2) = the data. At least for this application, since a tar file would be just = one file on the tape. If you want to see to the next file mark, you = need to use an ioctl to get there, or read a lot. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 07:29:01 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DE8A106564A; Thu, 10 Nov 2011 07:29:01 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D1C7D8FC0A; Thu, 10 Nov 2011 07:28:59 +0000 (UTC) Received: by qyk9 with SMTP id 9so3031008qyk.13 for ; Wed, 09 Nov 2011 23:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eWn5tPz6eNUU1fDMkY65UGZ7u8dOExoj5+rqyWdebU4=; b=C+ytyHx/j/65TDStlV1uNuS7ZjhZNC0/vcd76b/CK5sADPQArYjlp3aKkU5JMXFKQ9 iPSRuIuY6U1Lpu3D8KGSutTSsNYPBXJV5swQX+jzpwgaYLhu7MJM9+qF1wW35ullm0NL vy99xP8VVrIPmRmFCAQhD0ojpJUECKfvjHXmE= MIME-Version: 1.0 Received: by 10.229.240.139 with SMTP id la11mr838183qcb.27.1320910139168; Wed, 09 Nov 2011 23:28:59 -0800 (PST) Sender: giovanni.trematerra@gmail.com Received: by 10.229.1.216 with HTTP; Wed, 9 Nov 2011 23:28:59 -0800 (PST) In-Reply-To: <20111110031828.GC6110@elvis.mu.org> References: <20111110031828.GC6110@elvis.mu.org> Date: Thu, 10 Nov 2011 08:28:59 +0100 X-Google-Sender-Auth: wNZdRsrZbswq1ENslBLm35EhGqk Message-ID: From: Giovanni Trematerra To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 07:29:01 -0000 On Thu, Nov 10, 2011 at 4:18 AM, Alfred Perlstein wrot= e: > This just reeks of gratuitous breakage. =A0Sure it's > marked depricated, but there's little reason to break a ton > of applications just to remove 11 lines of code. > Absolutely not. So I'm asking. I was wondering if they were still in use, nowadays. > Maybe we can put it under an ifndef IVORY_TOWER. > I don't think it's worth. Thanks for your comments. -- Gianni From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 07:36:26 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FB6A106566B; Thu, 10 Nov 2011 07:36:26 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 04EDD8FC19; Thu, 10 Nov 2011 07:36:24 +0000 (UTC) Received: by qyc1 with SMTP id 1so6901715qyc.13 for ; Wed, 09 Nov 2011 23:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nUambMtWcRXruDRShL0lhwk8QjSac7UuSeaeuMOonZ0=; b=UpR02pTrgHC5hUTzgbhwaDNYvqwZ9vj7yGvKbqAiBGdrYhB0A7XQfxot1Ab8OqhBWc 37/z3tdA563U9nfO1V0yH4BSJwCH14CSFB9KRwMrd8ERpYzq9CSRr6xzeFIj1G19m2jy tHhtsZUlILjhCOmEeZ4xMkA4Tjqp1z8K35YeY= MIME-Version: 1.0 Received: by 10.229.69.195 with SMTP id a3mr828956qcj.179.1320910584401; Wed, 09 Nov 2011 23:36:24 -0800 (PST) Sender: giovanni.trematerra@gmail.com Received: by 10.229.1.216 with HTTP; Wed, 9 Nov 2011 23:36:24 -0800 (PST) In-Reply-To: <5CCE304D-FF92-45F1-8D1F-7B9EA224E417@bsdimp.com> References: <20111110031828.GC6110@elvis.mu.org> <5CCE304D-FF92-45F1-8D1F-7B9EA224E417@bsdimp.com> Date: Thu, 10 Nov 2011 08:36:24 +0100 X-Google-Sender-Auth: NzpFhPBAO3yRzcX_sEb0HMWa3CI Message-ID: From: Giovanni Trematerra To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , Alfred Perlstein , freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 07:36:26 -0000 On Thu, Nov 10, 2011 at 5:47 AM, Warner Losh wrote: > I tend to agree: aren't there more pressing problems in the project that will solve actual problems rather than create a lot of work to save a tiny number of bytes in the object code. > Of course, I'm mergeing fifo and pipe implementations. fifoes don't implement them while pipes do. So I was wondering if they were still used nowadays just to be clear to me if I have to preserve them or not. BTW happy birthday! :) -- Gianni From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 08:38:03 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27101106566C for ; Thu, 10 Nov 2011 08:38:03 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id DB4B48FC08 for ; Thu, 10 Nov 2011 08:38:02 +0000 (UTC) Received: by qyc1 with SMTP id 1so6946126qyc.13 for ; Thu, 10 Nov 2011 00:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9LfLpAICjoB0TzbTw90stXHYeFH3xoggvAY55Dsg+Bc=; b=GsV6ZbSUP7ZAs9NuwqzH0+aJfrbeg9uqtiyCf4bKDaM1O6bql1b8wNfbeYwHgzwb+D 3TuNprwy7lvtlefc1RbFvXlXwYd6rsVmkum76bw0rVgozbVZfCb0Oe80POh9Ka+xyVF6 9aYkgBZDT7IOipDfwSbUcXQO8hE8hTKKKSHxE= MIME-Version: 1.0 Received: by 10.229.69.195 with SMTP id a3mr847196qcj.179.1320914282160; Thu, 10 Nov 2011 00:38:02 -0800 (PST) Sender: giovanni.trematerra@gmail.com Received: by 10.229.1.216 with HTTP; Thu, 10 Nov 2011 00:38:02 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Nov 2011 09:38:02 +0100 X-Google-Sender-Auth: f3rx3s2tpe2hCWkgi0wcDB-qnaw Message-ID: From: Giovanni Trematerra To: Peter Wemm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 08:38:03 -0000 On Thu, Nov 10, 2011 at 1:49 AM, Peter Wemm wrote: > On Wed, Nov 9, 2011 at 3:39 PM, Giovanni Trematerra = wrote: >> Are they deprecated enough to be removed, now? >> FYI FIFO doesn't support them. >> >> -- >> Gianni >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/kern/sys_pipe.c (revision 227233) >> +++ sys/kern/sys_pipe.c (working copy) >> @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td) >> =A0 =A0 =A0 =A0*(int *)data =3D fgetown(&mpipe->pipe_sigio); >> =A0 =A0 =A0 =A0break; >> >> - =A0 /* This is deprecated, FIOSETOWN should be used instead. */ >> - =A0 case TIOCSPGRP: >> - =A0 =A0 =A0 PIPE_UNLOCK(mpipe); >> - =A0 =A0 =A0 error =3D fsetown(-(*(int *)data), &mpipe->pipe_sigio); >> - =A0 =A0 =A0 goto out_unlocked; >> - >> - =A0 /* This is deprecated, FIOGETOWN should be used instead. */ >> - =A0 case TIOCGPGRP: >> - =A0 =A0 =A0 *(int *)data =3D -fgetown(&mpipe->pipe_sigio); >> - =A0 =A0 =A0 break; >> - >> =A0 =A0default: >> =A0 =A0 =A0 =A0error =3D ENOTTY; > > Be very very careful with this. =A0It's part of the classic BSD job > control API. =A0It would be wise to survey whether any ports shells use > this. > > You might also want to consider things like this in libc: > int > tcsetpgrp(int fd, pid_t pgrp) > { > =A0 =A0 =A0 =A0int s; > > =A0 =A0 =A0 =A0s =3D pgrp; > =A0 =A0 =A0 =A0return (_ioctl(fd, TIOCSPGRP, &s)); > } > Our own libc code uses this, albeit on an API intended to be used on a tt= y. > > The shell I'd be most concerned about is csh/tcsh in our tree. It has > quite an #ifdef legacy layer and I couldn't convince myself it wasn't > using this indirectly (or the tc* functions) on pipes. > > It might also be an idea to see if the linux compat layer can be > switched over to using the newer API. > Thank you Peter for commenting. I meant just to remove them from pipe_pool because I was wondering that they weren't used anymore. As others pointed out, they are. -- Gianni From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 09:22:23 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78A9A106566C for ; Thu, 10 Nov 2011 09:22:23 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 3FDE08FC13 for ; Thu, 10 Nov 2011 09:22:23 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id pAA9BKbA045756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Nov 2011 01:11:20 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id pAA9BJtl045755; Thu, 10 Nov 2011 01:11:20 -0800 (PST) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA12600; Thu, 10 Nov 11 01:09:29 PST Date: Thu, 10 Nov 2011 08:09:21 -0800 From: perryh@pluto.rain.com To: imp@bsdimp.com Message-Id: <4ebbf731.37OBtp+PJFFB1Hsl%perryh@pluto.rain.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> In-Reply-To: <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bruce@cran.org.uk, ed@80386.nl, jilles@stack.nl, tim@kientzle.com, alfred@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 09:22:23 -0000 Warner Losh wrote: > On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: > > Anyone know how to properly request a "skip forward" > > on tape drives? That's one of the missing pieces. > > I thought that you couldn't seek(2) on tape drives. You must > read(2) the data. At least for this application, since a tar file > would be just one file on the tape. If you want to see to the > next file mark, you need to use an ioctl to get there, or read a > lot. AFAIK you can't seek(2) backward unless using something along the lines of a DECtape (remember those?), but there's no reason in principle why a forward seek(2) could not be implemented in the driver -- even without any help from the hardware. It would save some DMA, interrupt, and context-switch traffic, but even when searching for a filemark the drive won't move the tape any faster than when reading. From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 10:07:37 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC1B3106564A; Thu, 10 Nov 2011 10:07:37 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 482C98FC19; Thu, 10 Nov 2011 10:07:36 +0000 (UTC) Received: from [194.32.164.28] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id pAA9rYvI029191; Thu, 10 Nov 2011 09:53:34 GMT (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> Date: Thu, 10 Nov 2011 09:53:29 +0000 Content-Transfer-Encoding: 7bit Message-Id: <568E61A9-A3DA-4DBD-A9BB-6AFC4279DEA2@gid.co.uk> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 10:07:37 -0000 Hi, On 10 Nov 2011, at 06:03, Tim Kientzle wrote: > Anyone know how to properly request a "skip forward" > on tape drives? That's one of the missing pieces. See mtio(4). -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 10:07:37 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC1B3106564A; Thu, 10 Nov 2011 10:07:37 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 482C98FC19; Thu, 10 Nov 2011 10:07:36 +0000 (UTC) Received: from [194.32.164.28] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id pAA9rYvI029191; Thu, 10 Nov 2011 09:53:34 GMT (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> Date: Thu, 10 Nov 2011 09:53:29 +0000 Content-Transfer-Encoding: 7bit Message-Id: <568E61A9-A3DA-4DBD-A9BB-6AFC4279DEA2@gid.co.uk> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) Cc: Bruce Cran , Ed Schouten , Jilles Tjoelker , Alfred Perlstein , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 10:07:37 -0000 Hi, On 10 Nov 2011, at 06:03, Tim Kientzle wrote: > Anyone know how to properly request a "skip forward" > on tape drives? That's one of the missing pieces. See mtio(4). -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 12:39:51 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B4B01065670 for ; Thu, 10 Nov 2011 12:39:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [178.63.0.170]) by mx1.freebsd.org (Postfix) with ESMTP id 713A68FC16 for ; Thu, 10 Nov 2011 12:39:50 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 8730D2A28CC9; Thu, 10 Nov 2011 13:39:19 +0100 (CET) Date: Thu, 10 Nov 2011 13:39:19 +0100 From: Ed Schouten To: arch@FreeBSD.org Message-ID: <20111110123919.GF2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m972NQjnE83KvVa/" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 12:39:51 -0000 --m972NQjnE83KvVa/ Content-Type: multipart/mixed; boundary="GV0iVqYguTV4Q9ER" Content-Disposition: inline --GV0iVqYguTV4Q9ER Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I suspect this email could be one of the last emails I'm sending before one of you hire an assassin to get rid of me, but here it goes. A couple of days ago someone on IRC pointed me to the following discussion that is taking place at Fedora right now: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus%3D155= 792 Even though I tend to disagree with Lennart's opinions here and there, especially on point (h), where he explains there's no advantage of decomposing the system into a separate / and /usr, I do agree with the fact that `sbin' is a pretty weird thing. Nowadays the rule of thumb behind `sbin' is that it contains applications that are normally only needed by system administrators, but there are many tools in FreeBSD that contradict this rule: - md5(1) should be placed in /bin or /usr/bin, while it is stored in /sbin. It even has a man page in category 1. Very odd. - last(1) and w(1) are placed in /usr/bin, while lastlogin(8) and ac(8) are placed in /usr/sbin. - Tools like sysctl(8) and ifconfig(8) are usable by non-root users. - ... Now that we're (hopefully) heading into an era where permissions in the operating systems become more fine-grained, the distinction between bin and sbin will become even more vague. Similar to the entire bin <-> sbin thing, I think /usr/games is also a bit nonsensical, because the games -- including the fortune(6) database -- only account for about 3.4 MB and FreeBSD 9 will ship with a clang(1) binary that is a factor 8 or so larger. If people really want to get rid of the games, they'd be better off running `make delete-old WITHOUT_GAMES=3D' in /usr/src after the installation. My proposal is as follows: - Move everything in /sbin to /bin and turn it into a symbolic link pointing to /bin. - Move everything in /usr/sbin to /usr/bin and turn it into a symbolic link pointing to /usr/bin. - Move everything in /usr/games to /usr/bin and turn it into a symbolic link pointing to /usr/bin. Just as a test, I wrote a patch that does exactly this. I've attached it to this email. It would be dangerous to perform such a migration without any form of approval from the user, the user must perform the migration manually, using the commands supplied in /usr/src/UPDATING. I have added an `installcheck' target that prevents a user from running `make installworld' without performing the migration first. Do note that this patch makes no attempt to get rid of any other references to `sbin' in the source tree. In fact, we've got all the time in the world to get this sorted out, as long as we leave the symlinks in place. In fact, I guess we'll never get rid of them anyway, because almost all pieces of software hardcode strings like `/usr/sbin/sendmail'. Well, I think that's all I have to say. I guess I should hide in my underground lair for now. --=20 Ed Schouten WWW: http://80386.nl/ --GV0iVqYguTV4Q9ER Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="nuke-sbin.diff" Content-Transfer-Encoding: quoted-printable Index: games/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- games/Makefile.inc (revision 227417) +++ games/Makefile.inc (working copy) @@ -1,7 +1,7 @@ # @(#)Makefile.inc 8.1 (Berkeley) 5/31/93 # $FreeBSD$ =20 -BINDIR?=3D /usr/games +BINDIR?=3D /usr/bin FILESDIR?=3D ${SHAREDIR}/games WARNS?=3D 6 DISTRIBUTION?=3D games Index: usr.sbin/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.sbin/Makefile.inc (revision 227417) +++ usr.sbin/Makefile.inc (working copy) @@ -1,6 +1,6 @@ # @(#)Makefile.inc 8.1 (Berkeley) 6/6/93 # $FreeBSD$ =20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 WARNS?=3D 6 Index: sbin/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/Makefile.inc (revision 227417) +++ sbin/Makefile.inc (working copy) @@ -3,7 +3,7 @@ =20 .include =20 -BINDIR?=3D /sbin +BINDIR?=3D /bin WARNS?=3D 6 =20 .if ${MK_DYNAMICROOT} =3D=3D "no" Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.inc1 (revision 227417) +++ Makefile.inc1 (working copy) @@ -613,6 +613,18 @@ .endfor =20 # +# /sbin is now merged into /bin. The same holds for /usr/sbin and /usr/gam= es. +# +installcheck: installcheck_sbin_merge +installcheck_sbin_merge: +.for dir in ${DESTDIR}/sbin ${DESTDIR}/usr/sbin ${DESTDIR}/usr/games + @if test -d ${dir} -a ! -L ${dir}; then \ + echo "ERROR: Directory ${dir} is still present, see /usr/src/UPDATING en= try 20111110."; \ + false; \ + fi +.endfor + +# # Required install tools to be saved in a scratch dir for safety. # .if ${MK_INFO} !=3D "no" Index: UPDATING =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- UPDATING (revision 227417) +++ UPDATING (working copy) @@ -22,6 +22,24 @@ machines to maximize performance. (To disable malloc debugging, run ln -s aj /etc/malloc.conf.) =20 +20111110: + The /sbin, /usr/sbin and /usr/games directories have been merged + into /bin and /usr/bin. For compatibility, the old directories + have been replaced by symbolic links pointing to `bin'. To + prevent people from possibly breaking their system + automatically, you must perform the merge manually before + `make installworld'. This can be done as follows: + + chflags noschg /sbin/* /usr/sbin/* /usr/games/* + mv /sbin/* /bin + mv /usr/sbin/* /usr/games/* /usr/bin + rmdir /sbin /usr/sbin /usr/games + + After running these commands, you can safely run `make + installworld' to continue your upgrade. Do not reboot your + system in the mean time, as FreeBSD's boot procedure depends on + the existence of /sbin and /usr/sbin. + 20111108: The option VFS_ALLOW_NONMPSAFE option has been added in order to explicitely support non-MPSAFE filesystems. Index: etc/mtree/BSD.usr.dist =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- etc/mtree/BSD.usr.dist (revision 227417) +++ etc/mtree/BSD.usr.dist (working copy) @@ -7,8 +7,7 @@ . bin .. - games - .. + games type=3Dlink link=3Dbin include .. lib @@ -55,8 +54,7 @@ .. obj nochange .. - sbin - .. + sbin type=3Dlink link=3Dbin share calendar de_DE.ISO8859-1 Index: etc/mtree/BSD.root.dist =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- etc/mtree/BSD.root.dist (revision 227417) +++ etc/mtree/BSD.root.dist (working copy) @@ -85,8 +85,7 @@ .. root .. - sbin - .. + sbin type=3Dlink link=3Dbin tmp mode=3D01777 .. usr --GV0iVqYguTV4Q9ER-- --m972NQjnE83KvVa/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOu8X3AAoJEG5e2P40kaK73K0QAJAB7rljynToo/KLgysV8aeu srVD+SVNjXnazEEAwdhUjkiIvycSdWgD4cejA80SIYJO7VA3BWnSiZTOBZ86AkB7 4aWFUp57bVCdATQLeSH5ev735FulbH9PJskLm2iq+vYmLekorvIgfcjxV5Flp+ME gOz3VkAiIbFkkaSbiH4B/d8hyFScMTdYCxzcLTtJ2zHQuN4q0pS4JTEZViYf1xXT 4d/ra/hlYxNOS0QH2vm5OCYj3O5SBJv0FUco6G8NI4WJODKxO758AAYlL0BTxyYN Hai8+s6bYDFRlpj3EWN48UqPfkRobW/nx2/JEyhsmjUcQbyi05dLbxhjsZfuYVga MUSzyLkdgjyXFmcqGixqvE7NiPSIzfVP6lmpYz0/HZdbddXMtgMhIt75GBRW/WMO vn0qTaIpcyA7uSLDnDGf0tqePDWvCZAd9Ats9LyiBfMZRo6Za1qITdJRvMTv7bXP OBeKNe8piR/bDDrbf97dwsVpOzLr9GfBJm7hjpC9oavyTwnyGbnSpQzw95g2qFLX Tals3XjGmcCkDNZ3DDOf6CTe581CH607we0nkEX85yNhh8UDvNcir83FS62BENyj tDPQ8aLcQYOT/oMSUNNV6Cg1BEmFyzOeIWTLmZEqbAF/f1QeNQtjxN7zav0lDbws QjTV2BX7YcU6mCVa3On1 =5jtM -----END PGP SIGNATURE----- --m972NQjnE83KvVa/-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 14:01:55 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C821065670 for ; Thu, 10 Nov 2011 14:01:55 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 291B28FC12 for ; Thu, 10 Nov 2011 14:01:54 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E7C8C5E55; Thu, 10 Nov 2011 13:42:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id pAADVVOY012751; Thu, 10 Nov 2011 13:31:34 GMT (envelope-from phk@phk.freebsd.dk) To: Ed Schouten From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 10 Nov 2011 13:39:19 +0100." <20111110123919.GF2164@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 10 Nov 2011 13:31:31 +0000 Message-ID: <12750.1320931891@critter.freebsd.dk> Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 14:01:55 -0000 In message <20111110123919.GF2164@hoeg.nl>, Ed Schouten writes: >Nowadays the rule of thumb behind `sbin' is that it contains >applications that are normally only needed by system administrators, /sbin was for root in single user mode. That /usr/sbin/materialized can only be described as a mistake. -- 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 Thu Nov 10 15:01:17 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 525EA1065676; Thu, 10 Nov 2011 15:01:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DDDBC8FC14; Thu, 10 Nov 2011 15:01:16 +0000 (UTC) Received: by vws11 with SMTP id 11so3611707vws.13 for ; Thu, 10 Nov 2011 07:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gr7i29FG8a7Il0ccpbq+t4wRb2wcu6MhTrz/5cNcBTI=; b=KyrdPFZYykrEqOmzv/67FdCZL715Ov3DWoULn2QLjtsilFggfPiQhgxMDQ8C1sEOIf jDGyEbAS7Nhz5Oenns7NGBGHwAeivupOwT6m81u+5HKmCVG1e2DeKS+5jYxA2bsHS2xH f2EnDs7DRbEPslddldWAiHBJ19RNbx7S2fUjk= MIME-Version: 1.0 Received: by 10.52.95.164 with SMTP id dl4mr13510405vdb.72.1320937276199; Thu, 10 Nov 2011 07:01:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 07:01:16 -0800 (PST) In-Reply-To: <20111110012542.GA6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> <20111110012542.GA6110@elvis.mu.org> Date: Thu, 10 Nov 2011 07:01:16 -0800 X-Google-Sender-Auth: PbuTcpistVVdOhWSfRsj5yLedko Message-ID: From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: Bruce Cran , Ed Schouten , Paul Saab , Jilles Tjoelker , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 15:01:17 -0000 .. the minute you start talking about LRU modifications, secondary LRU, etc, you may as well implement ARC. :) adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 15:01:17 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 525EA1065676; Thu, 10 Nov 2011 15:01:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DDDBC8FC14; Thu, 10 Nov 2011 15:01:16 +0000 (UTC) Received: by vws11 with SMTP id 11so3611707vws.13 for ; Thu, 10 Nov 2011 07:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gr7i29FG8a7Il0ccpbq+t4wRb2wcu6MhTrz/5cNcBTI=; b=KyrdPFZYykrEqOmzv/67FdCZL715Ov3DWoULn2QLjtsilFggfPiQhgxMDQ8C1sEOIf jDGyEbAS7Nhz5Oenns7NGBGHwAeivupOwT6m81u+5HKmCVG1e2DeKS+5jYxA2bsHS2xH f2EnDs7DRbEPslddldWAiHBJ19RNbx7S2fUjk= MIME-Version: 1.0 Received: by 10.52.95.164 with SMTP id dl4mr13510405vdb.72.1320937276199; Thu, 10 Nov 2011 07:01:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 07:01:16 -0800 (PST) In-Reply-To: <20111110012542.GA6110@elvis.mu.org> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> <20111110012542.GA6110@elvis.mu.org> Date: Thu, 10 Nov 2011 07:01:16 -0800 X-Google-Sender-Auth: PbuTcpistVVdOhWSfRsj5yLedko Message-ID: From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: Bruce Cran , Ed Schouten , Paul Saab , Jilles Tjoelker , arch@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 15:01:17 -0000 .. the minute you start talking about LRU modifications, secondary LRU, etc, you may as well implement ARC. :) adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 16:29:16 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9044D106567B for ; Thu, 10 Nov 2011 16:29:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 430F18FC1B for ; Thu, 10 Nov 2011 16:29:16 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAAGKXr7021471 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 10 Nov 2011 09:20:34 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4ebbf731.37OBtp+PJFFB1Hsl%perryh@pluto.rain.com> Date: Thu, 10 Nov 2011 09:19:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00E98C7D-8683-4318-AFCA-5782EB17EE0E@bsdimp.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> <4ebbf731.37OBtp+PJFFB1Hsl%perryh@pluto.rain.com> To: perryh@pluto.rain.com X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 10 Nov 2011 09:20:35 -0700 (MST) Cc: bruce@cran.org.uk, ed@80386.nl, jilles@stack.nl, tim@kientzle.com, alfred@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 16:29:16 -0000 On Nov 10, 2011, at 9:09 AM, perryh@pluto.rain.com wrote: > Warner Losh wrote: >> On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: >>> Anyone know how to properly request a "skip forward" >>> on tape drives? That's one of the missing pieces. >>=20 >> I thought that you couldn't seek(2) on tape drives. You must >> read(2) the data. At least for this application, since a tar file >> would be just one file on the tape. If you want to see to the >> next file mark, you need to use an ioctl to get there, or read a >> lot. >=20 > AFAIK you can't seek(2) backward unless using something along the > lines of a DECtape (remember those?), but there's no reason in > principle why a forward seek(2) could not be implemented in the > driver -- even without any help from the hardware. It would save > some DMA, interrupt, and context-switch traffic, but even when > searching for a filemark the drive won't move the tape any faster > than when reading. Seek(2) never makes it down to the driver for character devices. = Character devices have no position. VMS did implement forward and reverse seeking on at least mag tapes. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 16:56:05 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB671065672 for ; Thu, 10 Nov 2011 16:56:05 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1B28FC14 for ; Thu, 10 Nov 2011 16:56:04 +0000 (UTC) Received: by eyd10 with SMTP id 10so3314972eyd.13 for ; Thu, 10 Nov 2011 08:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X3Bv1i0RzHGM1mHYJoVtQ86G87knkSHnARmTfQL/758=; b=yKS8dmoZw40WZUvVXnRJxAVigTpPnJuGUZ7om7ePc8gzLpC07MZS6EnePWQ9AYxp1c sH1GXezcCJiye+tlZAefZjHt6mroB/7sjLMCggswkMkovBWl7DBlKv/M0HPV+7ufi3pc 6ti1qPO4EZQmnLlOqs0VN3rhq1Rp/6C/KLNjc= MIME-Version: 1.0 Received: by 10.68.24.1 with SMTP id q1mr9297918pbf.29.1320944163123; Thu, 10 Nov 2011 08:56:03 -0800 (PST) Received: by 10.68.50.226 with HTTP; Thu, 10 Nov 2011 08:56:03 -0800 (PST) In-Reply-To: <20111110123919.GF2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> Date: Thu, 10 Nov 2011 08:56:03 -0800 Message-ID: From: Peter Wemm To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 16:56:05 -0000 On Thu, Nov 10, 2011 at 4:39 AM, Ed Schouten wrote: > Hi all, > > I suspect this email could be one of the last emails I'm sending before > one of you hire an assassin to get rid of me, but here it goes. > > A couple of days ago someone on IRC pointed me to the following > discussion that is taking place at Fedora right now: > > =A0 =A0 =A0 =A0http://thread.gmane.org/gmane.linux.redhat.fedora.devel/15= 5511/focus%3D155792 > > Even though I tend to disagree with Lennart's opinions here and there, > especially on point (h), where he explains there's no advantage of > decomposing the system into a separate / and /usr, I do agree with the > fact that `sbin' is a pretty weird thing. > > Nowadays the rule of thumb behind `sbin' is that it contains > applications that are normally only needed by system administrators, but > there are many tools in FreeBSD that contradict this rule: > > - md5(1) should be placed in /bin or /usr/bin, while it is stored in > =A0/sbin. It even has a man page in category 1. Very odd. > - last(1) and w(1) are placed in /usr/bin, while lastlogin(8) and ac(8) > =A0are placed in /usr/sbin. > - Tools like sysctl(8) and ifconfig(8) are usable by non-root users. > - ... > > Now that we're (hopefully) heading into an era where permissions in the > operating systems become more fine-grained, the distinction between bin > and sbin will become even more vague. > > Similar to the entire bin <-> sbin thing, I think /usr/games is also a > bit nonsensical, because the games -- including the fortune(6) database > -- only account for about 3.4 MB and FreeBSD 9 will ship with a clang(1) > binary that is a factor 8 or so larger. If people really want to get rid > of the games, they'd be better off running `make delete-old > WITHOUT_GAMES=3D' in /usr/src after the installation. > > My proposal is as follows: > > - Move everything in /sbin to /bin and turn it into a symbolic link > =A0pointing to /bin. > - Move everything in /usr/sbin to /usr/bin and turn it into a symbolic > =A0link pointing to /usr/bin. > - Move everything in /usr/games to /usr/bin and turn it into a symbolic > =A0link pointing to /usr/bin. [Argh, damn it! I had a huge reply here based on a misunderstanding of what you were proposing. I've collected some of the comments that are still even remotely relevant and tried to correct them, please forgive any I missed. I thought you were proposing a symlink farm rather than linking the dirs.] There's multiple factors at work, some still relevant, some no longer so. Once upon a time, there was this thing called $PATH. For each command you typed at a shell prompt, shells used to do this: foreach $dir (split(":", $PATH)) { execve($dir + $cmd, $args); } Indeed, execvp, execlp etc in libc still do precisely this. The more pathname components you jammed into $PATH, the more system calls and file system operations were involved in every single system(), shell script, etc. There was also not much in the way of a vfs pathname component cache back then. A lookup of a component required scanning directories in the usual case. They were usually in the buffer cache, but it still required scans. Scanning large directory files took longer than shorter ones, naturally enough, because it had to iterate across every entry and do a strcmp(). So, keeping directories smaller sped up shell scripts. The bin vs sbin split was done for multiple reasons. The general rule was that things that were only interesting or useful to admins, or required priviliges, or were related to system operation, generally went into sbin. There was this other evil thing of putting binaries in /etc.. eg: /etc/ifconfig, /etc/fsck and horrors like that. All of that crap was rounded up into sbin. The goal for bin was to have it have stuff that was relevant to end users and shell scripts etc, to make them faster. Take a random machine and directory contents that VOP_LOOKUP() has to process on a name cache miss: bin: 47 sbin: 122 usr/bin: 457 usr/sbin: 266 bin + /usr/bin =3D 504 bin + sbin + /usr/bin + /usr/sbin: 892 A name cache miss for something at the end of /usr/bin directory file causes a 504 node scan. If sbin is merged, that's 892 dirents scanned, at the worse case. We do have a decent name cache, but my recent time with it makes me wonder about a few things. We do a cache_enter() once we find a vnode to correspond with a name. Vnodes have to be resident in order to have a cached name. On machines with working sets in the order of millions of files, I don't imagine the vnodes for /bin and /usr/bin to hang around too long, and therefore the cache to purge quickly. There is also UFS_DIRHASH as a band-aid that would minimize the cost of a bunch of this, for the UFS case. There is also another user visible effect. Filename completion in shells is affected by this. If I use a shell with a basic user path (_PATH_DEFPATH "/usr/bin:/bin", which is trashed by login.conf) and hit 'm', it offers me 17 possible completions. If I add both sbin dirs to it, 'm' turns into 61 options. Of course, that pales in comparison to the impact of adding /usr/local/bin to the path, but it does show this does have potential user visibility. And there's also the issue that most most users add every possible directory to their $PATH anyway. Also.. there is still an extra impact of hitting symlinks. Suppose a $PATH has sbin earlier than bin. execlp("md5", "foo", 0) will find /sbin/md5 via the symlink before the real binary that moved to /bin/md5. Path evaluation would look a little like this (read the code in vfs_lookup.c:namei()): VOP_LOOKUP("/sbin/md5") -> namei() discovers sbin is a link and drops out the end of the loop. -> namei() does a VOP_READLINK() on sbin in "/", which ufs implements as an inode open, read, close -> namei() resets the path to /bin/md5 and jumps back to the top of the loop and starts again with locking the root vnode and iterating again to find "bin" in "/" Having said all that... There are reasons why it was done that way. I suspect the costs of the change are something we can eat and will be lost in other noise in the system. It's worth keeping in mind though that lots of incremental "small costs" add up over time when they're done in many many places. Is it really worth it though? Perhaps fix the couple of oddball cases instead? (eg: md5, lastlogin and friends). ac used to require access to privileged files due to privacy concerns on shared user systems. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 17:16:06 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C6A1065676 for ; Thu, 10 Nov 2011 17:16:06 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id EC7028FC18 for ; Thu, 10 Nov 2011 17:16:05 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 351162A28CC9; Thu, 10 Nov 2011 18:16:05 +0100 (CET) Date: Thu, 10 Nov 2011 18:16:05 +0100 From: Ed Schouten To: Peter Wemm Message-ID: <20111110171605.GI2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NqSa+Xr3J/G6Hhls" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 17:16:06 -0000 --NqSa+Xr3J/G6Hhls Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, * Peter Wemm , 20111110 17:56: > Of course, that pales in comparison to the impact of adding > /usr/local/bin to the path, but it does show this does have potential > user visibility. And there's also the issue that most most users add > every possible directory to their $PATH anyway. Exactly. Also, there are shells nowadays that cache all binaries in PATH up front, such as zsh. When they start, they loop through all dirents in all directories in $PATH and add it to a big cache. This entirely defeats this purpose. I don't think that there are that many people who don't add /sbin and /usr/sbin to $PATH nowadays. I have colleagues of mine who use Linux systems that don't have this in their $PATH. When I ask them whether it causes problems for them, they deny, but it turns out they simply put `sudo' in front of it, to work around that, regardless of whether it was needed. > Is it really worth it though? Perhaps fix the couple of oddball cases > instead? (eg: md5, lastlogin and friends). ac used to require access > to privileged files due to privacy concerns on shared user systems. I think if we have to look at each tool and re-examine whether they should be in bin or sbin and convert them to do so, it would take approximately the same amount of investment as moving them into a single place. And I am willing to do that. :-) --=20 Ed Schouten WWW: http://80386.nl/ --NqSa+Xr3J/G6Hhls Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvAbVAAoJEG5e2P40kaK7Zk0P/3PvQbFF5GOLZq5zhV9XufLa tmlk3FVGwSOTayQr+yyvttBF2vNRDKs8n9MoYdcSBd0NaffVW3IWpOUIhzc4rcUG sd1bKUB9iO15urRyihAVQZNLfjNC5fuuaqa9kJj/yG6XY85qlFLIuea8mRYGsYoh LZFOWhl3DN6fRk4+USzafyCpRvVzEd8BfSULNzB7KNr+AoVNXnE6Pp8zLurC7laq T8/paWf1cQAhUZigajPWxgWFLXplUG0TydGCKL0HsQWzdgDAS4zziq7e+svuX9Cu rplg6Y8q6Fx1gK+Qo6hUk2PJd3H8yzA8Z93R105fh9M7/hmxabubdOKdNm58pYFo 8C6MX9LBF54oPOiTVCsWBbzUbG5jngtCG7sucnRkKgRW0wZUEOYp7qBqWcfJxTjz evKcquuAnzrQuwbZGchkqhCPeowsAFHFY1CkToSo4Zw/6nXq3RLr+t7jTkEZbHlR zGcAYUuR3eloTEc+I9VzTp7yzUDMRKNPLrC/9A7HZtERLWxQXtVeZhLVZZZmfCN/ duOENCe5iNGeKOWjqMg/X2ogMmcqXAJDOOGgL/K+gtjbxcrTK7LLGQRHpFjppZPL lAPAy9nnAkuJE8VSTfFYo3gCOQwe34FoL6ZIMCxt9D3yv7wujDCRCMZrBwjlkdL0 D9TavV0bXoU+Jmgrm93Q =zr59 -----END PGP SIGNATURE----- --NqSa+Xr3J/G6Hhls-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 17:33:24 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AA47106566B for ; Thu, 10 Nov 2011 17:33:24 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A16218FC14 for ; Thu, 10 Nov 2011 17:33:23 +0000 (UTC) Received: by eyd10 with SMTP id 10so3368365eyd.13 for ; Thu, 10 Nov 2011 09:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z/FXshnWWcR9ibMSv8aQ08z7gl7Op3ZjZrIctt6jxgI=; b=jWR7g2gED3ifQ3/LSBCS07E2gAiaxBeGJbE31g4xSFRTEHXNTnAUmw8ZMRoWT1M3Ui bHjFA++AmjGTy+oFiYUq1LaUP2unWnRVHnlE5FXTL79utc5PEZ5dfxg4Zw6tKjRfIkLL 9Z01KUuvAI5/dvBxo5jvjwVoebLGazDVhH4vE= MIME-Version: 1.0 Received: by 10.68.28.103 with SMTP id a7mr16410163pbh.63.1320946401464; Thu, 10 Nov 2011 09:33:21 -0800 (PST) Received: by 10.68.50.226 with HTTP; Thu, 10 Nov 2011 09:33:21 -0800 (PST) In-Reply-To: <20111110171605.GI2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> Date: Thu, 10 Nov 2011 09:33:21 -0800 Message-ID: From: Peter Wemm To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 17:33:24 -0000 On Thu, Nov 10, 2011 at 9:16 AM, Ed Schouten wrote: > Hi Peter, > > * Peter Wemm , 20111110 17:56: >> Of course, that pales in comparison to the impact of adding >> /usr/local/bin to the path, but it does show this does have potential >> user visibility. =A0And there's also the issue that most most users add >> every possible directory to their $PATH anyway. > > Exactly. Also, there are shells nowadays that cache all binaries in PATH > up front, such as zsh. When they start, they loop through all dirents in > all directories in $PATH and add it to a big cache. This entirely > defeats this purpose. I use tcsh and zsh, I'm aware of this cache. However, libc doesn't, so things like /bin/sh when running shell scripts do not. make(1) does not. People do still care about buildworld time. Simple things like changing gcc to static linking were a few percentage points of buildworld time, back in the day. Having /bin/sh as a static binary used to be 3%-5% of buildworld time, simply because fork/exec was faster as the copy-on-write burden was less. This stuff adds up. > I don't think that there are that many people who don't add /sbin and > /usr/sbin to $PATH nowadays. I have colleagues of mine who use Linux > systems that don't have this in their $PATH. When I ask them whether it > causes problems for them, they deny, but it turns out they simply put > `sudo' in front of it, to work around that, regardless of whether it was > needed. Having /sbin in $PATH where /sbin is a symlink to /bin would be worse than having no /sbin at all, from a perspective of rootvnode lock lifetime. If you can figure out how to get people to remove /sbin and /usr/sbin from their paths after the symlink changes then it becomes a moot point. But heck, I still have /usr/X11R6 in mine... :( --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 17:42:02 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB7A1106566B for ; Thu, 10 Nov 2011 17:42:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 655658FC14 for ; Thu, 10 Nov 2011 17:42:02 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAAHcVxr022650 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 10 Nov 2011 10:38:32 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20111110171605.GI2164@hoeg.nl> Date: Thu, 10 Nov 2011 10:38:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> To: Ed Schouten X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 10 Nov 2011 10:38:32 -0700 (MST) Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 17:42:02 -0000 On Nov 10, 2011, at 10:16 AM, Ed Schouten wrote: > Hi Peter, >=20 > * Peter Wemm , 20111110 17:56: >> Of course, that pales in comparison to the impact of adding >> /usr/local/bin to the path, but it does show this does have potential >> user visibility. And there's also the issue that most most users add >> every possible directory to their $PATH anyway. >=20 > Exactly. Also, there are shells nowadays that cache all binaries in = PATH > up front, such as zsh. When they start, they loop through all dirents = in > all directories in $PATH and add it to a big cache. This entirely > defeats this purpose. tcsh and csh before it has been doing this since the 1980's, so it is = nothing new. Add a new binary to your path and forget to rehash: you = can't run it. > I don't think that there are that many people who don't add /sbin and > /usr/sbin to $PATH nowadays. I have colleagues of mine who use Linux > systems that don't have this in their $PATH. When I ask them whether = it > causes problems for them, they deny, but it turns out they simply put > `sudo' in front of it, to work around that, regardless of whether it = was > needed. Folks that grew up before the "all the world is a vax^W^Wruns Linux" = have it in their path, but younger colleges generally don't have it = unless they've been forced to use Solaris or *BSD at some point. >> Is it really worth it though? Perhaps fix the couple of oddball = cases >> instead? (eg: md5, lastlogin and friends). ac used to require access >> to privileged files due to privacy concerns on shared user systems. >=20 > I think if we have to look at each tool and re-examine whether they > should be in bin or sbin and convert them to do so, it would take > approximately the same amount of investment as moving them into a = single > place. And I am willing to do that. :-) I'm a bit torn here. It would be nice to have one, unified place for = binaries. Do embedded systems really need to burn the extra inodes on = sbin, libexec, etc? No, they don't. On the other hand, these paths = seep into so many places that I gave up my attempts years ago to just = put all the files in one place (I didn't like the symlink idea because I = worried about shells that were stupid and put all entires into their = hashes multiple times). I'd honestly start small here with (1) move the ones that are obviously = wrong (and aren't specified by posix to be wrong). (2) make it an option = to just make one or two binaries directories with compat symlinks = (because there's a ton of scripts that just know where binaries life). Warner= From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 17:47:22 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E11E6106566B for ; Thu, 10 Nov 2011 17:47:22 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id A77918FC19 for ; Thu, 10 Nov 2011 17:47:22 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 1C4DF2A28CC9; Thu, 10 Nov 2011 18:47:22 +0100 (CET) Date: Thu, 10 Nov 2011 18:47:22 +0100 From: Ed Schouten To: Peter Wemm Message-ID: <20111110174722.GJ2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cEobB2knsyc5ebfU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 17:47:23 -0000 --cEobB2knsyc5ebfU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Peter Wemm , 20111110 18:33: > Having /sbin in $PATH where /sbin is a symlink to /bin would be worse > than having no /sbin at all, from a perspective of rootvnode lock > lifetime. If you can figure out how to get people to remove /sbin and > /usr/sbin from their paths after the symlink changes then it becomes a > moot point. But heck, I still have /usr/X11R6 in mine... :( On the other hand, if people used to have /sbin in their path and *do* remove it properly after the upgrade, they should in theory see a performance improvement, right? Assume $PATH used to be /bin:/sbin:/usr/bin:/usr/sbin:/usr/games:... and is switched to /bin:/usr/bin:... after the upgrade. Now if somebody tries to execute something that's not part of the base system, then it would require at least 3 calls to execve(), whereas in our current setup it would require 6 system calls. Therefore I think it's hard to say anything conclusive about performance in this area. --=20 Ed Schouten WWW: http://80386.nl/ --cEobB2knsyc5ebfU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvA4pAAoJEG5e2P40kaK7uj0P/Rv2PrPsBy2RQre7LJlANaWh mC/qsrP/snio8nSI/szHYL3DDv6ELT1ghofNLapoEn4+drwZxG+OlHrLq9lwHS/s 7/HK8fGQHejIf93TcFc/wEH8OzKEvaYs06yi2yIQ/QLI4Ul6vifZ9S2JLFe/e+PR q/MlbMHE0tllF7kznc0rtJngnjCj5DxVrlHAhOw9al5/XZBYhSJCvkGQ5LTF09jB WFt5HzbKmz5ouYK0VF5eK1RW6g7dDdzQeOqfYqnUjsCN4TBXlZCqT8rUnlzYlx71 x9gheIw70zV3u97e9vLoeknxQsGPID1HnFJOgulqn6tOgDU0ueUzj6DQ7hhXp1kw 2gV1xyHIKHzAMnEC9xx222kfap+sJ1LmbdNJfuS0Acg1Z0kaBe9pjGPltmnwM1T5 vPrpxSKzEGN0Fy8IcN/I0quQhDRa7GBKRtxxTZUVMBGB+AICxuB7+/kFop/KxVXP 7JHW1VVisrFyVygM3NE4DFPfWm4n98ahCw7YL4kDk6jtfea8mamQo8foz0EDxeG7 vlgYt5xNbDlxFtFVwoMP8Y/6ajWOTPFoF4w8BGwwPxrCiKkBAUkK8TPv0FFr7cVP jXTbkby4brMgXad3zTvsvpp9JG2FtN853bD6OUVrHB1Jkszb7szSWHPt1D09J52L iUg7HNQLw47XvONW3bAR =HF7G -----END PGP SIGNATURE----- --cEobB2knsyc5ebfU-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 18:12:28 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6946A106567C for ; Thu, 10 Nov 2011 18:12:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EAD358FC16 for ; Thu, 10 Nov 2011 18:12:27 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so3607540bkb.13 for ; Thu, 10 Nov 2011 10:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LHpMW7tw787XCFzZM9Nnga3By0EL42daaOGNM2JI4PM=; b=rrPwQJCvvzLl5BCwjCGw7lf3Lpn2i1XAwUSHeW2sR1zJpXMoPhJr0GpvNfjSGNGAGI N8/emiuNdcsmMuboUq9y1b/JvrMJqaypxvf31nEAU+5ivVEXGP5zDGlshN+mAiHt6vXK QoBH/cIdWBjhkGdanY4NlOZSJFnPGfp1bXMm0= MIME-Version: 1.0 Received: by 10.182.41.69 with SMTP id d5mr2092297obl.47.1320948746496; Thu, 10 Nov 2011 10:12:26 -0800 (PST) Received: by 10.182.122.33 with HTTP; Thu, 10 Nov 2011 10:12:26 -0800 (PST) In-Reply-To: <20111110174722.GJ2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> Date: Thu, 10 Nov 2011 10:12:26 -0800 Message-ID: From: Garrett Cooper To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:12:28 -0000 On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten wrote: > * Peter Wemm , 20111110 18:33: >> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse >> than having no /sbin at all, from a perspective of rootvnode lock >> lifetime. =A0If you can figure out how to get people to remove /sbin and >> /usr/sbin from their paths after the symlink changes then it becomes a >> moot point. =A0But heck, I still have /usr/X11R6 in mine... :( > > On the other hand, if people used to have /sbin in their path and *do* > remove it properly after the upgrade, they should in theory see a > performance improvement, right? Doesn't the negative directory cache (namei, etc) mitigate this? Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 18:16:28 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31D00106566C for ; Thu, 10 Nov 2011 18:16:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id EA1A28FC1A for ; Thu, 10 Nov 2011 18:16:27 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 132102A28CC9; Thu, 10 Nov 2011 19:16:27 +0100 (CET) Date: Thu, 10 Nov 2011 19:16:27 +0100 From: Ed Schouten To: Garrett Cooper Message-ID: <20111110181627.GK2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jl+DbTnyraiZ/loT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:16:28 -0000 --Jl+DbTnyraiZ/loT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Garrett Cooper , 20111110 19:12: > On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten wrote: > > * Peter Wemm , 20111110 18:33: > >> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse > >> than having no /sbin at all, from a perspective of rootvnode lock > >> lifetime. =A0If you can figure out how to get people to remove /sbin a= nd > >> /usr/sbin from their paths after the symlink changes then it becomes a > >> moot point. =A0But heck, I still have /usr/X11R6 in mine... :( > > > > On the other hand, if people used to have /sbin in their path and *do* > > remove it properly after the upgrade, they should in theory see a > > performance improvement, right? >=20 > Doesn't the negative directory cache (namei, etc) mitigate this? Peter is also talking about the fact that if you have a PATH like /bin:/sbin:... and /sbin is a symbolic link to /bin, you end up doing this: execve("/bin/YOURAPP", ...) -> fails execve("/sbin/YOURAPP", ...) -> fails ... execve("/some/other/directory/YOURAPP", ...) -> success The first two system calls together are expected to be slightly slower than they used to be, because both these directories have now grown. --=20 Ed Schouten WWW: http://80386.nl/ --Jl+DbTnyraiZ/loT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvBT6AAoJEG5e2P40kaK77ZkP/2uQF/uYnJ8JWE/zva6wAhN0 x2DXc4ObwbjzynJRAI9MjysM9xi64mZag1a6fTWAQyx+eg+SLikR1Ze+RS5jfoOw SK5Rjs44kY+ffVomJBHF47SYh0FFYI3PyH670gZnjQ4WeWo8g2s3EdUUx7ULdur1 2bhUi6yEAlnkVaN2wisR7lokWXBZ+Wp3NIu/8+s0RTPx2Q+X3FZP4Ka1ekvq6Axx Mwm86Vi2Th+izNkm9xYpC8JTqA5LXtBVK98ly9b0hf3jUCXXDtZo5k5cpOPhoWFK O3LvR2AhDmR39EHaKcf4D66LEGLiIyq42HW5cGW939Z1I8IMJGeEvn4LpEjKZ3wv Wcw8EN8dT+fSKGQ2dhkUAa497p+vzZ9E1fZxe5kZbAZJQueiHPYKedm+pBN/oD51 QH4f7DnbBRR1m897BKkvO/7uvpkMYiC0gPAgpkYbu9frAFWNEOOeiH49IFSaBTXd ME/r8UR7QFPtSbxCejBlMvrqRmHQeK1YJoH8TVPvYd7TthA50Uo8zKINfMTbWGoU CJEmMMdyhqeei53sxdJBxKk001GaBYSmkk5YMmtQLx2Etvw6sspzq6xSxWjpEG9M fFmlC0AivIE20UhJDZi105nLttNHyCqcgVHL3feO7oYOA+wLw1m5evzitANpeV0a HMwJxSoTFipzWAbizDF4 =V8pb -----END PGP SIGNATURE----- --Jl+DbTnyraiZ/loT-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 18:25:32 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D59F1065670 for ; Thu, 10 Nov 2011 18:25:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 13FA58FC0A for ; Thu, 10 Nov 2011 18:25:32 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 7EEE32A28CC9; Thu, 10 Nov 2011 19:25:31 +0100 (CET) Date: Thu, 10 Nov 2011 19:25:31 +0100 From: Ed Schouten To: Warner Losh Message-ID: <20111110182531.GL2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ybNbZnZ8tziJ7D6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:25:32 -0000 --4ybNbZnZ8tziJ7D6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Warner, * Warner Losh , 20111110 18:38: > I'd honestly start small here with (1) move the ones that are > obviously wrong (and aren't specified by posix to be wrong). (2) make > it an option to just make one or two binaries directories with compat > symlinks (because there's a ton of scripts that just know where > binaries life). POSIX doesn't care about specific pathnames that much. According to the spec, only /, /dev, /dev/{console,null,tty} and /tmp are reserved. The rest can be arranged the way you like. The problem is that both proposals (being mine vs. the first option you mentioned) have regressions in some way or another: - Merging sbin with bin may potentially make stuff slower, because of redundant PATH lookups, under the assumption that people don't update their PATH. - Moving utilities from /usr/sbin to /usr/bin and vice versa can potentially cause even more breakage, since 3rd party applications may depend on their location. Even worse: if people don't properly run `make delete-old', they end up having multiple versions of the binary installed on their system. A few symlinks here and there isn't that bad. If we just make sure our base system can eventually work without them, most embedded systems can do so as well. --=20 Ed Schouten WWW: http://80386.nl/ --4ybNbZnZ8tziJ7D6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvBcbAAoJEG5e2P40kaK73wMP/27Ff8L0uv9Jhu+2jRmpuOit S4edQrtzE6MauKvYU4yrygXFERj5AClkYMOYiDKM0+ecxMJQ848VkHcAXkZz8aii wDA+jpoaGdu185CixTedNmY05WhoB6RzZg1jFWfikxd0OaLgBHJkNYcmr3t1r6er 2oeFZuCaj/Rt9ZbKd5Z2cc9zSzyoJnDGjKaT8U9sG7UiBTFK3w1+HSIDzoucT+su g87OJIx+abwDl4XANUsWXjHjiwg4w9EzpL+v1VH6hnvpErmNVF09sXoKM30sSVMT IBnVm+6GKa1IE+mflX5EIYow2oRLdomHFXZRZ8uCzUgD/SiAYBJdqKupQCw+NHat EtQV2GU6TgY6TKkuTMpSClbyWiyIgK5Bm804crC7laVdZDukDtX9xcUSlTZSmoEd tYsiuQzmzsmxOIld4MhwdL7HgkAECufgWu+a1Enq6bQubtIbbzCqFzy6izv5HRpf vigGBr5sqgcZRcynx4aa6920ahL10cPWTglBq7jMj302D8xga5B8f6TPVJ+iCqML YRSSu2aD3pPwJ2Vf1W9ifqRVEP9NH2cLI9J2MLF0Bhvc0I5SaOuI3PkCKCIl4vJT FIIi7yvG0If/xGxTq8wOAtvbo/K2NzAruCms97LX1CxADGjVYCCXYT2kiC6pVH4n rRuyzFyVce/gAZvKFBmy =fLQr -----END PGP SIGNATURE----- --4ybNbZnZ8tziJ7D6-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 18:36:57 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8DA61065676 for ; Thu, 10 Nov 2011 18:36:57 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 72CDD8FC18 for ; Thu, 10 Nov 2011 18:36:57 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id pAAIaqGm057862; Thu, 10 Nov 2011 13:36:52 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id pAAIap4b057861; Thu, 10 Nov 2011 13:36:51 -0500 (EST) (envelope-from wollman) Date: Thu, 10 Nov 2011 13:36:51 -0500 (EST) From: Garrett Wollman Message-Id: <201111101836.pAAIap4b057861@hergotha.csail.mit.edu> To: imp@bsdimp.com In-Reply-To: References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 10 Nov 2011 13:36:52 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:36:57 -0000 In article , Warner Losh writes: >I'd honestly start small here with (1) move the ones that are obviously >wrong (and aren't specified by posix to be wrong). POSIX doesn't specify paths for utilities. (The only paths specified by POSIX are "/dev/tty" and "/dev/null", and it doesn't require that "/dev" actually exist.) -GAWollman From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 18:43:05 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67877106566B for ; Thu, 10 Nov 2011 18:43:05 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 25EEB8FC1B for ; Thu, 10 Nov 2011 18:43:04 +0000 (UTC) Received: by ggnk3 with SMTP id k3so4714395ggn.13 for ; Thu, 10 Nov 2011 10:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sy3HeicSKFcHks54uRuKDs6Oypwalfoct9wa8ZWQiNo=; b=Q1HgsGVZZEhsAnSnbDk681E9KsTbJwAHh5CFykbnr6By2vYesGIL/yKUaIQb3xLWE3 BjS9CR1U8oSq01eKqGwXjv/p5fJhZ5T9HyTJiNRfgrkZiJbZDMGOJjT/+rN82XID4fdt oGaYfSyIaq82Cs+Fc1Ey8jGu3SkE4PwZyLoK4= MIME-Version: 1.0 Received: by 10.68.29.229 with SMTP id n5mr16565104pbh.80.1320950583936; Thu, 10 Nov 2011 10:43:03 -0800 (PST) Received: by 10.68.50.226 with HTTP; Thu, 10 Nov 2011 10:43:03 -0800 (PST) In-Reply-To: References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> Date: Thu, 10 Nov 2011 10:43:03 -0800 Message-ID: From: Peter Wemm To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:43:05 -0000 On Thu, Nov 10, 2011 at 10:12 AM, Garrett Cooper wrote= : > On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten wrote: >> * Peter Wemm , 20111110 18:33: >>> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse >>> than having no /sbin at all, from a perspective of rootvnode lock >>> lifetime. =A0If you can figure out how to get people to remove /sbin an= d >>> /usr/sbin from their paths after the symlink changes then it becomes a >>> moot point. =A0But heck, I still have /usr/X11R6 in mine... :( >> >> On the other hand, if people used to have /sbin in their path and *do* >> remove it properly after the upgrade, they should in theory see a >> performance improvement, right? > > =A0 =A0Doesn't the negative directory cache (namei, etc) mitigate this? > Thanks! Yes, the negative cache entries in the name cache should help. You know, we have very good tools to characterize the effects on this.. see ministat(1). I'd be interested to see if the effects are worth worrying about on things = like: repeated shell startup (think: system(3)), or sh -c "somecommand" buildworld time runtime of non-trivial shell scripts, eg: configure, perl Configure etc runtime of other some perl scripts that have a bunch of system() or `cmd` all over the damn place. .. all with and without optimal $PATHs and bad $PATHs. The one that I can't think of a good way to characterize would be systemic effects on rootvnode locking from hitting a /sbin->/bin symlink. That's harder to measure because it affects other users of the system than the item under test. Even things like sh -c "command" is hard to measure because it'll hit the name cache with 100% success and won't test the cache miss cases. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 19:05:38 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11016106564A for ; Thu, 10 Nov 2011 19:05:38 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF7B8FC13 for ; Thu, 10 Nov 2011 19:05:37 +0000 (UTC) Received: by wwg14 with SMTP id 14so2289540wwg.31 for ; Thu, 10 Nov 2011 11:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hf+TOfXrCArpJKfokkwHUf54pG+5KKrUPKLYxnRZoo8=; b=oh6G46MfvcFjNh/TCsMKB+64O6425Quysfe1n61LnRfVX0lcvcXWyDeTx6KzFJWoTD wTX4Gk6H+DB3JZtEvkmN0a3w/fN8WhbQJWxzbWBkA7/LGkbvDpCZpADlBOD1H64/MzGG Y8zgZAFs+3oCmTKRsHm2vXgCvN8n6XERmM4ho= MIME-Version: 1.0 Received: by 10.182.31.15 with SMTP id w15mr2153042obh.7.1320951935929; Thu, 10 Nov 2011 11:05:35 -0800 (PST) Received: by 10.182.122.33 with HTTP; Thu, 10 Nov 2011 11:05:35 -0800 (PST) In-Reply-To: References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> Date: Thu, 10 Nov 2011 11:05:35 -0800 Message-ID: From: Garrett Cooper To: Peter Wemm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 19:05:38 -0000 On Thu, Nov 10, 2011 at 10:43 AM, Peter Wemm wrote: > On Thu, Nov 10, 2011 at 10:12 AM, Garrett Cooper wro= te: >> On Thu, Nov 10, 2011 at 9:47 AM, Ed Schouten wrote: >>> * Peter Wemm , 20111110 18:33: >>>> Having /sbin in $PATH where /sbin is a symlink to /bin would be worse >>>> than having no /sbin at all, from a perspective of rootvnode lock >>>> lifetime. =A0If you can figure out how to get people to remove /sbin a= nd >>>> /usr/sbin from their paths after the symlink changes then it becomes a >>>> moot point. =A0But heck, I still have /usr/X11R6 in mine... :( >>> >>> On the other hand, if people used to have /sbin in their path and *do* >>> remove it properly after the upgrade, they should in theory see a >>> performance improvement, right? >> >> =A0 =A0Doesn't the negative directory cache (namei, etc) mitigate this? >> Thanks! > > Yes, the negative cache entries in the name cache should help. > > You know, we have very good tools to characterize the effects on > this.. see ministat(1). > > I'd be interested to see if the effects are worth worrying about on thing= s like: > > repeated shell startup (think: system(3)), or sh -c "somecommand" > buildworld time > runtime of non-trivial shell scripts, eg: configure, perl Configure etc > runtime of other some perl scripts that have a bunch of system() or > `cmd` all over the damn place. > > .. all with and without optimal $PATHs and bad $PATHs. > > The one that I can't think of a good way to characterize would be > systemic effects on rootvnode locking from hitting a /sbin->/bin > symlink. =A0That's harder to measure because it affects other users of > the system than the item under test. > > Even things like sh -c "command" is hard to measure because it'll hit > the name cache with 100% success and won't test the cache miss cases. gnn / Professor McKusick's book -- the Design and Implementation of FreeBSD -- suggests that this is an optimal method, but the benchmarks were run some time ago and hardware has changed. I think that rerunning the benchmarks on i386 vs amd64 vs {arm,mips,etc} would definitely be a good idea. Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 19:09:54 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69423106566B for ; Thu, 10 Nov 2011 19:09:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 2BDBA8FC13 for ; Thu, 10 Nov 2011 19:09:54 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 96AF82A28CC9; Thu, 10 Nov 2011 20:09:53 +0100 (CET) Date: Thu, 10 Nov 2011 20:09:53 +0100 From: Ed Schouten To: Garrett Cooper Message-ID: <20111110190953.GM2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wwtQuX191/I956S7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 19:09:54 -0000 --wwtQuX191/I956S7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Garrett Cooper , 20111110 20:05: > gnn / Professor McKusick's book -- the Design and Implementation of > FreeBSD -- suggests that this is an optimal method, but the benchmarks > were run some time ago and hardware has changed. I think that > rerunning the benchmarks on i386 vs amd64 vs {arm,mips,etc} would > definitely be a good idea. Be my guest. :-) --=20 Ed Schouten WWW: http://80386.nl/ --wwtQuX191/I956S7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvCGBAAoJEG5e2P40kaK7B3MQAIv5xwE0W1cbyb49p6zeDp2M WvsGgKcPSq2cS56Cc4z0Pa2+rQeDXiCpL02D16Xr53BDm/U0U8dX8ZEQ4QNsyg/l hhMRRLsrVlDPvJ2H6EUYfC4tSuETra5luFYPl3RLqcksj8YXn4Iu0Um8gCdgr1Tf QYeyfqkyMfMVlqpDfcNJpY8kwDHaJ+/4UOSijEKvJIMnpQoxX+oGZ0LOBHRCRhX8 D20e2P55DZvSExE0NgBULWB+pQBQUTjCM8JeNGx1xPolVrPHeW6PVvvL6P2NKrh8 NoFW8RahOtraluhW+SEr/lKuS9fPV68URFDckGfH+vmsOABuxv47ft3EU832La9A WZe9w8gfBE3lZ0XxIELqIPBk/Hh8Kk7WqlSHAWHqSgSR2Y7aYnqiAMGcrRADncwp NpaX6yoE3ONBbXTjqo8zKrjRLla9qNZcE2tE2+qtcIOOZXNjO6a6G4pqWEXbJd09 y2+t+4CcGfh1/UW0YLGXBzim9l0i4jWHjVkxrN2+ghaRc/nq4+MaDmtmbYa5Dm7R nAP38Noyzqv4DyKZw8gljxk8ZmFnzIPapfa/UToQ9whfVgu8ax9DXrTeG95Zdfel tDXfSJXP5gQxaGswnjNka+Pku9wGdztb/vB+1sREH7E7C+YF9T2EWyHbSkH5I46S PEv17lxoU8tOCWgxN0io =4uXf -----END PGP SIGNATURE----- --wwtQuX191/I956S7-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 19:18:36 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C548106566B; Thu, 10 Nov 2011 19:18:36 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07FCA8FC14; Thu, 10 Nov 2011 19:18:34 +0000 (UTC) Received: by yenl2 with SMTP id l2so1879492yen.13 for ; Thu, 10 Nov 2011 11:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gjKX+XBdp+xAUtIHVvYLw8+KNz2DzV8+l7aWPoRxrIg=; b=GuMoYY2tA3tflr+wfsAx7vnPHkaL9bKI5r755jWlC+pNFMVPLdDFbfkbKdKUohAV7N 5UOjuVHAa/pliH4IuYIERTC2w7iocKR5gdzPrEp6a7OW1XiyWcfHdwEP9cy3Z7nt7XWD 4H+nNCuoupfJf3/UvY2S74aE/ilAYnT0VkUkQ= MIME-Version: 1.0 Received: by 10.68.122.169 with SMTP id lt9mr16747591pbb.114.1320952713954; Thu, 10 Nov 2011 11:18:33 -0800 (PST) Received: by 10.68.50.226 with HTTP; Thu, 10 Nov 2011 11:18:33 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Nov 2011 11:18:33 -0800 Message-ID: From: Peter Wemm To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Giovanni Trematerra , freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 19:18:36 -0000 On Wed, Nov 9, 2011 at 5:52 PM, Garrett Cooper wrote: > On Nov 9, 2011, at 4:49 PM, Peter Wemm wrote: > >> On Wed, Nov 9, 2011 at 3:39 PM, Giovanni Trematerra = wrote: >>> Are they deprecated enough to be removed, now? >>> FYI FIFO doesn't support them. >>> >>> -- >>> Gianni >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/kern/sys_pipe.c (revision 227233) >>> +++ sys/kern/sys_pipe.c (working copy) >>> @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td) >>> =A0 =A0 =A0 =A0*(int *)data =3D fgetown(&mpipe->pipe_sigio); >>> =A0 =A0 =A0 =A0break; >>> >>> - =A0 /* This is deprecated, FIOSETOWN should be used instead. */ >>> - =A0 case TIOCSPGRP: >>> - =A0 =A0 =A0 PIPE_UNLOCK(mpipe); >>> - =A0 =A0 =A0 error =3D fsetown(-(*(int *)data), &mpipe->pipe_sigio); >>> - =A0 =A0 =A0 goto out_unlocked; >>> - >>> - =A0 /* This is deprecated, FIOGETOWN should be used instead. */ >>> - =A0 case TIOCGPGRP: >>> - =A0 =A0 =A0 *(int *)data =3D -fgetown(&mpipe->pipe_sigio); >>> - =A0 =A0 =A0 break; >>> - >>> =A0 =A0default: >>> =A0 =A0 =A0 =A0error =3D ENOTTY; >> >> Be very very careful with this. =A0It's part of the classic BSD job >> control API. =A0It would be wise to survey whether any ports shells use >> this. >> >> You might also want to consider things like this in libc: >> int >> tcsetpgrp(int fd, pid_t pgrp) >> { >> =A0 =A0 =A0 =A0int s; >> >> =A0 =A0 =A0 =A0s =3D pgrp; >> =A0 =A0 =A0 =A0return (_ioctl(fd, TIOCSPGRP, &s)); >> } >> Our own libc code uses this, albeit on an API intended to be used on a t= ty. >> >> The shell I'd be most concerned about is csh/tcsh in our tree. It has >> quite an #ifdef legacy layer and I couldn't convince myself it wasn't >> using this indirectly (or the tc* functions) on pipes. >> >> It might also be an idea to see if the linux compat layer can be >> switched over to using the newer API. > > Move to a compat library perhaps? > -Garrett It's not a compat library candidate. Summary of the issue: ioctl(fd, TIOCSPGRP, arg) can be used on sockets, pipes, ttys. But not fif= os. this is a classic BSD job control API. libc itself uses this internally on ttys. libc doesn't check that the function that does this is actually a tty, it could be being used by shells and pipes as an obscure side effect. The API is equivalent to FIOSETOWN etc and sockets and pipes use common code to implement both ioctl() calls. The proposed patch was to remove the TIOCSPGRP -> FIOSETOWN mapping for pipes only, to sync them with fifos. ttys and sockets would be unaffected. The implementation function still has to stay. Its not a large chunk of obsolete code that goes away, its just the mapping between the ioctl number and the implementation. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 22:08:47 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 597AC106564A for ; Thu, 10 Nov 2011 22:08:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B793314EF34; Thu, 10 Nov 2011 22:08:46 +0000 (UTC) Message-ID: <4EBC4B6E.4060607@FreeBSD.org> Date: Thu, 10 Nov 2011 14:08:46 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Ed Schouten References: <20111110123919.GF2164@hoeg.nl> In-Reply-To: <20111110123919.GF2164@hoeg.nl> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 22:08:47 -0000 On 11/10/2011 04:39, Ed Schouten wrote: > I suspect this email could be one of the last emails I'm sending before > one of you hire an assassin to get rid of me, but here it goes. Au contraire, I think your work on improving the general quality of our code has earned you many many brownie points, so you're far from being run out of town on a rail. :) This particular proposal though I personally am confused about, and I apologize if I missed something obvious, but what is the value of making this change? I've read the thread so far, and I understand that the hysterical raisins that prompted the creation of sbin may or may not still apply, but I haven't yet understood what we would gain by moving everything. Sorry if I'm being dense, Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 22:20:52 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C491065676 for ; Thu, 10 Nov 2011 22:20:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by mx1.freebsd.org (Postfix) with ESMTP id 07C528FC25 for ; Thu, 10 Nov 2011 22:20:52 +0000 (UTC) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E79BD5F984C; Thu, 10 Nov 2011 22:20:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4E76A216C6E; Thu, 10 Nov 2011 22:20:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 166FC1703A61; Fri, 11 Nov 2011 09:20:16 +1100 (EST) To: Garrett Cooper From: Mark Andrews References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> In-reply-to: Your message of "Thu, 10 Nov 2011 11:05:35 -0800." Date: Fri, 11 Nov 2011 09:20:16 +1100 Message-Id: <20111110222016.166FC1703A61@drugs.dv.isc.org> X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.ams1.isc.org Cc: Ed Schouten , arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 22:20:52 -0000 If we want to fix thing make any port the replicates anything in the base system install itself into its own heirachy. Installing into /usr/local make it impossible to select different version on a per user basis. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 23:06:19 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 292891065674 for ; Thu, 10 Nov 2011 23:06:19 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D67E48FC08 for ; Thu, 10 Nov 2011 23:06:18 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so4248008vcb.13 for ; Thu, 10 Nov 2011 15:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g5yZuKUXuEmgljaKKFHA7c5kVB4S5WjEPeK+LlFAtnE=; b=PcVXf61qgqC1MnkG5NJRS11niZPlrteKYaWDmfVWXB/EfzMJeR44szNp6C0o0SzcHg q6fb4lJNet/7E8TceTxj4AJlvvDEtVkEInxJe0Q2/y9v3cOwAGecIFVf9oQTW4w9IDGT wXerN+R3rJ1smjBkA1YC/xx2Kzjws9TLbIWD0= MIME-Version: 1.0 Received: by 10.229.29.73 with SMTP id p9mr1460149qcc.217.1320966378098; Thu, 10 Nov 2011 15:06:18 -0800 (PST) Sender: giovanni.trematerra@gmail.com Received: by 10.229.1.216 with HTTP; Thu, 10 Nov 2011 15:06:18 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Nov 2011 00:06:18 +0100 X-Google-Sender-Auth: gwNoM1OPRvJYbooSZy7wEI3u5Xw Message-ID: From: Giovanni Trematerra To: Peter Wemm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 23:06:19 -0000 On Thu, Nov 10, 2011 at 8:18 PM, Peter Wemm wrote: > On Wed, Nov 9, 2011 at 5:52 PM, Garrett Cooper wrote= : >> On Nov 9, 2011, at 4:49 PM, Peter Wemm wrote: >> >>> On Wed, Nov 9, 2011 at 3:39 PM, Giovanni Trematerra wrote: >>>> Are they deprecated enough to be removed, now? >>>> FYI FIFO doesn't support them. >>>> >>>> -- >>>> Gianni >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- sys/kern/sys_pipe.c (revision 227233) >>>> +++ sys/kern/sys_pipe.c (working copy) >>>> @@ -1304,17 +1304,6 @@ pipe_ioctl(fp, cmd, data, active_cred, td) >>>> =A0 =A0 =A0 =A0*(int *)data =3D fgetown(&mpipe->pipe_sigio); >>>> =A0 =A0 =A0 =A0break; >>>> >>>> - =A0 /* This is deprecated, FIOSETOWN should be used instead. */ >>>> - =A0 case TIOCSPGRP: >>>> - =A0 =A0 =A0 PIPE_UNLOCK(mpipe); >>>> - =A0 =A0 =A0 error =3D fsetown(-(*(int *)data), &mpipe->pipe_sigio); >>>> - =A0 =A0 =A0 goto out_unlocked; >>>> - >>>> - =A0 /* This is deprecated, FIOGETOWN should be used instead. */ >>>> - =A0 case TIOCGPGRP: >>>> - =A0 =A0 =A0 *(int *)data =3D -fgetown(&mpipe->pipe_sigio); >>>> - =A0 =A0 =A0 break; >>>> - >>>> =A0 =A0default: >>>> =A0 =A0 =A0 =A0error =3D ENOTTY; >>> >>> Be very very careful with this. =A0It's part of the classic BSD job >>> control API. =A0It would be wise to survey whether any ports shells use >>> this. >>> >>> You might also want to consider things like this in libc: >>> int >>> tcsetpgrp(int fd, pid_t pgrp) >>> { >>> =A0 =A0 =A0 =A0int s; >>> >>> =A0 =A0 =A0 =A0s =3D pgrp; >>> =A0 =A0 =A0 =A0return (_ioctl(fd, TIOCSPGRP, &s)); >>> } >>> Our own libc code uses this, albeit on an API intended to be used on a = tty. >>> >>> The shell I'd be most concerned about is csh/tcsh in our tree. It has >>> quite an #ifdef legacy layer and I couldn't convince myself it wasn't >>> using this indirectly (or the tc* functions) on pipes. >>> >>> It might also be an idea to see if the linux compat layer can be >>> switched over to using the newer API. >> >> Move to a compat library perhaps? >> -Garrett > > It's not a compat library candidate. > > Summary of the issue: > ioctl(fd, TIOCSPGRP, arg) can be used on sockets, pipes, ttys. =A0But not= fifos. > this is a classic BSD job control API. > libc itself uses this internally on ttys. > libc doesn't check that the function that does this is actually a tty, > it could be being used by shells and pipes as an obscure side effect. > The API is equivalent to FIOSETOWN etc and sockets and pipes use > common code to implement both ioctl() calls. > > The proposed patch was to remove the TIOCSPGRP -> FIOSETOWN mapping > for pipes only, to sync them with fifos. =A0ttys and sockets would be > unaffected. > > The implementation function still has to stay. =A0Its not a large chunk > of obsolete code that goes away, its just the mapping between the > ioctl number and the implementation. > Thank you Peter, just last question on this. Having just one ioctl function for both pipe and fifo, would be a problem having TIOCSPGRP and TIOCGPGRP implemented for fifo? -- Gianni From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 23:18:48 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1EE3106564A; Thu, 10 Nov 2011 23:18:48 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-dy0-f54.google.com (mail-dy0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F0B68FC13; Thu, 10 Nov 2011 23:18:48 +0000 (UTC) Received: by dyk29 with SMTP id 29so227395dyk.13 for ; Thu, 10 Nov 2011 15:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fe12w/twWX8VU6c4V9VUWR4YtKvag1kUiixmpUfu+7U=; b=T4Qxb4cHzRNVWRwxpUzpCiAUblWT5tkYlJuQl5+hH9vQGRcLCRf1psRDDwsb5BOvPn yFoPJTdeYnvX4bLI1levbIPL/Z4vlzxrMbZ21MB3vWsXhGK/0pmlg7DhXPya3pCbuFAI 6jLMMe7B6bAoSgv6pNDtFgH66iJZi5aCqbe6g= MIME-Version: 1.0 Received: by 10.68.24.65 with SMTP id s1mr18666636pbf.12.1320967126216; Thu, 10 Nov 2011 15:18:46 -0800 (PST) Received: by 10.68.50.226 with HTTP; Thu, 10 Nov 2011 15:18:46 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Nov 2011 15:18:46 -0800 Message-ID: From: Peter Wemm To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd-arch@freebsd.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 23:18:49 -0000 On Thu, Nov 10, 2011 at 3:06 PM, Giovanni Trematerra wrote: > Thank you Peter, just last question on this. > Having just one ioctl function for both pipe and fifo, would be a problem > having TIOCSPGRP and TIOCGPGRP implemented for fifo? If the code is common, I can't imagine a plausible scenario where it could cause a new problem. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Nov 10 23:30:01 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 427171065670; Thu, 10 Nov 2011 23:30:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id C859E8FC08; Thu, 10 Nov 2011 23:29:57 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAANQ8L5025533 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 10 Nov 2011 16:26:10 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 10 Nov 2011 16:26:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88ECC88C-1E3E-4FF1-A9AB-7105FF93ECBE@bsdimp.com> References: To: Peter Wemm X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 10 Nov 2011 16:26:10 -0700 (MST) Cc: Garrett Cooper , Giovanni Trematerra , freebsd-arch@FreeBSD.org Subject: Re: deprecated TIOCSPGRP and TIOCGPGRP ioctl command X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 23:30:01 -0000 On Nov 10, 2011, at 4:18 PM, Peter Wemm wrote: > On Thu, Nov 10, 2011 at 3:06 PM, Giovanni Trematerra = wrote: >> Thank you Peter, just last question on this. >> Having just one ioctl function for both pipe and fifo, would be a = problem >> having TIOCSPGRP and TIOCGPGRP implemented for fifo? >=20 > If the code is common, I can't imagine a plausible scenario where it > could cause a new problem. Yea, at most I could imagine someone writing an autoconfig script or = something that depends on this difference. However, I doubt there's any = autoconfig scripts that rely on being able to set them on a pipe, but = not on a fifo that would break. Oh, wait, that's assuming autoconf is sane, which may exceed the = evidence on the record... Warner From owner-freebsd-arch@FreeBSD.ORG Fri Nov 11 01:58:24 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D947106566C for ; Fri, 11 Nov 2011 01:58:24 +0000 (UTC) (envelope-from lankfordandrew@charter.net) Received: from que21.charter.net (que21.charter.net [209.225.8.22]) by mx1.freebsd.org (Postfix) with ESMTP id E88038FC0A for ; Fri, 11 Nov 2011 01:58:23 +0000 (UTC) Received: from imp11 ([10.20.200.11]) by mta31.charter.net (InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP id <20111111012206.TRBI11241.mta31.charter.net@imp11>; Thu, 10 Nov 2011 20:22:06 -0500 Received: from [192.168.1.110] ([75.138.218.188]) by imp11 with smtp.charter.net id vdN61h00N44UhuK05dN66K; Thu, 10 Nov 2011 20:22:06 -0500 X-Authority-Analysis: v=1.1 cv=3kn4snR/2TdwuYXvh+wm0CPnSGzQFWY7ukd303aPFv0= c=1 sm=1 a=WY28OWh-Hc4A:10 a=-KF8gwd8yYQA:10 a=yUnIBFQkZM0A:10 a=IkcTkHD0fZMA:10 a=2/T1fqaInIOOFaqk00hqeQ==:17 a=-ZVscbBoAnK5W6EZB30A:9 a=RUTXumDnAzNoEEKOdYIA:7 a=QEXdDO2ut3YA:10 a=2/T1fqaInIOOFaqk00hqeQ==:117 Message-ID: <4EBC78BE.2090408@charter.net> Date: Thu, 10 Nov 2011 20:22:06 -0500 From: Andrew Lankford User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: arch@freebsd.org, ed@80386.nl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 11 Nov 2011 03:18:01 +0000 Cc: Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 01:58:24 -0000 >- Move everything in /usr/games to /usr/bin and turn it into a symbolic link pointing to /usr/bin. No no no....move all or 99.9% of /usr/games to ports/games or ports/math. Then put an unencumbered ascii-graphics mode version of Quake 3 in /usr/bin. Perfection! Andrew Lankford From owner-freebsd-arch@FreeBSD.ORG Fri Nov 11 10:46:32 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5441F106564A for ; Fri, 11 Nov 2011 10:46:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 0946D8FC1E for ; Fri, 11 Nov 2011 10:46:31 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 47B552A28CB3; Fri, 11 Nov 2011 11:46:30 +0100 (CET) Date: Fri, 11 Nov 2011 11:46:30 +0100 From: Ed Schouten To: Peter Wemm Message-ID: <20111111104630.GO2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xYeFQzU4VZLrHqxU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 10:46:32 -0000 --xYeFQzU4VZLrHqxU Content-Type: multipart/mixed; boundary="2uzDqHpccQJpqF2n" Content-Disposition: inline --2uzDqHpccQJpqF2n Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, * Peter Wemm , 20111110 19:43: > repeated shell startup (think: system(3)), or sh -c "somecommand" I have done some testing and it seems we have little to worry about, in my opinion. I have written a small script that copies the `true' binary to each of the directories specified in $PATH and executes it 100.000 times. I have executed these tests on an installation where sbin is still separate and one where it is merged. Also, I've used both a $PATH variable that contains /sbin and one where it is removed. Observations: - Indeed, the running time increases when the binary to be executed is in a directory that is placed farther to the end of $PATH. - Redundant directories in $PATH do cause some overhead. - When we merge sbin with bin and the user properly removes sbin from his/her PATH variable, things get slightly faster than they used to be. - When the user forgets to do so, the results are slightly worse than before. Of course, this was just a quick way of testing things. If people want to do more thorough tests, be my guest. I have attached an updated version of my patch, the script I used to do the benchmark and the results I have obtained. --=20 Ed Schouten WWW: http://80386.nl/ --2uzDqHpccQJpqF2n Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="nuke-sbin.diff" Content-Transfer-Encoding: quoted-printable Index: secure/usr.sbin/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- secure/usr.sbin/Makefile.inc (revision 227417) +++ secure/usr.sbin/Makefile.inc (working copy) @@ -1,5 +1,5 @@ # $FreeBSD$ =20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 .include "../Makefile.inc" Index: games/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- games/Makefile.inc (revision 227417) +++ games/Makefile.inc (working copy) @@ -1,7 +1,7 @@ # @(#)Makefile.inc 8.1 (Berkeley) 5/31/93 # $FreeBSD$ =20 -BINDIR?=3D /usr/games +BINDIR?=3D /usr/bin FILESDIR?=3D ${SHAREDIR}/games WARNS?=3D 6 DISTRIBUTION?=3D games Index: tools/tools/cxgbtool/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- tools/tools/cxgbtool/Makefile (revision 227417) +++ tools/tools/cxgbtool/Makefile (working copy) @@ -5,6 +5,6 @@ NO_MAN=3D CFLAGS+=3D -I${.CURDIR}/../../../sys/dev/cxgb -I. CFLAGS+=3D -DCONFIG_T3_REGS -DCHELSIO_INTERNAL -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 .include Index: tools/tools/vimage/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- tools/tools/vimage/Makefile (revision 227417) +++ tools/tools/vimage/Makefile (working copy) @@ -9,6 +9,6 @@ =20 MAN=3D vimage.8 =20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 .include Index: tools/tools/cxgbetool/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- tools/tools/cxgbetool/Makefile (revision 227417) +++ tools/tools/cxgbetool/Makefile (working copy) @@ -4,6 +4,6 @@ SRCS=3D cxgbetool.c NO_MAN=3D CFLAGS+=3D -I${.CURDIR}/../../../sys/dev/cxgbe -I. -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 .include Index: kerberos5/usr.sbin/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- kerberos5/usr.sbin/Makefile.inc (revision 227417) +++ kerberos5/usr.sbin/Makefile.inc (working copy) @@ -1,5 +1,5 @@ # $FreeBSD$ =20 -BINDIR=3D /usr/sbin +BINDIR=3D /usr/bin =20 .include "../Makefile.inc" Index: share/man/man7/hier.7 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/man/man7/hier.7 (revision 227417) +++ share/man/man7/hier.7 (working copy) @@ -145,8 +145,6 @@ .It Pa /lib/ critical system libraries needed for binaries in .Pa /bin -and -.Pa /sbin .Pp .Bl -tag -width ".Pa geom/" -compact .It Pa geom/ @@ -157,8 +155,6 @@ .It Pa /libexec/ critical system utilities needed for binaries in .Pa /bin -and -.Pa /sbin .It Pa /media/ contains subdirectories to be used as mount points for removable media such as CDs, USB drives, and @@ -176,9 +172,6 @@ .Xr rescue 8 .It Pa /root/ root's HOME directory -.It Pa /sbin/ -system programs and administration utilities -fundamental to both single-user and multi-user environments .It Pa /tmp/ temporary files that are not guaranteed to persist across system reboots .It Pa /usr/ @@ -192,8 +185,6 @@ such as Linux (created by .Xr sysinstall 8 ) -.It Pa games/ -useful and semi-frivolous programs .It Pa include/ standard C include files .Pp @@ -462,8 +453,6 @@ The .Fx ports collection (optional). -.It Pa sbin/ -system daemons & system utilities (executed by users) .It Pa share/ architecture-independent files .Pp @@ -645,8 +634,6 @@ source code for contributed cryptography software .It Pa etc/ source code for files in /etc -.It Pa games/ -source code for files in /usr/games .It Pa gnu/ Utilities covered by the GNU General Public License .It Pa include/ @@ -661,8 +648,6 @@ files required to produce a .Fx release -.It Pa sbin/ -source code for files in /sbin .It Pa secure/ build directory for files in /usr/src/crypto .It Pa share/ @@ -674,8 +659,6 @@ .Fx .It Pa usr.bin/ source code for files in /usr/bin -.It Pa usr.sbin/ -source code for files in /usr/sbin .El .El .It Pa /var/ Index: usr.sbin/tcpdump/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.sbin/tcpdump/Makefile.inc (revision 227417) +++ usr.sbin/tcpdump/Makefile.inc (working copy) @@ -1,6 +1,6 @@ # @(#)Makefile.inc 5.1 (Berkeley) 5/11/90 # $FreeBSD$ =20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 WARNS?=3D 3 Index: usr.sbin/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.sbin/Makefile.inc (revision 227417) +++ usr.sbin/Makefile.inc (working copy) @@ -1,6 +1,6 @@ # @(#)Makefile.inc 8.1 (Berkeley) 6/6/93 # $FreeBSD$ =20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 WARNS?=3D 6 Index: usr.sbin/bootparamd/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.sbin/bootparamd/Makefile.inc (revision 227417) +++ usr.sbin/bootparamd/Makefile.inc (working copy) @@ -1,6 +1,6 @@ # @(#)Makefile.inc 5.1 (Berkeley) 5/11/90 # $FreeBSD$ =20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 WARNS?=3D 2 Index: usr.sbin/wpa/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.sbin/wpa/Makefile.inc (revision 227417) +++ usr.sbin/wpa/Makefile.inc (working copy) @@ -1,6 +1,6 @@ # $FreeBSD$ =20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 WPA_DISTDIR?=3D ${.CURDIR}/../../../contrib/wpa/ WPA_SUPPLICANT_DISTDIR?=3D${WPA_DISTDIR}/wpa_supplicant Index: usr.sbin/mailwrapper/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.sbin/mailwrapper/Makefile (revision 227417) +++ usr.sbin/mailwrapper/Makefile (working copy) @@ -11,11 +11,11 @@ .endif =20 .if ${MK_MAILWRAPPER} !=3D "no" || ${MK_SENDMAIL} !=3D "no" -SYMLINKS=3D ${BINDIR}/mailwrapper /usr/sbin/sendmail \ - ${BINDIR}/mailwrapper /usr/sbin/hoststat \ - ${BINDIR}/mailwrapper /usr/sbin/purgestat \ - ${BINDIR}/mailwrapper /usr/bin/newaliases \ - ${BINDIR}/mailwrapper /usr/bin/mailq +SYMLINKS=3D mailwrapper ${BINDIR}/sendmail \ + mailwrapper ${BINDIR}/hoststat \ + mailwrapper ${BINDIR}/purgestat \ + mailwrapper ${BINDIR}/newaliases \ + mailwrapper ${BINDIR}/mailq =20 .if ${MK_MAILWRAPPER} =3D=3D "no" && ${MK_SENDMAIL} !=3D "no" SYMLINKS+=3D /usr/libexec/sendmail/sendmail ${BINDIR}/mailwrapper Index: usr.sbin/nologin/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.sbin/nologin/Makefile (revision 227417) +++ usr.sbin/nologin/Makefile (working copy) @@ -4,7 +4,7 @@ PROG=3D nologin MAN=3D nologin.5 nologin.8 =20 -SYMLINKS=3D ${BINDIR}/nologin /sbin/nologin +SYMLINKS=3D ${BINDIR}/nologin /bin/nologin =20 # It is important that nologin be statically linked for security # reasons. A dynamic non-setuid binary can be linked against a trojan Index: include/paths.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- include/paths.h (revision 227417) +++ include/paths.h (working copy) @@ -38,9 +38,9 @@ /* Default search path. */ #define _PATH_DEFPATH "/usr/bin:/bin" /* All standard utilities path. */ -#define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" +#define _PATH_STDPATH "/usr/bin:/bin" /* Locate system binaries. */ -#define _PATH_SYSPATH "/sbin:/usr/sbin" +#define _PATH_SYSPATH "/bin:/usr/bin" =20 #define _PATH_AUTHCONF "/etc/auth.conf" #define _PATH_BSHELL "/bin/sh" @@ -58,31 +58,31 @@ #define _PATH_ETC "/etc" #define _PATH_FTPUSERS "/etc/ftpusers" #define _PATH_FWMEM "/dev/fwmem" -#define _PATH_HALT "/sbin/halt" +#define _PATH_HALT "/bin/halt" #ifdef COMPAT_32BIT #define _PATH_I18NMODULE "/usr/lib32/i18n" #else #define _PATH_I18NMODULE "/usr/lib/i18n" #endif -#define _PATH_IFCONFIG "/sbin/ifconfig" +#define _PATH_IFCONFIG "/bin/ifconfig" #define _PATH_KMEM "/dev/kmem" #define _PATH_LIBMAP_CONF "/etc/libmap.conf" #define _PATH_LOCALE "/usr/share/locale" #define _PATH_LOGIN "/usr/bin/login" #define _PATH_MAILDIR "/var/mail" #define _PATH_MAN "/usr/share/man" -#define _PATH_MDCONFIG "/sbin/mdconfig" +#define _PATH_MDCONFIG "/bin/mdconfig" #define _PATH_MEM "/dev/mem" -#define _PATH_MKSNAP_FFS "/sbin/mksnap_ffs" -#define _PATH_MOUNT "/sbin/mount" -#define _PATH_NEWFS "/sbin/newfs" +#define _PATH_MKSNAP_FFS "/bin/mksnap_ffs" +#define _PATH_MOUNT "/bin/mount" +#define _PATH_NEWFS "/bin/newfs" #define _PATH_NOLOGIN "/var/run/nologin" #define _PATH_RCP "/bin/rcp" -#define _PATH_REBOOT "/sbin/reboot" +#define _PATH_REBOOT "/bin/reboot" #define _PATH_RLOGIN "/usr/bin/rlogin" #define _PATH_RM "/bin/rm" #define _PATH_RSH "/usr/bin/rsh" -#define _PATH_SENDMAIL "/usr/sbin/sendmail" +#define _PATH_SENDMAIL "/usr/bin/sendmail" #define _PATH_SHELLS "/etc/shells" #define _PATH_TTY "/dev/tty" #define _PATH_UNIX "don't use _PATH_UNIX" @@ -107,9 +107,9 @@ #undef _PATH_DEFPATH #define _PATH_DEFPATH "/rescue:/usr/bin:/bin" #undef _PATH_STDPATH -#define _PATH_STDPATH "/rescue:/usr/bin:/bin:/usr/sbin:/sbin" +#define _PATH_STDPATH "/rescue:/usr/bin:/bin" #undef _PATH_SYSPATH -#define _PATH_SYSPATH "/rescue:/sbin:/usr/sbin" +#define _PATH_SYSPATH "/rescue:/bin:/usr/bin" #undef _PATH_BSHELL #define _PATH_BSHELL "/rescue/sh" #undef _PATH_CP Index: sbin/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/Makefile.inc (revision 227417) +++ sbin/Makefile.inc (working copy) @@ -3,7 +3,7 @@ =20 .include =20 -BINDIR?=3D /sbin +BINDIR?=3D /bin WARNS?=3D 6 =20 .if ${MK_DYNAMICROOT} =3D=3D "no" Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.inc1 (revision 227417) +++ Makefile.inc1 (working copy) @@ -613,6 +613,18 @@ .endfor =20 # +# /sbin is now merged into /bin. The same holds for /usr/sbin and /usr/gam= es. +# +installcheck: installcheck_sbin_merge +installcheck_sbin_merge: +.for dir in ${DESTDIR}/sbin ${DESTDIR}/usr/sbin ${DESTDIR}/usr/games + @if test -d ${dir} -a ! -L ${dir}; then \ + echo "ERROR: Directory ${dir} is still present, see /usr/src/UPDATING en= try 20111110."; \ + false; \ + fi +.endfor + +# # Required install tools to be saved in a scratch dir for safety. # .if ${MK_INFO} !=3D "no" Index: cddl/sbin/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- cddl/sbin/Makefile.inc (revision 227417) +++ cddl/sbin/Makefile.inc (working copy) @@ -1,5 +1,5 @@ # $FreeBSD$ =20 -BINDIR?=3D /sbin +BINDIR?=3D /bin =20 .include "../Makefile.inc" Index: cddl/usr.sbin/dtrace/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- cddl/usr.sbin/dtrace/Makefile (revision 227417) +++ cddl/usr.sbin/dtrace/Makefile (working copy) @@ -4,7 +4,7 @@ =20 PROG=3D dtrace SRCS=3D dtrace.c -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 WARNS?=3D 1 =20 Index: cddl/usr.sbin/plockstat/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- cddl/usr.sbin/plockstat/Makefile (revision 227417) +++ cddl/usr.sbin/plockstat/Makefile (working copy) @@ -4,7 +4,7 @@ =20 PROG=3D plockstat SRCS=3D plockstat.c=20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 WARNS?=3D 1 =20 Index: cddl/usr.sbin/lockstat/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- cddl/usr.sbin/lockstat/Makefile (revision 227417) +++ cddl/usr.sbin/lockstat/Makefile (working copy) @@ -5,7 +5,7 @@ PROG=3D lockstat NO_MAN=3D SRCS=3D lockstat.c sym.c -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 WARNS?=3D 1 =20 Index: cddl/usr.sbin/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- cddl/usr.sbin/Makefile.inc (revision 227417) +++ cddl/usr.sbin/Makefile.inc (working copy) @@ -1,5 +1,5 @@ # $FreeBSD$ =20 -BINDIR?=3D /usr/sbin +BINDIR?=3D /usr/bin =20 .include "../Makefile.inc" Index: ObsoleteFiles.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ObsoleteFiles.inc (revision 227417) +++ ObsoleteFiles.inc (working copy) @@ -2164,8 +2164,6 @@ OLD_FILES+=3Dusr/libexec/named-xfer OLD_FILES+=3Dusr/sbin/named.restart OLD_FILES+=3Dusr/sbin/ndc -OLD_FILES+=3Dusr/sbin/nslookup -OLD_FILES+=3Dusr/sbin/nsupdate OLD_FILES+=3Dusr/share/doc/bind/html/acl.html OLD_FILES+=3Dusr/share/doc/bind/html/address_list.html OLD_FILES+=3Dusr/share/doc/bind/html/comments.html @@ -2528,7 +2526,6 @@ # 200212XX OLD_FILES+=3Dusr/sbin/kenv OLD_FILES+=3Dusr/bin/kenv -OLD_FILES+=3Dusr/sbin/elf2aout # 200210XX OLD_FILES+=3Dusr/include/libusbhid.h OLD_FILES+=3Dusr/share/man/man3/All_FreeBSD.3.gz Index: UPDATING =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- UPDATING (revision 227417) +++ UPDATING (working copy) @@ -22,6 +22,24 @@ machines to maximize performance. (To disable malloc debugging, run ln -s aj /etc/malloc.conf.) =20 +20111110: + The /sbin, /usr/sbin and /usr/games directories have been merged + into /bin and /usr/bin. For compatibility, the old directories + have been replaced by symbolic links pointing to `bin'. To + prevent people from possibly breaking their system + automatically, you must perform the merge manually before + `make installworld'. This can be done as follows: + + chflags noschg /sbin/* /usr/sbin/* /usr/games/* + mv /sbin/* /bin + mv /usr/sbin/* /usr/games/* /usr/bin + rmdir /sbin /usr/sbin /usr/games + + After running these commands, you can safely run `make + installworld' to continue your upgrade. Do not reboot your + system in the mean time, as FreeBSD's boot procedure depends on + the existence of /sbin and /usr/sbin. + 20111108: The option VFS_ALLOW_NONMPSAFE option has been added in order to explicitely support non-MPSAFE filesystems. Index: libexec/bootpd/tools/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- libexec/bootpd/tools/Makefile.inc (revision 227417) +++ libexec/bootpd/tools/Makefile.inc (working copy) @@ -1,6 +1,6 @@ # Makefile.inc # $FreeBSD$ =20 -BINDIR=3D /usr/sbin +BINDIR=3D /usr/bin =20 WARNS?=3D 1 Index: etc/mtree/BSD.usr.dist =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- etc/mtree/BSD.usr.dist (revision 227417) +++ etc/mtree/BSD.usr.dist (working copy) @@ -7,8 +7,7 @@ . bin .. - games - .. + games type=3Dlink link=3Dbin include .. lib @@ -55,8 +54,7 @@ .. obj nochange .. - sbin - .. + sbin type=3Dlink link=3Dbin share calendar de_DE.ISO8859-1 Index: etc/mtree/BSD.root.dist =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- etc/mtree/BSD.root.dist (revision 227417) +++ etc/mtree/BSD.root.dist (working copy) @@ -85,8 +85,7 @@ .. root .. - sbin - .. + sbin type=3Dlink link=3Dbin tmp mode=3D01777 .. usr Index: etc/login.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- etc/login.conf (revision 227417) +++ etc/login.conf (working copy) @@ -27,7 +27,7 @@ :copyright=3D/etc/COPYRIGHT:\ :welcome=3D/etc/motd:\ :setenv=3DMAIL=3D/var/mail/$,BLOCKSIZE=3DK,FTP_PASSIVE_MODE=3DYES:\ - :path=3D/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/loc= al/bin ~/bin:\ + :path=3D/bin /usr/bin /usr/local/sbin /usr/local/bin ~/bin:\ :nologin=3D/var/run/nologin:\ :cputime=3Dunlimited:\ :datasize=3Dunlimited:\ @@ -163,7 +163,7 @@ # :ignoretime:\ # :requirehome@:\ # :accounted@:\ -# :path=3D~/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sb= in:\ +# :path=3D~/bin /bin /usr/bin /usr/local/bin /usr/local/sbin:\ # :umask=3D022:\ # :tc=3Dstandard: # @@ -172,7 +172,7 @@ ## root - fallback for root logins ## #root:\ -# :path=3D~/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sb= in:\ +# :path=3D~/bin /bin /usr/bin /usr/local/bin /usr/local/sbin:\ # :cputime=3Dinfinity:\ # :datasize=3Dinfinity:\ # :stacksize=3Dinfinity:\ @@ -214,7 +214,7 @@ ## Settings used by news subsystem ## #news:\ -# :path=3D/usr/local/news/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin= /usr/local/sbin:\ +# :path=3D/usr/local/news/bin /bin /usr/bin /usr/local/bin /usr/local/sbin= :\ # :cputime=3Dinfinity:\ # :filesize=3D128M:\ # :datasize-cur=3D64M:\ --2uzDqHpccQJpqF2n Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bench-results.txt" /sbin, /usr/sbin and /usr/games separate: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/ed/bin => /sbin 263.38 real 80.16 user 185.91 sys => /bin 263.73 real 79.81 user 186.33 sys => /usr/sbin 264.08 real 76.82 user 189.69 sys => /usr/bin 264.44 real 78.04 user 188.80 sys => /usr/games 265.21 real 78.92 user 188.72 sys => /usr/local/sbin 266.19 real 78.54 user 190.04 sys => /usr/local/bin 266.58 real 78.53 user 190.31 sys => /home/ed/bin 267.84 real 78.21 user 191.91 sys PATH=/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/ed/bin => /bin 262.75 real 79.18 user 185.91 sys => /usr/bin 263.49 real 76.18 user 189.86 sys => /usr/local/sbin 264.51 real 77.81 user 189.07 sys => /usr/local/bin 265.14 real 77.97 user 189.53 sys => /home/ed/bin 266.14 real 76.18 user 192.33 sys /sbin, /usr/sbin and /usr/games merged: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/ed/bin => /sbin 264.12 real 78.53 user 188.00 sys => /bin 263.96 real 78.46 user 187.92 sys => /usr/sbin 265.21 real 77.12 user 190.47 sys => /usr/bin 265.44 real 77.59 user 190.21 sys => /usr/games 265.55 real 78.52 user 189.42 sys => /usr/local/sbin 267.28 real 78.21 user 191.37 sys => /usr/local/bin 267.48 real 77.20 user 192.66 sys => /home/ed/bin 268.73 real 77.79 user 193.30 sys PATH=/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/ed/bin => /bin 263.59 real 76.95 user 189.03 sys => /usr/bin 264.37 real 76.95 user 189.84 sys => /usr/local/sbin 265.15 real 78.53 user 189.03 sys => /usr/local/bin 265.75 real 77.10 user 190.98 sys => /home/ed/bin 266.89 real 77.06 user 192.13 sys --2uzDqHpccQJpqF2n-- --xYeFQzU4VZLrHqxU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvP0GAAoJEG5e2P40kaK75/0P/2cAk/OeMO0WEEfMDmn+3Xjs f1c/IjY6YoSJ0zVdPQBjosjbG0cujmgRqGZ4gXTH8HLjh2iDhjMXe8FlChp+wI4t 0Gi+d4RtFg6g4Q7e2gH6LIjSBIW16w/Zg9eu79S9/m1pC2I84R8HEWfa+2N8jOlY feMxD/KQGXzng2Q1bAYLtJS5+ZKpSx3o96ZYZ2RLGNL8eG/fQtJ+baQLtYZjEcEP e9202MXMetB1+X7I3jSCWuiKw3vO9UrYyNGG9icTWVCYF4lSyFyUudkQEO4uMrHO vKPYBxG69vkaUtyh1wPQUS41AW7wnnkY1gmYYvdh4xfzSn6MeupFK6Pi6cO+jk3S nBczhxTEBsSbIx8PfeTBKLXSQFINYDcnARzSqUStz1BccgFe1NZdEn7qSrbeq//z 8e8lOF38qO5sMtRTAt3etG7/VC5MbdB9Hr4ymHzDJpYEwMOU+DNA2+4pkMfpiv1o TWSSiY6kbq4MK8Q+yAAzn4E+HPEpqwu1jCSgzKuFtW4QJbXdkNlwgwckgU6rREGr KnLyD1D6S416gOwUEFbobR25iAHcsP3/3jduM6PBoDKm+K3K0TCAtkM16tstTcLt +ENXuQaRhrfi4IKRyO4xSqUt92yWaNlTwcgtaq4COZEN2VlEG43/NzhA/vtAFFy3 Ib6qBuWiV7F18hukiaUY =BCG3 -----END PGP SIGNATURE----- --xYeFQzU4VZLrHqxU-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 11 11:28:22 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFB6E106564A; Fri, 11 Nov 2011 11:28:22 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 886998FC19; Fri, 11 Nov 2011 11:28:22 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 7CE1F2A28CB3; Fri, 11 Nov 2011 12:28:21 +0100 (CET) Date: Fri, 11 Nov 2011 12:28:21 +0100 From: Ed Schouten To: Doug Barton Message-ID: <20111111112821.GP2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QFliEIXSSz7hGqqc" Content-Disposition: inline In-Reply-To: <4EBC4B6E.4060607@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 11:28:22 -0000 --QFliEIXSSz7hGqqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Doug, * Doug Barton , 20111110 23:08: > On 11/10/2011 04:39, Ed Schouten wrote: > > I suspect this email could be one of the last emails I'm sending before > > one of you hire an assassin to get rid of me, but here it goes. >=20 > Au contraire, I think your work on improving the general quality of our > code has earned you many many brownie points, so you're far from being > run out of town on a rail. :) Thanks. :-) > This particular proposal though I personally am confused about, and I > apologize if I missed something obvious, but what is the value of making > this change? I've read the thread so far, and I understand that the > hysterical raisins that prompted the creation of sbin may or may not > still apply, but I haven't yet understood what we would gain by moving > everything. Simplicity. Right now we have binaries executed by users installed in five different places. I give bachelor courses on (embedded) Linux/FreeBSD systems administration and software development and explaining to them why it is done this way is getting tiresome. But the point is: there are quite some tools in */sbin that should be moved to */bin. I can at least point out 15 of them. Moving these tools around requires the same amount of effort as simply getting rid of sbin. If I have to decide on which of these to work, I'd choose the latter, because as far as I know, sbin has no reason to exist anyway. Also, it probably causes even less of a burden on our users, because `make installworld' will simply force them to migrate, while if we move binaries around, we can only hope that the user runs `make delete-old'. --=20 Ed Schouten WWW: http://80386.nl/ --QFliEIXSSz7hGqqc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvQbVAAoJEG5e2P40kaK7Dl4P/3UN3Wbfpe63BfyFSvbbE81p lVG0Vaj7kCWiRsmlGzENGt9jLzgjZ+wVZpKzN1t3B4bXcYMDxvcwYFEUlwucemG4 x7YAwUkZd+wYBo6vc9TgTz272JYvB0/aasWQwSo/QUShNTgQ2Mk6pTdANdTVL78O iTk8wwaHpDSKqxLpL7zKWeEuKTsLc1EiT278ZIoPAImUO1+na9nm5C4LTvS0aM5W xIi/GeaQTyplBAEBzzjjhlxTLX2XSW6Q9NLbVSpxZVI3IoCSeDTe+eMkp2BmU/8Q FviNBR0EkebQfalf6DMWfW26pid5hLPAMFqmhBmPWHTEi+DQ4yGHdq3XsdnoCrVD a+k1azVVMo+2tTn1gybBr/Y7FcZdwR3OFoykts7SRjdudyr2IaDkyM3Y9c37fB6W GQFz0FW7HuKMppa6anSDsgYUoUQoP4Eu38jESh7jH3L2Fhdn9JyVNaKtutR6qza/ RrRzXmJnZ8bh0cE3ezz0MRGahVQh+wrJdfJQEjSW42nlsqD/zGfQL2nVrGpgElxO gz1au4/oDjiPVmQHzSy9ikxMTCHW8c4DoEeRawTwKEZlpOVjHR8W7e9sHfEzgUcY GU2p6RhhaflLATMZsgFiXvLktWsbGp700Lmmg4tlEFh/deaj0oiDZ4z3aEt9jZgi cF9qcOesS6b5sqFPmZWX =VKHO -----END PGP SIGNATURE----- --QFliEIXSSz7hGqqc-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 11 12:00:21 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228771065687 for ; Fri, 11 Nov 2011 12:00:21 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id D95028FC17 for ; Fri, 11 Nov 2011 12:00:20 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 4FC4A2A28CDB; Fri, 11 Nov 2011 13:00:20 +0100 (CET) Date: Fri, 11 Nov 2011 13:00:20 +0100 From: Ed Schouten To: Gleb Kurtsou Message-ID: <20111111120020.GQ2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> <20111111104630.GO2164@hoeg.nl> <20111111114226.GA2002@reks> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ZVTVymsHR1TEBjP" Content-Disposition: inline In-Reply-To: <20111111114226.GA2002@reks> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 12:00:21 -0000 --4ZVTVymsHR1TEBjP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Gleb, * Gleb Kurtsou , 20111111 12:42: > It's not clear if you used sbin symlinks in tests, no script attached. The tests where sbin was merged into bin, it was using the patchset attached to the email, thus symlinks were present. --=20 Ed Schouten WWW: http://80386.nl/ --4ZVTVymsHR1TEBjP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvQ5UAAoJEG5e2P40kaK716MQAI+MefcciXP7NVLisinc1yrR +yk/pqcpsctBQgLv0W7JQbxS8kE/clgeSPGgmhv3T8yPVZtH3yEE3P5Gwdg6j2Ju HdxxraDKOSYkcXrmMzK49T9pwsmgQ2TeYDdVjdwMRfHcQQpuWFvnP0vuYDJrqQKu vI6tb6yL8L0Xx6HHlFFcPN1Gi7I1lMl/p9ve65ariIZQLLAJOet2VQAnMoO2h2VF +HG/Nhi/LOceSDIrzMKXTPP5CzIpEIwZM7++PEcOhbqAXcyHz7uBudCayuCCPw2U O4/DHjZxvFrO6EF4oLYGCiFhmVIe/wjn9EuQIxtv6EMDGP7lnyEfmHoh5NHl/lCc vrW0S/YPiHpu3YxdjFbNsUyeXUN644k0piBInT5iSrb7/Gq3oTRT/2A+wgPcdeye np9sWCzrcSTdlVbzdX3ngi/00nizQehg6q/pKSd2+DR5J99KstDIGfUpMI6z/YjC ijmm/Y1KifqiFWzS/EFrryaHhFrJRniGfxLVz99Rjjedyf4/PaRFlbh9EtOso9mI 0ScGF65HodcFfpQbQ9styAOmpBSY+3Zk8ruyq7QFWuaCQf54b3VghWLQ8HQEBpLv AyXv3hGO3YEkQ+VJ+fU9I60wgUWSMD5tKrWSUEb/vMnQ91/kwtXDrmFEsquI9LEm JyRIwEjj/vdET1XVJ1Vc =h2C2 -----END PGP SIGNATURE----- --4ZVTVymsHR1TEBjP-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 11 12:07:19 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC87C1065670 for ; Fri, 11 Nov 2011 12:07:19 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF6488FC17 for ; Fri, 11 Nov 2011 12:07:18 +0000 (UTC) Received: by faar19 with SMTP id r19so5539723faa.13 for ; Fri, 11 Nov 2011 04:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=r7jdgsRUDHj9+ulbCE6aYiJr5Zw7s6LQjpZS3YHzTRg=; b=DAW87xTq3CzBRKehUq5eCxXXw0/523TtNwVThPQHEwIM6KMdFojx8g2PivwP/zABYn 3QuMNqFVk0gXbCfy8XUrtIrtakHoZ/x1XTz+HnVonnBKvepHp5CZo8KfSsY7/CLD5NXf RSic+2EXov2PiNF8PnCW1oqaYHcxFg6uexcQk= Received: by 10.204.7.133 with SMTP id d5mr8072582bkd.64.1321011750336; Fri, 11 Nov 2011 03:42:30 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id q6sm10255333bka.6.2011.11.11.03.42.27 (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 03:42:28 -0800 (PST) Date: Fri, 11 Nov 2011 13:42:26 +0200 From: Gleb Kurtsou To: Ed Schouten Message-ID: <20111111114226.GA2002@reks> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> <20111111104630.GO2164@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20111111104630.GO2164@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 12:07:19 -0000 On (11/11/2011 11:46), Ed Schouten wrote: > Hi Peter, > > * Peter Wemm , 20111110 19:43: > > repeated shell startup (think: system(3)), or sh -c "somecommand" > > I have done some testing and it seems we have little to worry about, in > my opinion. I have written a small script that copies the `true' binary > to each of the directories specified in $PATH and executes it 100.000 > times. I have executed these tests on an installation where sbin is > still separate and one where it is merged. Also, I've used both a $PATH > variable that contains /sbin and one where it is removed. It's not clear if you used sbin symlinks in tests, no script attached. It's VOP_READLINK overhead we should care about. All entries (incl negative cache) will be cached by VFS under bin/. I presume difference to be negligible and support the change. sbin/something lookup: vp0 = VOP_LOOKUP(sbin) (may be cached) VOP_READLINK(vp0) vp1 = VOP_LOOKUP(bin) (may be cached) vp2 = VOP_LOOKUP(something) (may be cached) > > Observations: > - Indeed, the running time increases when the binary to be executed is > in a directory that is placed farther to the end of $PATH. > - Redundant directories in $PATH do cause some overhead. > - When we merge sbin with bin and the user properly removes sbin from > his/her PATH variable, things get slightly faster than they used to > be. > - When the user forgets to do so, the results are slightly worse than > before. > > Of course, this was just a quick way of testing things. If people want > to do more thorough tests, be my guest. I have attached an updated > version of my patch, the script I used to do the benchmark and the > results I have obtained. > > -- > Ed Schouten > WWW: http://80386.nl/ > Index: secure/usr.sbin/Makefile.inc > =================================================================== > --- secure/usr.sbin/Makefile.inc (revision 227417) > +++ secure/usr.sbin/Makefile.inc (working copy) > @@ -1,5 +1,5 @@ > # $FreeBSD$ > > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > .include "../Makefile.inc" > Index: games/Makefile.inc > =================================================================== > --- games/Makefile.inc (revision 227417) > +++ games/Makefile.inc (working copy) > @@ -1,7 +1,7 @@ > # @(#)Makefile.inc 8.1 (Berkeley) 5/31/93 > # $FreeBSD$ > > -BINDIR?= /usr/games > +BINDIR?= /usr/bin > FILESDIR?= ${SHAREDIR}/games > WARNS?= 6 > DISTRIBUTION?= games > Index: tools/tools/cxgbtool/Makefile > =================================================================== > --- tools/tools/cxgbtool/Makefile (revision 227417) > +++ tools/tools/cxgbtool/Makefile (working copy) > @@ -5,6 +5,6 @@ > NO_MAN= > CFLAGS+= -I${.CURDIR}/../../../sys/dev/cxgb -I. > CFLAGS+= -DCONFIG_T3_REGS -DCHELSIO_INTERNAL > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > .include > Index: tools/tools/vimage/Makefile > =================================================================== > --- tools/tools/vimage/Makefile (revision 227417) > +++ tools/tools/vimage/Makefile (working copy) > @@ -9,6 +9,6 @@ > > MAN= vimage.8 > > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > .include > Index: tools/tools/cxgbetool/Makefile > =================================================================== > --- tools/tools/cxgbetool/Makefile (revision 227417) > +++ tools/tools/cxgbetool/Makefile (working copy) > @@ -4,6 +4,6 @@ > SRCS= cxgbetool.c > NO_MAN= > CFLAGS+= -I${.CURDIR}/../../../sys/dev/cxgbe -I. > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > .include > Index: kerberos5/usr.sbin/Makefile.inc > =================================================================== > --- kerberos5/usr.sbin/Makefile.inc (revision 227417) > +++ kerberos5/usr.sbin/Makefile.inc (working copy) > @@ -1,5 +1,5 @@ > # $FreeBSD$ > > -BINDIR= /usr/sbin > +BINDIR= /usr/bin > > .include "../Makefile.inc" > Index: share/man/man7/hier.7 > =================================================================== > --- share/man/man7/hier.7 (revision 227417) > +++ share/man/man7/hier.7 (working copy) > @@ -145,8 +145,6 @@ > .It Pa /lib/ > critical system libraries needed for binaries in > .Pa /bin > -and > -.Pa /sbin > .Pp > .Bl -tag -width ".Pa geom/" -compact > .It Pa geom/ > @@ -157,8 +155,6 @@ > .It Pa /libexec/ > critical system utilities needed for binaries in > .Pa /bin > -and > -.Pa /sbin > .It Pa /media/ > contains subdirectories to be used as mount points > for removable media such as CDs, USB drives, and > @@ -176,9 +172,6 @@ > .Xr rescue 8 > .It Pa /root/ > root's HOME directory > -.It Pa /sbin/ > -system programs and administration utilities > -fundamental to both single-user and multi-user environments > .It Pa /tmp/ > temporary files that are not guaranteed to persist across system reboots > .It Pa /usr/ > @@ -192,8 +185,6 @@ > such as Linux > (created by > .Xr sysinstall 8 ) > -.It Pa games/ > -useful and semi-frivolous programs > .It Pa include/ > standard C include files > .Pp > @@ -462,8 +453,6 @@ > The > .Fx > ports collection (optional). > -.It Pa sbin/ > -system daemons & system utilities (executed by users) > .It Pa share/ > architecture-independent files > .Pp > @@ -645,8 +634,6 @@ > source code for contributed cryptography software > .It Pa etc/ > source code for files in /etc > -.It Pa games/ > -source code for files in /usr/games > .It Pa gnu/ > Utilities covered by the GNU General Public License > .It Pa include/ > @@ -661,8 +648,6 @@ > files required to produce a > .Fx > release > -.It Pa sbin/ > -source code for files in /sbin > .It Pa secure/ > build directory for files in /usr/src/crypto > .It Pa share/ > @@ -674,8 +659,6 @@ > .Fx > .It Pa usr.bin/ > source code for files in /usr/bin > -.It Pa usr.sbin/ > -source code for files in /usr/sbin > .El > .El > .It Pa /var/ > Index: usr.sbin/tcpdump/Makefile.inc > =================================================================== > --- usr.sbin/tcpdump/Makefile.inc (revision 227417) > +++ usr.sbin/tcpdump/Makefile.inc (working copy) > @@ -1,6 +1,6 @@ > # @(#)Makefile.inc 5.1 (Berkeley) 5/11/90 > # $FreeBSD$ > > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > WARNS?= 3 > Index: usr.sbin/Makefile.inc > =================================================================== > --- usr.sbin/Makefile.inc (revision 227417) > +++ usr.sbin/Makefile.inc (working copy) > @@ -1,6 +1,6 @@ > # @(#)Makefile.inc 8.1 (Berkeley) 6/6/93 > # $FreeBSD$ > > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > WARNS?= 6 > Index: usr.sbin/bootparamd/Makefile.inc > =================================================================== > --- usr.sbin/bootparamd/Makefile.inc (revision 227417) > +++ usr.sbin/bootparamd/Makefile.inc (working copy) > @@ -1,6 +1,6 @@ > # @(#)Makefile.inc 5.1 (Berkeley) 5/11/90 > # $FreeBSD$ > > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > WARNS?= 2 > Index: usr.sbin/wpa/Makefile.inc > =================================================================== > --- usr.sbin/wpa/Makefile.inc (revision 227417) > +++ usr.sbin/wpa/Makefile.inc (working copy) > @@ -1,6 +1,6 @@ > # $FreeBSD$ > > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > WPA_DISTDIR?= ${.CURDIR}/../../../contrib/wpa/ > WPA_SUPPLICANT_DISTDIR?=${WPA_DISTDIR}/wpa_supplicant > Index: usr.sbin/mailwrapper/Makefile > =================================================================== > --- usr.sbin/mailwrapper/Makefile (revision 227417) > +++ usr.sbin/mailwrapper/Makefile (working copy) > @@ -11,11 +11,11 @@ > .endif > > .if ${MK_MAILWRAPPER} != "no" || ${MK_SENDMAIL} != "no" > -SYMLINKS= ${BINDIR}/mailwrapper /usr/sbin/sendmail \ > - ${BINDIR}/mailwrapper /usr/sbin/hoststat \ > - ${BINDIR}/mailwrapper /usr/sbin/purgestat \ > - ${BINDIR}/mailwrapper /usr/bin/newaliases \ > - ${BINDIR}/mailwrapper /usr/bin/mailq > +SYMLINKS= mailwrapper ${BINDIR}/sendmail \ > + mailwrapper ${BINDIR}/hoststat \ > + mailwrapper ${BINDIR}/purgestat \ > + mailwrapper ${BINDIR}/newaliases \ > + mailwrapper ${BINDIR}/mailq > > .if ${MK_MAILWRAPPER} == "no" && ${MK_SENDMAIL} != "no" > SYMLINKS+= /usr/libexec/sendmail/sendmail ${BINDIR}/mailwrapper > Index: usr.sbin/nologin/Makefile > =================================================================== > --- usr.sbin/nologin/Makefile (revision 227417) > +++ usr.sbin/nologin/Makefile (working copy) > @@ -4,7 +4,7 @@ > PROG= nologin > MAN= nologin.5 nologin.8 > > -SYMLINKS= ${BINDIR}/nologin /sbin/nologin > +SYMLINKS= ${BINDIR}/nologin /bin/nologin > > # It is important that nologin be statically linked for security > # reasons. A dynamic non-setuid binary can be linked against a trojan > Index: include/paths.h > =================================================================== > --- include/paths.h (revision 227417) > +++ include/paths.h (working copy) > @@ -38,9 +38,9 @@ > /* Default search path. */ > #define _PATH_DEFPATH "/usr/bin:/bin" > /* All standard utilities path. */ > -#define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" > +#define _PATH_STDPATH "/usr/bin:/bin" > /* Locate system binaries. */ > -#define _PATH_SYSPATH "/sbin:/usr/sbin" > +#define _PATH_SYSPATH "/bin:/usr/bin" > > #define _PATH_AUTHCONF "/etc/auth.conf" > #define _PATH_BSHELL "/bin/sh" > @@ -58,31 +58,31 @@ > #define _PATH_ETC "/etc" > #define _PATH_FTPUSERS "/etc/ftpusers" > #define _PATH_FWMEM "/dev/fwmem" > -#define _PATH_HALT "/sbin/halt" > +#define _PATH_HALT "/bin/halt" > #ifdef COMPAT_32BIT > #define _PATH_I18NMODULE "/usr/lib32/i18n" > #else > #define _PATH_I18NMODULE "/usr/lib/i18n" > #endif > -#define _PATH_IFCONFIG "/sbin/ifconfig" > +#define _PATH_IFCONFIG "/bin/ifconfig" > #define _PATH_KMEM "/dev/kmem" > #define _PATH_LIBMAP_CONF "/etc/libmap.conf" > #define _PATH_LOCALE "/usr/share/locale" > #define _PATH_LOGIN "/usr/bin/login" > #define _PATH_MAILDIR "/var/mail" > #define _PATH_MAN "/usr/share/man" > -#define _PATH_MDCONFIG "/sbin/mdconfig" > +#define _PATH_MDCONFIG "/bin/mdconfig" > #define _PATH_MEM "/dev/mem" > -#define _PATH_MKSNAP_FFS "/sbin/mksnap_ffs" > -#define _PATH_MOUNT "/sbin/mount" > -#define _PATH_NEWFS "/sbin/newfs" > +#define _PATH_MKSNAP_FFS "/bin/mksnap_ffs" > +#define _PATH_MOUNT "/bin/mount" > +#define _PATH_NEWFS "/bin/newfs" > #define _PATH_NOLOGIN "/var/run/nologin" > #define _PATH_RCP "/bin/rcp" > -#define _PATH_REBOOT "/sbin/reboot" > +#define _PATH_REBOOT "/bin/reboot" > #define _PATH_RLOGIN "/usr/bin/rlogin" > #define _PATH_RM "/bin/rm" > #define _PATH_RSH "/usr/bin/rsh" > -#define _PATH_SENDMAIL "/usr/sbin/sendmail" > +#define _PATH_SENDMAIL "/usr/bin/sendmail" > #define _PATH_SHELLS "/etc/shells" > #define _PATH_TTY "/dev/tty" > #define _PATH_UNIX "don't use _PATH_UNIX" > @@ -107,9 +107,9 @@ > #undef _PATH_DEFPATH > #define _PATH_DEFPATH "/rescue:/usr/bin:/bin" > #undef _PATH_STDPATH > -#define _PATH_STDPATH "/rescue:/usr/bin:/bin:/usr/sbin:/sbin" > +#define _PATH_STDPATH "/rescue:/usr/bin:/bin" > #undef _PATH_SYSPATH > -#define _PATH_SYSPATH "/rescue:/sbin:/usr/sbin" > +#define _PATH_SYSPATH "/rescue:/bin:/usr/bin" > #undef _PATH_BSHELL > #define _PATH_BSHELL "/rescue/sh" > #undef _PATH_CP > Index: sbin/Makefile.inc > =================================================================== > --- sbin/Makefile.inc (revision 227417) > +++ sbin/Makefile.inc (working copy) > @@ -3,7 +3,7 @@ > > .include > > -BINDIR?= /sbin > +BINDIR?= /bin > WARNS?= 6 > > .if ${MK_DYNAMICROOT} == "no" > Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 227417) > +++ Makefile.inc1 (working copy) > @@ -613,6 +613,18 @@ > .endfor > > # > +# /sbin is now merged into /bin. The same holds for /usr/sbin and /usr/games. > +# > +installcheck: installcheck_sbin_merge > +installcheck_sbin_merge: > +.for dir in ${DESTDIR}/sbin ${DESTDIR}/usr/sbin ${DESTDIR}/usr/games > + @if test -d ${dir} -a ! -L ${dir}; then \ > + echo "ERROR: Directory ${dir} is still present, see /usr/src/UPDATING entry 20111110."; \ > + false; \ > + fi > +.endfor > + > +# > # Required install tools to be saved in a scratch dir for safety. > # > .if ${MK_INFO} != "no" > Index: cddl/sbin/Makefile.inc > =================================================================== > --- cddl/sbin/Makefile.inc (revision 227417) > +++ cddl/sbin/Makefile.inc (working copy) > @@ -1,5 +1,5 @@ > # $FreeBSD$ > > -BINDIR?= /sbin > +BINDIR?= /bin > > .include "../Makefile.inc" > Index: cddl/usr.sbin/dtrace/Makefile > =================================================================== > --- cddl/usr.sbin/dtrace/Makefile (revision 227417) > +++ cddl/usr.sbin/dtrace/Makefile (working copy) > @@ -4,7 +4,7 @@ > > PROG= dtrace > SRCS= dtrace.c > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > WARNS?= 1 > > Index: cddl/usr.sbin/plockstat/Makefile > =================================================================== > --- cddl/usr.sbin/plockstat/Makefile (revision 227417) > +++ cddl/usr.sbin/plockstat/Makefile (working copy) > @@ -4,7 +4,7 @@ > > PROG= plockstat > SRCS= plockstat.c > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > WARNS?= 1 > > Index: cddl/usr.sbin/lockstat/Makefile > =================================================================== > --- cddl/usr.sbin/lockstat/Makefile (revision 227417) > +++ cddl/usr.sbin/lockstat/Makefile (working copy) > @@ -5,7 +5,7 @@ > PROG= lockstat > NO_MAN= > SRCS= lockstat.c sym.c > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > WARNS?= 1 > > Index: cddl/usr.sbin/Makefile.inc > =================================================================== > --- cddl/usr.sbin/Makefile.inc (revision 227417) > +++ cddl/usr.sbin/Makefile.inc (working copy) > @@ -1,5 +1,5 @@ > # $FreeBSD$ > > -BINDIR?= /usr/sbin > +BINDIR?= /usr/bin > > .include "../Makefile.inc" > Index: ObsoleteFiles.inc > =================================================================== > --- ObsoleteFiles.inc (revision 227417) > +++ ObsoleteFiles.inc (working copy) > @@ -2164,8 +2164,6 @@ > OLD_FILES+=usr/libexec/named-xfer > OLD_FILES+=usr/sbin/named.restart > OLD_FILES+=usr/sbin/ndc > -OLD_FILES+=usr/sbin/nslookup > -OLD_FILES+=usr/sbin/nsupdate > OLD_FILES+=usr/share/doc/bind/html/acl.html > OLD_FILES+=usr/share/doc/bind/html/address_list.html > OLD_FILES+=usr/share/doc/bind/html/comments.html > @@ -2528,7 +2526,6 @@ > # 200212XX > OLD_FILES+=usr/sbin/kenv > OLD_FILES+=usr/bin/kenv > -OLD_FILES+=usr/sbin/elf2aout > # 200210XX > OLD_FILES+=usr/include/libusbhid.h > OLD_FILES+=usr/share/man/man3/All_FreeBSD.3.gz > Index: UPDATING > =================================================================== > --- UPDATING (revision 227417) > +++ UPDATING (working copy) > @@ -22,6 +22,24 @@ > machines to maximize performance. (To disable malloc debugging, run > ln -s aj /etc/malloc.conf.) > > +20111110: > + The /sbin, /usr/sbin and /usr/games directories have been merged > + into /bin and /usr/bin. For compatibility, the old directories > + have been replaced by symbolic links pointing to `bin'. To > + prevent people from possibly breaking their system > + automatically, you must perform the merge manually before > + `make installworld'. This can be done as follows: > + > + chflags noschg /sbin/* /usr/sbin/* /usr/games/* > + mv /sbin/* /bin > + mv /usr/sbin/* /usr/games/* /usr/bin > + rmdir /sbin /usr/sbin /usr/games > + > + After running these commands, you can safely run `make > + installworld' to continue your upgrade. Do not reboot your > + system in the mean time, as FreeBSD's boot procedure depends on > + the existence of /sbin and /usr/sbin. > + > 20111108: > The option VFS_ALLOW_NONMPSAFE option has been added in order to > explicitely support non-MPSAFE filesystems. > Index: libexec/bootpd/tools/Makefile.inc > =================================================================== > --- libexec/bootpd/tools/Makefile.inc (revision 227417) > +++ libexec/bootpd/tools/Makefile.inc (working copy) > @@ -1,6 +1,6 @@ > # Makefile.inc > # $FreeBSD$ > > -BINDIR= /usr/sbin > +BINDIR= /usr/bin > > WARNS?= 1 > Index: etc/mtree/BSD.usr.dist > =================================================================== > --- etc/mtree/BSD.usr.dist (revision 227417) > +++ etc/mtree/BSD.usr.dist (working copy) > @@ -7,8 +7,7 @@ > . > bin > .. > - games > - .. > + games type=link link=bin > include > .. > lib > @@ -55,8 +54,7 @@ > .. > obj nochange > .. > - sbin > - .. > + sbin type=link link=bin > share > calendar > de_DE.ISO8859-1 > Index: etc/mtree/BSD.root.dist > =================================================================== > --- etc/mtree/BSD.root.dist (revision 227417) > +++ etc/mtree/BSD.root.dist (working copy) > @@ -85,8 +85,7 @@ > .. > root > .. > - sbin > - .. > + sbin type=link link=bin > tmp mode=01777 > .. > usr > Index: etc/login.conf > =================================================================== > --- etc/login.conf (revision 227417) > +++ etc/login.conf (working copy) > @@ -27,7 +27,7 @@ > :copyright=/etc/COPYRIGHT:\ > :welcome=/etc/motd:\ > :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\ > - :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin ~/bin:\ > + :path=/bin /usr/bin /usr/local/sbin /usr/local/bin ~/bin:\ > :nologin=/var/run/nologin:\ > :cputime=unlimited:\ > :datasize=unlimited:\ > @@ -163,7 +163,7 @@ > # :ignoretime:\ > # :requirehome@:\ > # :accounted@:\ > -# :path=~/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin:\ > +# :path=~/bin /bin /usr/bin /usr/local/bin /usr/local/sbin:\ > # :umask=022:\ > # :tc=standard: > # > @@ -172,7 +172,7 @@ > ## root - fallback for root logins > ## > #root:\ > -# :path=~/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin:\ > +# :path=~/bin /bin /usr/bin /usr/local/bin /usr/local/sbin:\ > # :cputime=infinity:\ > # :datasize=infinity:\ > # :stacksize=infinity:\ > @@ -214,7 +214,7 @@ > ## Settings used by news subsystem > ## > #news:\ > -# :path=/usr/local/news/bin /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin:\ > +# :path=/usr/local/news/bin /bin /usr/bin /usr/local/bin /usr/local/sbin:\ > # :cputime=infinity:\ > # :filesize=128M:\ > # :datasize-cur=64M:\ > /sbin, /usr/sbin and /usr/games separate: > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/ed/bin > => /sbin > 263.38 real 80.16 user 185.91 sys > => /bin > 263.73 real 79.81 user 186.33 sys > => /usr/sbin > 264.08 real 76.82 user 189.69 sys > => /usr/bin > 264.44 real 78.04 user 188.80 sys > => /usr/games > 265.21 real 78.92 user 188.72 sys > => /usr/local/sbin > 266.19 real 78.54 user 190.04 sys > => /usr/local/bin > 266.58 real 78.53 user 190.31 sys > => /home/ed/bin > 267.84 real 78.21 user 191.91 sys > PATH=/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/ed/bin > => /bin > 262.75 real 79.18 user 185.91 sys > => /usr/bin > 263.49 real 76.18 user 189.86 sys > => /usr/local/sbin > 264.51 real 77.81 user 189.07 sys > => /usr/local/bin > 265.14 real 77.97 user 189.53 sys > => /home/ed/bin > 266.14 real 76.18 user 192.33 sys > /sbin, /usr/sbin and /usr/games merged: > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/ed/bin > => /sbin > 264.12 real 78.53 user 188.00 sys > => /bin > 263.96 real 78.46 user 187.92 sys > => /usr/sbin > 265.21 real 77.12 user 190.47 sys > => /usr/bin > 265.44 real 77.59 user 190.21 sys > => /usr/games > 265.55 real 78.52 user 189.42 sys > => /usr/local/sbin > 267.28 real 78.21 user 191.37 sys > => /usr/local/bin > 267.48 real 77.20 user 192.66 sys > => /home/ed/bin > 268.73 real 77.79 user 193.30 sys > PATH=/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/ed/bin > => /bin > 263.59 real 76.95 user 189.03 sys > => /usr/bin > 264.37 real 76.95 user 189.84 sys > => /usr/local/sbin > 265.15 real 78.53 user 189.03 sys > => /usr/local/bin > 265.75 real 77.10 user 190.98 sys > => /home/ed/bin > 266.89 real 77.06 user 192.13 sys From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 00:08:43 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A584C106564A; Sat, 12 Nov 2011 00:08:43 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7B38FC13; Sat, 12 Nov 2011 00:08:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAC08VYX011327; Sat, 12 Nov 2011 00:08:31 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id n74ug67nywvwh28zvsvpmvy6da; Sat, 12 Nov 2011 00:08:31 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> Date: Fri, 11 Nov 2011 16:08:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1251.1) Cc: arch@freebsd.org, "arch@" Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:08:43 -0000 On Nov 9, 2011, at 10:46 PM, Warner Losh wrote: >=20 > On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: >> Anyone know how to properly request a "skip forward" >> on tape drives? That's one of the missing pieces. >=20 > I thought that you couldn't seek(2) on tape drives. You must read(2) = the data. At least for this application, since a tar file would be just = one file on the tape. If you want to see to the next file mark, you = need to use an ioctl to get there, or read a lot. Yes, seek(2) is badly broken on tape drives. It does nothing and = doesn't return an error (unlike seek(2) on pipes, which does return an = error). I've seen references to ioctls that are supported by some drivers and/or = hardware that allow skipping forward by some number of records. But I = don't know the details. I doubt it's a major performance optimization in most cases, but it = would still be nice to avoid copying the data all the way down just to = ignore it. Tim From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 00:08:43 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A584C106564A; Sat, 12 Nov 2011 00:08:43 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7B38FC13; Sat, 12 Nov 2011 00:08:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAC08VYX011327; Sat, 12 Nov 2011 00:08:31 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id n74ug67nywvwh28zvsvpmvy6da; Sat, 12 Nov 2011 00:08:31 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> Date: Fri, 11 Nov 2011 16:08:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1251.1) Cc: arch@freebsd.org, "arch@" Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:08:43 -0000 On Nov 9, 2011, at 10:46 PM, Warner Losh wrote: >=20 > On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: >> Anyone know how to properly request a "skip forward" >> on tape drives? That's one of the missing pieces. >=20 > I thought that you couldn't seek(2) on tape drives. You must read(2) = the data. At least for this application, since a tar file would be just = one file on the tape. If you want to see to the next file mark, you = need to use an ioctl to get there, or read a lot. Yes, seek(2) is badly broken on tape drives. It does nothing and = doesn't return an error (unlike seek(2) on pipes, which does return an = error). I've seen references to ioctls that are supported by some drivers and/or = hardware that allow skipping forward by some number of records. But I = don't know the details. I doubt it's a major performance optimization in most cases, but it = would still be nice to avoid copying the data all the way down just to = ignore it. Tim From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 00:18:49 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70E2106564A; Sat, 12 Nov 2011 00:18:49 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 81BC18FC0A; Sat, 12 Nov 2011 00:18:49 +0000 (UTC) Received: by ggnk3 with SMTP id k3so6712992ggn.13 for ; Fri, 11 Nov 2011 16:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VJ0du0gYY5FRWFakJTRj4hqa6E0uT0CcvxHEj9s5Mhg=; b=t3iqUyT9R0AGLHf5C75F5J4Rl71ofVfSujuOoIZVlZOgt7p8xwbgd1MaT0F9x7d1GY /stgUSK0LNB36u7RnrkAi1cuP2rO1Lf5w5T7uWMfjrD77Fy/HR8IwErMtlHuzA2e5qce Ki9AtCk3yOUC3iv/Zi217xQBJRvbOO8vxKY8U= MIME-Version: 1.0 Received: by 10.68.24.1 with SMTP id q1mr21695289pbf.29.1321057128463; Fri, 11 Nov 2011 16:18:48 -0800 (PST) Received: by 10.68.50.226 with HTTP; Fri, 11 Nov 2011 16:18:48 -0800 (PST) In-Reply-To: <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> Date: Fri, 11 Nov 2011 16:18:48 -0800 Message-ID: From: Peter Wemm To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, "arch@" Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:18:49 -0000 On Fri, Nov 11, 2011 at 4:08 PM, Tim Kientzle wrote: > On Nov 9, 2011, at 10:46 PM, Warner Losh wrote: >> >> On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: >>> Anyone know how to properly request a "skip forward" >>> on tape drives? =A0That's one of the missing pieces. >> >> I thought that you couldn't seek(2) on tape drives. =A0You must read(2) = the data. =A0At least for this application, since a tar file would be just = one file on the tape. =A0If you want to see to the next file mark, you need= to use an ioctl to get there, or read a lot. > > Yes, seek(2) is badly broken on tape drives. =A0It does nothing and doesn= 't return an error (unlike seek(2) on pipes, which does return an error). > > I've seen references to ioctls that are supported by some drivers and/or = hardware that allow skipping forward by some number of records. =A0But I do= n't know the details. > > I doubt it's a major performance optimization in most cases, but it would= still be nice to avoid copying the data all the way down just to ignore it= . > > Tim Honestly, I think we've got bigger problems to worry about than whether lseek() works on magnetic tape drives in a form that tar/libarchive can use. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 00:18:49 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70E2106564A; Sat, 12 Nov 2011 00:18:49 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 81BC18FC0A; Sat, 12 Nov 2011 00:18:49 +0000 (UTC) Received: by ggnk3 with SMTP id k3so6712992ggn.13 for ; Fri, 11 Nov 2011 16:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VJ0du0gYY5FRWFakJTRj4hqa6E0uT0CcvxHEj9s5Mhg=; b=t3iqUyT9R0AGLHf5C75F5J4Rl71ofVfSujuOoIZVlZOgt7p8xwbgd1MaT0F9x7d1GY /stgUSK0LNB36u7RnrkAi1cuP2rO1Lf5w5T7uWMfjrD77Fy/HR8IwErMtlHuzA2e5qce Ki9AtCk3yOUC3iv/Zi217xQBJRvbOO8vxKY8U= MIME-Version: 1.0 Received: by 10.68.24.1 with SMTP id q1mr21695289pbf.29.1321057128463; Fri, 11 Nov 2011 16:18:48 -0800 (PST) Received: by 10.68.50.226 with HTTP; Fri, 11 Nov 2011 16:18:48 -0800 (PST) In-Reply-To: <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> Date: Fri, 11 Nov 2011 16:18:48 -0800 Message-ID: From: Peter Wemm To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org, "arch@" Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:18:49 -0000 On Fri, Nov 11, 2011 at 4:08 PM, Tim Kientzle wrote: > On Nov 9, 2011, at 10:46 PM, Warner Losh wrote: >> >> On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: >>> Anyone know how to properly request a "skip forward" >>> on tape drives? =A0That's one of the missing pieces. >> >> I thought that you couldn't seek(2) on tape drives. =A0You must read(2) = the data. =A0At least for this application, since a tar file would be just = one file on the tape. =A0If you want to see to the next file mark, you need= to use an ioctl to get there, or read a lot. > > Yes, seek(2) is badly broken on tape drives. =A0It does nothing and doesn= 't return an error (unlike seek(2) on pipes, which does return an error). > > I've seen references to ioctls that are supported by some drivers and/or = hardware that allow skipping forward by some number of records. =A0But I do= n't know the details. > > I doubt it's a major performance optimization in most cases, but it would= still be nice to avoid copying the data all the way down just to ignore it= . > > Tim Honestly, I think we've got bigger problems to worry about than whether lseek() works on magnetic tape drives in a form that tar/libarchive can use. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 00:40:19 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3F809106566C for ; Sat, 12 Nov 2011 00:40:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5A20E1570D4; Sat, 12 Nov 2011 00:40:16 +0000 (UTC) Message-ID: <4EBDC06F.6020907@FreeBSD.org> Date: Fri, 11 Nov 2011 16:40:15 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Ed Schouten References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> In-Reply-To: <20111111112821.GP2164@hoeg.nl> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:40:19 -0000 On 11/11/2011 03:28, Ed Schouten wrote: > Hello Doug, > > * Doug Barton , 20111110 23:08: >> This particular proposal though I personally am confused about, and I >> apologize if I missed something obvious, but what is the value of making >> this change? I've read the thread so far, and I understand that the >> hysterical raisins that prompted the creation of sbin may or may not >> still apply, but I haven't yet understood what we would gain by moving >> everything. > > Simplicity. Personally I don't see that as a good enough reason to deal with the disruption that this change would cause. > Right now we have binaries executed by users installed in > five different places. I give bachelor courses on (embedded) > Linux/FreeBSD systems administration and software development and > explaining to them why it is done this way is getting tiresome. If it takes you more than 2 minutes, you're doing it wrong. :) > But the point is: there are quite some tools in */sbin that should be > moved to */bin. I can at least point out 15 of them. Why don't we discuss those specifics first? > Moving these tools > around requires the same amount of effort as simply getting rid of sbin. For those individual tools, yes. But you're discounting the collateral damage. > If I have to decide on which of these to work, I'd choose the latter, > because as far as I know, sbin has no reason to exist anyway. > > Also, it probably causes even less of a burden on our users, because > `make installworld' will simply force them to migrate, while if we move > binaries around, we can only hope that the user runs `make delete-old'. Um, if 'make installworld' were to delete existing stuff that would be an overwhelming POLA violation. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 03:25:17 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DE191065670 for ; Sat, 12 Nov 2011 03:25:16 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id A214A8FC0A for ; Sat, 12 Nov 2011 03:25:16 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id pAC3PF7K093140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Nov 2011 19:25:16 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id pAC3PFHW093139; Fri, 11 Nov 2011 19:25:15 -0800 (PST) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA21197; Fri, 11 Nov 11 19:18:02 PST Date: Sat, 12 Nov 2011 02:17:50 -0800 From: perryh@pluto.rain.com To: peter@wemm.org Message-Id: <4ebe47ce.gGq91QcdXBP300Km%perryh@pluto.rain.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tim@kientzle.com, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 03:25:17 -0000 Peter Wemm wrote: > On Fri, Nov 11, 2011 at 4:08 PM, Tim Kientzle > wrote: > > ... seek(2) is badly broken on tape drives. > > It does nothing and doesn't return an error ... > > Honestly, I think we've got bigger problems to worry about > than whether lseek() works on magnetic tape drives ... True, but failing silently -- doing nothing but not returning an error -- is a POLA violation. Those are worth fixing simply on principle. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 03:41:59 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A13BA106566C for ; Sat, 12 Nov 2011 03:41:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 56DD58FC08 for ; Sat, 12 Nov 2011 03:41:59 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAC3fq8E039574 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 11 Nov 2011 20:41:53 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4ebe47ce.gGq91QcdXBP300Km%perryh@pluto.rain.com> Date: Fri, 11 Nov 2011 20:41:45 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> <4ebe47ce.gGq91QcdXBP300Km%perryh@pluto.rain.com> To: perryh@pluto.rain.com X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 11 Nov 2011 20:41:54 -0700 (MST) Cc: tim@kientzle.com, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 03:41:59 -0000 On Nov 12, 2011, at 3:17 AM, perryh@pluto.rain.com wrote: > Peter Wemm wrote: >> On Fri, Nov 11, 2011 at 4:08 PM, Tim Kientzle >> wrote: >>> ... seek(2) is badly broken on tape drives. >>> It does nothing and doesn't return an error ... >> >> Honestly, I think we've got bigger problems to worry about >> than whether lseek() works on magnetic tape drives ... > > True, but failing silently -- doing nothing but not returning an > error -- is a POLA violation. Those are worth fixing simply on > principle. Early Unix layering made that kinda hard... :( Warner From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 10:39:20 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B21F106566B; Sat, 12 Nov 2011 10:39:20 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id A1B1E8FC08; Sat, 12 Nov 2011 10:39:19 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 8D4FE2A28CC8; Sat, 12 Nov 2011 11:39:18 +0100 (CET) Date: Sat, 12 Nov 2011 11:39:18 +0100 From: Ed Schouten To: Doug Barton Message-ID: <20111112103918.GV2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XCIqNWEteo88hZlY" Content-Disposition: inline In-Reply-To: <4EBDC06F.6020907@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 10:39:20 -0000 --XCIqNWEteo88hZlY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Doug, * Doug Barton , 20111112 01:40: > > But the point is: there are quite some tools in */sbin that should be > > moved to */bin. I can at least point out 15 of them. >=20 > Why don't we discuss those specifics first? In my opinion at least the following binaries are candidates of apps that can be moved from sbin to bin, as they all work to some degree without root privileges: - ac - arp - config - daemon - dmesg - ifconfig - jls - kldstat - lastlogin - md5 - mtree - ping - ping6 - pkg_info - pkg_version - pstat - rcorder - rmd160 - sendmail - sha1 - sha256 - sysctl > For those individual tools, yes. But you're discounting the collateral > damage. Being? > Um, if 'make installworld' were to delete existing stuff that would be > an overwhelming POLA violation. But my patch doesn't do that. Please take a look at what it does. The user is kindly asked to move the binaries himself. Otherwise `make installworld' simply refuses to run. Unrelated to that, `make installworld' already deletes existing files =66rom the DESTDIR: - /.profile - /.cshrc - /sys - Some man/nls-related files. --=20 Ed Schouten WWW: http://80386.nl/ --XCIqNWEteo88hZlY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvkzWAAoJEG5e2P40kaK7Ad8P/jP0/t9HX/JZzb7Zqtha9tLl N3rUzU9ueWNtStuLwqGevDP0l+G31BU2eWMte1/oMQVeEb2LtkyzqaYJSMG/XWu0 nDg1/seSpXUGU4UOFJyMm+I9kXQHHF0VMtSYGMdH4dk7kM8xeLxJf9tx/HdPxJbM 1MiNXF3+zaHkXwuSvST/9P3AXGvYkh/Z9fufSKsl/S7GfS3VDB0f1qGC4MD6bilF AwgTxNndnJZR3RJ0z0JNRNyoeKAING8PUTlZevfCHD9A9J1GcAnYKcsGK/mel3KN CQQ/rpnEMf+vy8vuqjAy2L2/lnJEkHPekOJG/FZFqH0YFBrAoLHUM+g+doSlfKO/ aFhEANGiCnyrtW0loQyDagFjUcUInFOBpp4uA6IDUtFvBZpQZCl07IoVGfELPEJy XXFEoM8PDdxEIDlovEFUahAMcGMZiNtIqzJaIQ572bVhLrH8q42b1ODBoMRmqeRQ 3IId47gAvNSA3wM9toTxUBtEApQ+N9TWVMOowXzdCP1uwbQHwy5OcFYZdi7YqkRF bfJ6iFLHK4HAm6vMspTUsPdnKeHAxGFSx1j/YafORlTg58Wv/R0j20DehAUOpk/H 74+jnn2I7NlN8Ojd2K+50d+LuBGaIHbSariWS5aftJWCTywyobe+ZWRC9L3118SY fu0/0MQk9nN1A4wUtL/9 =j3dO -----END PGP SIGNATURE----- --XCIqNWEteo88hZlY-- From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 12:18:32 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F6E7106566B for ; Sat, 12 Nov 2011 12:18:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id A06A58FC17 for ; Sat, 12 Nov 2011 12:18:31 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 161602A28CC8; Sat, 12 Nov 2011 13:18:31 +0100 (CET) Date: Sat, 12 Nov 2011 13:18:31 +0100 From: Ed Schouten To: Vitaly Magerya Message-ID: <20111112121831.GW2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> <20111111104630.GO2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j+D14l8Ki1YJdzYp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 12:18:32 -0000 --j+D14l8Ki1YJdzYp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Vitaly, * Vitaly Magerya , 20111112 13:09: > Ed, will you also remove sbin entries from PATH assignments in > share/skel/dot.cshrc and share/skel/dot.profile? Sure! I think I had them already had them updated in my SVN working copy, but I'll check. --=20 Ed Schouten WWW: http://80386.nl/ --j+D14l8Ki1YJdzYp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOvmQWAAoJEG5e2P40kaK7ANMP/0oANpPi4hoKnureUJAiz1rE tdba/z4OxQBirYD3tByKNRLn9gpOtfIPbazw/ZztLFiQJg2eTZD+BAfvoOhAeAc/ YbYgkEk2JvwrDIImN7x/7hq3Z+pf14OKxRtdvsfp9d1jdpoRzmp5g1Kcma5BQ9cW znO7vCF0huPzu8vdemUnzEQEu8wVInoPB8aT63O4x2mUx80EuABYPIxter92MEgd IZQ5f34HGfUeletoE0HI4SbrRW4ItN1m3dVu3bKeV5oxh3kpk7la9WJSnuUmHpPh Q6mU268fA+Gv9M6HEmPUixPl894ufLkW3MgUY8QMaT0o3YcPhZ+T3oECoMvcwkrE XM+/xJC64vanSyI5jpcpVDUWm9BRz1yvKlZXQ2fHy2+6K6qVnmg/3o7WAflQAekt 4Xczdw7r6z9vW+6BDXl72QstRZ+MkBM5dRObtJQgiF1vg7XfR1Q2j0BvFIlNI948 ff8KpBevXZeVOzqwlRyBJWUrxGAa5c3n1GLpUNVXvVc6D+NF6NwLMp2AUpTCGceb lO0MJ3PtisI4lr8JRLwFnvn78g3TUjFwukICDInGgoIOZkl3yCFeu+qBEF4OEctp AojLvsc97jwfO0jsWc8GSTniCETOuUwh+ff6Ty1oGh7ETpOIJ2/QPoRMOiwLDQds 3mg35zNL36QLddiRi8ww =VV66 -----END PGP SIGNATURE----- --j+D14l8Ki1YJdzYp-- From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 12:36:03 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D67C2106564A for ; Sat, 12 Nov 2011 12:36:03 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 649858FC0A for ; Sat, 12 Nov 2011 12:36:02 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so5816792bkb.13 for ; Sat, 12 Nov 2011 04:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NP2cloed6LkHN/2JBFU34OOVuHNV2A+DTciltiCx+fQ=; b=Gjh6IvK4sRcJqlzd97g4uwdj0VMqtNi4dVKZ3WvvjQ2lMtj9oo3yavy9mSCzuLtIp8 kS/kUuMGKef9mTI7WSb2M7qigY0mKcjthKiZ4o8NALC9D9eg7fdjkhRoQ227yOImD93B HlRlC3fUwqDQs19i/8uBiwIwS4oL2tEnVmUMY= MIME-Version: 1.0 Received: by 10.205.120.9 with SMTP id fw9mr4222923bkc.137.1321099775907; Sat, 12 Nov 2011 04:09:35 -0800 (PST) Received: by 10.223.126.145 with HTTP; Sat, 12 Nov 2011 04:09:35 -0800 (PST) In-Reply-To: <20111111104630.GO2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> <20111110174722.GJ2164@hoeg.nl> <20111111104630.GO2164@hoeg.nl> Date: Sat, 12 Nov 2011 14:09:35 +0200 Message-ID: From: Vitaly Magerya To: Ed Schouten Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 12:36:03 -0000 Ed Schouten wrote: > I have attached an updated > version of my patch, the script I used to do the benchmark and the > results I have obtained. Ed, will you also remove sbin entries from PATH assignments in share/skel/dot.cshrc and share/skel/dot.profile? From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 16:47:11 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BF841065676 for ; Sat, 12 Nov 2011 16:47:11 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC758FC08 for ; Sat, 12 Nov 2011 16:47:10 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id D6287A04; Sat, 12 Nov 2011 17:29:52 +0100 (CET) Date: Sat, 12 Nov 2011 17:28:59 +0100 From: Pawel Jakub Dawidek To: Peter Wemm Message-ID: <20111112162858.GA29868@garage.freebsd.pl> References: <20111110123919.GF2164@hoeg.nl> <20111110171605.GI2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ed Schouten , arch@freebsd.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 16:47:11 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 10, 2011 at 09:33:21AM -0800, Peter Wemm wrote: > On Thu, Nov 10, 2011 at 9:16 AM, Ed Schouten wrote: > > Hi Peter, > > > > * Peter Wemm , 20111110 17:56: > >> Of course, that pales in comparison to the impact of adding > >> /usr/local/bin to the path, but it does show this does have potential > >> user visibility. =A0And there's also the issue that most most users add > >> every possible directory to their $PATH anyway. > > > > Exactly. Also, there are shells nowadays that cache all binaries in PATH > > up front, such as zsh. When they start, they loop through all dirents in > > all directories in $PATH and add it to a big cache. This entirely > > defeats this purpose. >=20 > I use tcsh and zsh, I'm aware of this cache. >=20 > However, libc doesn't, so things like /bin/sh when running shell > scripts do not. make(1) does not. People do still care about > buildworld time. Simple things like changing gcc to static linking > were a few percentage points of buildworld time, back in the day. > Having /bin/sh as a static binary used to be 3%-5% of buildworld time, > simply because fork/exec was faster as the copy-on-write burden was > less. This stuff adds up. Peter, are you sure that one big directory is worse than many smaller directories for lookup? If we have many small directories the shell would do the following: execve("/bin/cmd") execve("/usr/bin/cmd") execve("/sbin/cmd") execve("/usr/sbin/cmd") With one small directory it will do only one execve(2). Neither ZFS nor UFS (at least with dirhash, which is the default) doesn't implement lookup as readdir of entire directory and strcmp() in a loop. Things are better organized and lookups are not O(n). When you have more directories you have to pay price of multiple lookups and multipe system calls, which for me seems much more expensive. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6+nsoACgkQForvXbEpPzQYygCfXewt4uEJ9e10zo9zzVI7swrv 9p8AnRyVQ7o7+HXp4v4zu51L0Cs9k2zq =w+14 -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 22:01:23 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70DB3106564A for ; Sat, 12 Nov 2011 22:01:23 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 499A48FC15 for ; Sat, 12 Nov 2011 22:01:23 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id pACM1HBo005035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 12 Nov 2011 14:01:17 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id pACM1GMf005034; Sat, 12 Nov 2011 14:01:16 -0800 (PST) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA24427; Sat, 12 Nov 11 13:57:15 PST Date: Sat, 12 Nov 2011 20:57:03 -0800 From: perryh@pluto.rain.com To: imp@bsdimp.com Message-Id: <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> <4ebe47ce.gGq91QcdXBP300Km%perryh@pluto.rain.com> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tim@kientzle.com, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 22:01:23 -0000 Warner Losh wrote: > On Nov 12, 2011, at 3:17 AM, perryh@pluto.rain.com wrote: > > Peter Wemm wrote: > >> On Fri, Nov 11, 2011 at 4:08 PM, Tim Kientzle > >> wrote: > >>> ... seek(2) is badly broken on tape drives. > >>> It does nothing and doesn't return an error ... > >> > >> Honestly, I think we've got bigger problems to worry about > >> than whether lseek() works on magnetic tape drives ... > > > > True, but failing silently -- doing nothing but not returning an > > error -- is a POLA violation. Those are worth fixing simply on > > principle. > > Early Unix layering made that kinda hard... :( and yet, it somehow manages to return an error if applied to a pipe. There must be some point at which the inode type affects the result. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 23:23:48 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 173ED106566B for ; Sat, 12 Nov 2011 23:23:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E195215209E; Sat, 12 Nov 2011 23:23:47 +0000 (UTC) Message-ID: <4EBF0003.3060401@FreeBSD.org> Date: Sat, 12 Nov 2011 15:23:47 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Ed Schouten References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> In-Reply-To: <20111112103918.GV2164@hoeg.nl> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 23:23:48 -0000 On 11/12/2011 02:39, Ed Schouten wrote: > Hi Doug, > > * Doug Barton , 20111112 01:40: >>> But the point is: there are quite some tools in */sbin that should be >>> moved to */bin. I can at least point out 15 of them. >> >> Why don't we discuss those specifics first? > > In my opinion at least the following binaries are candidates of apps > that can be moved from sbin to bin, as they all work to some degree > without root privileges: The idea behind sbin isn't "needs root privileges." From hier(7): /sbin/ system programs and administration utilities fundamental to both single-user and multi-user environments > - ac > - arp > - config > - daemon > - dmesg > - ifconfig > - jls > - kldstat > - lastlogin > - md5 > - mtree > - ping > - ping6 > - pkg_info > - pkg_version > - pstat > - rcorder > - rmd160 > - sendmail > - sha1 > - sha256 > - sysctl Except for the hash tools (md5, etc.) those are all properly located in sbin. >> For those individual tools, yes. But you're discounting the collateral >> damage. > > Being? User confusion, conflict between how things are done in the base vs. how they are done in ports, problems for users who install stuff in /sbin and/or /usr/sbin, and the other problems that have been mentioned in this thread. >> Um, if 'make installworld' were to delete existing stuff that would be >> an overwhelming POLA violation. > > But my patch doesn't do that. Please take a look at what it does. The > user is kindly asked to move the binaries himself. Otherwise `make > installworld' simply refuses to run. Yeah, I saw that, which is why I was confused. I would argue that what you're proposing is also a POLA violation, although perhaps less so. > Unrelated to that, `make installworld' already deletes existing files > from the DESTDIR: > > - /.profile > - /.cshrc Do you have a reference? I had to add code to mergemaster to handle installing updates to them, fixing the symlinks, etc. > - /sys Are you sure that this happens on an already installed system? I know I've had to update this link on systems where I've moved my src tree. > - Some man/nls-related files. Not sure about these. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/