From owner-freebsd-arch@FreeBSD.ORG Sun Nov 13 08:32: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 EF0FE106564A; Sun, 13 Nov 2011 08:32:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6D98FC0A; Sun, 13 Nov 2011 08:32:19 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAD8WFQ9065459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 10:32:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAD8WFg4093418; Sun, 13 Nov 2011 10:32:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAD8WFZ1093417; Sun, 13 Nov 2011 10:32:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Nov 2011 10:32:15 +0200 From: Kostik Belousov To: arch@freebsd.org Message-ID: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RecmMh7zm4dDGtcP" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org, avg@freebsd.org Subject: Stop scheduler on panic 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: Sun, 13 Nov 2011 08:32:20 -0000 --RecmMh7zm4dDGtcP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I was tricked into finishing the work by Andrey Gapon, who developed the patch to reliably stop other processors on panic. The patch greatly improves the chances of getting dump on panic on SMP host. Several people already saw the patchset, and I remember that Andrey posted it to some lists. The change stops other (*) processors early upon the panic. This way, no parallel manipulation of the kernel memory is performed by CPUs. In particular, the kernel memory map is static. Patch prevents the panic thread from blocking and switching out. * - in the context of the description, other means not current. Since other threads are not run anymore, lock owner cannot release a lock which is required by panic thread. Due to this, we need to fake a lock acquisition after the panic, which adds minimal overhead to the locking cost. The patch tries to not add any overhead on the fast path of the lock acquire. The check for the after-panic condition was reduced to single memory access, done only when the quick cas lock attempt failed, and braced with __unlikely compiler hint. For now, the new mode of operation is disabled by default, since some further USB changes are needed to make USB keyboard usable in that environment. With the patch, getting a dump from the machine without debugger compiled in is much more realistic. Please comment, I will commit the change in 2 weeks unless strong reasons not to are given. http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch --RecmMh7zm4dDGtcP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6/gI8ACgkQC3+MBN1Mb4hPZACdGVqOo6jiI4LP4qLX/9Kv19y6 U2UAni3euzO0s2e8m1kKpC00dSByyUR/ =tKJL -----END PGP SIGNATURE----- --RecmMh7zm4dDGtcP-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 13 09:19:42 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 4C8F1106566B; Sun, 13 Nov 2011 09:19:42 +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 E15698FC0A; Sun, 13 Nov 2011 09:19:41 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id E975C2A28CF7; Sun, 13 Nov 2011 10:19:40 +0100 (CET) Date: Sun, 13 Nov 2011 10:19:40 +0100 From: Ed Schouten To: Doug Barton Message-ID: <20111113091940.GX2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FhvelBhrd33NvMcY" Content-Disposition: inline In-Reply-To: <4EBF0003.3060401@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: Sun, 13 Nov 2011 09:19:42 -0000 --FhvelBhrd33NvMcY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Doug Barton , 20111113 00:23: > Except for the hash tools (md5, etc.) those are all properly located in > sbin. So this is where the sbin <-> bin separation already causes troubles. Even in a discussion between two people it is impossible to determine in which of the directories it should be placed. I think John Doe would agree a compiler suite is something more `administrative' than an application to send emails, yet they are placed in bin and sbin respectively. This is actually one of the reasons why I proposed the merge. The separation between /bin and /usr/bin is easy to reason about: if the system boots fine without it being placed in /bin, just put it in /usr/bin. This does not hold for bin and sbin. > >> For those individual tools, yes. But you're discounting the collateral > >> damage. > >=20 > > Being? >=20 > 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. This is not a problem, because of the symbolic links we add. If people install stuff in /sbin, it gets placed in /bin. About the user confusion, all the directories they need are added to $PATH. Also, if they ls(1) around a bit, they'll figure it out. > > Unrelated to that, `make installworld' already deletes existing files > > from the DESTDIR: > >=20 > > - /.profile > > - /.cshrc >=20 > Do you have a reference? I had to add code to mergemaster to handle > installing updates to them, fixing the symlinks, etc. >=20 > > - /sys >=20 > 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. >=20 > > - Some man/nls-related files. >=20 > Not sure about these. This is all done in etc/Makefile. You can also try it yourself: rm /sys echo hello world > /sys make installworld --=20 Ed Schouten WWW: http://80386.nl/ --FhvelBhrd33NvMcY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOv4usAAoJEG5e2P40kaK7OmwP/0XF4Nnr96SFgGnkGDaO7Lqy 15FYoQuSrXzPAD1UnbM531mkqD1B1ZeBOpnVbqcy6MbVILvNHzUy75VzVG5DYYji 36dc/wha1xak6rFwQteVG2x8VFDWY+3TeLiHc4V0czfg1y+0oUFBgv7KbXqZR6z0 0ocdqDkspGdCSldQ8zEgyBAd71so59gEgLy8/oWZo8RFX05zQmVYV8xfErVE0wyA h6m94V8o2iIwNOwob0IYKZnUsJCIf87AQSQFk+LU7BNsJx3zkmbv5hKZEjLwY5oN Y+BbgTCdx0HD7G6XYnFMivhnwtUyU3y2e9HB9lIHQ6ndK/p90L+MA/0y8+ZxVqOO saTwST1H9zsh/CCuF5JoqAGGWrPkmrHg9pbSZEPwAS7+knqzNH1ON6oO7zYJQt+9 TN7rSbxc3MUZJjHVf2VoS3VB756Pge+3zWR1cV/nXryOflcFElqdczoTgqe7iYSc OM04Acr/q0QpI0/TKDUaOS5bSqkc1NLP5f677CB1zrdI8RsPFC2/pns1UsXLCxSb k7KMSeUzZ4L6QQAINwO89bCljyfImfS6z63AHeUJN/ykO9/NF1MKyk2sINeKi34a dU5sIHBFpTYxTrCgmGHVIzegIFu2L5tPbMRHqgEDHu2l+xw7K76ldRUGnEA4ovRq Y/dnNSoZ0UulJkvjfrM8 =kkgf -----END PGP SIGNATURE----- --FhvelBhrd33NvMcY-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 13 10:54:32 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 9758E1065675 for ; Sun, 13 Nov 2011 10:54:32 +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 534B28FC13 for ; Sun, 13 Nov 2011 10:54:31 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3212F5DA8; Sun, 13 Nov 2011 10:54:30 +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 pADAsRAE015484; Sun, 13 Nov 2011 10:54:28 GMT (envelope-from phk@phk.freebsd.dk) To: perryh@pluto.rain.com From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 12 Nov 2011 20:57:03 PST." <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 13 Nov 2011 10:54:27 +0000 Message-ID: <15483.1321181667@critter.freebsd.dk> 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: Sun, 13 Nov 2011 10:54:32 -0000 In message <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com>, perryh@pluto.rain .com writes: >Warner Losh wrote: >> >> 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. There is a big difference: pipes operate at the fdesc level, devices sit behind what can best be explained as a symlink into a different name-space, and the cdevsw API does not pass the fdesc offset in. -- 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 Sun Nov 13 11:29:31 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 7D256106566C for ; Sun, 13 Nov 2011 11:29:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E45858FC08 for ; Sun, 13 Nov 2011 11:29:30 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pADBDdfx030352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 13:13:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pADBDdrv093851; Sun, 13 Nov 2011 13:13:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pADBDcef093850; Sun, 13 Nov 2011 13:13:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Nov 2011 13:13:38 +0200 From: Kostik Belousov To: Poul-Henning Kamp Message-ID: <20111113111338.GX50300@deviant.kiev.zoral.com.ua> References: <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com> <15483.1321181667@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xts/o66bJCDUp3W0" Content-Disposition: inline In-Reply-To: <15483.1321181667@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: tim@kientzle.com, perryh@pluto.rain.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: Sun, 13 Nov 2011 11:29:31 -0000 --xts/o66bJCDUp3W0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 13, 2011 at 10:54:27AM +0000, Poul-Henning Kamp wrote: > In message <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com>, perryh@plut= o.rain > .com writes: > >Warner Losh wrote: >=20 > >> >> wrote: > >> >>> ... seek(2) is badly broken on tape drives. > >> >>> It does nothing and doesn't return an error ... > >> >>=20 > >> >> Honestly, I think we've got bigger problems to worry about > >> >> than whether lseek() works on magnetic tape drives ... > >> >=20 > >> > 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. >=20 > There is a big difference: pipes operate at the fdesc level, devices > sit behind what can best be explained as a symlink into a different > name-space, and the cdevsw API does not pass the fdesc offset in. I do not think this is true. Devfs does pass the file offset as uio_offset to the cdevsw read and write methods. Also, the dev nodes are marked as seekable. Drivers can see the file offset and operate on them properly, but not at the lseek(2) time. --xts/o66bJCDUp3W0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6/pmIACgkQC3+MBN1Mb4jkdQCgjeSrEBr7Nche80zypS8vpQTl 6lMAn19exjL9N8n2YYDmxQtWgDwG1XuG =GPhu -----END PGP SIGNATURE----- --xts/o66bJCDUp3W0-- From owner-freebsd-arch@FreeBSD.ORG Sun Nov 13 11:36: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 8E870106564A for ; Sun, 13 Nov 2011 11:36:21 +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 4A0178FC15 for ; Sun, 13 Nov 2011 11:36:21 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4202E5DA8; Sun, 13 Nov 2011 11:36:20 +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 pADBaJ26026039; Sun, 13 Nov 2011 11:36:20 GMT (envelope-from phk@phk.freebsd.dk) To: Kostik Belousov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 13 Nov 2011 13:13:38 +0200." <20111113111338.GX50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 13 Nov 2011 11:36:19 +0000 Message-ID: <26038.1321184179@critter.freebsd.dk> Cc: tim@kientzle.com, perryh@pluto.rain.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: Sun, 13 Nov 2011 11:36:21 -0000 In message <20111113111338.GX50300@deviant.kiev.zoral.com.ua>, Kostik Belousov writes: >Drivers can see the file offset and operate on them properly, but not at >the lseek(2) time. Right, that's what I meant: The offset is not passed in as an independent entity, only as a param of data movement. -- 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 Sun Nov 13 22:57:44 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 C55261065670 for ; Sun, 13 Nov 2011 22:57:44 +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 7D4B41548CF; Sun, 13 Nov 2011 22:57:41 +0000 (UTC) Message-ID: <4EC04B65.4030801@FreeBSD.org> Date: Sun, 13 Nov 2011 14:57:41 -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> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> In-Reply-To: <20111113091940.GX2164@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: Sun, 13 Nov 2011 22:57:44 -0000 On 11/13/2011 01:19, Ed Schouten wrote: > * Doug Barton , 20111113 00:23: >> Except for the hash tools (md5, etc.) those are all properly located in >> sbin. > > So this is where the sbin <-> bin separation already causes troubles. > Even in a discussion between two people it is impossible to determine in > which of the directories it should be placed. "Agreement" is not a feature if one of us is wrong. :) > I think John Doe would agree a compiler suite is something more > `administrative' than an application to send emails, yet they are placed > in bin and sbin respectively. I think that your perspective may be skewed towards a single-user and/or developer-centric model. Those of us who operate multi-user systems have a different set of criteria. However, there are 3 possibilities here: 1. You're right 2. I'm right 3. Lack of "agreement." Since in 2 out of 3 of those scenarios the status quo prevails, can we drop it now? > This is actually one of the reasons why I proposed the merge. The > separation between /bin and /usr/bin is easy to reason about: if the > system boots fine without it being placed in /bin, just put it in > /usr/bin. This does not hold for bin and sbin. Actually I think a much more interesting, and likely more useful change would be to put everything into /bin. For years now I've been running with a partition layout like this: / 3 G (this includes /usr/) /var 2 G /usr/local * Throw in a tmpmfs and you're done. This gives a nice clean separation between things that should be written to and things that shouldn't. The home, ports, src, and obj directories are all in /usr/local/, with symlinks in the regular places. In spite of the fact that I run -current on an everyday basis, and have a non-trivial number of panics due to testing new stuff, this layout has allowed my "system" to be spared and permitted me to quickly recover after a panic; vs. the bad-old-days when the fact that /usr was being written to during the panic caused a key system file to be corrupted, resulting in hours of hilarity ensuing. On my system currently, with one old kernel, / + /usr is only 430 M, about 270 M of that in /usr (I don't have everything installed, but I also have some dross, so the numbers should compare favorably to a newly installed full system). I make the / slice large enough that it can hold a full system, plus several old kernels, and still have room to spare. If we're going to talk about making a change that's actually worth making, let's just move everything into / and get rid of /usr altogether. It served its purpose back when it came into being, but with modern disk sizes and the (unfortunate) prevalence of the "one big /" layout model, it's time in the sun is long past. >>>> 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. > > This is not a problem, because of the symbolic links we add. I think you're way, way too optimistic about this. I also think your logic is fuzzy. If the change is worth making, the symlinks shouldn't be necessary. If the symlinks are necessary, the change shouldn't be made. > If people > install stuff in /sbin, it gets placed in /bin. About the user > confusion, all the directories they need are added to $PATH. Also, if > they ls(1) around a bit, they'll figure it out. .... and then they write to the mailing lists and ask why the heck is something that's always been in sbin now in bin, and what are these symlinks about, and why did you make this gratuitous change?!? And our answer is? >>> 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. > > This is all done in etc/Makefile. I see. However I would argue that these are sins of the past. I still haven't seen a clearly articulated benefit to making this move. (Note, I understand your argument that it fits some specific standard of "better organized," I just don't agree, and even if I did I wouldn't agree that it's sufficiently beneficial to justify the drama that it would create.) 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 Sun Nov 13 23:25: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 E0F6E1065670; Sun, 13 Nov 2011 23:25:19 +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 BFA1D8FC0A; Sun, 13 Nov 2011 23:25:19 +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 pADNPEUo099334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Nov 2011 15:25:15 -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 pADNPEgi099333; Sun, 13 Nov 2011 15:25:14 -0800 (PST) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA28726; Sun, 13 Nov 11 15:17:34 PST Date: Sun, 13 Nov 2011 22:17:21 -0800 From: perryh@pluto.rain.com To: ed@80386.nl Message-Id: <4ec0b271.XEX0E3cu8vL6mgou%perryh@pluto.rain.com> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> In-Reply-To: <20111113091940.GX2164@hoeg.nl> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dougb@freebsd.org, freebsd-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: Sun, 13 Nov 2011 23:25:20 -0000 Ed Schouten wrote: > I think John Doe would agree a compiler suite is something more > `administrative' than an application to send emails, yet they are > placed in bin and sbin respectively. A compiler is certainly used by ordinary users (e.g. programming students), not solely by administrators. While sendmail is involved in sending mail, it is an MTA (not an MUA) and therefore is not ordinarily run from the command line other than when debugging. It's not at all clear to me why sendmail should be in either /sbin or /bin: historically it was in /usr/lib, along with other programs that were expected to be invoked by other programs (or by rc scripts) and thus should not be in PATH. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 00:08:26 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 503291065674 for ; Mon, 14 Nov 2011 00:08:26 +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 2C9868FC08 for ; Mon, 14 Nov 2011 00:08:25 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAE08KCW026183; Mon, 14 Nov 2011 00:08:20 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id k7cgzbziers4gy33b4je5d3fzw; Mon, 14 Nov 2011 00:08:20 +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: <4EC04B65.4030801@FreeBSD.org> Date: Sun, 13 Nov 2011 16:08:19 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1251.1) 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: Mon, 14 Nov 2011 00:08:26 -0000 On Nov 13, 2011, at 2:57 PM, Doug Barton wrote: > > Actually I think a much more interesting, and likely more useful change > would be to put everything into /bin. I'm really confused, Doug. You've been vehemently arguing against merging /bin and /sbin, but here you seem to be claiming that it would be better to instead merge /bin, /sbin, /usr/bin, and /usr/sbin. Care to clarify? Personally, I really like Ed's proposal. In part, that's from my personal experience of being highly annoyed whenever I use a Linux system that doesn't put /sbin into my path. If I always expect both /bin and /sbin to be in my path, then just combining them into one directory makes a whale of a lot of sense. I agree the transition issues are delicate, but we've dealt with equally difficult transition issues before. Tim From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 00:21:04 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 31065106566B for ; Mon, 14 Nov 2011 00:21:04 +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 ED2E014F6AB; Mon, 14 Nov 2011 00:21:03 +0000 (UTC) Message-ID: <4EC05EEF.5030908@FreeBSD.org> Date: Sun, 13 Nov 2011 16:21:03 -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: Tim Kientzle References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Mon, 14 Nov 2011 00:21:04 -0000 On 11/13/2011 16:08, Tim Kientzle wrote: > On Nov 13, 2011, at 2:57 PM, Doug Barton wrote: >> >> Actually I think a much more interesting, and likely more useful change >> would be to put everything into /bin. > > I'm really confused, Doug. > > You've been vehemently arguing against merging /bin and > /sbin, but here you seem to be claiming that it would be > better to instead merge /bin, /sbin, /usr/bin, and /usr/sbin. > > Care to clarify? Go back and reread the message that you quoted from, and hopefully it will be clear to you. I'm not sure I can say it any better than I did. > Personally, I really like Ed's proposal. Nothing stops you from implementing it locally. :) > In part, that's > from my personal experience of being highly annoyed > whenever I use a Linux system that doesn't put /sbin into > my path. Ed's proposal won't help you on Linux systems. OTOH, we've had */sbin in the default path for many years, which means that relative to the cause of your pain Ed's proposal provides no benefit on a FreeBSD system. > If I always expect both /bin and /sbin to be in my > path, then just combining them into one directory makes > a whale of a lot of sense. > > I agree the transition issues are delicate, but we've > dealt with equally difficult transition issues before. First, I think you are also dramatically underestimating the level of drama that this is going to cause. Second, (and here's a hint to the answer to your first question) given that there is so little (if any) benefit, why create all the pain in the first place? 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 Mon Nov 14 01:38: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 4E1F1106566B; Mon, 14 Nov 2011 01:38:57 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [63.231.190.5]) by mx1.freebsd.org (Postfix) with ESMTP id D24088FC0A; Mon, 14 Nov 2011 01:38:56 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.3/8.13.6) with ESMTP id pAE11XEa067064; Sun, 13 Nov 2011 19:01:33 -0600 (CST) (envelope-from mike@mail.karels.net) Message-Id: <201111140101.pAE11XEa067064@mail.karels.net> To: Doug Barton From: Mike Karels In-reply-to: Your message of Sun, 13 Nov 2011 16:21:03 -0800. <4EC05EEF.5030908@FreeBSD.org> Date: Sun, 13 Nov 2011 19:01:33 -0600 Sender: mike@karels.net Cc: arch@freebsd.org, Tim Kientzle , Ed Schouten Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mike@karels.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:38:57 -0000 I have to agree with Doug. If the directories were unified and we were proposing splitting them based on efficiency, I would say it is not worth doing. However, the directories are separate now, and I don't see sufficient benefit from combining them. fwiw, I think at least 90% of the users at work do not have /sbin and /usr/sbin in their paths now, and they do not need them. (Yes, there are still multi-user systems, and not everyone is a sysadmin.) I think this is a solution in search of a problem. Mike From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 02:22:25 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 260C41065670; Mon, 14 Nov 2011 02:22:25 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by mx1.freebsd.org (Postfix) with ESMTP id D46638FC0C; Mon, 14 Nov 2011 02:22:24 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id pAE18qPo017402; Sun, 13 Nov 2011 20:08:53 -0500 Message-ID: <4EC06A24.6070502@FreeBSD.org> Date: Sun, 13 Nov 2011 20:08:52 -0500 From: Garance A Drosehn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 1.50 (*) [Hold at 12.00] COMBINED_FROM,RATWARE_GECKO_BUILD X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.228 Cc: arch@FreeBSD.org, Doug Barton 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: Mon, 14 Nov 2011 02:22:25 -0000 On 11/12/11 5:39 AM, 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: > > - ac > - arp > - config > - daemon > - dmesg > - ifconfig > - jls > - kldstat > - lastlogin > - md5 > - mtree > - ping > - ping6 > - pkg_info > - pkg_version > - pstat > - rcorder > - rmd160 > - sendmail > - sha1 > - sha256 > - sysctl > > FWIW: I wouldn't mind if md5, sha1, sha256 and rmd160 were moved, although I can also guess why they were initially put in the '/sbin' directory. As an aside, note the 'openssl' command is in /usr/bin, and it includes support for those digest types as well as several others. I wouldn't mind if ping, ping6, pkg_info, and pkg_version moved. I definitely don't understand why 'lastlogin' is in /usr/sbin while 'last' is in /usr/bin. I don't think that ac, arp, config, daemon, dmesg, jls, kldstat, rcorder, or sendmail should be moved. I'm not sure what I think about moving the other binaries in that list. Even moving the binaries which are reasonable to move can cause some problems, as sometimes scripts are written with hardcoded paths and assumptions of what options an executable supports based on where it was found. This is what happens for users (or autoconf rules) who have work with multiple flavors of unix. In my full-time job, I do support for a college. And given some of the professors I have to support, there really *IS* an advantage to having "systems-y" binary outside of their normal path. The people who do *need* those systems-y binaries should be people who understand unix enough that adding /sbin to their PATH is not a problem. And the people I know who cannot handle setting PATH, are also people who should not be running some of the commands listed above. IMO. I'm just giving my opinion, as I do not have the energy for some long debate about every binary someone might want to move. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 09:29: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 21F2A1065670; Mon, 14 Nov 2011 09:29:24 +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 B62158FC08; Mon, 14 Nov 2011 09:29:23 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id CEE362A28CF0; Mon, 14 Nov 2011 10:29:22 +0100 (CET) Date: Mon, 14 Nov 2011 10:29:22 +0100 From: Ed Schouten To: Doug Barton Message-ID: <20111114092922.GA2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a9msq94+WlNd0NRk" Content-Disposition: inline In-Reply-To: <4EC04B65.4030801@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: Mon, 14 Nov 2011 09:29:24 -0000 --a9msq94+WlNd0NRk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Doug, * Doug Barton , 20111113 23:57: > If we're going to talk about making a change that's actually worth > making, let's just move everything into / and get rid of /usr > altogether. It served its purpose back when it came into being, but with > modern disk sizes and the (unfortunate) prevalence of the "one big /" > layout model, it's time in the sun is long past. Now that I think of it, it may be possible to sort of combine this with my approach in a way that it doesn't break POLA for existing users. What if we leave everything in the tree alone, but only modify the code, so that any new installations on empty directory structures use the following symlinks: - /sbin -> /bin - /usr/bin -> /bin - /usr/games -> /bin - /usr/lib -> /lib - /usr/sbin -> /bin But now the question remains how we should change the default partitioning. I think default installations place home directories in /usr/home, with a symlink from /home. Should they now be placed in /usr/local/home? --=20 Ed Schouten WWW: http://80386.nl/ --a9msq94+WlNd0NRk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOwN9yAAoJEG5e2P40kaK7Wi8P/A3b3l0128FWST61dLFi0xUN mISP/hmCRcxXysBjg0JqjKrT/PAVF7r4zCa9dEMpiDQoKtnQeG3f06Qy2RYJrMEN q496y1b6IQpqdHEMknWgCv20oW6JyCuR+s1Y5N3FiTrFRHjeUrfbuqDm8NLdhyWt hj7k8r+klkkND+A+gCT7r8PkTr7NrPnb/5Lir+dI62sGa+Qte0NQnn0lVzbfOJ4k JNInn4jTeid78k8zObprBHqmqrUMmb1ka2iTI7QHB9Ff5O8VKj6/Krggiobj36Ih xe/Sct/1AcovITV7npgfy1//bWNBlzdzXLSYDAtwvJahqr7hI6TFcLoYPUldvt6y waJtO9fM0GpCXLpFihCrP3uanLqwqL7SUwELqR3QOxzULU1SLdGhpAXZvpLgNUS8 c9Z8HSudw5kxQ/3BxR/B5i4UCROEKzgUfdUudM5C3QzhWNAZDO0J053SpJLkjeX/ o77m8+DbDk9B/Dd7aSQ6/ESPfDmf+aSYmGcSYwNvM+AOA/LQeYjLNqHApruNdmei 3gnltA63sMnBHhDWC1Wb9WLODRXjEpRrXlM7G5z8/0OGBeJgUM9VJ9pGzBusONfo Hr29OtgOeobn/OVk7VZFCwjQM+sP8La01OWZYgQt+UogfufXlEiOI0NIj7U/PMpj kAKiZSo8VvJqlocosvvq =3yxi -----END PGP SIGNATURE----- --a9msq94+WlNd0NRk-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 09:33: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 D999B106564A; Mon, 14 Nov 2011 09:33: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 9F4918FC13; Mon, 14 Nov 2011 09:33:22 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 15FAD2A28CFB; Mon, 14 Nov 2011 10:33:22 +0100 (CET) Date: Mon, 14 Nov 2011 10:33:22 +0100 From: Ed Schouten To: Doug Barton Message-ID: <20111114093322.GB2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bnBIwIKtMHAVL+3z" Content-Disposition: inline In-Reply-To: <20111114092922.GA2164@hoeg.nl> 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: Mon, 14 Nov 2011 09:33:22 -0000 --bnBIwIKtMHAVL+3z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten , 20111114 10:29: > But now the question remains how we should change the default > partitioning. I think default installations place home directories in > /usr/home, with a symlink from /home. Should they now be placed in > /usr/local/home? Oh wait. It seems the new FreeBSD installer by default only writes a / and a swap. Then this comment can be ignored. --=20 Ed Schouten WWW: http://80386.nl/ --bnBIwIKtMHAVL+3z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOwOBhAAoJEG5e2P40kaK70RsQAJXK6BqNWWnUD8ZjwZVkJHUx JSiijc501S7zdxysqRNYCbnluCK4Z1HF4QNEKjlu3dWwJERUCz1dfNAo4KPC10vA 3aEi3Cx5EWrw/+ovodBMfFzqCMjXXZvu2wp6e+gUzqe6Xnno1LzQokdL08rVlAY8 MZFq+pT/c3IThRP8PDIfVuBOPHeoDrQaiRuoglRxgmP/FE7Rgbyo/Pg5xU3UvSrv xy79lCX/e4Gkxy4jZyJpzu3kzGFtU83fV2zsjT1xyn7tHLlB9PjozE6sYS8pQDVR xR2aQscFQrCWBc3cVfvkFFY+nMsxAst5PbZkTbsT9MvHa+D32UWt4584Yqbz/mkW sVcCKX2DEls2AvJs3QrD3iW61lMYqyuVViZKhyDP0WsHwIGG4bDkiCARoPjqxdoG r+W1racKFyLV8wvfnzZZDxROSRLCjnJJPwVuURdJ3wXgcWjM36kdaIzhnuX+EG5F ivhlqe7ky78B2LqgN5o7NFlaQckzMAmlETX8Zu+CHE2WSpFdb6gaNnr3hH+0zX0c w+uymqeeJ5xbivCxAmxFHUicHQMmIYZvzZ510oMgSa9bLvAYPH2GKSSPXF89NM7x wvnnkfd//gIeywKz17B+pEqurgkDZVpIhtDN+AEiIo/KbJ9GraNRPCbks8Km44mw FZDdCnnu0fSQgGQg+f1m =GqBz -----END PGP SIGNATURE----- --bnBIwIKtMHAVL+3z-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 09:42:26 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 281B4106567C; Mon, 14 Nov 2011 09:42:26 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id AB4188FC19; Mon, 14 Nov 2011 09:42:24 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 0E3876A661D; Mon, 14 Nov 2011 10:42:24 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id IvyOn8CwFgSW; Mon, 14 Nov 2011 10:42:23 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id B737E6A61CD; Mon, 14 Nov 2011 10:42:23 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id pAE9gNO4032301; Mon, 14 Nov 2011 10:42:23 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id pAE9gNkL031638; Mon, 14 Nov 2011 10:42:23 +0100 (CET) (envelope-from lars) Date: Mon, 14 Nov 2011 10:42:23 +0100 From: Lars Engels To: Ed Schouten Message-ID: <20111114094223.GE80782@e-new.0x20.net> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> <20111114093322.GB2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9l24NVCWtSuIVIod" Content-Disposition: inline In-Reply-To: <20111114093322.GB2164@hoeg.nl> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org, Doug Barton 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: Mon, 14 Nov 2011 09:42:26 -0000 --9l24NVCWtSuIVIod Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 14, 2011 at 10:33:22AM +0100, Ed Schouten wrote: > * Ed Schouten , 20111114 10:29: > > But now the question remains how we should change the default > > partitioning. I think default installations place home directories in > > /usr/home, with a symlink from /home. Should they now be placed in > > /usr/local/home? >=20 > Oh wait. It seems the new FreeBSD installer by default only writes a / > and a swap. Then this comment can be ignored. It does, but that was not a democratic decision, AFAIK... --9l24NVCWtSuIVIod Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7A4n8ACgkQKc512sD3afiRhQCcDU4WTc7A97dARZLnRGAflqEY 6VoAoJgAKa3l5LR+siG0fkI3sHNmUISo =ffP7 -----END PGP SIGNATURE----- --9l24NVCWtSuIVIod-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 10:12: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 C6C111065672 for ; Mon, 14 Nov 2011 10:12:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1A04B8FC0A for ; Mon, 14 Nov 2011 10:12:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA01903; Mon, 14 Nov 2011 12:06:49 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RPtRB-0001xu-1C; Mon, 14 Nov 2011 12:06:49 +0200 Message-ID: <4EC0E838.50609@FreeBSD.org> Date: Mon, 14 Nov 2011 12:06:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic 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: Mon, 14 Nov 2011 10:12:51 -0000 on 13/11/2011 10:32 Kostik Belousov said the following: > I was tricked into finishing the work by Andrey Gapon, who developed the > patch to reliably stop other processors on panic. The patch greatly > improves the chances of getting dump on panic on SMP host. Several people > already saw the patchset, and I remember that Andrey posted it to some > lists. > > The change stops other (*) processors early upon the panic. This way, no > parallel manipulation of the kernel memory is performed by CPUs. In > particular, the kernel memory map is static. Patch prevents the panic > thread from blocking and switching out. > > * - in the context of the description, other means not current. > > Since other threads are not run anymore, lock owner cannot release a lock > which is required by panic thread. Due to this, we need to fake a lock > acquisition after the panic, which adds minimal overhead to the locking > cost. The patch tries to not add any overhead on the fast path of the lock > acquire. The check for the after-panic condition was reduced to single > memory access, done only when the quick cas lock attempt failed, and braced > with __unlikely compiler hint. > > For now, the new mode of operation is disabled by default, since some > further USB changes are needed to make USB keyboard usable in that > environment. > > With the patch, getting a dump from the machine without debugger compiled > in is much more realistic. Please comment, I will commit the change in 2 > weeks unless strong reasons not to are given. > > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch > On a more serious note: - some code in my latest version of the patch was contributed by or was based on the code or ideas contributed by jhb and mdf (so that attributions are not lost) - there was a concern about how sync-on-panic would work About the latter, I have never really tested it. mdf has suggested to move the sync-on-panic code to a place after we ensure that there is only one CPU in panic(), but before we stop other CPUs. I think that I've already sent you a list of the early testers for various WIP versions of the patch. And thanks a lot again. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 10:12:53 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 4736E106566B for ; Mon, 14 Nov 2011 10:12:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8FB518FC13 for ; Mon, 14 Nov 2011 10:12:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA01715; Mon, 14 Nov 2011 11:58:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RPtIh-0001xQ-7Q; Mon, 14 Nov 2011 11:58:03 +0200 Message-ID: <4EC0E62A.4040708@FreeBSD.org> Date: Mon, 14 Nov 2011 11:58:02 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic 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: Mon, 14 Nov 2011 10:12:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kostik, thanks a lot! I am not really sorry for taking part in tricking you into doing this :) I guess I now own that cognac back :) on 13/11/2011 10:32 Kostik Belousov said the following: > I was tricked into finishing the work by Andrey Gapon, who developed the > patch to reliably stop other processors on panic. The patch greatly > improves the chances of getting dump on panic on SMP host. Several people > already saw the patchset, and I remember that Andrey posted it to some > lists. > > The change stops other (*) processors early upon the panic. This way, no > parallel manipulation of the kernel memory is performed by CPUs. In > particular, the kernel memory map is static. Patch prevents the panic > thread from blocking and switching out. > > * - in the context of the description, other means not current. > > Since other threads are not run anymore, lock owner cannot release a lock > which is required by panic thread. Due to this, we need to fake a lock > acquisition after the panic, which adds minimal overhead to the locking > cost. The patch tries to not add any overhead on the fast path of the lock > acquire. The check for the after-panic condition was reduced to single > memory access, done only when the quick cas lock attempt failed, and > braced with __unlikely compiler hint. > > For now, the new mode of operation is disabled by default, since some > further USB changes are needed to make USB keyboard usable in that > environment. > > With the patch, getting a dump from the machine without debugger compiled > in is much more realistic. Please comment, I will commit the change in 2 > weeks unless strong reasons not to are given. > > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch > - -- Andriy Gapon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOwOYqAAoJEHSlLSemUf4v8VYH/13H/MXhxOc6Vz6r+M6x4yDn 03/TwS+QO7+689KEWvr5NQjPcV7cI3Ku3UIS3QlSUQIZYhhepJjK1UgQHM7ra5yr qzXwpEEealJc7GKSjMTIAsjpfcPgRdT66nwymPZWS3ojZJVXYPiGmc4p3uDVrAgv MnuKOdOVUaeI4tOqYa4wWoCSz++tTpbqIGQrlLTWn8yzhGDvNdj2YTEPoETbrTWO E/t8r+BPqeE5pkJjEoDMOpdZqzBB/45x5krocVVCWZL8gt5hp7c5CutGe6lsJ3on Agv5CGyCQb50AmyapDhc/miECtf4qEekFxO3wiqNBTgHxoN2uxvkIMvUhNlxqGg= =yxdc -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 13:09: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 C75081065670; Mon, 14 Nov 2011 13:09:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C10DC8FC1A; Mon, 14 Nov 2011 13:09:02 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAED8vkE068215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 15:08:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAED8v7G098385; Mon, 14 Nov 2011 15:08:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAED8vKg098384; Mon, 14 Nov 2011 15:08:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 14 Nov 2011 15:08:57 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20111114130857.GC50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC0E838.50609@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YTXTVaVjKhDLKTix" Content-Disposition: inline In-Reply-To: <4EC0E838.50609@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org, current@freebsd.org Subject: Re: Stop scheduler on panic 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: Mon, 14 Nov 2011 13:09:03 -0000 --YTXTVaVjKhDLKTix Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote: > on 13/11/2011 10:32 Kostik Belousov said the following: > > I was tricked into finishing the work by Andrey Gapon, who developed the > > patch to reliably stop other processors on panic. The patch greatly > > improves the chances of getting dump on panic on SMP host. Several peop= le > > already saw the patchset, and I remember that Andrey posted it to some > > lists. > >=20 > > The change stops other (*) processors early upon the panic. This way, = no > > parallel manipulation of the kernel memory is performed by CPUs. In > > particular, the kernel memory map is static. Patch prevents the panic > > thread from blocking and switching out. > >=20 > > * - in the context of the description, other means not current. > >=20 > > Since other threads are not run anymore, lock owner cannot release a lo= ck > > which is required by panic thread. Due to this, we need to fake a lock > > acquisition after the panic, which adds minimal overhead to the locking > > cost. The patch tries to not add any overhead on the fast path of the l= ock > > acquire. The check for the after-panic condition was reduced to single > > memory access, done only when the quick cas lock attempt failed, and br= aced > > with __unlikely compiler hint. > >=20 > > For now, the new mode of operation is disabled by default, since some= =20 > > further USB changes are needed to make USB keyboard usable in that=20 > > environment. > >=20 > > With the patch, getting a dump from the machine without debugger compil= ed > > in is much more realistic. Please comment, I will commit the change in= 2 > > weeks unless strong reasons not to are given. > >=20 > > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch > >=20 >=20 >=20 > On a more serious note: > - some code in my latest version of the patch was contributed by or was b= ased > on the code or ideas contributed by jhb and mdf (so that attributions are= not > lost) Please provide me with proper attribution for contributors and testers. > - there was a concern about how sync-on-panic would work >=20 > About the latter, I have never really tested it. mdf has suggested to > move the sync-on-panic code to a place after we ensure that there is > only one CPU in panic(), but before we stop other CPUs. sync_on_panic is incompatible with the patch. I argue that it provides non-zero chance of damaging good filesystems even if panic was unrelated to the fs/bio/device layer. As an example, consider the case when other CPU was modifying in-memory representation of the metadata, and panic happen on this CPU. If you write half-changed block back, you make more damage to the filesystem then if you do not. The half-backed sync spoils any journaling or SU consistency guarantees. The issues of multithreading nature of our storage subsystem are secondary. The user who sets either tunable shall know what he does. > > I think that I've already sent you a list of the early testers for > various WIP versions of the patch. I do not have the list. BTW, if you want, feel free to handle the commit youself. You definitely spent much more efforts on the stuff and deserve the credit. I was promised in private that a review will be provided during this weekend. --YTXTVaVjKhDLKTix Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7BEukACgkQC3+MBN1Mb4gE/wCggdI+mhzimk5hH5kOX6F70qMb AZcAnAx/abmVDuBXVq9zHSGIoEDJUhFX =dG36 -----END PGP SIGNATURE----- --YTXTVaVjKhDLKTix-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 13:32:10 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 09320106566C; Mon, 14 Nov 2011 13:32:10 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id A2C1E8FC14; Mon, 14 Nov 2011 13:32:09 +0000 (UTC) Received: by qabj40 with SMTP id j40so6447477qab.13 for ; Mon, 14 Nov 2011 05:32:08 -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=X60VthMrZd8k7H9wEW/mvQFu33QUp7VjfAvllffzyXA=; b=uwi6kcO4iguoBqnbrQqTbfiVnQi9vlazghje2dxVlzVOg8UqKjjwvchNCTp0lrmxN5 xlqZzI1BsP5JaZEK+pvyEFcGKFsc0HkjM2MQ+F3IijCOY3YuUJPxQSfg1UM1H3BGbxaz WbV6yZ4wSV729ERU7W+GNnDMUqVmWhnIpffdQ= MIME-Version: 1.0 Received: by 10.224.182.196 with SMTP id cd4mr13357658qab.3.1321267334407; Mon, 14 Nov 2011 02:42:14 -0800 (PST) Received: by 10.224.73.195 with HTTP; Mon, 14 Nov 2011 02:42:14 -0800 (PST) In-Reply-To: <20111114092922.GA2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> Date: Mon, 14 Nov 2011 05:42:14 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Ed Schouten Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: arch@freebsd.org, Doug Barton 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: Mon, 14 Nov 2011 13:32:10 -0000 On Mon, Nov 14, 2011 at 4:29 AM, Ed Schouten wrote: > Hi Doug, > > * Doug Barton , 20111113 23:57: > > If we're going to talk about making a change that's actually worth > > making, let's just move everything into / and get rid of /usr > > altogether. It served its purpose back when it came into being, but with > > modern disk sizes and the (unfortunate) prevalence of the "one big /" > > layout model, it's time in the sun is long past. > > Now that I think of it, it may be possible to sort of combine this with > my approach in a way that it doesn't break POLA for existing users. What > if we leave everything in the tree alone, but only modify the code, so > that any new installations on empty directory structures use the > following symlinks: > > - /sbin -> /bin > - /usr/bin -> /bin > - /usr/games -> /bin > - /usr/lib -> /lib > - /usr/sbin -> /bin > ............................................. > > But now the question remains how we should change the default > partitioning. I think default installations place home directories in > /usr/home, with a symlink from /home. Should they now be placed in > /usr/local/home? > ............................................. > > -- > Ed Schouten > WWW: http://80386.nl/ > Is it not possible to use a symbolic link from /usr/home to /home and put /home into a separate partition or drive ? Mandriva Linux ( and other Linux distributions , mostly ) is using this separate partition and it is possible to completely install ( not upgrade ) a new version without losing /home by only specifying to mount the existing /home during new installation . Even it is asking whether /var will be re-installed or not . In FreeBSD , such a new ( default ) version installation from released *.iso CD/DVD is not possible without losing existing /usr/home . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 15:37: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 9C1E41065670; Mon, 14 Nov 2011 15:37:38 +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 520F08FC1B; Mon, 14 Nov 2011 15:37:38 +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 pAEFTBMn068592 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 08:29:11 -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: <20111114092922.GA2164@hoeg.nl> Date: Mon, 14 Nov 2011 08:29:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33576F33-EA87-467F-945F-1ED4349FF1B6@bsdimp.com> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@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]); Mon, 14 Nov 2011 08:29:11 -0700 (MST) Cc: arch@FreeBSD.org, Doug Barton 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: Mon, 14 Nov 2011 15:37:38 -0000 On Nov 14, 2011, at 2:29 AM, Ed Schouten wrote: > Hi Doug, >=20 > * Doug Barton , 20111113 23:57: >> If we're going to talk about making a change that's actually worth >> making, let's just move everything into / and get rid of /usr >> altogether. It served its purpose back when it came into being, but = with >> modern disk sizes and the (unfortunate) prevalence of the "one big /" >> layout model, it's time in the sun is long past. >=20 > Now that I think of it, it may be possible to sort of combine this = with > my approach in a way that it doesn't break POLA for existing users. = What > if we leave everything in the tree alone, but only modify the code, so > that any new installations on empty directory structures use the > following symlinks: >=20 > - /sbin -> /bin > - /usr/bin -> /bin > - /usr/games -> /bin > - /usr/lib -> /lib > - /usr/sbin -> /bin >=20 > But now the question remains how we should change the default > partitioning. I think default installations place home directories in > /usr/home, with a symlink from /home. Should they now be placed in > /usr/local/home? That assumes that you have wide-spread support to change the status-quo. = It isn't clear from this thread that you've made that case. Doug is right that there be dragons here, and I for one would like to = see cold, hard data on the actual effect of hundreds of systems that = have a good mix of ports installed rather than logic that it shouldn't = matter. Warner= From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 15:56: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 E4C4C106564A; Mon, 14 Nov 2011 15:56:57 +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 BC6158FC18; Mon, 14 Nov 2011 15:56:57 +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 5924746B46; Mon, 14 Nov 2011 10:56:57 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E1F968A050; Mon, 14 Nov 2011 10:56:56 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org, mike@karels.net Date: Mon, 14 Nov 2011 08:02:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111140101.pAE11XEa067064@mail.karels.net> In-Reply-To: <201111140101.pAE11XEa067064@mail.karels.net> MIME-Version: 1.0 Message-Id: <201111140802.13355.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 14 Nov 2011 10:56:57 -0500 (EST) Cc: Ed Schouten , arch@freebsd.org, Doug Barton , Tim Kientzle 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: Mon, 14 Nov 2011 15:56:58 -0000 On Sunday, November 13, 2011 8:01:33 pm Mike Karels wrote: > I have to agree with Doug. If the directories were unified and we were > proposing splitting them based on efficiency, I would say it is not worth > doing. However, the directories are separate now, and I don't see sufficient > benefit from combining them. fwiw, I think at least 90% of the users at > work do not have /sbin and /usr/sbin in their paths now, and they do not > need them. (Yes, there are still multi-user systems, and not everyone > is a sysadmin.) > > I think this is a solution in search of a problem. I agree. The upheaval and drama doesn't seem to be worth the change. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 15:56:57 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 E4C4C106564A; Mon, 14 Nov 2011 15:56:57 +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 BC6158FC18; Mon, 14 Nov 2011 15:56:57 +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 5924746B46; Mon, 14 Nov 2011 10:56:57 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E1F968A050; Mon, 14 Nov 2011 10:56:56 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org, mike@karels.net Date: Mon, 14 Nov 2011 08:02:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111140101.pAE11XEa067064@mail.karels.net> In-Reply-To: <201111140101.pAE11XEa067064@mail.karels.net> MIME-Version: 1.0 Message-Id: <201111140802.13355.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 14 Nov 2011 10:56:57 -0500 (EST) Cc: Ed Schouten , arch@freebsd.org, Doug Barton , Tim Kientzle 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: Mon, 14 Nov 2011 15:56:58 -0000 On Sunday, November 13, 2011 8:01:33 pm Mike Karels wrote: > I have to agree with Doug. If the directories were unified and we were > proposing splitting them based on efficiency, I would say it is not worth > doing. However, the directories are separate now, and I don't see sufficient > benefit from combining them. fwiw, I think at least 90% of the users at > work do not have /sbin and /usr/sbin in their paths now, and they do not > need them. (Yes, there are still multi-user systems, and not everyone > is a sysadmin.) > > I think this is a solution in search of a problem. I agree. The upheaval and drama doesn't seem to be worth the change. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 15:59: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 F084B1065673; Mon, 14 Nov 2011 15:59:38 +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 A48098FC1A; Mon, 14 Nov 2011 15:59:38 +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 pAEFs93s068828 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 08:54:09 -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: Mon, 14 Nov 2011 08:53:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> To: Mehmet Erol Sanliturk 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]); Mon, 14 Nov 2011 08:54:09 -0700 (MST) Cc: Ed Schouten , Doug Barton , 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: Mon, 14 Nov 2011 15:59:39 -0000 On Nov 14, 2011, at 3:42 AM, Mehmet Erol Sanliturk wrote: > Is it not possible to use a symbolic link from /usr/home to /home and = put > /home into a separate partition or drive ? >=20 > Mandriva Linux ( and other Linux distributions , mostly ) is using = this > separate partition and it is possible to completely install ( not = upgrade ) > a new version without losing /home by only specifying to mount the = existing > /home during new installation . Even it is asking whether /var will be > re-installed or not . >=20 > In FreeBSD , such a new ( default ) version installation from released > *.iso CD/DVD is not possible without losing existing /usr/home . I haven't created a FreeBSD system that has users in /usr/home since = 1998 or so. It is about the stupidest place to put user directories, = since it keeps you from mounting things read-only, mixes user data with = critical system data, etc. I've always created a /machine-name = partition for the users to live in. This also lets me mount dune:/dune = from harmony on /dune and harmony:/harmony on /harmony on dune so that = any absolute paths that sneak in are preserved on the other machine.... = Although to be honest lately I've tended to have one big file server = machine and not even create a user's partition on slave machines. = Still, nothing in /usr/home there either :) Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 16:08: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 C7D1C106564A; Mon, 14 Nov 2011 16:08:08 +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 7DAB78FC08; Mon, 14 Nov 2011 16:08:08 +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 pAEFwCan068883 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 08:58:13 -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: <20111114094223.GE80782@e-new.0x20.net> Date: Mon, 14 Nov 2011 08:58:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> <20111114093322.GB2164@hoeg.nl> <20111114094223.GE80782@e-new.0x20.net> To: Lars Engels 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]); Mon, 14 Nov 2011 08:58:13 -0700 (MST) Cc: Ed Schouten , Doug Barton , 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: Mon, 14 Nov 2011 16:08:08 -0000 On Nov 14, 2011, at 2:42 AM, Lars Engels wrote: > On Mon, Nov 14, 2011 at 10:33:22AM +0100, Ed Schouten wrote: >> * Ed Schouten , 20111114 10:29: >>> But now the question remains how we should change the default >>> partitioning. I think default installations place home directories = in >>> /usr/home, with a symlink from /home. Should they now be placed in >>> /usr/local/home? >>=20 >> Oh wait. It seems the new FreeBSD installer by default only writes a = / >> and a swap. Then this comment can be ignored. >=20 > It does, but that was not a democratic decision, AFAIK... At the time, it was also *EXPLICITLY* stated that this wasn't a grab to = moving things out of /usr, or changing that. There's a fair amount of = infrastructure that depends on the separation and while it wouldn't be = hard to separate it out, there's likely a non-zero amount of work to = getting it all right. That's a *MUCH* bigger deal than collapsing /*bin = into /bin or /usr/*bin into /usr/bin. Ed: Have you tested nanobsd, tinybsd and picobsd with even the modest = changes you posted earlier? Warner From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 16:42:05 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 DA28F1065672 for ; Mon, 14 Nov 2011 16:42:05 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 966DF8FC12 for ; Mon, 14 Nov 2011 16:42:05 +0000 (UTC) Received: from baby-jane.lamaiziere.net (221.176.97.84.rev.sfr.net [84.97.176.221]) by smtp.lamaiziere.net (Postfix) with ESMTPA id BCA7AFAA31A5; Mon, 14 Nov 2011 17:26:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 2749B730AF7; Mon, 14 Nov 2011 17:26:10 +0100 (CET) Date: Mon, 14 Nov 2011 17:26:09 +0100 From: Patrick Lamaiziere To: freebsd-arch@freebsd.org, Ed Schouten Message-ID: <20111114172609.1c2aeb0a@davenulle.org> In-Reply-To: <20111114092922.GA2164@hoeg.nl> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Mon, 14 Nov 2011 16:42:05 -0000 Le Mon, 14 Nov 2011 10:29:22 +0100, Ed Schouten a écrit : Hello, > But now the question remains how we should change the default > partitioning. I think default installations place home directories in > /usr/home, with a symlink from /home. Should they now be placed in > /usr/local/home? I would like to keep /usr/local for ports only. When things are going wrong with ports it is sometimes easier to rm -rf /usr/local and rebuild all from scratch. My 2 centimes. Regards. From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 17:22: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 EE3C2106566B; Mon, 14 Nov 2011 17:22:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E1D0A8FC0A; Mon, 14 Nov 2011 17:22:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08690; Mon, 14 Nov 2011 19:22:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EC14E63.2090506@FreeBSD.org> Date: Mon, 14 Nov 2011 19:22:43 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC0E838.50609@FreeBSD.org> <20111114130857.GC50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111114130857.GC50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D8E014BB4D54A54E4F13B1A" Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic 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: Mon, 14 Nov 2011 17:22:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D8E014BB4D54A54E4F13B1A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable on 14/11/2011 15:08 Kostik Belousov said the following: > On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote: >> On a more serious note: >> - some code in my latest version of the patch was contributed by or wa= s based >> on the code or ideas contributed by jhb and mdf (so that attributions = are not >> lost) Oops, forgot the most recent and quite big contribution from Attilio. > Please provide me with proper attribution for contributors and testers.= My memory has faded a bit, so let's make it simple. In cooperation with: attilio, avg, jhb, kib, mdf Tested by: avg, Eugene Grosbein , gnn, Steven Hartland , glebius, kib [strike out obvious/unnecessary] >> - there was a concern about how sync-on-panic would work >> >> About the latter, I have never really tested it. mdf has suggested to >> move the sync-on-panic code to a place after we ensure that there is >> only one CPU in panic(), but before we stop other CPUs. > sync_on_panic is incompatible with the patch. I argue that it provides > non-zero chance of damaging good filesystems even if panic was unrelate= d > to the fs/bio/device layer. As an example, consider the case when other= > CPU was modifying in-memory representation of the metadata, and panic > happen on this CPU. If you write half-changed block back, you make more= > damage to the filesystem then if you do not. The half-backed sync spoil= s > any journaling or SU consistency guarantees. Not sure how this is different from what we have right now (without the p= atch). Perhaps I misunderstand what you say, but, just in case, the proposal was= to do sync-on-panic before stopping other CPUs. > The issues of multithreading nature of our storage subsystem are second= ary. >=20 > The user who sets either tunable shall know what he does. That has always been the case. and apparently there are people who still want this option to exist. >> I think that I've already sent you a list of the early testers for >> various WIP versions of the patch. > I do not have the list. Included above. > BTW, if you want, feel free to handle the commit youself. You definitel= y > spent much more efforts on the stuff and deserve the credit. >=20 > I was promised in private that a review will be provided during this > weekend. Unfortunately too little time and spare mind capacity to do the commit no= w. I do not care much about the credit (or commit-o-meter) as long as we get= functionality in. It was/is a collective effort in any case. Besides I won't be able to handle any potential regression reports in a sufficiently speedy manner. --=20 Andriy Gapon --------------enig5D8E014BB4D54A54E4F13B1A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOwU5sAAoJEHSlLSemUf4vt/gIAK3ErPHwuIpwBFvSjvgP0OQF clr4Ox7yl8MfvXej43nqRnj00ySRpqpFT+kAbruKlnkiPJoIeD4DOJr1eMSi1/CD lt8J5guUPIon/or5V/e703jnv/KTaR63d2ihHZg9y1GVWww2iFZTamg4M46aGtF5 Y83J1tBWOROEy9MaFHGtyBSaQBgAMIpMLnY+L1ueXerzAaCfXVlXT4osEt95fJRg hPhfgfWK6CDwswwo01aom0x7bVl+xA5rXDUFpDVD8LDcGjpYVAstH181Uh4sO69w 61wQTaC7G9b+1jOx8eALK8k1ssBFamwaJ/pcmsBbXrvBUJCFgdb8wzwX0ZlZGb0= =o+eV -----END PGP SIGNATURE----- --------------enig5D8E014BB4D54A54E4F13B1A-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 17:48:14 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 08CB8106566C; Mon, 14 Nov 2011 17:48:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7D368FC08; Mon, 14 Nov 2011 17:48:13 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4FFB146B0C; Mon, 14 Nov 2011 12:48:13 -0500 (EST) Date: Mon, 14 Nov 2011 17:48:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <201111140802.13355.jhb@freebsd.org> Message-ID: References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , Doug Barton , mike@karels.net, Tim Kientzle , arch@freebsd.org, freebsd-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: Mon, 14 Nov 2011 17:48:14 -0000 On Mon, 14 Nov 2011, John Baldwin wrote: > On Sunday, November 13, 2011 8:01:33 pm Mike Karels wrote: >> I have to agree with Doug. If the directories were unified and we were >> proposing splitting them based on efficiency, I would say it is not worth >> doing. However, the directories are separate now, and I don't see >> sufficient benefit from combining them. fwiw, I think at least 90% of the >> users at work do not have /sbin and /usr/sbin in their paths now, and they >> do not need them. (Yes, there are still multi-user systems, and not >> everyone is a sysadmin.) >> >> I think this is a solution in search of a problem. > > I agree. The upheaval and drama doesn't seem to be worth the change. Ditto. I agree with Ed that it is more aesthetically pleasing and in keeping with the actual design principles we have, but it would be quite disruptive for downstream users. Especially if the source tree is rearranged, since not all revision control systems (or import methods) take kindly to large-scale renaming of subtrees with substantial patches. Such barriers should only be introduced where there's a compelling reason to do so, and I don't see that for this, even if it would fall neatly on the pile of "If we had to do it all over again, we'd do it X way". Robert From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 17:48:14 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 08CB8106566C; Mon, 14 Nov 2011 17:48:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7D368FC08; Mon, 14 Nov 2011 17:48:13 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4FFB146B0C; Mon, 14 Nov 2011 12:48:13 -0500 (EST) Date: Mon, 14 Nov 2011 17:48:13 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <201111140802.13355.jhb@freebsd.org> Message-ID: References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , Doug Barton , mike@karels.net, Tim Kientzle , arch@freebsd.org, freebsd-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: Mon, 14 Nov 2011 17:48:14 -0000 On Mon, 14 Nov 2011, John Baldwin wrote: > On Sunday, November 13, 2011 8:01:33 pm Mike Karels wrote: >> I have to agree with Doug. If the directories were unified and we were >> proposing splitting them based on efficiency, I would say it is not worth >> doing. However, the directories are separate now, and I don't see >> sufficient benefit from combining them. fwiw, I think at least 90% of the >> users at work do not have /sbin and /usr/sbin in their paths now, and they >> do not need them. (Yes, there are still multi-user systems, and not >> everyone is a sysadmin.) >> >> I think this is a solution in search of a problem. > > I agree. The upheaval and drama doesn't seem to be worth the change. Ditto. I agree with Ed that it is more aesthetically pleasing and in keeping with the actual design principles we have, but it would be quite disruptive for downstream users. Especially if the source tree is rearranged, since not all revision control systems (or import methods) take kindly to large-scale renaming of subtrees with substantial patches. Such barriers should only be introduced where there's a compelling reason to do so, and I don't see that for this, even if it would fall neatly on the pile of "If we had to do it all over again, we'd do it X way". Robert From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 17:57: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 28730106566C; Mon, 14 Nov 2011 17:57:21 +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 F333D8FC15; Mon, 14 Nov 2011 17:57:20 +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 9FB2046B51; Mon, 14 Nov 2011 12:57:20 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 484378A052; Mon, 14 Nov 2011 12:57:20 -0500 (EST) From: John Baldwin To: Bruce Cran Date: Mon, 14 Nov 2011 11:32:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201110281426.00013.jhb@freebsd.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> In-Reply-To: <4EBB104F.5010000@cran.org.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111141132.49616.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 14 Nov 2011 12:57:20 -0500 (EST) 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: Mon, 14 Nov 2011 17:57:21 -0000 On Wednesday, November 09, 2011 6:44:15 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/ > . I think this would be a fine extension to add. You could do it just by using O_DIRECT though, no need for fadvise(). (FADV_NOREUSE effectively forces O_DIRECT on, so if you want to use it for the entire file, you can just use O_DIRECT). However, the application should be very careful to only read full FS blocks on block-aligned boundaries (using fs_bsize from stat) to avoid excessive I/O operations. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 17:57: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 28730106566C; Mon, 14 Nov 2011 17:57:21 +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 F333D8FC15; Mon, 14 Nov 2011 17:57:20 +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 9FB2046B51; Mon, 14 Nov 2011 12:57:20 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 484378A052; Mon, 14 Nov 2011 12:57:20 -0500 (EST) From: John Baldwin To: Bruce Cran Date: Mon, 14 Nov 2011 11:32:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201110281426.00013.jhb@freebsd.org> <201111080800.32717.jhb@freebsd.org> <4EBB104F.5010000@cran.org.uk> In-Reply-To: <4EBB104F.5010000@cran.org.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111141132.49616.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 14 Nov 2011 12:57:20 -0500 (EST) 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: Mon, 14 Nov 2011 17:57:21 -0000 On Wednesday, November 09, 2011 6:44:15 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/ > . I think this would be a fine extension to add. You could do it just by using O_DIRECT though, no need for fadvise(). (FADV_NOREUSE effectively forces O_DIRECT on, so if you want to use it for the entire file, you can just use O_DIRECT). However, the application should be very careful to only read full FS blocks on block-aligned boundaries (using fs_bsize from stat) to avoid excessive I/O operations. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 19:34: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 12A60106566B; Mon, 14 Nov 2011 19:34:36 +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 6ACCF8FC08; Mon, 14 Nov 2011 19:34:35 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 615282A28CFB; Mon, 14 Nov 2011 20:34:34 +0100 (CET) Date: Mon, 14 Nov 2011 20:34:34 +0100 From: Ed Schouten To: Robert Watson Message-ID: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0uCeA/GhJk5vQd80" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Tim Kientzle , Doug Barton , mike@karels.net, arch@freebsd.org, freebsd-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: Mon, 14 Nov 2011 19:34:36 -0000 --0uCeA/GhJk5vQd80 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Robert, others, Before I get to the subject, please excuse me for not commenting on all your emails individually. I am afraid that if I would do that, the discussion will fragment. The first thing I noticed is that some of the emails mention that the work I proposed was a solution searching for a problem. I have to emphasize this is clearly not my intention. It was something that I started to notice when I was working on the utmpx code in 2009, where half of the utilities were stored in /usr/bin, while the others were placed in /usr/sbin. The reason why I let it wait until now, is because even though I was considering moving the tools around back then, I realized that this causes major headaches for our users, because if they don't run `make delete-old' (which isn't even described in the handbook, by the way), they'll end up having two copies. I reasoned that performing a merge of sbin to bin automatically fixes this. Combined with the arguments that I gave in my opening email, I am under the impression that this is something that we should consider. The reason why I brought it up last week, is because I got reminded of the issue by seeing the Fedora discussion. So to summarize: the reason why I proposed this, is _not_ because the Fedora folks think it's cool, it's because work in this area was (is?) on my TODO list anyway. The fact that the Fedora folks are also discussing this, was only a confirmation for me that this is a point of discussion in a larger part of UNIX-land -- not just FreeBSD. Now let me respond to Robert's email specifically, as it raises an interesting point, which I already thought about, but had not specifically mentioned in the introduction email. =46rom now on, let us assume we're discussing the patchset I have sent to the list initially -- not the discussion between Doug and I, where we discussed a full merge into /bin and /lib. * Robert Watson , 20111114 18:48: > Ditto. I agree with Ed that it is more aesthetically pleasing and in > keeping with the actual design principles we have, but it would be > quite disruptive for downstream users. Especially if the source tree > is rearranged, since not all revision control systems (or import > methods) take kindly to large-scale renaming of subtrees with > substantial patches. So let us divide our users in two groups; regular users and vendors. Group 1: regular users ---------------------- In my opinion the patch isn't really disruptive for our end users. One of the things that I don't want to do, is perform the merge of the sbin and games directories automatically. This is because one small error or assumption in our scripts can render many the system unbootable. If it turns out we don't have anything to worry about, we could eventually automate this through some means. If committed to SVN in its current form, users will experience the following upgrade procedure: - csup or svn up the source tree - The user compiles the source, installs the kernel, reboots, etc. - The user runs `make installworld', but it will simply print a message, asking the user to read /usr/src/UPDATING, which contains four simple shell commands that perform the merge. - When done, the user runs `make installworld', which will now continue to work properly. So all in all this is a pretty simple procedure. The total overhead is only four small shell commands on a single `make installworld'. Compared to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say the least. Group 2: vendors ---------------- So a pretty serious point that Robert raises, is that changes to source tree layout are really irritating for our vendors. Now keep in mind that I have mentioned nothing in particular about source tree layout. Even though it would be a lot more consistent if those directories are merged as well, I have not been promoting this. We could easily put the following policy in place: any new (or massively rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories are left the way they are. In other words: the directory src/usr.sbin/ can be described as "applications that were historically installed in /usr/sbin". So vendors shouldn't notice that much of the transition. They can just build on top of our source tree the way they currently do. The only merge conflicts they could experience, are lines of code where we replace path names, but conflicts in that area are as likely as any other changeset. I think this message covers most of the things I wanted to say for now. I really hope we can continue this discussion in a fruitful manner. I have noticed that even though there has been criticism, there have also been many people that have expressed support for this work, both privately and on the mailing list, so it would be nice if this discussion actually leads to something useful. Just because certain aspects have so far not been worked out completely, doesn't mean the idea as a whole is a bad thing. And if it turns out to be a bad thing, then so be it. At least it has served as a lesson. Maybe it's worth asking yourself this question: "say, we were to merge sbin with bin, what kind of problems can we walk into and how should they be resolved?" Thanks, --=20 Ed Schouten WWW: http://80386.nl/ --0uCeA/GhJk5vQd80 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOwW1KAAoJEG5e2P40kaK7ZQQP/3qfaUBCjj6GAhnzOuWaL73o Iq6FeWdbqCbG7H8LtSaktTjhD+RQCFwkPuZO2uvIJAep24JsS08p1UgN6MOlBLRA 9tVZgp4UM7iVXH4hUomeCHZGUKx+JnMvTQ/9KAxL8+crN7iyoXoDT0OXP9ruE5Sf 0MkbsPJNhF5Tzxqo9Tuia+ITgWbhbVwCA0UebGCy8k23r1tGzBWkhn+uLe0Az+aw sAPF5bfw+ztQ30qaAJCqlW0FGjVog7Iix9CJn5QUBtcl+7Ilyj43uoAmkJygdDfn VzYjzOC9xRlrmLBYGt10mb1NYP0hHUcAKgmVhZuboH7bMga5hZAMpF7MpfOz/w5X DTfc4348utcPgHgY0uUw5Odt0y8YERtaF+JLYN0dxfMT+2OGPr2ENK4bdTkN11ap CgaeDcaXRsN0chHULfNTkdHxPyYrz9Zz/Ra91Rs/kAzn3mXl2USM5196769GM4V5 BuQGuuVykNhZDUh6koMD5GkC7zotKx/DPcghm2B/GaZxKIG2MBQfnId0r/Lw+Fv3 AAGlYB7c83MftgqfB9ERHQXeguh9cD/hngThsdTzckEEP5h7j3teyQPWZfL3tzn5 gGpykO+FcYLtKQCe9IVE6ayLXaAE6ZwvOH1EXGciB7BwLawM2TfvLQ7JGCd91iby xFxvLoFWGMKW27LCJaDP =n+uK -----END PGP SIGNATURE----- --0uCeA/GhJk5vQd80-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 19:34:36 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 12A60106566B; Mon, 14 Nov 2011 19:34:36 +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 6ACCF8FC08; Mon, 14 Nov 2011 19:34:35 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 615282A28CFB; Mon, 14 Nov 2011 20:34:34 +0100 (CET) Date: Mon, 14 Nov 2011 20:34:34 +0100 From: Ed Schouten To: Robert Watson Message-ID: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0uCeA/GhJk5vQd80" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Tim Kientzle , Doug Barton , mike@karels.net, arch@freebsd.org, freebsd-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: Mon, 14 Nov 2011 19:34:36 -0000 --0uCeA/GhJk5vQd80 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Robert, others, Before I get to the subject, please excuse me for not commenting on all your emails individually. I am afraid that if I would do that, the discussion will fragment. The first thing I noticed is that some of the emails mention that the work I proposed was a solution searching for a problem. I have to emphasize this is clearly not my intention. It was something that I started to notice when I was working on the utmpx code in 2009, where half of the utilities were stored in /usr/bin, while the others were placed in /usr/sbin. The reason why I let it wait until now, is because even though I was considering moving the tools around back then, I realized that this causes major headaches for our users, because if they don't run `make delete-old' (which isn't even described in the handbook, by the way), they'll end up having two copies. I reasoned that performing a merge of sbin to bin automatically fixes this. Combined with the arguments that I gave in my opening email, I am under the impression that this is something that we should consider. The reason why I brought it up last week, is because I got reminded of the issue by seeing the Fedora discussion. So to summarize: the reason why I proposed this, is _not_ because the Fedora folks think it's cool, it's because work in this area was (is?) on my TODO list anyway. The fact that the Fedora folks are also discussing this, was only a confirmation for me that this is a point of discussion in a larger part of UNIX-land -- not just FreeBSD. Now let me respond to Robert's email specifically, as it raises an interesting point, which I already thought about, but had not specifically mentioned in the introduction email. =46rom now on, let us assume we're discussing the patchset I have sent to the list initially -- not the discussion between Doug and I, where we discussed a full merge into /bin and /lib. * Robert Watson , 20111114 18:48: > Ditto. I agree with Ed that it is more aesthetically pleasing and in > keeping with the actual design principles we have, but it would be > quite disruptive for downstream users. Especially if the source tree > is rearranged, since not all revision control systems (or import > methods) take kindly to large-scale renaming of subtrees with > substantial patches. So let us divide our users in two groups; regular users and vendors. Group 1: regular users ---------------------- In my opinion the patch isn't really disruptive for our end users. One of the things that I don't want to do, is perform the merge of the sbin and games directories automatically. This is because one small error or assumption in our scripts can render many the system unbootable. If it turns out we don't have anything to worry about, we could eventually automate this through some means. If committed to SVN in its current form, users will experience the following upgrade procedure: - csup or svn up the source tree - The user compiles the source, installs the kernel, reboots, etc. - The user runs `make installworld', but it will simply print a message, asking the user to read /usr/src/UPDATING, which contains four simple shell commands that perform the merge. - When done, the user runs `make installworld', which will now continue to work properly. So all in all this is a pretty simple procedure. The total overhead is only four small shell commands on a single `make installworld'. Compared to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say the least. Group 2: vendors ---------------- So a pretty serious point that Robert raises, is that changes to source tree layout are really irritating for our vendors. Now keep in mind that I have mentioned nothing in particular about source tree layout. Even though it would be a lot more consistent if those directories are merged as well, I have not been promoting this. We could easily put the following policy in place: any new (or massively rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories are left the way they are. In other words: the directory src/usr.sbin/ can be described as "applications that were historically installed in /usr/sbin". So vendors shouldn't notice that much of the transition. They can just build on top of our source tree the way they currently do. The only merge conflicts they could experience, are lines of code where we replace path names, but conflicts in that area are as likely as any other changeset. I think this message covers most of the things I wanted to say for now. I really hope we can continue this discussion in a fruitful manner. I have noticed that even though there has been criticism, there have also been many people that have expressed support for this work, both privately and on the mailing list, so it would be nice if this discussion actually leads to something useful. Just because certain aspects have so far not been worked out completely, doesn't mean the idea as a whole is a bad thing. And if it turns out to be a bad thing, then so be it. At least it has served as a lesson. Maybe it's worth asking yourself this question: "say, we were to merge sbin with bin, what kind of problems can we walk into and how should they be resolved?" Thanks, --=20 Ed Schouten WWW: http://80386.nl/ --0uCeA/GhJk5vQd80 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOwW1KAAoJEG5e2P40kaK7ZQQP/3qfaUBCjj6GAhnzOuWaL73o Iq6FeWdbqCbG7H8LtSaktTjhD+RQCFwkPuZO2uvIJAep24JsS08p1UgN6MOlBLRA 9tVZgp4UM7iVXH4hUomeCHZGUKx+JnMvTQ/9KAxL8+crN7iyoXoDT0OXP9ruE5Sf 0MkbsPJNhF5Tzxqo9Tuia+ITgWbhbVwCA0UebGCy8k23r1tGzBWkhn+uLe0Az+aw sAPF5bfw+ztQ30qaAJCqlW0FGjVog7Iix9CJn5QUBtcl+7Ilyj43uoAmkJygdDfn VzYjzOC9xRlrmLBYGt10mb1NYP0hHUcAKgmVhZuboH7bMga5hZAMpF7MpfOz/w5X DTfc4348utcPgHgY0uUw5Odt0y8YERtaF+JLYN0dxfMT+2OGPr2ENK4bdTkN11ap CgaeDcaXRsN0chHULfNTkdHxPyYrz9Zz/Ra91Rs/kAzn3mXl2USM5196769GM4V5 BuQGuuVykNhZDUh6koMD5GkC7zotKx/DPcghm2B/GaZxKIG2MBQfnId0r/Lw+Fv3 AAGlYB7c83MftgqfB9ERHQXeguh9cD/hngThsdTzckEEP5h7j3teyQPWZfL3tzn5 gGpykO+FcYLtKQCe9IVE6ayLXaAE6ZwvOH1EXGciB7BwLawM2TfvLQ7JGCd91iby xFxvLoFWGMKW27LCJaDP =n+uK -----END PGP SIGNATURE----- --0uCeA/GhJk5vQd80-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 19:44:46 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 657BF1065676; Mon, 14 Nov 2011 19:44:46 +0000 (UTC) (envelope-from adrian.chadd@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 D568C8FC0A; Mon, 14 Nov 2011 19:44:45 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so7882349vcb.13 for ; Mon, 14 Nov 2011 11:44:45 -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=2PJIr2igY0hbEH5ANGQJlMDwUBKrMZzDMu+6aOyFSOY=; b=WiYxtz9UzdjkvPGvv3la71/EF6GKkaRzgx1wvmp1G+uY+B36tQnSKja82QGuG4zvhP lYwZ2tDmHM5t0+pf9lw9om4rYXkGxngDSubXB7bqXV2e24GlElD4pP+MkKPOFkiPcN4S lLFVCi7gotdlX4N8P0u9tfTfaaNe139EIALo0= MIME-Version: 1.0 Received: by 10.52.34.78 with SMTP id x14mr30455392vdi.122.1321299885220; Mon, 14 Nov 2011 11:44:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Mon, 14 Nov 2011 11:44:45 -0800 (PST) In-Reply-To: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> Date: Mon, 14 Nov 2011 11:44:45 -0800 X-Google-Sender-Auth: Pg3824gKLN9tR6VySqXxUBhsfPM Message-ID: From: Adrian Chadd To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Kientzle , Doug Barton , mike@karels.net, arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 19:44:46 -0000 I honestly think we have _much bigger_ things to try and fix before we worry about the layout of binaries in the directory hierarchy. Once we've sorted out things like virtualisation hooks for the installer and management, better package management and upgrade paths, module/kernel build sync, cross-compiled ports, non-root installation methods, etc, etc.. I think then we could look at this kind of thing. 2c, Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 19:44:46 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 657BF1065676; Mon, 14 Nov 2011 19:44:46 +0000 (UTC) (envelope-from adrian.chadd@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 D568C8FC0A; Mon, 14 Nov 2011 19:44:45 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so7882349vcb.13 for ; Mon, 14 Nov 2011 11:44:45 -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=2PJIr2igY0hbEH5ANGQJlMDwUBKrMZzDMu+6aOyFSOY=; b=WiYxtz9UzdjkvPGvv3la71/EF6GKkaRzgx1wvmp1G+uY+B36tQnSKja82QGuG4zvhP lYwZ2tDmHM5t0+pf9lw9om4rYXkGxngDSubXB7bqXV2e24GlElD4pP+MkKPOFkiPcN4S lLFVCi7gotdlX4N8P0u9tfTfaaNe139EIALo0= MIME-Version: 1.0 Received: by 10.52.34.78 with SMTP id x14mr30455392vdi.122.1321299885220; Mon, 14 Nov 2011 11:44:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Mon, 14 Nov 2011 11:44:45 -0800 (PST) In-Reply-To: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> Date: Mon, 14 Nov 2011 11:44:45 -0800 X-Google-Sender-Auth: Pg3824gKLN9tR6VySqXxUBhsfPM Message-ID: From: Adrian Chadd To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Kientzle , Doug Barton , mike@karels.net, arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 19:44:46 -0000 I honestly think we have _much bigger_ things to try and fix before we worry about the layout of binaries in the directory hierarchy. Once we've sorted out things like virtualisation hooks for the installer and management, better package management and upgrade paths, module/kernel build sync, cross-compiled ports, non-root installation methods, etc, etc.. I think then we could look at this kind of thing. 2c, Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 20:15: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 14FBC106566C for ; Mon, 14 Nov 2011 20:15:59 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7A478FC12 for ; Mon, 14 Nov 2011 20:15:58 +0000 (UTC) Received: by yenl11 with SMTP id l11so1987029yen.13 for ; Mon, 14 Nov 2011 12:15:58 -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=3BiRwEoGSoWGLQXkaNSiwTZ0vQwO3P7BlM2sYKvFJWU=; b=ffTAmntD28pdgbTHzWoaR8P63ecJyyvYyMUd2f6EJ16TWZoKh/uQ4NJMwVUTvo2+Zm rzA1VG0QKCk0Boh1eGbQJECsQUESXms+iQ879cRga40fIysKntFXP+hSEzIs0kxj0Pfa DPvr4VeqmhnGmjeCsZZFE2zz1eM40QJYIN/LU= MIME-Version: 1.0 Received: by 10.68.28.66 with SMTP id z2mr16029578pbg.8.1321300425094; Mon, 14 Nov 2011 11:53:45 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Mon, 14 Nov 2011 11:53:45 -0800 (PST) In-Reply-To: References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> Date: Mon, 14 Nov 2011 11:53:45 -0800 X-Google-Sender-Auth: _TZiJdT-q-tfxDgOn-CWZaPQxUY Message-ID: From: mdf@FreeBSD.org To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Ed Schouten , freebsd-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: Mon, 14 Nov 2011 20:15:59 -0000 On Mon, Nov 14, 2011 at 11:44 AM, Adrian Chadd wrote: > I honestly think we have _much bigger_ things to try and fix before we > worry about the layout of binaries in the directory hierarchy. > > Once we've sorted out things like virtualisation hooks for the > installer and management, better package management and upgrade paths, > module/kernel build sync, cross-compiled ports, non-root installation > methods, etc, etc.. I think then we could look at this kind of thing. Except that Ed isn't volunteering to work on those; they don't scratch his itch. My personal and vendor perspective is that mostly I don't care where the utilities are. I'm not a sysadmin so I can't comment on that aspect of it. However, if we are voting, I'm cautiously in favor of Ed's proposal, simply because I like change that makes things simpler, regardless of the costs involved in a switch. Cheers, matthew From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 20:16: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 346D61065670; Mon, 14 Nov 2011 20:16:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D7CE68FC12; Mon, 14 Nov 2011 20:16:16 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pAEK2Buu031651; Mon, 14 Nov 2011 15:02:11 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Mon, 14 Nov 2011 15:02:11 -0500 (EST) Date: Mon, 14 Nov 2011 15:02:11 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Adrian Chadd In-Reply-To: Message-ID: References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , Doug Barton , mike@karels.net, Tim Kientzle , arch@freebsd.org, Robert Watson Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 20:16:17 -0000 On Mon, 14 Nov 2011, Adrian Chadd wrote: > I honestly think we have _much bigger_ things to try and fix before we > worry about the layout of binaries in the directory hierarchy. > > Once we've sorted out things like virtualisation hooks for the > installer and management, better package management and upgrade paths, > module/kernel build sync, cross-compiled ports, non-root installation > methods, etc, etc.. I think then we could look at this kind of thing. +1 And also how to stop double posts to the same list (freebsd-arch@ removed). -- DE From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 20:16: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 933F4106566C; Mon, 14 Nov 2011 20:16: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 560018FC16; Mon, 14 Nov 2011 20:16:20 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id BF6412A28CF0; Mon, 14 Nov 2011 21:16:19 +0100 (CET) Date: Mon, 14 Nov 2011 21:16:19 +0100 From: Ed Schouten To: Adrian Chadd Message-ID: <20111114201619.GD2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rWTGJt96jR0TCFDW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Tim Kientzle , Doug Barton , Robert Watson , mike@karels.net, 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: Mon, 14 Nov 2011 20:16:20 -0000 --rWTGJt96jR0TCFDW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Adrian, * Adrian Chadd , 20111114 20:44: > I honestly think we have _much bigger_ things to try and fix before we > worry about the layout of binaries in the directory hierarchy. Sorry for being a bit rude here, but such arguments can be applied to any work within the project. Some examples below: | I honestly think we have _much bigger_ things to try and fix before we | introduce support for yet another file system in the kernel that isn't | BSD licensed. | I honestly think we have _much bigger_ things to try and fix before we | introduce support for yet another security mechanism in the kernel | that has little usage by other pieces of software (yet). | I honestly think we have _much bigger_ things to try and fix before we | spend time fixing bugs in sh(1). And yet, people appreciate ZFS, Capsicum and the work jilles@ is doing on many of our base system utilities. Keep in mind that there are quite some people on the project who hack for fun -- not because their employer/contractor has some kind of agenda. --=20 Ed Schouten WWW: http://80386.nl/ --rWTGJt96jR0TCFDW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOwXcTAAoJEG5e2P40kaK7jPgP/Rf8Ceiwg31gB3eG8RBY0GZ0 R3wereAvt8bJVFaUPwzun61DWa/6d0qMQIsJa+hOhyNNJdd4lCSQYAmGpcbelYc8 hl7GG7M6aQFn7/HLZ15/JxV1bRCYRCLAsFKqnJu+uAcQWOhxvBhokXxNbiOu14+n hs1d4/YEnfMayvA7NpcJsbrXpFFGzQuSIPSDInol6m7etYJCxh10dAC984l7SYjf V3udYm8avghK7YRLjJyn0D8BvsaBL75DwJUt4jzcwIqGevFuQfQT9K+XvhpuB3WT PwFc2OvNPd8mtzsv4AOtk4kX+LSLytUs4xtmF7RHZnoldTjzkKixVW9Ishh/UFih g4W38nTcpH6igHIS4sLM2n/SMw6wjNdtEimsD/cX3OJaiASZBvbW8Lj+wNJrgBBg pa22ZWujsYA71vcnIv1GYXsujphoLASzBwLo6krLsuVJa6Chq1ZhOLTBrrfxT953 Pn/EREu8WRY0WAnfpuT37TbmxBqAn0B6pctscTqZ1nZs1iIAclvW30KhGyyf/00b 4FwhuhondCAJ34Dl8K8kI79py9PINjUzxKlpG3oImmkjaXnptc5iDT2TM0+KO2/V OoP1IN6oYQku7b02hJ27uavAHquo2bgsP2StYSnyv4idUy6RWuCkOXI0H8+kBf5m lmvFItZyHPDTWncyWgcU =eUZT -----END PGP SIGNATURE----- --rWTGJt96jR0TCFDW-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 21:34:53 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 A3F8E106566C; Mon, 14 Nov 2011 21:34:53 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF7D8FC14; Mon, 14 Nov 2011 21:34:53 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id pAELYncl047631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 22:34:49 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1321306489; bh=nDRQVpxsw2VFlW17kpHQOsUzODopE+2oBXLbgvYhEzk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=PfEWT6SSYrWBKu9wAEPDJ8FL4X49bpqRD5QS9kyXgzSNqo/XXjrqPQRN9pK6dQQnr d6eyaYsMAUNMhKDQKYUmSZ0wdXUwhPDsUCiXEfGGutW+HgZSxdG3BcX8UYg3ljonLz ErG4NBfMR2XcxeH1qi2KSfmlDkBWDf+352EQvcO4= Date: Mon, 14 Nov 2011 22:34:49 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Ed Schouten Message-ID: <20111114213448.GQ26743@acme.spoerlein.net> Mail-Followup-To: Ed Schouten , Doug Barton , arch@freebsd.org References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114092922.GA2164@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, Doug Barton 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: Mon, 14 Nov 2011 21:34:53 -0000 On Mon, 2011-11-14 at 10:29:22 +0100, Ed Schouten wrote: > Hi Doug, > > * Doug Barton , 20111113 23:57: > > If we're going to talk about making a change that's actually worth > > making, let's just move everything into / and get rid of /usr > > altogether. It served its purpose back when it came into being, but with > > modern disk sizes and the (unfortunate) prevalence of the "one big /" > > layout model, it's time in the sun is long past. > > Now that I think of it, it may be possible to sort of combine this with > my approach in a way that it doesn't break POLA for existing users. What > if we leave everything in the tree alone, but only modify the code, so > that any new installations on empty directory structures use the > following symlinks: > > - /sbin -> /bin > - /usr/bin -> /bin > - /usr/games -> /bin > - /usr/lib -> /lib > - /usr/sbin -> /bin Yes please, although it'll never happen :( Why can't we have all the base system in /bin, /lib, /etc with the usual /usr/src /usr/ports /usr/home /usr/compat and the kicker: have all ports install into /usr/bin and /usr/lib (yes, you read that right!) I know that /usr doesn't really stand for "user", so having these contain the third party apps that the user installed is a bit of a stretch, but it wouldn't be the first time in history that something changed its original meaning. (I left /usr/share and /usr/include as an exercise for the reader.) > But now the question remains how we should change the default > partitioning. I think default installations place home directories in > /usr/home, with a symlink from /home. Should they now be placed in > /usr/local/home? No please don't, any serious installations have their own /home partition anyway. Also in the past, deleting /usr/local only meant you lost all installed ports and /usr/local/etc -- something you usually can easily recover from. Not so if /usr/local/home is where your real data lies. Cheers, Uli From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 21:38:46 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 9F067106566C; Mon, 14 Nov 2011 21:38:46 +0000 (UTC) (envelope-from adrian.chadd@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 2F29E8FC17; Mon, 14 Nov 2011 21:38:45 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so8040368vcb.13 for ; Mon, 14 Nov 2011 13:38:45 -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=udLYd6FgTx9BvupgMLG7eRQal9SZPVyNWs6vbnLK0bc=; b=Hmb4N5awRJ2XCmMNGDY29/Nd64+FsMc/uf4f5Skh+RHG+LxAlglnMLbAmA/Bkb3OC4 aUNfc41XPuRQd8mCkSY65v6FNTEdz0n2MNM19huwFUU/yKbvzRzou7K2+SaKJTcqNHgi iKb84PzeF7RhP8ERwJsiNp6vFooXuKWPJHSvc= MIME-Version: 1.0 Received: by 10.52.34.78 with SMTP id x14mr31163708vdi.122.1321306725148; Mon, 14 Nov 2011 13:38:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Mon, 14 Nov 2011 13:38:45 -0800 (PST) In-Reply-To: <20111114201619.GD2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> <20111114201619.GD2164@hoeg.nl> Date: Mon, 14 Nov 2011 13:38:45 -0800 X-Google-Sender-Auth: mwCdQ3bfo5-1XHmA-bj3-sVPMQ4 Message-ID: From: Adrian Chadd To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Kientzle , Doug Barton , Robert Watson , mike@karels.net, 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: Mon, 14 Nov 2011 21:38:46 -0000 I don't mean to be rude either, but the cost-benefit ratio of something like ZFS and Capsicum versus tinkering with the layout of binaries in the filesystem should take someone about 30 seconds to evaluate. I'm not saying "let's not do it!" (quite the opposite - I mean, I still was hacking on squid until recently), but it's just looking at how many emails this topic gets versus others, I find it hard to believe the amount of brain cycles this thread COULD end up dedicating is .. well, very large. :-) Again, it's just my 2c, Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 21:45: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 6C6E91065673; Mon, 14 Nov 2011 21:45:06 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-dy0-f54.google.com (mail-dy0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id B1A528FC0C; Mon, 14 Nov 2011 21:45:04 +0000 (UTC) Received: by dyk29 with SMTP id 29so353678dyk.13 for ; Mon, 14 Nov 2011 13:45:03 -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=5iARt8c4w+85j4ynQiOCO+C506MYE0hcPhBiLVo6Nn4=; b=hljhuF6CPjDuRrGmr5KAwUbFEvuZIZo+yvMTCWMd6iRabDnMJIYoCkI8Gp6nc/RAd4 O6KzdvdNO9ISKRai1MMei3ZxxF/ONddD2w1/fsnHkgdvQHPLArJp+3j+gsMQ9gveaZW5 kok8YYMqlFn1jT+3as01EkjK3Q1Cqb10QLDVI= MIME-Version: 1.0 Received: by 10.182.12.66 with SMTP id w2mr2357539obb.7.1321307103286; Mon, 14 Nov 2011 13:45:03 -0800 (PST) Received: by 10.182.7.34 with HTTP; Mon, 14 Nov 2011 13:45:03 -0800 (PST) In-Reply-To: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> Date: Mon, 14 Nov 2011 13:45:03 -0800 Message-ID: From: Garrett Cooper To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tim Kientzle , Doug Barton , mike@karels.net, arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 21:45:06 -0000 On Mon, Nov 14, 2011 at 11:34 AM, Ed Schouten wrote: > Hello Robert, others, > > Before I get to the subject, please excuse me for not commenting on all > your emails individually. I am afraid that if I would do that, the > discussion will fragment. > > The first thing I noticed is that some of the emails mention that the > work I proposed was a solution searching for a problem. I have to > emphasize this is clearly not my intention. It was something that I > started to notice when I was working on the utmpx code in 2009, where > half of the utilities were stored in /usr/bin, while the others were > placed in /usr/sbin. The reason why I let it wait until now, is because > even though I was considering moving the tools around back then, I > realized that this causes major headaches for our users, because if they > don't run `make delete-old' (which isn't even described in the handbook, > by the way), they'll end up having two copies. I reasoned that > performing a merge of sbin to bin automatically fixes this. Combined > with the arguments that I gave in my opening email, I am under the > impression that this is something that we should consider. > > The reason why I brought it up last week, is because I got reminded of > the issue by seeing the Fedora discussion. So to summarize: the reason > why I proposed this, is _not_ because the Fedora folks think it's cool, > it's because work in this area was (is?) on my TODO list anyway. The > fact that the Fedora folks are also discussing this, was only a > confirmation for me that this is a point of discussion in a larger part > of UNIX-land -- not just FreeBSD. > > Now let me respond to Robert's email specifically, as it raises an > interesting point, which I already thought about, but had not > specifically mentioned in the introduction email. > > From now on, let us assume we're discussing the patchset I have sent to > the list initially -- not the discussion between Doug and I, where we > discussed a full merge into /bin and /lib. > > * Robert Watson , 20111114 18:48: >> Ditto. =A0I agree with Ed that it is more aesthetically pleasing and in >> keeping with the actual design principles we have, but it would be >> quite disruptive for downstream users. =A0Especially if the source tree >> is rearranged, since not all revision control systems (or import >> methods) take kindly to large-scale renaming of subtrees with >> substantial patches. =A0 > > So let us divide our users in two groups; regular users and vendors. > > Group 1: regular users > ---------------------- > In my opinion the patch isn't really disruptive for our end users. One > of the things that I don't want to do, is perform the merge of the > sbin and games directories automatically. This is because one small > error or assumption in our scripts can render many the system > unbootable. If it turns out we don't have anything to worry about, we > could eventually automate this through some means. If committed to SVN > in its current form, users will experience the following upgrade > procedure: > > - csup or svn up the source tree > - The user compiles the source, installs the kernel, reboots, etc. > - The user runs `make installworld', but it will simply print a message, > =A0asking the user to read /usr/src/UPDATING, which contains four simple > =A0shell commands that perform the merge. > - When done, the user runs `make installworld', which will now continue > =A0to work properly. > > So all in all this is a pretty simple procedure. The total overhead is > only four small shell commands on a single `make installworld'. Compared > to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say > the least. > > Group 2: vendors > ---------------- > So a pretty serious point that Robert raises, is that changes to source > tree layout are really irritating for our vendors. Now keep in mind that > I have mentioned nothing in particular about source tree layout. Even > though it would be a lot more consistent if those directories are merged > as well, I have not been promoting this. > > We could easily put the following policy in place: any new (or massively > rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in > src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories > are left the way they are. In other words: the directory src/usr.sbin/ > can be described as "applications that were historically installed in > /usr/sbin". > > So vendors shouldn't notice that much of the transition. They can just > build on top of our source tree the way they currently do. The only > merge conflicts they could experience, are lines of code where we > replace path names, but conflicts in that area are as likely as any > other changeset. > > I think this message covers most of the things I wanted to say for now. > I really hope we can continue this discussion in a fruitful manner. I > have noticed that even though there has been criticism, there have also > been many people that have expressed support for this work, both > privately and on the mailing list, so it would be nice if this > discussion actually leads to something useful. > > Just because certain aspects have so far not been worked out completely, > doesn't mean the idea as a whole is a bad thing. And if it turns out to > be a bad thing, then so be it. At least it has served as a lesson. Maybe > it's worth asking yourself this question: "say, we were to merge sbin > with bin, what kind of problems can we walk into and how should they be > resolved?" Having written a few shell scripts and debugging others' -- I can speak from experience and say that there are folks who do one of the following: 1. Hardcode paths to utilities (/usr/sbin/sysctl comes to mind). Maybe for optimization; maybe to avoid alias'ing, etc. 2. Use which / command -p / etc to divine where their binaries come from. 3. Hardcode PATH to a restricted path to ensure determinism. 4. Just dash it all and call commands without any predivined path. 5. People might have come up with tricky ways of determining real files from symlinks in their scripts or other programs in order to 'divine' their existence. 6. People have come up with interesting path overlaying; this is especially true in larger companies where there's 15+ years of development history, e.g. my previous employer. The difference between one binary and another is the difference between your application working and not working. Please be careful because I'm sure your changes are going to break items 1., 2., 5. and 6., which is going to break a lot of 3rd party scripts, binaries (vendor code like the mergepoint BMC update utilities), ports, and packages in inexplicable ways. Anyhow, back to your regularly scheduled bikeshed. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 21:45:06 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 6C6E91065673; Mon, 14 Nov 2011 21:45:06 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-dy0-f54.google.com (mail-dy0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id B1A528FC0C; Mon, 14 Nov 2011 21:45:04 +0000 (UTC) Received: by dyk29 with SMTP id 29so353678dyk.13 for ; Mon, 14 Nov 2011 13:45:03 -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=5iARt8c4w+85j4ynQiOCO+C506MYE0hcPhBiLVo6Nn4=; b=hljhuF6CPjDuRrGmr5KAwUbFEvuZIZo+yvMTCWMd6iRabDnMJIYoCkI8Gp6nc/RAd4 O6KzdvdNO9ISKRai1MMei3ZxxF/ONddD2w1/fsnHkgdvQHPLArJp+3j+gsMQ9gveaZW5 kok8YYMqlFn1jT+3as01EkjK3Q1Cqb10QLDVI= MIME-Version: 1.0 Received: by 10.182.12.66 with SMTP id w2mr2357539obb.7.1321307103286; Mon, 14 Nov 2011 13:45:03 -0800 (PST) Received: by 10.182.7.34 with HTTP; Mon, 14 Nov 2011 13:45:03 -0800 (PST) In-Reply-To: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> Date: Mon, 14 Nov 2011 13:45:03 -0800 Message-ID: From: Garrett Cooper To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tim Kientzle , Doug Barton , mike@karels.net, arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 21:45:06 -0000 On Mon, Nov 14, 2011 at 11:34 AM, Ed Schouten wrote: > Hello Robert, others, > > Before I get to the subject, please excuse me for not commenting on all > your emails individually. I am afraid that if I would do that, the > discussion will fragment. > > The first thing I noticed is that some of the emails mention that the > work I proposed was a solution searching for a problem. I have to > emphasize this is clearly not my intention. It was something that I > started to notice when I was working on the utmpx code in 2009, where > half of the utilities were stored in /usr/bin, while the others were > placed in /usr/sbin. The reason why I let it wait until now, is because > even though I was considering moving the tools around back then, I > realized that this causes major headaches for our users, because if they > don't run `make delete-old' (which isn't even described in the handbook, > by the way), they'll end up having two copies. I reasoned that > performing a merge of sbin to bin automatically fixes this. Combined > with the arguments that I gave in my opening email, I am under the > impression that this is something that we should consider. > > The reason why I brought it up last week, is because I got reminded of > the issue by seeing the Fedora discussion. So to summarize: the reason > why I proposed this, is _not_ because the Fedora folks think it's cool, > it's because work in this area was (is?) on my TODO list anyway. The > fact that the Fedora folks are also discussing this, was only a > confirmation for me that this is a point of discussion in a larger part > of UNIX-land -- not just FreeBSD. > > Now let me respond to Robert's email specifically, as it raises an > interesting point, which I already thought about, but had not > specifically mentioned in the introduction email. > > From now on, let us assume we're discussing the patchset I have sent to > the list initially -- not the discussion between Doug and I, where we > discussed a full merge into /bin and /lib. > > * Robert Watson , 20111114 18:48: >> Ditto. =A0I agree with Ed that it is more aesthetically pleasing and in >> keeping with the actual design principles we have, but it would be >> quite disruptive for downstream users. =A0Especially if the source tree >> is rearranged, since not all revision control systems (or import >> methods) take kindly to large-scale renaming of subtrees with >> substantial patches. =A0 > > So let us divide our users in two groups; regular users and vendors. > > Group 1: regular users > ---------------------- > In my opinion the patch isn't really disruptive for our end users. One > of the things that I don't want to do, is perform the merge of the > sbin and games directories automatically. This is because one small > error or assumption in our scripts can render many the system > unbootable. If it turns out we don't have anything to worry about, we > could eventually automate this through some means. If committed to SVN > in its current form, users will experience the following upgrade > procedure: > > - csup or svn up the source tree > - The user compiles the source, installs the kernel, reboots, etc. > - The user runs `make installworld', but it will simply print a message, > =A0asking the user to read /usr/src/UPDATING, which contains four simple > =A0shell commands that perform the merge. > - When done, the user runs `make installworld', which will now continue > =A0to work properly. > > So all in all this is a pretty simple procedure. The total overhead is > only four small shell commands on a single `make installworld'. Compared > to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say > the least. > > Group 2: vendors > ---------------- > So a pretty serious point that Robert raises, is that changes to source > tree layout are really irritating for our vendors. Now keep in mind that > I have mentioned nothing in particular about source tree layout. Even > though it would be a lot more consistent if those directories are merged > as well, I have not been promoting this. > > We could easily put the following policy in place: any new (or massively > rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in > src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories > are left the way they are. In other words: the directory src/usr.sbin/ > can be described as "applications that were historically installed in > /usr/sbin". > > So vendors shouldn't notice that much of the transition. They can just > build on top of our source tree the way they currently do. The only > merge conflicts they could experience, are lines of code where we > replace path names, but conflicts in that area are as likely as any > other changeset. > > I think this message covers most of the things I wanted to say for now. > I really hope we can continue this discussion in a fruitful manner. I > have noticed that even though there has been criticism, there have also > been many people that have expressed support for this work, both > privately and on the mailing list, so it would be nice if this > discussion actually leads to something useful. > > Just because certain aspects have so far not been worked out completely, > doesn't mean the idea as a whole is a bad thing. And if it turns out to > be a bad thing, then so be it. At least it has served as a lesson. Maybe > it's worth asking yourself this question: "say, we were to merge sbin > with bin, what kind of problems can we walk into and how should they be > resolved?" Having written a few shell scripts and debugging others' -- I can speak from experience and say that there are folks who do one of the following: 1. Hardcode paths to utilities (/usr/sbin/sysctl comes to mind). Maybe for optimization; maybe to avoid alias'ing, etc. 2. Use which / command -p / etc to divine where their binaries come from. 3. Hardcode PATH to a restricted path to ensure determinism. 4. Just dash it all and call commands without any predivined path. 5. People might have come up with tricky ways of determining real files from symlinks in their scripts or other programs in order to 'divine' their existence. 6. People have come up with interesting path overlaying; this is especially true in larger companies where there's 15+ years of development history, e.g. my previous employer. The difference between one binary and another is the difference between your application working and not working. Please be careful because I'm sure your changes are going to break items 1., 2., 5. and 6., which is going to break a lot of 3rd party scripts, binaries (vendor code like the mergepoint BMC update utilities), ports, and packages in inexplicable ways. Anyhow, back to your regularly scheduled bikeshed. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 21:57: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 055D1106564A; Mon, 14 Nov 2011 21:57:19 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 746BB8FC12; Mon, 14 Nov 2011 21:57:18 +0000 (UTC) Received: by qadb10 with SMTP id b10so2387264qad.13 for ; Mon, 14 Nov 2011 13:57:18 -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=T9Uo3axiuJbo5g3vhIHHR03cTEojxJVoMdQYvv6bmY0=; b=hZZJ/9QBZ3DYpp43Xe4YksZJ4o5JAeKmGVUvJ7gtBVm9UrXDm3KuiRuBGJE3Iwg32S 1lNFmSxoe+2oWtueUJFVp8ML9O8kq5dFTZ8MeMmPJ6yPj45ht/XB19zInWh2Scx57xSU Z2r5TZhXxiWeuBLUm6YJzPGxEkGfCI3ViAx2I= MIME-Version: 1.0 Received: by 10.224.215.73 with SMTP id hd9mr15797873qab.94.1321307837872; Mon, 14 Nov 2011 13:57:17 -0800 (PST) Received: by 10.224.73.195 with HTTP; Mon, 14 Nov 2011 13:57:17 -0800 (PST) In-Reply-To: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> Date: Mon, 14 Nov 2011 16:57:17 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Ed Schouten Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Tim Kientzle , Doug Barton , mike@karels.net, arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 21:57:19 -0000 On Mon, Nov 14, 2011 at 2:34 PM, Ed Schouten wrote: > Hello Robert, others, > > Before I get to the subject, please excuse me for not commenting on all > your emails individually. I am afraid that if I would do that, the > discussion will fragment. > > The first thing I noticed is that some of the emails mention that the > work I proposed was a solution searching for a problem. I have to > emphasize this is clearly not my intention. It was something that I > started to notice when I was working on the utmpx code in 2009, where > half of the utilities were stored in /usr/bin, while the others were > placed in /usr/sbin. The reason why I let it wait until now, is because > even though I was considering moving the tools around back then, I > realized that this causes major headaches for our users, because if they > don't run `make delete-old' (which isn't even described in the handbook, > by the way), they'll end up having two copies. I reasoned that > performing a merge of sbin to bin automatically fixes this. Combined > with the arguments that I gave in my opening email, I am under the > impression that this is something that we should consider. > > The reason why I brought it up last week, is because I got reminded of > the issue by seeing the Fedora discussion. So to summarize: the reason > why I proposed this, is _not_ because the Fedora folks think it's cool, > it's because work in this area was (is?) on my TODO list anyway. The > fact that the Fedora folks are also discussing this, was only a > confirmation for me that this is a point of discussion in a larger part > of UNIX-land -- not just FreeBSD. > > Now let me respond to Robert's email specifically, as it raises an > interesting point, which I already thought about, but had not > specifically mentioned in the introduction email. > > From now on, let us assume we're discussing the patchset I have sent to > the list initially -- not the discussion between Doug and I, where we > discussed a full merge into /bin and /lib. > > * Robert Watson , 20111114 18:48: > > Ditto. I agree with Ed that it is more aesthetically pleasing and in > > keeping with the actual design principles we have, but it would be > > quite disruptive for downstream users. Especially if the source tree > > is rearranged, since not all revision control systems (or import > > methods) take kindly to large-scale renaming of subtrees with > > substantial patches. > > So let us divide our users in two groups; regular users and vendors. > > Group 1: regular users > ---------------------- > In my opinion the patch isn't really disruptive for our end users. One > of the things that I don't want to do, is perform the merge of the > sbin and games directories automatically. This is because one small > error or assumption in our scripts can render many the system > unbootable. If it turns out we don't have anything to worry about, we > could eventually automate this through some means. If committed to SVN > in its current form, users will experience the following upgrade > procedure: > > - csup or svn up the source tree > - The user compiles the source, installs the kernel, reboots, etc. > - The user runs `make installworld', but it will simply print a message, > asking the user to read /usr/src/UPDATING, which contains four simple > shell commands that perform the merge. > - When done, the user runs `make installworld', which will now continue > to work properly. > > So all in all this is a pretty simple procedure. The total overhead is > only four small shell commands on a single `make installworld'. Compared > to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say > the least. > > Group 2: vendors > ---------------- > So a pretty serious point that Robert raises, is that changes to source > tree layout are really irritating for our vendors. Now keep in mind that > I have mentioned nothing in particular about source tree layout. Even > though it would be a lot more consistent if those directories are merged > as well, I have not been promoting this. > > We could easily put the following policy in place: any new (or massively > rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in > src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories > are left the way they are. In other words: the directory src/usr.sbin/ > can be described as "applications that were historically installed in > /usr/sbin". > > So vendors shouldn't notice that much of the transition. They can just > build on top of our source tree the way they currently do. The only > merge conflicts they could experience, are lines of code where we > replace path names, but conflicts in that area are as likely as any > other changeset. > > I think this message covers most of the things I wanted to say for now. > I really hope we can continue this discussion in a fruitful manner. I > have noticed that even though there has been criticism, there have also > been many people that have expressed support for this work, both > privately and on the mailing list, so it would be nice if this > discussion actually leads to something useful. > > Just because certain aspects have so far not been worked out completely, > doesn't mean the idea as a whole is a bad thing. And if it turns out to > be a bad thing, then so be it. At least it has served as a lesson. Maybe > it's worth asking yourself this question: "say, we were to merge sbin > with bin, what kind of problems can we walk into and how should they be > resolved?" > > Thanks, > -- > Ed Schouten > WWW: http://80386.nl/ I am not against any rearrangement in the executable directory contents , but there is one important problem . In Windows , any one installing a program which requires administrator privilege , stores anything they want into \Windows\... directories , even configuration files . This structure is making the so called operating system areas a real garbage bin : It is nearly impossible to maintain a clean operating system copy because of additional garbage where it is absolutely possible to store such files into another directory external to \Windows . My fear is that , in FreeBSD , combination of executables into a single directory will make it like the so called operating system ( impossible to maintain its integrity ) . Some time later , I will start to assemble an operating system from only permissive sources . My first candidate will be FreeBSD . My plan is as follows : Make /root directory in a ( SDHC ) DRIVE . Move all of the root usable binaries into /root/bin . Eliminate any super user possibility from user accounts or access to root related executables . When the root logs out , the /root drive will be removable . Allow root login when computer is booted . After login of a user , and logout , do NOT allow root login . Make /bin and other configuration , etc. files a ( SDHC ) DRIVE . Make /boot and its related parts a ( SDHC ) DRIVE . Make user definitions stored into a /users directory and in a ( SDHC ) DRIVE . Install ALL packages , ports etc. by ALL users into /usr in a ( SDHC ) DRIVE . Install ALL user directories in another Fixed disk DRIVE or external USB stick , SDHC cards , external hard disks ( by defining their platforms , drives in their user definitions ) and mount them by using their specified LABELs when the user logs . Do NOT use any global /tmp , for each user , use /home/user/tmp , for root /tmp in a ( fixed or external ) external hard disk or other kind of removable drive . Install a boot manager into a ( SDHC ) DRIVE to manage booting of required/wanted operating systems stored in ( SDHC ) DRIVEs , mountable by their LABELs , by scanning attached drives , generating loadable kernels menu from attached drives or from its fixed menu . After login of user , by using a global_fstab , generate a suitable fstab entries selection for the user . Scan all of the operating system sources , and define all of ( 1) the operating system file names ( 2 ) the package related file names into symbolic constant header files with their access mode kinds . Change all writable files to /home/*/tmp . /user/*/var , etc. , root related files to /root/var/ in a write-possible ( fixed ) hard disk . Make file access privileges more detailed and improve robustness of usage of files ( for example copy is possible , not possible ) . Include a suitable X version into base . Include a suitable window manager into base with properly defined menus ( not empty ) for operating system parts . Allow use of multiple monitors allocatable to console , window(s) , virtual terminal(s) . Improve package managers to allow installation of packages into user home directories when they are used by the users , into operating system related directories by the root in the producer computer to prepare ( SDHC) DRIVEs for the usable computers . REASON : - In school laboratories , public computing platform , and like places : Store ( SDHC ) DRIVES within the computer case as inaccessible by the users , therefore without any possible modification . Let the users to use their removable drives for their homes . - In safety critical applications : Maintain a computer to prepare the above mentioned parts , then attach them to other computers . Keep producer computer in a physically secure place . I have collected all related hardware . I am waiting the FreeBSD 9.0 Release to start study of the sources and make modifications one by one toward generation of an applicable version such as defined above . All over the years during computer usage , my most irritating disappointment is the invasion of our systems by the malicious software . Now I want to generate an operating system which will be physically unpenetrable . Such a physical arrangement will prevent operating system related software , parameter modifications , placement of malicious software into operating system areas . When security requirements are not fulfilled even a little more , any other arrangements will not be so attractive or important when the speeds of the present processors and hard drives ( conventional or SSD ) is extremely fast . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 22:09: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 09B5F1065674; Mon, 14 Nov 2011 22:09: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 CD60F8FC15; Mon, 14 Nov 2011 22:09:54 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 64B9D1A3C4A; Mon, 14 Nov 2011 14:09:54 -0800 (PST) Date: Mon, 14 Nov 2011 14:09:54 -0800 From: Alfred Perlstein To: Mehmet Erol Sanliturk Message-ID: <20111114220953.GE1455@elvis.mu.org> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> 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: Ed Schouten , Doug Barton , mike@karels.net, Tim Kientzle , arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 22:09:56 -0000 I'd just like to throw in my regular bit of sacrilege and ask if what we would be moving to would conform to any standard, perhaps a linux or sysv model, otherwise a departure from BSD "standards" to something totally new seems really unwise if all we are aiming to do is reduce the number of directories in $PATH. -Alfred * Mehmet Erol Sanliturk [111114 13:57] wrote: > On Mon, Nov 14, 2011 at 2:34 PM, Ed Schouten wrote: > > > Hello Robert, others, > > > > Before I get to the subject, please excuse me for not commenting on all > > your emails individually. I am afraid that if I would do that, the > > discussion will fragment. > > > > The first thing I noticed is that some of the emails mention that the > > work I proposed was a solution searching for a problem. I have to > > emphasize this is clearly not my intention. It was something that I > > started to notice when I was working on the utmpx code in 2009, where > > half of the utilities were stored in /usr/bin, while the others were > > placed in /usr/sbin. The reason why I let it wait until now, is because > > even though I was considering moving the tools around back then, I > > realized that this causes major headaches for our users, because if they > > don't run `make delete-old' (which isn't even described in the handbook, > > by the way), they'll end up having two copies. I reasoned that > > performing a merge of sbin to bin automatically fixes this. Combined > > with the arguments that I gave in my opening email, I am under the > > impression that this is something that we should consider. > > > > The reason why I brought it up last week, is because I got reminded of > > the issue by seeing the Fedora discussion. So to summarize: the reason > > why I proposed this, is _not_ because the Fedora folks think it's cool, > > it's because work in this area was (is?) on my TODO list anyway. The > > fact that the Fedora folks are also discussing this, was only a > > confirmation for me that this is a point of discussion in a larger part > > of UNIX-land -- not just FreeBSD. > > > > Now let me respond to Robert's email specifically, as it raises an > > interesting point, which I already thought about, but had not > > specifically mentioned in the introduction email. > > > > From now on, let us assume we're discussing the patchset I have sent to > > the list initially -- not the discussion between Doug and I, where we > > discussed a full merge into /bin and /lib. > > > > * Robert Watson , 20111114 18:48: > > > Ditto. I agree with Ed that it is more aesthetically pleasing and in > > > keeping with the actual design principles we have, but it would be > > > quite disruptive for downstream users. Especially if the source tree > > > is rearranged, since not all revision control systems (or import > > > methods) take kindly to large-scale renaming of subtrees with > > > substantial patches. > > > > So let us divide our users in two groups; regular users and vendors. > > > > Group 1: regular users > > ---------------------- > > In my opinion the patch isn't really disruptive for our end users. One > > of the things that I don't want to do, is perform the merge of the > > sbin and games directories automatically. This is because one small > > error or assumption in our scripts can render many the system > > unbootable. If it turns out we don't have anything to worry about, we > > could eventually automate this through some means. If committed to SVN > > in its current form, users will experience the following upgrade > > procedure: > > > > - csup or svn up the source tree > > - The user compiles the source, installs the kernel, reboots, etc. > > - The user runs `make installworld', but it will simply print a message, > > asking the user to read /usr/src/UPDATING, which contains four simple > > shell commands that perform the merge. > > - When done, the user runs `make installworld', which will now continue > > to work properly. > > > > So all in all this is a pretty simple procedure. The total overhead is > > only four small shell commands on a single `make installworld'. Compared > > to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say > > the least. > > > > Group 2: vendors > > ---------------- > > So a pretty serious point that Robert raises, is that changes to source > > tree layout are really irritating for our vendors. Now keep in mind that > > I have mentioned nothing in particular about source tree layout. Even > > though it would be a lot more consistent if those directories are merged > > as well, I have not been promoting this. > > > > We could easily put the following policy in place: any new (or massively > > rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in > > src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories > > are left the way they are. In other words: the directory src/usr.sbin/ > > can be described as "applications that were historically installed in > > /usr/sbin". > > > > So vendors shouldn't notice that much of the transition. They can just > > build on top of our source tree the way they currently do. The only > > merge conflicts they could experience, are lines of code where we > > replace path names, but conflicts in that area are as likely as any > > other changeset. > > > > I think this message covers most of the things I wanted to say for now. > > I really hope we can continue this discussion in a fruitful manner. I > > have noticed that even though there has been criticism, there have also > > been many people that have expressed support for this work, both > > privately and on the mailing list, so it would be nice if this > > discussion actually leads to something useful. > > > > Just because certain aspects have so far not been worked out completely, > > doesn't mean the idea as a whole is a bad thing. And if it turns out to > > be a bad thing, then so be it. At least it has served as a lesson. Maybe > > it's worth asking yourself this question: "say, we were to merge sbin > > with bin, what kind of problems can we walk into and how should they be > > resolved?" > > > > Thanks, > > -- > > Ed Schouten > > WWW: http://80386.nl/ > > > > I am not against any rearrangement in the executable directory contents , > but there is one important problem . > > In Windows , any one installing a program which requires administrator > privilege , > stores anything they want into \Windows\... directories , even > configuration files . > This structure is making the so called operating system areas a real > garbage bin : > > It is nearly impossible to maintain a clean operating system copy because of > additional garbage where it is absolutely possible to store such files into > another directory external to \Windows . > > My fear is that , in FreeBSD , combination of executables into a single > directory will make it like the so called operating system ( impossible to > maintain its integrity ) . > > > Some time later , I will start to assemble an operating system from only > permissive sources . My first candidate will be FreeBSD . > > My plan is as follows : > > Make /root directory in a ( SDHC ) DRIVE . Move all of the root usable > binaries into /root/bin . Eliminate any super user possibility from user > accounts or access to root related executables . > > > When the root logs out , the /root drive will be removable . > > Allow root login when computer is booted . After login of a user , and > logout , do NOT allow root login . > > > Make /bin and other configuration , etc. files a ( SDHC ) DRIVE . > > Make /boot and its related parts a ( SDHC ) DRIVE . > > Make user definitions stored into a /users directory and in a ( SDHC ) > DRIVE . > > Install ALL packages , ports etc. by ALL users into /usr in a ( SDHC ) > DRIVE . > > > Install ALL user directories in another Fixed disk DRIVE or external USB > stick , SDHC cards , external hard disks ( by defining their platforms , > drives in their user definitions ) and mount them by using their specified > LABELs when the user logs . > > Do NOT use any global /tmp , > for each user , use /home/user/tmp , > for root /tmp in a ( fixed or external ) external hard disk or other kind > of removable drive . > > Install a boot manager into a ( SDHC ) DRIVE to manage booting of > required/wanted > operating systems stored in ( SDHC ) DRIVEs , mountable by their LABELs , > by scanning attached drives , generating loadable kernels menu from > attached drives or from its fixed menu . > > > After login of user , by using a global_fstab , generate a suitable fstab > entries selection for the user . > > Scan all of the operating system sources , and define all of > ( 1) the operating system file names > ( 2 ) the package related file names > > into symbolic constant header files with their access mode kinds . > > Change all writable files to /home/*/tmp . /user/*/var , etc. , > root related files to /root/var/ in a write-possible ( fixed ) hard disk . > > Make file access privileges more detailed and improve robustness of usage > of files > ( for example copy is possible , not possible ) . > > Include a suitable X version into base . > Include a suitable window manager into base with properly defined menus ( > not empty ) for operating system parts . > > Allow use of multiple monitors allocatable to console , window(s) , virtual > terminal(s) . > > Improve package managers to allow installation of packages into user home > directories when they are used by the users , > into operating system related directories by the root in the producer > computer to prepare ( SDHC) DRIVEs for the usable computers . > > > REASON : > > - In school laboratories , public computing platform , and like places : > Store ( SDHC ) DRIVES within the computer case as inaccessible by the > users , therefore without any possible modification . Let the users to > use their removable drives for their homes . > > - In safety critical applications : Maintain a computer to prepare the > above mentioned parts , then attach them to other computers . Keep producer > computer in a physically secure place . > > > I have collected all related hardware . > I am waiting the FreeBSD 9.0 Release to start study of the sources and make > modifications one by one toward generation of an applicable version such as > defined above . > > > All over the years during computer usage , my most irritating > disappointment is the invasion of our systems by the malicious software . > Now I want to generate an operating system which will be physically > unpenetrable . > > > Such a physical arrangement will prevent operating system related software > , parameter modifications , placement of malicious software into operating > system areas . > > > When security requirements are not fulfilled even a little more , any other > arrangements will not be so attractive or important when the speeds of the > present processors and hard drives ( conventional or SSD ) is extremely > fast . > > Thank you very much . > > Mehmet Erol Sanliturk > _______________________________________________ > 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 Mon Nov 14 22:09: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 09B5F1065674; Mon, 14 Nov 2011 22:09: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 CD60F8FC15; Mon, 14 Nov 2011 22:09:54 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 64B9D1A3C4A; Mon, 14 Nov 2011 14:09:54 -0800 (PST) Date: Mon, 14 Nov 2011 14:09:54 -0800 From: Alfred Perlstein To: Mehmet Erol Sanliturk Message-ID: <20111114220953.GE1455@elvis.mu.org> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> 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: Ed Schouten , Doug Barton , mike@karels.net, Tim Kientzle , arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 22:09:56 -0000 I'd just like to throw in my regular bit of sacrilege and ask if what we would be moving to would conform to any standard, perhaps a linux or sysv model, otherwise a departure from BSD "standards" to something totally new seems really unwise if all we are aiming to do is reduce the number of directories in $PATH. -Alfred * Mehmet Erol Sanliturk [111114 13:57] wrote: > On Mon, Nov 14, 2011 at 2:34 PM, Ed Schouten wrote: > > > Hello Robert, others, > > > > Before I get to the subject, please excuse me for not commenting on all > > your emails individually. I am afraid that if I would do that, the > > discussion will fragment. > > > > The first thing I noticed is that some of the emails mention that the > > work I proposed was a solution searching for a problem. I have to > > emphasize this is clearly not my intention. It was something that I > > started to notice when I was working on the utmpx code in 2009, where > > half of the utilities were stored in /usr/bin, while the others were > > placed in /usr/sbin. The reason why I let it wait until now, is because > > even though I was considering moving the tools around back then, I > > realized that this causes major headaches for our users, because if they > > don't run `make delete-old' (which isn't even described in the handbook, > > by the way), they'll end up having two copies. I reasoned that > > performing a merge of sbin to bin automatically fixes this. Combined > > with the arguments that I gave in my opening email, I am under the > > impression that this is something that we should consider. > > > > The reason why I brought it up last week, is because I got reminded of > > the issue by seeing the Fedora discussion. So to summarize: the reason > > why I proposed this, is _not_ because the Fedora folks think it's cool, > > it's because work in this area was (is?) on my TODO list anyway. The > > fact that the Fedora folks are also discussing this, was only a > > confirmation for me that this is a point of discussion in a larger part > > of UNIX-land -- not just FreeBSD. > > > > Now let me respond to Robert's email specifically, as it raises an > > interesting point, which I already thought about, but had not > > specifically mentioned in the introduction email. > > > > From now on, let us assume we're discussing the patchset I have sent to > > the list initially -- not the discussion between Doug and I, where we > > discussed a full merge into /bin and /lib. > > > > * Robert Watson , 20111114 18:48: > > > Ditto. I agree with Ed that it is more aesthetically pleasing and in > > > keeping with the actual design principles we have, but it would be > > > quite disruptive for downstream users. Especially if the source tree > > > is rearranged, since not all revision control systems (or import > > > methods) take kindly to large-scale renaming of subtrees with > > > substantial patches. > > > > So let us divide our users in two groups; regular users and vendors. > > > > Group 1: regular users > > ---------------------- > > In my opinion the patch isn't really disruptive for our end users. One > > of the things that I don't want to do, is perform the merge of the > > sbin and games directories automatically. This is because one small > > error or assumption in our scripts can render many the system > > unbootable. If it turns out we don't have anything to worry about, we > > could eventually automate this through some means. If committed to SVN > > in its current form, users will experience the following upgrade > > procedure: > > > > - csup or svn up the source tree > > - The user compiles the source, installs the kernel, reboots, etc. > > - The user runs `make installworld', but it will simply print a message, > > asking the user to read /usr/src/UPDATING, which contains four simple > > shell commands that perform the merge. > > - When done, the user runs `make installworld', which will now continue > > to work properly. > > > > So all in all this is a pretty simple procedure. The total overhead is > > only four small shell commands on a single `make installworld'. Compared > > to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say > > the least. > > > > Group 2: vendors > > ---------------- > > So a pretty serious point that Robert raises, is that changes to source > > tree layout are really irritating for our vendors. Now keep in mind that > > I have mentioned nothing in particular about source tree layout. Even > > though it would be a lot more consistent if those directories are merged > > as well, I have not been promoting this. > > > > We could easily put the following policy in place: any new (or massively > > rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in > > src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories > > are left the way they are. In other words: the directory src/usr.sbin/ > > can be described as "applications that were historically installed in > > /usr/sbin". > > > > So vendors shouldn't notice that much of the transition. They can just > > build on top of our source tree the way they currently do. The only > > merge conflicts they could experience, are lines of code where we > > replace path names, but conflicts in that area are as likely as any > > other changeset. > > > > I think this message covers most of the things I wanted to say for now. > > I really hope we can continue this discussion in a fruitful manner. I > > have noticed that even though there has been criticism, there have also > > been many people that have expressed support for this work, both > > privately and on the mailing list, so it would be nice if this > > discussion actually leads to something useful. > > > > Just because certain aspects have so far not been worked out completely, > > doesn't mean the idea as a whole is a bad thing. And if it turns out to > > be a bad thing, then so be it. At least it has served as a lesson. Maybe > > it's worth asking yourself this question: "say, we were to merge sbin > > with bin, what kind of problems can we walk into and how should they be > > resolved?" > > > > Thanks, > > -- > > Ed Schouten > > WWW: http://80386.nl/ > > > > I am not against any rearrangement in the executable directory contents , > but there is one important problem . > > In Windows , any one installing a program which requires administrator > privilege , > stores anything they want into \Windows\... directories , even > configuration files . > This structure is making the so called operating system areas a real > garbage bin : > > It is nearly impossible to maintain a clean operating system copy because of > additional garbage where it is absolutely possible to store such files into > another directory external to \Windows . > > My fear is that , in FreeBSD , combination of executables into a single > directory will make it like the so called operating system ( impossible to > maintain its integrity ) . > > > Some time later , I will start to assemble an operating system from only > permissive sources . My first candidate will be FreeBSD . > > My plan is as follows : > > Make /root directory in a ( SDHC ) DRIVE . Move all of the root usable > binaries into /root/bin . Eliminate any super user possibility from user > accounts or access to root related executables . > > > When the root logs out , the /root drive will be removable . > > Allow root login when computer is booted . After login of a user , and > logout , do NOT allow root login . > > > Make /bin and other configuration , etc. files a ( SDHC ) DRIVE . > > Make /boot and its related parts a ( SDHC ) DRIVE . > > Make user definitions stored into a /users directory and in a ( SDHC ) > DRIVE . > > Install ALL packages , ports etc. by ALL users into /usr in a ( SDHC ) > DRIVE . > > > Install ALL user directories in another Fixed disk DRIVE or external USB > stick , SDHC cards , external hard disks ( by defining their platforms , > drives in their user definitions ) and mount them by using their specified > LABELs when the user logs . > > Do NOT use any global /tmp , > for each user , use /home/user/tmp , > for root /tmp in a ( fixed or external ) external hard disk or other kind > of removable drive . > > Install a boot manager into a ( SDHC ) DRIVE to manage booting of > required/wanted > operating systems stored in ( SDHC ) DRIVEs , mountable by their LABELs , > by scanning attached drives , generating loadable kernels menu from > attached drives or from its fixed menu . > > > After login of user , by using a global_fstab , generate a suitable fstab > entries selection for the user . > > Scan all of the operating system sources , and define all of > ( 1) the operating system file names > ( 2 ) the package related file names > > into symbolic constant header files with their access mode kinds . > > Change all writable files to /home/*/tmp . /user/*/var , etc. , > root related files to /root/var/ in a write-possible ( fixed ) hard disk . > > Make file access privileges more detailed and improve robustness of usage > of files > ( for example copy is possible , not possible ) . > > Include a suitable X version into base . > Include a suitable window manager into base with properly defined menus ( > not empty ) for operating system parts . > > Allow use of multiple monitors allocatable to console , window(s) , virtual > terminal(s) . > > Improve package managers to allow installation of packages into user home > directories when they are used by the users , > into operating system related directories by the root in the producer > computer to prepare ( SDHC) DRIVEs for the usable computers . > > > REASON : > > - In school laboratories , public computing platform , and like places : > Store ( SDHC ) DRIVES within the computer case as inaccessible by the > users , therefore without any possible modification . Let the users to > use their removable drives for their homes . > > - In safety critical applications : Maintain a computer to prepare the > above mentioned parts , then attach them to other computers . Keep producer > computer in a physically secure place . > > > I have collected all related hardware . > I am waiting the FreeBSD 9.0 Release to start study of the sources and make > modifications one by one toward generation of an applicable version such as > defined above . > > > All over the years during computer usage , my most irritating > disappointment is the invasion of our systems by the malicious software . > Now I want to generate an operating system which will be physically > unpenetrable . > > > Such a physical arrangement will prevent operating system related software > , parameter modifications , placement of malicious software into operating > system areas . > > > When security requirements are not fulfilled even a little more , any other > arrangements will not be so attractive or important when the speeds of the > present processors and hard drives ( conventional or SSD ) is extremely > fast . > > Thank you very much . > > Mehmet Erol Sanliturk > _______________________________________________ > 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 Mon Nov 14 22:57: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 30925106564A; Mon, 14 Nov 2011 22:57:33 +0000 (UTC) (envelope-from m.e.sanliturk@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 C06408FC13; Mon, 14 Nov 2011 22:57:32 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so8136253vcb.13 for ; Mon, 14 Nov 2011 14:57:32 -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=T9Uo3axiuJbo5g3vhIHHR03cTEojxJVoMdQYvv6bmY0=; b=hZZJ/9QBZ3DYpp43Xe4YksZJ4o5JAeKmGVUvJ7gtBVm9UrXDm3KuiRuBGJE3Iwg32S 1lNFmSxoe+2oWtueUJFVp8ML9O8kq5dFTZ8MeMmPJ6yPj45ht/XB19zInWh2Scx57xSU Z2r5TZhXxiWeuBLUm6YJzPGxEkGfCI3ViAx2I= MIME-Version: 1.0 Received: by 10.224.215.73 with SMTP id hd9mr15797873qab.94.1321307837872; Mon, 14 Nov 2011 13:57:17 -0800 (PST) Received: by 10.224.73.195 with HTTP; Mon, 14 Nov 2011 13:57:17 -0800 (PST) In-Reply-To: <20111114193434.GC2164@hoeg.nl> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> Date: Mon, 14 Nov 2011 16:57:17 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Ed Schouten Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Tim Kientzle , Doug Barton , mike@karels.net, arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 22:57:33 -0000 On Mon, Nov 14, 2011 at 2:34 PM, Ed Schouten wrote: > Hello Robert, others, > > Before I get to the subject, please excuse me for not commenting on all > your emails individually. I am afraid that if I would do that, the > discussion will fragment. > > The first thing I noticed is that some of the emails mention that the > work I proposed was a solution searching for a problem. I have to > emphasize this is clearly not my intention. It was something that I > started to notice when I was working on the utmpx code in 2009, where > half of the utilities were stored in /usr/bin, while the others were > placed in /usr/sbin. The reason why I let it wait until now, is because > even though I was considering moving the tools around back then, I > realized that this causes major headaches for our users, because if they > don't run `make delete-old' (which isn't even described in the handbook, > by the way), they'll end up having two copies. I reasoned that > performing a merge of sbin to bin automatically fixes this. Combined > with the arguments that I gave in my opening email, I am under the > impression that this is something that we should consider. > > The reason why I brought it up last week, is because I got reminded of > the issue by seeing the Fedora discussion. So to summarize: the reason > why I proposed this, is _not_ because the Fedora folks think it's cool, > it's because work in this area was (is?) on my TODO list anyway. The > fact that the Fedora folks are also discussing this, was only a > confirmation for me that this is a point of discussion in a larger part > of UNIX-land -- not just FreeBSD. > > Now let me respond to Robert's email specifically, as it raises an > interesting point, which I already thought about, but had not > specifically mentioned in the introduction email. > > From now on, let us assume we're discussing the patchset I have sent to > the list initially -- not the discussion between Doug and I, where we > discussed a full merge into /bin and /lib. > > * Robert Watson , 20111114 18:48: > > Ditto. I agree with Ed that it is more aesthetically pleasing and in > > keeping with the actual design principles we have, but it would be > > quite disruptive for downstream users. Especially if the source tree > > is rearranged, since not all revision control systems (or import > > methods) take kindly to large-scale renaming of subtrees with > > substantial patches. > > So let us divide our users in two groups; regular users and vendors. > > Group 1: regular users > ---------------------- > In my opinion the patch isn't really disruptive for our end users. One > of the things that I don't want to do, is perform the merge of the > sbin and games directories automatically. This is because one small > error or assumption in our scripts can render many the system > unbootable. If it turns out we don't have anything to worry about, we > could eventually automate this through some means. If committed to SVN > in its current form, users will experience the following upgrade > procedure: > > - csup or svn up the source tree > - The user compiles the source, installs the kernel, reboots, etc. > - The user runs `make installworld', but it will simply print a message, > asking the user to read /usr/src/UPDATING, which contains four simple > shell commands that perform the merge. > - When done, the user runs `make installworld', which will now continue > to work properly. > > So all in all this is a pretty simple procedure. The total overhead is > only four small shell commands on a single `make installworld'. Compared > to the /usr/X11R6 -> /usr/local migration, it should be trivial, to say > the least. > > Group 2: vendors > ---------------- > So a pretty serious point that Robert raises, is that changes to source > tree layout are really irritating for our vendors. Now keep in mind that > I have mentioned nothing in particular about source tree layout. Even > though it would be a lot more consistent if those directories are merged > as well, I have not been promoting this. > > We could easily put the following policy in place: any new (or massively > rewritten?) utilities installed in /bin or /usr/bin _must_ be placed in > src/bin/ and src/usr.bin/. The src/sbin/ and src/usr.sbin/ directories > are left the way they are. In other words: the directory src/usr.sbin/ > can be described as "applications that were historically installed in > /usr/sbin". > > So vendors shouldn't notice that much of the transition. They can just > build on top of our source tree the way they currently do. The only > merge conflicts they could experience, are lines of code where we > replace path names, but conflicts in that area are as likely as any > other changeset. > > I think this message covers most of the things I wanted to say for now. > I really hope we can continue this discussion in a fruitful manner. I > have noticed that even though there has been criticism, there have also > been many people that have expressed support for this work, both > privately and on the mailing list, so it would be nice if this > discussion actually leads to something useful. > > Just because certain aspects have so far not been worked out completely, > doesn't mean the idea as a whole is a bad thing. And if it turns out to > be a bad thing, then so be it. At least it has served as a lesson. Maybe > it's worth asking yourself this question: "say, we were to merge sbin > with bin, what kind of problems can we walk into and how should they be > resolved?" > > Thanks, > -- > Ed Schouten > WWW: http://80386.nl/ I am not against any rearrangement in the executable directory contents , but there is one important problem . In Windows , any one installing a program which requires administrator privilege , stores anything they want into \Windows\... directories , even configuration files . This structure is making the so called operating system areas a real garbage bin : It is nearly impossible to maintain a clean operating system copy because of additional garbage where it is absolutely possible to store such files into another directory external to \Windows . My fear is that , in FreeBSD , combination of executables into a single directory will make it like the so called operating system ( impossible to maintain its integrity ) . Some time later , I will start to assemble an operating system from only permissive sources . My first candidate will be FreeBSD . My plan is as follows : Make /root directory in a ( SDHC ) DRIVE . Move all of the root usable binaries into /root/bin . Eliminate any super user possibility from user accounts or access to root related executables . When the root logs out , the /root drive will be removable . Allow root login when computer is booted . After login of a user , and logout , do NOT allow root login . Make /bin and other configuration , etc. files a ( SDHC ) DRIVE . Make /boot and its related parts a ( SDHC ) DRIVE . Make user definitions stored into a /users directory and in a ( SDHC ) DRIVE . Install ALL packages , ports etc. by ALL users into /usr in a ( SDHC ) DRIVE . Install ALL user directories in another Fixed disk DRIVE or external USB stick , SDHC cards , external hard disks ( by defining their platforms , drives in their user definitions ) and mount them by using their specified LABELs when the user logs . Do NOT use any global /tmp , for each user , use /home/user/tmp , for root /tmp in a ( fixed or external ) external hard disk or other kind of removable drive . Install a boot manager into a ( SDHC ) DRIVE to manage booting of required/wanted operating systems stored in ( SDHC ) DRIVEs , mountable by their LABELs , by scanning attached drives , generating loadable kernels menu from attached drives or from its fixed menu . After login of user , by using a global_fstab , generate a suitable fstab entries selection for the user . Scan all of the operating system sources , and define all of ( 1) the operating system file names ( 2 ) the package related file names into symbolic constant header files with their access mode kinds . Change all writable files to /home/*/tmp . /user/*/var , etc. , root related files to /root/var/ in a write-possible ( fixed ) hard disk . Make file access privileges more detailed and improve robustness of usage of files ( for example copy is possible , not possible ) . Include a suitable X version into base . Include a suitable window manager into base with properly defined menus ( not empty ) for operating system parts . Allow use of multiple monitors allocatable to console , window(s) , virtual terminal(s) . Improve package managers to allow installation of packages into user home directories when they are used by the users , into operating system related directories by the root in the producer computer to prepare ( SDHC) DRIVEs for the usable computers . REASON : - In school laboratories , public computing platform , and like places : Store ( SDHC ) DRIVES within the computer case as inaccessible by the users , therefore without any possible modification . Let the users to use their removable drives for their homes . - In safety critical applications : Maintain a computer to prepare the above mentioned parts , then attach them to other computers . Keep producer computer in a physically secure place . I have collected all related hardware . I am waiting the FreeBSD 9.0 Release to start study of the sources and make modifications one by one toward generation of an applicable version such as defined above . All over the years during computer usage , my most irritating disappointment is the invasion of our systems by the malicious software . Now I want to generate an operating system which will be physically unpenetrable . Such a physical arrangement will prevent operating system related software , parameter modifications , placement of malicious software into operating system areas . When security requirements are not fulfilled even a little more , any other arrangements will not be so attractive or important when the speeds of the present processors and hard drives ( conventional or SSD ) is extremely fast . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 23:04:22 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 5ADAA106566C; Mon, 14 Nov 2011 23:04:22 +0000 (UTC) (envelope-from m.e.sanliturk@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 BD00E8FC0C; Mon, 14 Nov 2011 23:04:21 +0000 (UTC) Received: by vws11 with SMTP id 11so8181904vws.13 for ; Mon, 14 Nov 2011 15:04:21 -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=LgBGur0G2QiX++a1sSF8kNcbXaDlJQs9CEFw0UtBEIg=; b=Ucib1YFuFsmhMp3nKP5QDd92gk7f/+mWXzs1XoZMzmgxU/Ir8FVzRTk8MonA2qcJ5U Ibj1WIgy/ySPoXPE+/Iq4K1LbiIDSYHmhDuAdcYx+h21MzeF16gzNJwEK/9tRrvibOSG cD5qm7x+c9qpgMB8Eugh3wbOfW26o8EZnEKgA= MIME-Version: 1.0 Received: by 10.224.194.5 with SMTP id dw5mr15575617qab.16.1321311860997; Mon, 14 Nov 2011 15:04:20 -0800 (PST) Received: by 10.224.73.195 with HTTP; Mon, 14 Nov 2011 15:04:20 -0800 (PST) In-Reply-To: <20111114220953.GE1455@elvis.mu.org> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> <20111114220953.GE1455@elvis.mu.org> Date: Mon, 14 Nov 2011 18:04:20 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ed Schouten , Doug Barton , mike@karels.net, Tim Kientzle , arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 23:04:22 -0000 On Mon, Nov 14, 2011 at 5:09 PM, Alfred Perlstein wrote: > I'd just like to throw in my regular bit of sacrilege and ask > if what we would be moving to would conform to any standard, > perhaps a linux or sysv model, otherwise a departure from BSD > "standards" to something totally new seems really unwise if all > we are aiming to do is reduce the number of directories in $PATH. > > -Alfred > > * Mehmet Erol Sanliturk [111114 13:57] wrote: > > On Mon, Nov 14, 2011 at 2:34 PM, Ed Schouten wrote: > > > > > -- > > > Ed Schouten > > > WWW: http://80386.nl/ > > > > > > > > > > > Mehmet Erol Sanliturk > > -- > - Alfred Perlstein > .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 > .- FreeBSD committer > Please , notice that - Physical layout is different from logical layout . By proper mount statements it is possible to generate conventional FreeBSD directory layout from any physical layout . - Needs define tools . To stick to rules which does not fulfill requirements of needs causes change of the tools . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Mon Nov 14 23:04: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 5ADAA106566C; Mon, 14 Nov 2011 23:04:22 +0000 (UTC) (envelope-from m.e.sanliturk@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 BD00E8FC0C; Mon, 14 Nov 2011 23:04:21 +0000 (UTC) Received: by vws11 with SMTP id 11so8181904vws.13 for ; Mon, 14 Nov 2011 15:04:21 -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=LgBGur0G2QiX++a1sSF8kNcbXaDlJQs9CEFw0UtBEIg=; b=Ucib1YFuFsmhMp3nKP5QDd92gk7f/+mWXzs1XoZMzmgxU/Ir8FVzRTk8MonA2qcJ5U Ibj1WIgy/ySPoXPE+/Iq4K1LbiIDSYHmhDuAdcYx+h21MzeF16gzNJwEK/9tRrvibOSG cD5qm7x+c9qpgMB8Eugh3wbOfW26o8EZnEKgA= MIME-Version: 1.0 Received: by 10.224.194.5 with SMTP id dw5mr15575617qab.16.1321311860997; Mon, 14 Nov 2011 15:04:20 -0800 (PST) Received: by 10.224.73.195 with HTTP; Mon, 14 Nov 2011 15:04:20 -0800 (PST) In-Reply-To: <20111114220953.GE1455@elvis.mu.org> References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> <20111114220953.GE1455@elvis.mu.org> Date: Mon, 14 Nov 2011 18:04:20 -0500 Message-ID: From: Mehmet Erol Sanliturk To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ed Schouten , Doug Barton , mike@karels.net, Tim Kientzle , arch@freebsd.org, Robert Watson , freebsd-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: Mon, 14 Nov 2011 23:04:22 -0000 On Mon, Nov 14, 2011 at 5:09 PM, Alfred Perlstein wrote: > I'd just like to throw in my regular bit of sacrilege and ask > if what we would be moving to would conform to any standard, > perhaps a linux or sysv model, otherwise a departure from BSD > "standards" to something totally new seems really unwise if all > we are aiming to do is reduce the number of directories in $PATH. > > -Alfred > > * Mehmet Erol Sanliturk [111114 13:57] wrote: > > On Mon, Nov 14, 2011 at 2:34 PM, Ed Schouten wrote: > > > > > -- > > > Ed Schouten > > > WWW: http://80386.nl/ > > > > > > > > > > > Mehmet Erol Sanliturk > > -- > - Alfred Perlstein > .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 > .- FreeBSD committer > Please , notice that - Physical layout is different from logical layout . By proper mount statements it is possible to generate conventional FreeBSD directory layout from any physical layout . - Needs define tools . To stick to rules which does not fulfill requirements of needs causes change of the tools . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-arch@FreeBSD.ORG Tue Nov 15 01:13: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 D9D3C1065792 for ; Tue, 15 Nov 2011 01:13:35 +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 B73BA8FC12 for ; Tue, 15 Nov 2011 01:13:35 +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 pAF1DPBl068917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Nov 2011 17:13:26 -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 pAF1DPtl068916; Mon, 14 Nov 2011 17:13:25 -0800 (PST) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA04055; Mon, 14 Nov 11 17:04:32 PST Date: Tue, 15 Nov 2011 00:04:18 -0800 From: perryh@pluto.rain.com To: patfbsd@davenulle.org Message-Id: <4ec21d02.DIq3JznJ4WBtwCd7%perryh@pluto.rain.com> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> <20111114172609.1c2aeb0a@davenulle.org> In-Reply-To: <20111114172609.1c2aeb0a@davenulle.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: ed@80386.nl, freebsd-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: Tue, 15 Nov 2011 01:13:35 -0000 Patrick Lamaiziere wrote: > I would like to keep /usr/local for ports only. > When things are going wrong with ports it is sometimes > easier to rm -rf /usr/local and rebuild all from scratch. When using this approach -- which I agree makes sense -- where should one put truly local (non-ports) executables (/usr/local/bin and /usr/local/sbin being reserved for ports executables)? From owner-freebsd-arch@FreeBSD.ORG Tue Nov 15 10:35:22 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 8CA1C106564A for ; Tue, 15 Nov 2011 10:35:22 +0000 (UTC) (envelope-from pcthegreat@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 49F638FC08 for ; Tue, 15 Nov 2011 10:35:22 +0000 (UTC) Received: by ggnk3 with SMTP id k3so10282781ggn.13 for ; Tue, 15 Nov 2011 02:35:21 -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:cc :content-type; bh=HT2tVcHOR6+UNfSl6r+j5hw4Nxge5Sz9+3z+aFUq21M=; b=SXLwsWw5xyGOKzMQ7+E09sb8IMFM6qZ9I05ZX9s0yLRX3gqOLHW7raP6hBx4Pe0hL1 choXWhhLF4LnJBD1FzmKBVV1oObFFil9D1fO8Y6WzbBgqralcepIbpTyI2PX86QuSds4 U3ZEjZt7jy4+aIFJM9EgJMvl0n8sVuLSi+rx0= MIME-Version: 1.0 Received: by 10.68.38.169 with SMTP id h9mt71183409pbk.113.1321351561362; Tue, 15 Nov 2011 02:06:01 -0800 (PST) Received: by 10.68.44.65 with HTTP; Tue, 15 Nov 2011 02:06:01 -0800 (PST) In-Reply-To: <4ec21d02.DIq3JznJ4WBtwCd7%perryh@pluto.rain.com> References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> <20111114172609.1c2aeb0a@davenulle.org> <4ec21d02.DIq3JznJ4WBtwCd7%perryh@pluto.rain.com> Date: Tue, 15 Nov 2011 14:06:01 +0400 Message-ID: From: selven Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ed@80386.nl, patfbsd@davenulle.org, freebsd-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: Tue, 15 Nov 2011 10:35:22 -0000 It does makes sense, but over the years people have gotten used to it, wrote scripts that assumed certain things to be in /sbin while some to be at /bin .. wouldn't the mere action of discussing about whether we should do it some other way when it the gain is not the great be called as bike shedding? On Tue, Nov 15, 2011 at 12:04 PM, wrote: > Patrick Lamaiziere wrote: > > > I would like to keep /usr/local for ports only. > > When things are going wrong with ports it is sometimes > > easier to rm -rf /usr/local and rebuild all from scratch. > > When using this approach -- which I agree makes sense -- > where should one put truly local (non-ports) executables > (/usr/local/bin and /usr/local/sbin being reserved for > ports executables)? > _______________________________________________ > 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" > -- *Pirabarlen Cheenaramen *| $3|v3n* * /*memory is like prison*/ (user==selven)?free(user):user=malloc(sizeof(brain)); P Save electricity & disk space. Cat this mail to >/dev/null 2>&1 after use. From owner-freebsd-arch@FreeBSD.ORG Tue Nov 15 15:14: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 CCFD1106566B for ; Tue, 15 Nov 2011 15:14:23 +0000 (UTC) (envelope-from pcthegreat@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1458FC18 for ; Tue, 15 Nov 2011 15:14:23 +0000 (UTC) Received: by pzk33 with SMTP id 33so31453900pzk.3 for ; Tue, 15 Nov 2011 07:14:23 -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=Y/SxTBSxoxYh1z1zJX90zdrPRVT2a0LxIrIWC1h++DA=; b=t22l6SOC+fY2Ou9gKp8tqhtQctILyiwf0JBJQ7IBGqqPp36VimIQVK5X44/QYGysWQ C5U8gZJUtT6oR3OwENIyKSIiFgtruFpNigaV60q1vyzAW71cU7KgXLW7jrO6jucYksLe 8B2lJXp/462XuyzGwuwaMAIbvJozRHonUQ/jo= MIME-Version: 1.0 Received: by 10.68.209.9 with SMTP id mi9mr19332480pbc.62.1321370062552; Tue, 15 Nov 2011 07:14:22 -0800 (PST) Received: by 10.68.44.65 with HTTP; Tue, 15 Nov 2011 07:14:22 -0800 (PST) In-Reply-To: References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> <4EBF0003.3060401@FreeBSD.org> <20111113091940.GX2164@hoeg.nl> <4EC04B65.4030801@FreeBSD.org> <20111114092922.GA2164@hoeg.nl> <20111114172609.1c2aeb0a@davenulle.org> <4ec21d02.DIq3JznJ4WBtwCd7%perryh@pluto.rain.com> Date: Tue, 15 Nov 2011 19:14:22 +0400 Message-ID: From: selven To: selven Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ed@80386.nl, patfbsd@davenulle.org, freebsd-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: Tue, 15 Nov 2011 15:14:23 -0000 My excuse for the poor english : 'inebriated' It does makes sense, but over the years people have gotten used to it, wrote scripts that assumed certain things to be in /sbin while some to be at /bin .. wouldn't the mere action of discussing about whether we should do it some other way when the gain is not that great, be called as bike shedding? On Tue, Nov 15, 2011 at 2:06 PM, selven wrote: > It does makes sense, but over the years people have gotten used to it, > wrote scripts that assumed certain things to be in /sbin while some to be > at /bin .. wouldn't the mere action of discussing about whether we should > do it some other way when it the gain is not the great be called as bike > shedding? > > > > On Tue, Nov 15, 2011 at 12:04 PM, wrote: > >> Patrick Lamaiziere wrote: >> >> > I would like to keep /usr/local for ports only. >> > When things are going wrong with ports it is sometimes >> > easier to rm -rf /usr/local and rebuild all from scratch. >> >> When using this approach -- which I agree makes sense -- >> where should one put truly local (non-ports) executables >> (/usr/local/bin and /usr/local/sbin being reserved for >> ports executables)? >> _______________________________________________ >> 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" >> > > > > -- > *Pirabarlen Cheenaramen *| $3|v3n* * > /*memory is like prison*/ > (user==selven)?free(user):user=malloc(sizeof(brain)); > P Save electricity & disk space. Cat this mail to >/dev/null 2>&1 after > use. > > -- *Pirabarlen Cheenaramen *| $3|v3n* * L'escalier mobile: +230 49 24 918 email: pcthegeat@gmail.com || god@hackers.mu contact: http://godifiy.me /*memory is like prison*/ (user==selven)?free(user):user=malloc(sizeof(brain)); P Save electricity & disk space. Cat this mail to >/dev/null 2>&1 after use. From owner-freebsd-arch@FreeBSD.ORG Tue Nov 15 20:20: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 8E75C106564A for ; Tue, 15 Nov 2011 20:20:48 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB518FC1D for ; Tue, 15 Nov 2011 20:20:47 +0000 (UTC) Received: from gilead.netel.rpi.edu (gilead.netel.rpi.edu [128.113.124.121]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id pAFKKj6q032705; Tue, 15 Nov 2011 15:20:46 -0500 Message-ID: <4EC2C99D.3090800@FreeBSD.org> Date: Tue, 15 Nov 2011 15:20:45 -0500 From: Garance A Drosehn User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <201111140101.pAE11XEa067064@mail.karels.net> <201111140802.13355.jhb@freebsd.org> <20111114193434.GC2164@hoeg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 3.10 (***) [Hold at 12.00] APOSTROPHE_OBFUSCATION, COMBINED_FROM, J_CHICKENPOX_53, RATWARE_GECKO_BUILD X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.228 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: Tue, 15 Nov 2011 20:20:48 -0000 On 11/14/11 4:45 PM, Garrett Cooper wrote: >> Just because certain aspects have so far not been worked out completely, >> doesn't mean the idea as a whole is a bad thing. And if it turns out to >> be a bad thing, then so be it. At least it has served as a lesson. Maybe >> it's worth asking yourself this question: "say, we were to merge sbin >> with bin, what kind of problems can we walk into and how should they be >> resolved?" >> > Having written a few shell scripts and debugging others' -- I can > speak from experience and say that there are folks who do one of the > following: > > 1. Hardcode paths to utilities (/usr/sbin/sysctl comes to mind). Maybe > for optimization; maybe to avoid alias'ing, etc. > 2. Use which / command -p / etc to divine where their binaries come from. > 3. Hardcode PATH to a restricted path to ensure determinism. > 4. Just dash it all and call commands without any predivined path. > 5. People might have come up with tricky ways of determining real > files from symlinks in their scripts or other programs in order to > 'divine' their existence. > 6. People have come up with interesting path overlaying; this is > especially true in larger companies where there's 15+ years of > development history, e.g. my previous employer. The difference between > one binary and another is the difference between your application > working and not working. > > Please be careful because I'm sure your changes are going to break > items 1., 2., 5. and 6., which is going to break a lot of 3rd party > scripts, binaries (vendor code like the mergepoint BMC update > utilities), ports, and packages in inexplicable ways. > > Anyhow, back to your regularly scheduled bikeshed. > I agree completely with all the concerns listed by Garrett. There are a lot of changes which might be nice if we were starting from scratch, but which at this point would require much more work than they're worth. I expect this is one of those changes. I expect that because I don't see this as producing enough benefit for all the disruption and mysterious failures it will cause. If this change breaks some autoconf script, for instance, that will disrupt and distress a lot of end users who ARE NOT DEVELOPERS, and it also will piss off all the 3rd party developers who will be told to stop whatever they were working on just because the FreeBSD project wanted to shuffle around the location of a lot of binaries. And there's absolutely no way that you can convince me that ever single poorly-written-but-working autoconf script will work correctly after making a change as disruptive as the one you propose. I've spent too many years debugging scripts which made important decisions based on utterly stupid criteria which just-happened to work. This might be a project which is done gradually over a few years, but it is not something which must be committed to right now as some high-priority project. I'll pick red for this bikeshed, because that's what our users will be seeing if we rush into a mass migration of all of sbin. IMO. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Nov 16 17:56:04 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 CCF8C1065670; Wed, 16 Nov 2011 17:56:04 +0000 (UTC) (envelope-from rmh.aybabtu@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 708378FC16; Wed, 16 Nov 2011 17:56:04 +0000 (UTC) Received: by iakl21 with SMTP id l21so1361252iak.13 for ; Wed, 16 Nov 2011 09:56:03 -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:cc:content-type; bh=kwR8P3jzT3WihS41hugqBDDN/+fdezlS87ibzEQbTMw=; b=NvMWQ2jG+6lKGCWJThA9XigC9nn8AMN/IGqi8D7nv8KxGTs0sbvpAboxbJkDjohdle CkUcmXo2X1uFKGHKZI5oU825cPICU3MYBc8ZIrMYz/aG6JOTw4jlcsbaVFctYKH7J0/j drvSYYSQqDK6Q3VzPmcPk4iuJhVNse2akyNyw= MIME-Version: 1.0 Received: by 10.42.135.69 with SMTP id o5mr33096228ict.34.1321464435209; Wed, 16 Nov 2011 09:27:15 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Wed, 16 Nov 2011 09:27:15 -0800 (PST) Date: Wed, 16 Nov 2011 18:27:15 +0100 X-Google-Sender-Auth: g_ZVFk04DyEWnpXFv4YxJp4aN6o Message-ID: From: Robert Millan To: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=90e6ba6e836c3e770904b1dd6a9a Cc: Kostik Belousov , Adrian Chadd Subject: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 16 Nov 2011 17:56:04 -0000 --90e6ba6e836c3e770904b1dd6a9a Content-Type: text/plain; charset=UTF-8 Hi! Out of the kernel headers that are installed in /usr/include/ hierracy, there are some which include support multiple operating systems (usually FreeBSD and other *BSD flavours). This patch adds support to detect GNU/kFreeBSD as well. In all cases, we match the same declarations as FreeBSD does (which is to be expected in kernel headers, since both systems share the same kernel). Does it look fine? --90e6ba6e836c3e770904b1dd6a9a Content-Type: text/x-diff; charset=US-ASCII; name="gnu-kfreebsd_headers.diff" Content-Disposition: attachment; filename="gnu-kfreebsd_headers.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv2lkl460 ZGlmZiAtdXIgc3lzLm9sZC9jYW0vc2NzaS9zY3NpX2xvdy5oIHN5cy9jYW0vc2NzaS9zY3NpX2xv dy5oCi0tLSBzeXMub2xkL2NhbS9zY3NpL3Njc2lfbG93LmgJMjAwNy0xMi0yNSAxODo1MjowMi4w MDAwMDAwMDAgKzAxMDAKKysrIHN5cy9jYW0vc2NzaS9zY3NpX2xvdy5oCTIwMTEtMTEtMTMgMTQ6 MTI6NDEuMTIxOTA4MzgwICswMTAwCkBAIC01Myw3ICs1Myw3IEBACiAjZGVmaW5lCVNDU0lfTE9X X0lOVEVSRkFDRV9YUwogI2VuZGlmCS8qIF9fTmV0QlNEX18gKi8KIAotI2lmZGVmCV9fRnJlZUJT RF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVs X18pCiAjZGVmaW5lCVNDU0lfTE9XX0lOVEVSRkFDRV9DQU0KICNkZWZpbmUJQ0FNCiAjZW5kaWYJ LyogX19GcmVlQlNEX18gKi8KQEAgLTY0LDcgKzY0LDcgQEAKICNpbmNsdWRlIDxkZXYvaXNhL2Nj YnF1ZS5oPgogI2VuZGlmCS8qIF9fTmV0QlNEX18gKi8KIAotI2lmZGVmCV9fRnJlZUJTRF9fCisj aWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiAj aW5jbHVkZSA8c3lzL2RldmljZV9wb3J0Lmg+CiAjaW5jbHVkZSA8c3lzL2tkYi5oPgogI2luY2x1 ZGUgPGNhbS9jYW0uaD4KQEAgLTg1LDcgKzg1LDcgQEAKICNkZWZpbmUJU0NTSV9MT1dfQlpFUk8o cHQsIHNpemUpCW1lbXNldCgocHQpLCAwLCAoc2l6ZSkpCiAjZW5kaWYJLyogX19OZXRCU0RfXyAq LwogCi0jaWZkZWYJX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICN1bmRlZglNU0dfSURFTlRJRlkKICNkZWZpbmUJU0NT SV9MT1dfREVCVUdHRVIoZGV2KQlrZGJfZW50ZXIoS0RCX1dIWV9DQU0sIGRldikKICNkZWZpbmUJ U0NTSV9MT1dfREVMQVkobXUpCURFTEFZKChtdSkpCkBAIC0xMTEsNyArMTExLDcgQEAKIH07CiAj ZW5kaWYJLyogX19OZXRCU0RfXyAqLwogCi0jaWZkZWYJX19GcmVlQlNEX18KKyNpZiBkZWZpbmVk KF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHR5cGVkZWYJc3Ry dWN0IHNjc2lfc2Vuc2VfZGF0YSBzY3NpX2xvd19vc2RlcF9zZW5zZV9kYXRhX3Q7CiAKIHN0cnVj dCBzY3NpX2xvd19vc2RlcF9pbnRlcmZhY2UgewpkaWZmIC11ciBzeXMub2xkL2NhbS9zY3NpL3Nj c2lfbG93X3Bpc2EuaCBzeXMvY2FtL3Njc2kvc2NzaV9sb3dfcGlzYS5oCi0tLSBzeXMub2xkL2Nh bS9zY3NpL3Njc2lfbG93X3Bpc2EuaAkyMDA1LTAxLTA1IDIzOjM0OjM3LjAwMDAwMDAwMCArMDEw MAorKysgc3lzL2NhbS9zY3NpL3Njc2lfbG93X3Bpc2EuaAkyMDExLTExLTEzIDE0OjEyOjQxLjEy MTkwODM4MCArMDEwMApAQCAtNDAsNyArNDAsNyBAQAogaW50IHNjc2lfbG93X25vdGlmeV9waXNh KHBpc2FfZGV2aWNlX2hhbmRsZV90LCBwaXNhX2V2ZW50X3QpOwogI2VuZGlmCS8qIF9fTmV0QlNE X18gKi8KIAotI2lmZGVmCV9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwg ZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBpbnQgc2NzaV9sb3dfYWN0aXZhdGVfcGlzYShz dHJ1Y3Qgc2NzaV9sb3dfc29mdGMgKiwgaW50KTsKIGludCBzY3NpX2xvd19kZWFjdGl2YXRlX3Bp c2Eoc3RydWN0IHNjc2lfbG93X3NvZnRjICopOwogI2VuZGlmCS8qIF9fRnJlZUJTRF9fICovCmRp ZmYgLXVyIHN5cy5vbGQvY29udHJpYi9hbHRxL2FsdHEvYWx0cV92YXIuaCBzeXMvY29udHJpYi9h bHRxL2FsdHEvYWx0cV92YXIuaAotLS0gc3lzLm9sZC9jb250cmliL2FsdHEvYWx0cS9hbHRxX3Zh ci5oCTIwMTEtMDMtMTAgMTk6NDk6MTUuMDAwMDAwMDAwICswMTAwCisrKyBzeXMvY29udHJpYi9h bHRxL2FsdHEvYWx0cV92YXIuaAkyMDExLTExLTEzIDE0OjEyOjQxLjExODkwNzM0MSArMDEwMApA QCAtMjAxLDcgKzIwMSw3IEBACiAjZGVmaW5lCUNBTExPVVRfU1RPUChjKQkJdW50aW1lb3V0KChj KS0+Y19mdW5jLChjKS0+Y19hcmcpCiAjZGVmaW5lCUNBTExPVVRfSU5JVElBTElaRVIJeyBOVUxM LCBOVUxMIH0KICNlbmRpZgotI2lmICFkZWZpbmVkKF9fRnJlZUJTRF9fKQorI2lmICFkZWZpbmVk KF9fRnJlZUJTRF9fKSAmJiAhZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiB0eXBlZGVmIHZv aWQgKHRpbWVvdXRfdCkodm9pZCAqKTsKICNlbmRpZgogCmRpZmYgLXVyIHN5cy5vbGQvY29udHJp Yi9hbHRxL2FsdHEvaWZfYWx0cS5oIHN5cy9jb250cmliL2FsdHEvYWx0cS9pZl9hbHRxLmgKLS0t IHN5cy5vbGQvY29udHJpYi9hbHRxL2FsdHEvaWZfYWx0cS5oCTIwMTEtMDMtMTAgMTk6NDk6MTUu MDAwMDAwMDAwICswMTAwCisrKyBzeXMvY29udHJpYi9hbHRxL2FsdHEvaWZfYWx0cS5oCTIwMTEt MTEtMTMgMTQ6MTI6NDEuMTE5OTA3MTI4ICswMTAwCkBAIC0yOSw3ICsyOSw3IEBACiAjaWZuZGVm IF9BTFRRX0lGX0FMVFFfSF8KICNkZWZpbmUJX0FMVFFfSUZfQUxUUV9IXwogCi0jaWZkZWYgX19G cmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9r ZXJuZWxfXykKICNpbmNsdWRlIDxzeXMvbG9jay5oPgkJLyogWFhYICovCiAjaW5jbHVkZSA8c3lz L211dGV4Lmg+CQkvKiBYWFggKi8KICNpbmNsdWRlIDxzeXMvZXZlbnQuaD4JCS8qIFhYWCAqLwpA QCAtNTEsNyArNTEsNyBAQAogCWludAlpZnFfbGVuOwogCWludAlpZnFfbWF4bGVuOwogCWludAlp ZnFfZHJvcHM7Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8 fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIAlzdHJ1Y3QJbXR4IGlmcV9tdHg7CiAjZW5k aWYKIApkaWZmIC11ciBzeXMub2xkL2NvbnRyaWIvcGYvbmV0L2lmX3BmbG9nLmggc3lzL2NvbnRy aWIvcGYvbmV0L2lmX3BmbG9nLmgKLS0tIHN5cy5vbGQvY29udHJpYi9wZi9uZXQvaWZfcGZsb2cu aAkyMDExLTA2LTI4IDEzOjU3OjI1LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2NvbnRyaWIvcGYv bmV0L2lmX3BmbG9nLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xMzA5MDY0NjkgKzAxMDAKQEAgLTMw LDcgKzMwLDcgQEAKICNkZWZpbmUJUEZMT0dJRlNfTUFYCTE2CiAKIHN0cnVjdCBwZmxvZ19zb2Z0 YyB7Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIAlzdHJ1Y3QgaWZuZXQJCSpzY19pZnA7CS8qIHRoZSBp bnRlcmZhY2UgcG9pbnRlciAqLwogI2Vsc2UKIAlzdHJ1Y3QgaWZuZXQJCXNjX2lmOwkJLyogdGhl IGludGVyZmFjZSAqLwpAQCAtNzQsNyArNzQsNyBAQAogI2RlZmluZQlPTERfUEZMT0dfSERSTEVO CXNpemVvZihzdHJ1Y3Qgb2xkX3BmbG9naGRyKQogCiAjaWZkZWYgX0tFUk5FTAotI2lmZGVmIF9f RnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rf a2VybmVsX18pCiBzdHJ1Y3QgcGZfcnVsZTsKIHN0cnVjdCBwZl9ydWxlc2V0Owogc3RydWN0IHBm aV9raWY7CmRpZmYgLXVyIHN5cy5vbGQvY29udHJpYi9wZi9uZXQvaWZfcGZsb3cuaCBzeXMvY29u dHJpYi9wZi9uZXQvaWZfcGZsb3cuaAotLS0gc3lzLm9sZC9jb250cmliL3BmL25ldC9pZl9wZmxv dy5oCTIwMTEtMDYtMjggMTM6NTc6MjUuMDAwMDAwMDAwICswMjAwCisrKyBzeXMvY29udHJpYi9w Zi9uZXQvaWZfcGZsb3cuaAkyMDExLTExLTEzIDE0OjEyOjQxLjEzMDkwNjQ2OSArMDEwMApAQCAt NjYsNyArNjYsNyBAQAogCXVuc2lnbmVkIGludAkJIHNjX21heGNvdW50OwogCXVfaW50NjRfdAkJ IHNjX2djb3VudGVyOwogCXN0cnVjdCBpcF9tb3B0aW9ucwkgc2NfaW1vOwotI2lmZGVmIF9fRnJl ZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2Vy bmVsX18pCiAJc3RydWN0IGNhbGxvdXQJCSBzY190bW87CiAjZWxzZQogCXN0cnVjdCB0aW1lb3V0 CQkgc2NfdG1vOwpkaWZmIC11ciBzeXMub2xkL2NvbnRyaWIvcGYvbmV0L2lmX3Bmc3luYy5oIHN5 cy9jb250cmliL3BmL25ldC9pZl9wZnN5bmMuaAotLS0gc3lzLm9sZC9jb250cmliL3BmL25ldC9p Zl9wZnN5bmMuaAkyMDExLTA2LTI4IDEzOjU3OjI1LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2Nv bnRyaWIvcGYvbmV0L2lmX3Bmc3luYy5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTMxOTA2MjU3ICsw MTAwCkBAIC0yNjgsNyArMjY4LDcgQEAKIAlpbnQJCSBwZnN5bmNyX2F1dGhsZXZlbDsKIH07CiAK LSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQo X19GcmVlQlNEX2tlcm5lbF9fKQogI2RlZmluZQlTSU9DU0VUUEZTWU5DICAgX0lPVygnaScsIDI0 Nywgc3RydWN0IGlmcmVxKQogI2RlZmluZQlTSU9DR0VUUEZTWU5DICAgX0lPV1IoJ2knLCAyNDgs IHN0cnVjdCBpZnJlcSkKICNlbmRpZgpAQCAtMjg4LDcgKzI4OCw3IEBACiAjZGVmaW5lCVBGU1lO Q19TX0RFRkVSCTB4ZmUKICNkZWZpbmUJUEZTWU5DX1NfTk9ORQkweGZmCiAKLSNpZmRlZiBfX0Zy ZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tl cm5lbF9fKQogdm9pZAkJCXBmc3luY19pbnB1dChzdHJ1Y3QgbWJ1ZiAqLCBfX3VudXNlZCBpbnQp OwogI2Vsc2UKIHZvaWQJCQlwZnN5bmNfaW5wdXQoc3RydWN0IG1idWYgKiwgLi4uKTsKQEAgLTMw MCw3ICszMDAsNyBAQAogI2RlZmluZQlQRlNZTkNfU0lfQ0tTVU0JCTB4MDIKICNkZWZpbmUJUEZT WU5DX1NJX0FDSwkJMHgwNAogaW50CQkJcGZzeW5jX3N0YXRlX2ltcG9ydChzdHJ1Y3QgcGZzeW5j X3N0YXRlICosIHVfaW50OF90KTsKLSNpZm5kZWYgX19GcmVlQlNEX18KKyNpZiAhZGVmaW5lZChf X0ZyZWVCU0RfXykgJiYgIWRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogdm9pZAkJCXBmc3lu Y19zdGF0ZV9leHBvcnQoc3RydWN0IHBmc3luY19zdGF0ZSAqLAogCQkJICAgIHN0cnVjdCBwZl9z dGF0ZSAqKTsKICNlbmRpZgpkaWZmIC11ciBzeXMub2xkL2NvbnRyaWIvcGYvbmV0L3BmdmFyLmgg c3lzL2NvbnRyaWIvcGYvbmV0L3BmdmFyLmgKLS0tIHN5cy5vbGQvY29udHJpYi9wZi9uZXQvcGZ2 YXIuaAkyMDExLTEwLTIzIDEyOjA1OjI1LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2NvbnRyaWIv cGYvbmV0L3BmdmFyLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xMzQ5MDY3MzggKzAxMDAKQEAgLTM3 LDcgKzM3LDcgQEAKICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KICNpbmNsdWRlIDxzeXMvcXVldWUu aD4KICNpbmNsdWRlIDxzeXMvdHJlZS5oPgotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5l ZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiAjaW5jbHVkZSA8 c3lzL2xvY2suaD4KICNpbmNsdWRlIDxzeXMvc3guaD4KICNlbHNlCkBAIC00Niw3ICs0Niw3IEBA CiAKICNpbmNsdWRlIDxuZXQvcmFkaXguaD4KICNpbmNsdWRlIDxuZXQvcm91dGUuaD4KLSNpZmRl ZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVl QlNEX2tlcm5lbF9fKQogI2luY2x1ZGUgPG5ldC9pZl9jbG9uZS5oPgogI2luY2x1ZGUgPG5ldC9w Zl9tdGFnLmg+CiAjaW5jbHVkZSA8dm0vdW1hLmg+CkBAIC01NCw3ICs1NCw3IEBACiAjaW5jbHVk ZSA8bmV0aW5ldC9pcF9pcHNwLmg+CiAjZW5kaWYKIAotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYg ZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiAjaW5j bHVkZSA8bmV0aW5ldC9pbi5oPgogI2VuZGlmCiAKQEAgLTYyLDcgKzYyLDcgQEAKIAogc3RydWN0 IGlwOwogc3RydWN0IGlwNl9oZHI7Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9f RnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHN0cnVjdCBpbnBjYjsK ICNlbmRpZgogCkBAIC0xNzMsNyArMTczLDcgQEAKIAkJfQkJCSBhOwogCQljaGFyCQkJIGlmbmFt ZVtJRk5BTVNJWl07CiAJCWNoYXIJCQkgdGJsbmFtZVtQRl9UQUJMRV9OQU1FX1NJWkVdOwotI2lm ZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0Zy ZWVCU0Rfa2VybmVsX18pCiAjZGVmaW5lCVJUTEFCRUxfTEVOCTMyCiAjZW5kaWYKIAkJY2hhcgkJ CSBydGxhYmVsbmFtZVtSVExBQkVMX0xFTl07CkBAIC0yMTEsNyArMjExLDcgQEAKICAqIEFkZHJl c3MgbWFuaXB1bGF0aW9uIG1hY3JvcwogICovCiAKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRl ZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogI2RlZmlu ZQlzcGxzb2Z0bmV0KCkJc3BsbmV0KCkKIAogI2RlZmluZQlIVE9OTCh4KQkoeCkgPSBodG9ubCgo X191aW50MzJfdCkoeCkpCkBAIC0yMzYsNyArMjM2LDcgQEAKIAlpZiAodmFyKQkJCQkJXAogCQl1 bWFfemRlc3Ryb3kodmFyKQogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJl ZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIGV4dGVybiBzdHJ1Y3QgbXR4 IHBmX3Rhc2tfbXR4OwogCiAjZGVmaW5lCVBGX0xPQ0tfQVNTRVJUKCkJbXR4X2Fzc2VydCgmcGZf dGFza19tdHgsIE1BX09XTkVEKQpAQCAtODMzLDcgKzgzMyw3IEBACiAJdV9pbnQ2NF90CQkgaWQ7 CiAJdV9pbnQzMl90CQkgY3JlYXRvcmlkOwogCXVfaW50OF90CQkgZGlyZWN0aW9uOwotI2lmZGVm IF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVC U0Rfa2VybmVsX18pCiAJdV9pbnQ4X3QJCSBwYWRbMl07CiAJdV9pbnQ4X3QJCSBsb2NhbF9mbGFn czsKICNkZWZpbmUJUEZTVEFURV9FWFBJUklORyAweDAxCkBAIC05MjMsNyArOTIzLDcgQEAKIAlz YV9mYW1pbHlfdAkgYWY7CiAJdV9pbnQ4X3QJIHByb3RvOwogCXVfaW50OF90CSBkaXJlY3Rpb247 Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVk KF9fRnJlZUJTRF9rZXJuZWxfXykKIAl1X2ludDhfdAkgbG9jYWxfZmxhZ3M7CiAjZGVmaW5lCVBG U1RBVEVfRVhQSVJJTkcJCTB4MDEKIAl1X2ludDhfdAkgcGFkOwpAQCAtOTM1LDcgKzkzNSw3IEBA CiAJdV9pbnQ4X3QJIHVwZGF0ZXM7CiB9IF9fcGFja2VkOwogCi0jaWZkZWYgX19GcmVlQlNEX18K KyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykK ICNpZmRlZiBfS0VSTkVMCiAvKiBwZnN5bmMgKi8KIHR5cGVkZWYgaW50CQlwZnN5bmNfc3RhdGVf aW1wb3J0X3Qoc3RydWN0IHBmc3luY19zdGF0ZSAqLCB1X2ludDhfdCk7CkBAIC0xMjE1LDcgKzEy MTUsNyBAQAogUkJfSEVBRChwZmlfaWZoZWFkLCBwZmlfa2lmKTsKIAogLyogc3RhdGUgdGFibGVz ICovCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICNpZmRlZiBfS0VSTkVMCiBWTkVUX0RFQ0xBUkUoc3Ry dWN0IHBmX3N0YXRlX3RyZWUsCSBwZl9zdGF0ZXRibCk7CiAjZGVmaW5lCVZfcGZfc3RhdGV0YmwJ CQkgVk5FVChwZl9zdGF0ZXRibCkKQEAgLTEyNzcsNyArMTI3Nyw3IEBACiAJc3RydWN0IHBmX2Fk ZHIJKmRzdDsJCS8qIGRzdCBhZGRyZXNzICovCiAJdV9pbnQxNl90ICpzcG9ydDsKIAl1X2ludDE2 X3QgKmRwb3J0OwotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykg fHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiAJc3RydWN0IHBmX210YWcJKnBmX210YWc7 CiAjZW5kaWYKIApAQCAtMTQwMyw3ICsxNDAzLDcgQEAKIAkJCSooYSkgPSAoeCk7IFwKIAl9IHdo aWxlICgwKQogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8 fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICNkZWZpbmUgUkVBU09OX1NFVChhLCB4KSBc CiAJZG8geyBcCiAJCWlmICgoYSkgIT0gTlVMTCkgXApAQCAtMTQ4OCw3ICsxNDg4LDcgQEAKIAl1 X2ludDMyX3QJCSBwYXJlbnRfcWlkOwkvKiBwYXJlbnQgcXVldWUgaWQgKi8KIAl1X2ludDMyX3QJ CSBiYW5kd2lkdGg7CS8qIHF1ZXVlIGJhbmR3aWR0aCAqLwogCXVfaW50OF90CQkgcHJpb3JpdHk7 CS8qIHByaW9yaXR5ICovCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJT RF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIAl1X2ludDhfdAkJIGxvY2FsX2Zs YWdzOwkvKiBkeW5hbWljIGludGVyZmFjZSAqLwogI2RlZmluZQlQRkFMVFFfRkxBR19JRl9SRU1P VkVECQkweDAxCiAjZW5kaWYKQEAgLTE3NjgsNyArMTc2OCw3IEBACiAjZGVmaW5lCURJT0NTRVRJ RkZMQUcJX0lPV1IoJ0QnLCA4OSwgc3RydWN0IHBmaW9jX2lmYWNlKQogI2RlZmluZQlESU9DQ0xS SUZGTEFHCV9JT1dSKCdEJywgOTAsIHN0cnVjdCBwZmlvY19pZmFjZSkKICNkZWZpbmUJRElPQ0tJ TExTUkNOT0RFUwlfSU9XUignRCcsIDkxLCBzdHJ1Y3QgcGZpb2Nfc3JjX25vZGVfa2lsbCkKLSNp ZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19G cmVlQlNEX2tlcm5lbF9fKQogc3RydWN0IHBmX2lmc3BlZWQgewogCWNoYXIJCQlpZm5hbWVbSUZO QU1TSVpdOwogCXVfaW50MzJfdAkJYmF1ZHJhdGU7CkBAIC0xNzc5LDcgKzE3NzksNyBAQAogI2lm ZGVmIF9LRVJORUwKIFJCX0hFQUQocGZfc3JjX3RyZWUsIHBmX3NyY19ub2RlKTsKIFJCX1BST1RP VFlQRShwZl9zcmNfdHJlZSwgcGZfc3JjX25vZGUsIGVudHJ5LCBwZl9zcmNfY29tcGFyZSk7Ci0j aWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9f RnJlZUJTRF9rZXJuZWxfXykKIFZORVRfREVDTEFSRShzdHJ1Y3QgcGZfc3JjX3RyZWUsCSB0cmVl X3NyY190cmFja2luZyk7CiAjZGVmaW5lCVZfdHJlZV9zcmNfdHJhY2tpbmcJCSBWTkVUKHRyZWVf c3JjX3RyYWNraW5nKQogI2Vsc2UKQEAgLTE3ODksNyArMTc4OSw3IEBACiBSQl9IRUFEKHBmX3N0 YXRlX3RyZWVfaWQsIHBmX3N0YXRlKTsKIFJCX1BST1RPVFlQRShwZl9zdGF0ZV90cmVlX2lkLCBw Zl9zdGF0ZSwKICAgICBlbnRyeV9pZCwgcGZfc3RhdGVfY29tcGFyZV9pZCk7Ci0jaWZkZWYgX19G cmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9r ZXJuZWxfXykKIFZORVRfREVDTEFSRShzdHJ1Y3QgcGZfc3RhdGVfdHJlZV9pZCwJIHRyZWVfaWQp OwogI2RlZmluZQlWX3RyZWVfaWQJCQkgVk5FVCh0cmVlX2lkKQogVk5FVF9ERUNMQVJFKHN0cnVj dCBwZl9zdGF0ZV9xdWV1ZSwJIHN0YXRlX2xpc3QpOwpAQCAtMTgwMCwxNCArMTgwMCwxNCBAQAog I2VuZGlmCiAKIFRBSUxRX0hFQUQocGZfcG9vbHF1ZXVlLCBwZl9wb29sKTsKLSNpZmRlZiBfX0Zy ZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tl cm5lbF9fKQogVk5FVF9ERUNMQVJFKHN0cnVjdCBwZl9wb29scXVldWUsCSBwZl9wb29sc1syXSk7 CiAjZGVmaW5lCVZfcGZfcG9vbHMJCQkgVk5FVChwZl9wb29scykKICNlbHNlCiBleHRlcm4gc3Ry dWN0IHBmX3Bvb2xxdWV1ZQkJICBwZl9wb29sc1syXTsKICNlbmRpZgogVEFJTFFfSEVBRChwZl9h bHRxcXVldWUsIHBmX2FsdHEpOwotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0Zy ZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBWTkVUX0RFQ0xBUkUoc3Ry dWN0IHBmX2FsdHFxdWV1ZSwJIHBmX2FsdHFzWzJdKTsKICNkZWZpbmUJVl9wZl9hbHRxcwkJCSBW TkVUKHBmX2FsdHFzKQogVk5FVF9ERUNMQVJFKHN0cnVjdCBwZl9wYWxpc3QsCQkgcGZfcGFidWYp OwpAQCAtMTgxNyw3ICsxODE3LDcgQEAKIGV4dGVybiBzdHJ1Y3QgcGZfcGFsaXN0CQkJICBwZl9w YWJ1ZjsKICNlbmRpZgogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJT RF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIFZORVRfREVDTEFSRSh1X2ludDMy X3QsCQkJIHRpY2tldF9hbHRxc19hY3RpdmUpOwogI2RlZmluZQlWX3RpY2tldF9hbHRxc19hY3Rp dmUJCSBWTkVUKHRpY2tldF9hbHRxc19hY3RpdmUpCiBWTkVUX0RFQ0xBUkUodV9pbnQzMl90LAkJ CSB0aWNrZXRfYWx0cXNfaW5hY3RpdmUpOwpAQCAtMTg0OSw3ICsxODQ5LDcgQEAKIGV4dGVybiB2 b2lkCQkJIHBmX3RibGFkZHJfcmVtb3ZlKHN0cnVjdCBwZl9hZGRyX3dyYXAgKik7CiBleHRlcm4g dm9pZAkJCSBwZl90YmxhZGRyX2NvcHlvdXQoc3RydWN0IHBmX2FkZHJfd3JhcCAqKTsKIGV4dGVy biB2b2lkCQkJIHBmX2NhbGNfc2tpcF9zdGVwcyhzdHJ1Y3QgcGZfcnVsZXF1ZXVlICopOwotI2lm ZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0Zy ZWVCU0Rfa2VybmVsX18pCiAjaWZkZWYgQUxUUQogZXh0ZXJuCXZvaWQJCQkgcGZfYWx0cV9pZm5l dF9ldmVudChzdHJ1Y3QgaWZuZXQgKiwgaW50KTsKICNlbmRpZgpAQCAtMTg4Niw3ICsxODg2LDcg QEAKIGV4dGVybiBzdHJ1Y3QgcG9vbAkJIHBmX3N0YXRlX3NjcnViX3BsOwogI2VuZGlmCiBleHRl cm4gdm9pZAkJCSBwZl9wdXJnZV90aHJlYWQodm9pZCAqKTsKLSNpZmRlZiBfX0ZyZWVCU0RfXwor I2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQog ZXh0ZXJuIGludAkJCSBwZl9wdXJnZV9leHBpcmVkX3NyY19ub2RlcyhpbnQpOwogZXh0ZXJuIGlu dAkJCSBwZl9wdXJnZV9leHBpcmVkX3N0YXRlcyh1X2ludDMyX3QgLCBpbnQpOwogI2Vsc2UKQEAg LTE5MTEsNyArMTkxMSw3IEBACiBleHRlcm4gdV9pbnQxNl90CQkgcGZfY2tzdW1fZml4dXAodV9p bnQxNl90LCB1X2ludDE2X3QsIHVfaW50MTZfdCwKIAkJCQkgICAgdV9pbnQ4X3QpOwogCi0jaWZk ZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJl ZUJTRF9rZXJuZWxfXykKIFZORVRfREVDTEFSRShzdHJ1Y3QgaWZuZXQgKiwJCSBzeW5jX2lmcCk7 CiAjZGVmaW5lCVZfc3luY19pZnAJCSAJIFZORVQoc3luY19pZnApOwogVk5FVF9ERUNMQVJFKHN0 cnVjdCBwZl9ydWxlLAkJIHBmX2RlZmF1bHRfcnVsZSk7CkBAIC0xOTI0LDEyICsxOTI0LDEyIEBA CiAJCQkJICAgIHVfaW50OF90KTsKIHZvaWQJCQkJIHBmX3JtX3J1bGUoc3RydWN0IHBmX3J1bGVx dWV1ZSAqLAogCQkJCSAgICBzdHJ1Y3QgcGZfcnVsZSAqKTsKLSNpZm5kZWYgX19GcmVlQlNEX18K KyNpZiAhZGVmaW5lZChfX0ZyZWVCU0RfXykgJiYgIWRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9f KQogc3RydWN0IHBmX2RpdmVydAkJKnBmX2ZpbmRfZGl2ZXJ0KHN0cnVjdCBtYnVmICopOwogI2Vu ZGlmCiAKICNpZmRlZiBJTkVUCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJl ZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIGludAlwZl90ZXN0KGludCwg c3RydWN0IGlmbmV0ICosIHN0cnVjdCBtYnVmICoqLCBzdHJ1Y3QgZXRoZXJfaGVhZGVyICosCiAg ICAgc3RydWN0IGlucGNiICopOwogI2Vsc2UKQEAgLTE5MzgsNyArMTkzOCw3IEBACiAjZW5kaWYg LyogSU5FVCAqLwogCiAjaWZkZWYgSU5FVDYKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmlu ZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogaW50CXBmX3Rl c3Q2KGludCwgc3RydWN0IGlmbmV0ICosIHN0cnVjdCBtYnVmICoqLCBzdHJ1Y3QgZXRoZXJfaGVh ZGVyICosCiAgICAgc3RydWN0IGlucGNiICopOwogI2Vsc2UKQEAgLTE5NDksNyArMTk0OSw3IEBA CiB2b2lkCXBmX2FkZHJfaW5jKHN0cnVjdCBwZl9hZGRyICosIHNhX2ZhbWlseV90KTsKICNlbmRp ZiAvKiBJTkVUNiAqLwogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJT RF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHVfaW50MzJfdAlwZl9uZXdfaXNu KHN0cnVjdCBwZl9zdGF0ZSAqKTsKICNlbmRpZgogdm9pZCAgICpwZl9wdWxsX2hkcihzdHJ1Y3Qg bWJ1ZiAqLCBpbnQsIHZvaWQgKiwgaW50LCB1X3Nob3J0ICosIHVfc2hvcnQgKiwKQEAgLTE5ODYs NyArMTk4Niw3IEBACiB2b2lkCXBmX3B1cmdlX2V4cGlyZWRfZnJhZ21lbnRzKHZvaWQpOwogaW50 CXBmX3JvdXRhYmxlKHN0cnVjdCBwZl9hZGRyICphZGRyLCBzYV9mYW1pbHlfdCBhZiwgc3RydWN0 IHBmaV9raWYgKik7CiBpbnQJcGZfcnRsYWJlbF9tYXRjaChzdHJ1Y3QgcGZfYWRkciAqLCBzYV9m YW1pbHlfdCwgc3RydWN0IHBmX2FkZHJfd3JhcCAqKTsKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lm IGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogaW50 CXBmX3NvY2tldF9sb29rdXAoaW50LCBzdHJ1Y3QgcGZfcGRlc2MgKiwgIHN0cnVjdCBpbnBjYiAq KTsKICNlbHNlCiBpbnQJcGZfc29ja2V0X2xvb2t1cChpbnQsIHN0cnVjdCBwZl9wZGVzYyAqKTsK QEAgLTIwMzEsNyArMjAzMSw3IEBACiBpbnQJcGZyX2luYV9kZWZpbmUoc3RydWN0IHBmcl90YWJs ZSAqLCBzdHJ1Y3QgcGZyX2FkZHIgKiwgaW50LCBpbnQgKiwKIAkgICAgaW50ICosIHVfaW50MzJf dCwgaW50KTsKIAotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykg fHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBWTkVUX0RFQ0xBUkUoc3RydWN0IHBmaV9r aWYgKiwJCSBwZmlfYWxsKTsKICNkZWZpbmUJVl9wZmlfYWxsCSAJCSBWTkVUKHBmaV9hbGwpCiAj ZWxzZQpAQCAtMjAzOSw3ICsyMDM5LDcgQEAKICNlbmRpZgogCiB2b2lkCQkgcGZpX2luaXRpYWxp emUodm9pZCk7Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8 fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHZvaWQJCSBwZmlfY2xlYW51cCh2b2lkKTsK ICNlbmRpZgogc3RydWN0IHBmaV9raWYJKnBmaV9raWZfZ2V0KGNvbnN0IGNoYXIgKik7CkBAIC0y MDYxLDcgKzIwNjEsNyBAQAogaW50CQkgcGZpX3NldF9mbGFncyhjb25zdCBjaGFyICosIGludCk7 CiBpbnQJCSBwZmlfY2xlYXJfZmxhZ3MoY29uc3QgY2hhciAqLCBpbnQpOwogCi0jaWZkZWYgX19G cmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9r ZXJuZWxfXykKIGludAkJIHBmX21hdGNoX3RhZyhzdHJ1Y3QgbWJ1ZiAqLCBzdHJ1Y3QgcGZfcnVs ZSAqLCBpbnQgKiwKIAkJICAgIHN0cnVjdCBwZl9tdGFnICopOwogI2Vsc2UKQEAgLTIwNzEsNyAr MjA3MSw3IEBACiB2b2lkCQkgcGZfdGFnMnRhZ25hbWUodV9pbnQxNl90LCBjaGFyICopOwogdm9p ZAkJIHBmX3RhZ19yZWYodV9pbnQxNl90KTsKIHZvaWQJCSBwZl90YWdfdW5yZWYodV9pbnQxNl90 KTsKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmlu ZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogaW50CQkgcGZfdGFnX3BhY2tldChzdHJ1Y3QgbWJ1ZiAq LCBpbnQsIGludCwgc3RydWN0IHBmX210YWcgKik7CiAjZWxzZQogaW50CQkgcGZfdGFnX3BhY2tl dChzdHJ1Y3QgbWJ1ZiAqLCBpbnQsIGludCk7CkBAIC0yMDgwLDE0ICsyMDgwLDE0IEBACiB2b2lk CQkgcGZfcWlkMnFuYW1lKHVfaW50MzJfdCwgY2hhciAqKTsKIHZvaWQJCSBwZl9xaWRfdW5yZWYo dV9pbnQzMl90KTsKIAotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0Rf XykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBWTkVUX0RFQ0xBUkUoc3RydWN0IHBm X3N0YXR1cywJCSBwZl9zdGF0dXMpOwogI2RlZmluZQlWX3BmX3N0YXR1cwkJCSBWTkVUKHBmX3N0 YXR1cykKICNlbHNlCiBleHRlcm4gc3RydWN0IHBmX3N0YXR1cwlwZl9zdGF0dXM7CiAjZW5kaWYK IAotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5l ZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBWTkVUX0RFQ0xBUkUodW1hX3pvbmVfdCwJCSBwZl9mcmVu dF9wbCk7CiAjZGVmaW5lCVZfcGZfZnJlbnRfcGwJCQkgVk5FVChwZl9mcmVudF9wbCkKIFZORVRf REVDTEFSRSh1bWFfem9uZV90LAkJIHBmX2ZyYWdfcGwpOwpAQCAtMjEwMywxNCArMjEwMywxNCBA QAogCXZvaWQJCSpwcDsKIAl1bnNpZ25lZAkgbGltaXQ7CiB9OwotI2lmZGVmIF9fRnJlZUJTRF9f CisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18p CiBWTkVUX0RFQ0xBUkUoc3RydWN0IHBmX3Bvb2xfbGltaXQsCQkgcGZfcG9vbF9saW1pdHNbUEZf TElNSVRfTUFYXSk7CiAjZGVmaW5lCVZfcGZfcG9vbF9saW1pdHMJCQkgVk5FVChwZl9wb29sX2xp bWl0cykKICNlbHNlCiBleHRlcm4gc3RydWN0IHBmX3Bvb2xfbGltaXQJcGZfcG9vbF9saW1pdHNb UEZfTElNSVRfTUFYXTsKICNlbmRpZgogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVk KF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHN0cnVjdCBwZl9m cmVudCB7CiAJTElTVF9FTlRSWShwZl9mcmVudCkgZnJfbmV4dDsKIAlzdHJ1Y3QgaXAgKmZyX2lw OwpAQCAtMjE0NCw3ICsyMTQ0LDcgQEAKIAogI2VuZGlmIC8qIF9LRVJORUwgKi8KIAotI2lmZGVm IF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVC U0Rfa2VybmVsX18pCiAjaWZkZWYgX0tFUk5FTAogVk5FVF9ERUNMQVJFKHN0cnVjdCBwZl9hbmNo b3JfZ2xvYmFsLAkJIHBmX2FuY2hvcnMpOwogI2RlZmluZQlWX3BmX2FuY2hvcnMJCQkJIFZORVQo cGZfYW5jaG9ycykKQEAgLTIxNzIsNyArMjE3Miw3IEBACiBzdHJ1Y3QgcGZfcnVsZXNldAkqcGZf ZmluZF9vcl9jcmVhdGVfcnVsZXNldChjb25zdCBjaGFyICopOwogdm9pZAkJCSBwZl9yc19pbml0 aWFsaXplKHZvaWQpOwogCi0jaWZuZGVmIF9fRnJlZUJTRF9fCisjaWYgIWRlZmluZWQoX19GcmVl QlNEX18pICYmICFkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICNpZmRlZiBfS0VSTkVMCiBp bnQJCQkgcGZfYW5jaG9yX2NvcHlvdXQoY29uc3Qgc3RydWN0IHBmX3J1bGVzZXQgKiwKIAkJCSAg ICBjb25zdCBzdHJ1Y3QgcGZfcnVsZSAqLCBzdHJ1Y3QgcGZpb2NfcnVsZSAqKTsKQEAgLTIxOTMs NyArMjE5Myw3IEBACiAJICAgIGNvbnN0IHN0cnVjdCB0Y3BoZHIgKik7CiB2b2lkCXBmX29zZnBf Zmx1c2godm9pZCk7CiBpbnQJcGZfb3NmcF9nZXQoc3RydWN0IHBmX29zZnBfaW9jdGwgKik7Ci0j aWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9f RnJlZUJTRF9rZXJuZWxfXykKIGludAlwZl9vc2ZwX2luaXRpYWxpemUodm9pZCk7CiB2b2lkCXBm X29zZnBfY2xlYW51cCh2b2lkKTsKICNlbHNlCmRpZmYgLXVyIHN5cy5vbGQvZGV2L2ZpcmV3aXJl L2ZpcmV3aXJlcmVnLmggc3lzL2Rldi9maXJld2lyZS9maXJld2lyZXJlZy5oCi0tLSBzeXMub2xk L2Rldi9maXJld2lyZS9maXJld2lyZXJlZy5oCTIwMDctMDctMjAgMDU6NDI6NTcuMDAwMDAwMDAw ICswMjAwCisrKyBzeXMvZGV2L2ZpcmV3aXJlL2ZpcmV3aXJlcmVnLmgJMjAxMS0xMS0xMyAxNDox Mjo0MS4xMjI5MDc2MDkgKzAxMDAKQEAgLTc1LDcgKzc1LDcgQEAKIH07CiAKIHN0cnVjdCBmaXJl d2lyZV9zb2Z0YyB7Ci0jaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgJiYgX19GcmVlQlNEX3ZlcnNp b24gPj0gNTAwMDAwCisjaWYgKGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVl QlNEX2tlcm5lbF9fKSkgJiYgX19GcmVlQlNEX3ZlcnNpb24gPj0gNTAwMDAwCiAJc3RydWN0IGNk ZXYgKmRldjsKICNlbmRpZgogCXN0cnVjdCBmaXJld2lyZV9jb21tICpmYzsKZGlmZiAtdXIgc3lz Lm9sZC9kZXYvbG1jL2lmX2xtYy5oIHN5cy9kZXYvbG1jL2lmX2xtYy5oCi0tLSBzeXMub2xkL2Rl di9sbWMvaWZfbG1jLmgJMjAwOS0xMS0xOSAxOToyMTo1MS4wMDAwMDAwMDAgKzAxMDAKKysrIHN5 cy9kZXYvbG1jL2lmX2xtYy5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTI0OTA4MzAyICswMTAwCkBA IC05ODQsNyArOTg0LDcgQEAKICNlbmRpZgogICB1X2ludDMyX3QgYWRkcmVzczE7CQkvKiBidWZm ZXIxIGJ1cyBhZGRyZXNzICovCiAgIHVfaW50MzJfdCBhZGRyZXNzMjsJCS8qIGJ1ZmZlcjIgYnVz IGFkZHJlc3MgKi8KLSNpZiAoZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX05ldEJT RF9fKSB8fCBkZWZpbmVkKF9fT3BlbkJTRF9fKSkKKyNpZiAoZGVmaW5lZChfX0ZyZWVCU0RfXykg fHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pIHx8IGRlZmluZWQoX19OZXRCU0RfXykgfHwg ZGVmaW5lZChfX09wZW5CU0RfXykpCiAgIGJ1c19kbWFtYXBfdCBtYXA7CQkvKiBidXMgZG1hbWFw IGZvciB0aGlzIGRlc2NyaXB0b3IgKi8KICMgZGVmaW5lIFRMUF9CVVNfRFNMX1ZBTAkoc2l6ZW9m KGJ1c19kbWFtYXBfdCkgJiBUTFBfQlVTX0RTTCkKICNlbHNlCkBAIC0xMDM1LDcgKzEwMzUsNyBA QAogI2VsaWYgQlNECiAgIHN0cnVjdCBtYnVmICpoZWFkOwkJLyogdGFpbC1xdWV1ZSBvZiBtYnVm cyAqLwogICBzdHJ1Y3QgbWJ1ZiAqdGFpbDsKLSMgaWYgKGRlZmluZWQoX19GcmVlQlNEX18pIHx8 IGRlZmluZWQoX19OZXRCU0RfXykgfHwgZGVmaW5lZChfX09wZW5CU0RfXykpCisjIGlmIChkZWZp bmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykgfHwgZGVmaW5l ZChfX05ldEJTRF9fKSB8fCBkZWZpbmVkKF9fT3BlbkJTRF9fKSkKICAgYnVzX2RtYV90YWdfdCB0 YWc7CQkvKiBidXNfZG1hIHRhZyBmb3IgZGVzYyBhcnJheSAqLwogICBidXNfZG1hbWFwX3QgbWFw OwkJLyogYnVzX2RtYSBtYXAgZm9yIGRlc2MgYXJyYXkgKi8KICAgYnVzX2RtYV9zZWdtZW50X3Qg c2Vnc1syXTsJLyogYnVzX2RtYW1hcF9sb2FkKCkgb3IgYnVzX2RtYW1lbV9hbGxvYygpICovCkBA IC0xMDY4LDcgKzEwNjgsNyBAQAogICovCiAjZGVmaW5lIElPUkVGX0NTUiAxICAvKiBhY2Nlc3Mg VHVsaXAgQ1NScyB3aXRoIElPIGN5Y2xlcyBpZiAxICovCiAKLSNpZiAoZGVmaW5lZChfX0ZyZWVC U0RfXykgJiYgZGVmaW5lZChERVZJQ0VfUE9MTElORykpCisjaWYgKChkZWZpbmVkKF9fRnJlZUJT RF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoREVWSUNFX1BP TExJTkcpKQogIyBkZWZpbmUgREVWX1BPTEwgMQogI2Vsc2UKICMgZGVmaW5lIERFVl9QT0xMIDAK QEAgLTExNTEsNyArMTE1MSw3IEBACiAjIGVuZGlmCiAjZW5kaWYKIAotI2lmZGVmIF9fRnJlZUJT RF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVs X18pCiAgIHN0cnVjdCBjYWxsb3V0IGNhbGxvdXQ7CS8qIHdhdGNoZG9nIG5lZWRzIHRoaXMgICAg ICAgICAgICAgICAgICAqLwogICBzdHJ1Y3QgZGV2aWNlCSpkZXY7CQkvKiBiYXNlIGRldmljZSBw b2ludGVyICAgICAgICAgICAgICAgICAgICAgKi8KICAgYnVzX3NwYWNlX3RhZ190IGNzcl90YWc7 CS8qIGJ1c19zcGFjZSBuZWVkcyB0aGlzICAgICAgICAgICAgICAgICAgICAqLwpAQCAtMTIxMCw3 ICsxMjEwLDcgQEAKIAogLyogSGlkZSB0aGUgbWlub3IgZGlmZmVyZW5jZXMgYmV0d2VlbiBPUyB2 ZXJzaW9ucyAqLwogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9f KSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICAgdHlwZWRlZiB2b2lkIGludHJfcmV0 dXJuX3Q7CiAjIGRlZmluZSAgUkVBRF9QQ0lfQ0ZHKHNjLCBhZGRyKSAgICAgICBwY2lfcmVhZF9j b25maWcgKChzYyktPmRldiwgYWRkciwgNCkKICMgZGVmaW5lIFdSSVRFX1BDSV9DRkcoc2MsIGFk ZHIsIGRhdGEpIHBjaV93cml0ZV9jb25maWcoKHNjKS0+ZGV2LCBhZGRyLCBkYXRhLCA0KQpAQCAt MTQyOCw3ICsxNDI4LDcgQEAKICNlbmRpZgogCiAjaWYgKGRlZmluZWQoX19ic2RpX18pIHx8IC8q IHVuY29uZGl0aW9uYWxseSAqLyBcCi0gICAgKGRlZmluZWQoX19GcmVlQlNEX18pICYmIChfX0Zy ZWVCU0RfdmVyc2lvbiA8IDUwMzAwMCkpIHx8IFwKKyAgICAoKGRlZmluZWQoX19GcmVlQlNEX18p IHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKSkgJiYgKF9fRnJlZUJTRF92ZXJzaW9uIDwg NTAzMDAwKSkgfHwgXAogICAgIChkZWZpbmVkKF9fTmV0QlNEX18pICAmJiAoX19OZXRCU0RfVmVy c2lvbl9fIDwgMTA2MDAwMDAwKSkgfHwgXAogICAgIChkZWZpbmVkKF9fT3BlbkJTRF9fKSAmJiAo ICBPcGVuQlNEIDwgMjAwMTExKSkpCiAjIGRlZmluZSBJRlFfRU5RVUVVRShpZnEsIG0sIHBhLCBl cnIpICAgXApAQCAtMTUzMSw3ICsxNTMxLDcgQEAKIHN0YXRpYyBpbnQgIHQxX2lvY3RsKHNvZnRj X3QgKiwgc3RydWN0IGlvY3RsICopOwogCiAjaWYgSUZORVQKLSMgaWYgKChkZWZpbmVkKF9fRnJl ZUJTRF9fKSAmJiAoX19GcmVlQlNEX3ZlcnNpb24gPCA1MDAwMDApKSB8fFwKKyMgaWYgKCgoZGVm aW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pKSAmJiBfX0Zy ZWVCU0RfdmVyc2lvbiA8IDUwMDAwMCkgfHxcCiAgICAgICAgIGRlZmluZWQoX19OZXRCU0RfXykg fHwgZGVmaW5lZChfX09wZW5CU0RfXykgfHwgZGVmaW5lZChfX2JzZGlfXykpCiBzdGF0aWMgdm9p ZCBuZXRpc3JfZGlzcGF0Y2goaW50LCBzdHJ1Y3QgbWJ1ZiAqKTsKICMgZW5kaWYKQEAgLTE1NDEs NyArMTU0MSw3IEBACiAjaWYgQlNECiBzdGF0aWMgdm9pZCBtYnVmX2VucXVldWUoc3RydWN0IGRl c2NfcmluZyAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKIHN0YXRpYyBzdHJ1Y3QgbWJ1ZiogbWJ1Zl9kZXF1 ZXVlKHN0cnVjdCBkZXNjX3JpbmcgKik7Ci0jIGlmZGVmIF9fRnJlZUJTRF9fCisjIGlmIGRlZmlu ZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogc3RhdGljIHZv aWQgZmJzZF9kbWFtYXBfbG9hZCh2b2lkICosIGJ1c19kbWFfc2VnbWVudF90ICosIGludCwgaW50 KTsKICMgZW5kaWYKIHN0YXRpYyBpbnQgY3JlYXRlX3Jpbmcoc29mdGNfdCAqLCBzdHJ1Y3QgZGVz Y19yaW5nICosIGludCk7CkBAIC0xNTcwLDcgKzE1NzAsNyBAQAogc3RhdGljIHZvaWQgY29yZV9p bnRlcnJ1cHQodm9pZCAqLCBpbnQpOwogc3RhdGljIHZvaWQgdXNlcl9pbnRlcnJ1cHQoc29mdGNf dCAqLCBpbnQpOwogI2lmIEJTRAotIyBpZiAoZGVmaW5lZChfX0ZyZWVCU0RfXykgJiYgZGVmaW5l ZChERVZJQ0VfUE9MTElORykpCisjIGlmIChkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVk KF9fRnJlZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoREVWSUNFX1BPTExJTkcpCiBzdGF0aWMg aW50IGZic2RfcG9sbChzdHJ1Y3QgaWZuZXQgKiwgZW51bSBwb2xsX2NtZCwgaW50KTsKICMgZW5k aWYKIHN0YXRpYyBpbnRyX3JldHVybl90IGJzZF9pbnRlcnJ1cHQodm9pZCAqKTsKQEAgLTE2Mzgs NyArMTYzOCw3IEBACiBzdGF0aWMgaW50IGF0dGFjaF9jYXJkKHNvZnRjX3QgKiwgY29uc3QgY2hh ciAqKTsKIHN0YXRpYyB2b2lkIGRldGFjaF9jYXJkKHNvZnRjX3QgKik7CiAKLSNpZmRlZiBfX0Zy ZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tl cm5lbF9fKQogc3RhdGljIGludCBmYnNkX3Byb2JlKGRldmljZV90KTsKIHN0YXRpYyBpbnQgZmJz ZF9kZXRhY2goZGV2aWNlX3QpOwogc3RhdGljIGludCBmYnNkX3NodXRkb3duKGRldmljZV90KTsK ZGlmZiAtdXIgc3lzLm9sZC9kZXYvbXB0L21waWxpYi9tcGlfdHlwZS5oIHN5cy9kZXYvbXB0L21w aWxpYi9tcGlfdHlwZS5oCi0tLSBzeXMub2xkL2Rldi9tcHQvbXBpbGliL21waV90eXBlLmgJMjAw Ni0wMi0yNiAyMzo1MDoxNC4wMDAwMDAwMDAgKzAxMDAKKysrIHN5cy9kZXYvbXB0L21waWxpYi9t cGlfdHlwZS5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTI1OTA2NjkzICswMTAwCkBAIC03Nyw3ICs3 Nyw3IEBACiB0eXBlZGVmIHNpZ25lZCAgIHNob3J0ICBTMTY7CiB0eXBlZGVmIHVuc2lnbmVkIHNo b3J0ICBVMTY7CiAKLSNpZmRlZglfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18p IHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogCiB0eXBlZGVmIGludDMyX3QgIFMzMjsK IHR5cGVkZWYgdWludDMyX3QgVTMyOwpkaWZmIC11ciBzeXMub2xkL2Rldi93aS9pZl93aXJlZy5o IHN5cy9kZXYvd2kvaWZfd2lyZWcuaAotLS0gc3lzLm9sZC9kZXYvd2kvaWZfd2lyZWcuaAkyMDA5 LTA1LTIwIDIyOjAwOjQwLjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2Rldi93aS9pZl93aXJlZy5o CTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTI3OTA2NTQ3ICswMTAwCkBAIC04NCw3ICs4NCw3IEBACiAj aWZkZWYgX19OZXRCU0RfXwogI2RlZmluZSBPU19TVFJJTkdfTkFNRQkiTmV0QlNEIgogI2VuZGlm Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVk KF9fRnJlZUJTRF9rZXJuZWxfXykKICNkZWZpbmUgT1NfU1RSSU5HX05BTUUJIkZyZWVCU0QiCiAj ZW5kaWYKICNpZmRlZiBfX09wZW5CU0RfXwpkaWZmIC11ciBzeXMub2xkL2ZzL25mcy9uZnNfdmFy Lmggc3lzL2ZzL25mcy9uZnNfdmFyLmgKLS0tIHN5cy5vbGQvZnMvbmZzL25mc192YXIuaAkyMDEx LTA3LTE2IDEwOjA1OjE3LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2ZzL25mcy9uZnNfdmFyLmgJ MjAxMS0xMS0xMyAxNDoxMjo0MS4xMjg5MDY2MTUgKzAxMDAKQEAgLTc2LDcgKzc2LDcgQEAKIHN0 cnVjdCBuZnN2YXR0cjsKIHN0cnVjdCBuZnNfdmF0dHI7CiBzdHJ1Y3QgTkZTU1ZDQVJHUzsKLSNp ZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19G cmVlQlNEX2tlcm5lbF9fKQogTkZTX0FDQ0VTU19BUkdTOwogTkZTX09QRU5fQVJHUzsKIE5GU19H RVRBVFRSX0FSR1M7CmRpZmYgLXVyIHN5cy5vbGQvbmV0L2lmX2F0bS5oIHN5cy9uZXQvaWZfYXRt LmgKLS0tIHN5cy5vbGQvbmV0L2lmX2F0bS5oCTIwMDktMDQtMTYgMjI6MzA6MjguMDAwMDAwMDAw ICswMjAwCisrKyBzeXMvbmV0L2lmX2F0bS5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTI5OTA2NDAy ICswMTAwCkBAIC0yMDIsNyArMjAyLDcgQEAKIAogI2lmIGRlZmluZWQoX19OZXRCU0RfXykgfHwg ZGVmaW5lZChfX09wZW5CU0RfXykgfHwgZGVmaW5lZChfX2JzZGlfXykKICNkZWZpbmUJUlRBTExP QzEoQSxCKQkJcnRhbGxvYzEoKEEpLChCKSkKLSNlbGlmIGRlZmluZWQoX19GcmVlQlNEX18pCisj ZWxpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykK ICNkZWZpbmUJUlRBTExPQzEoQSxCKQkJcnRhbGxvYzEoKEEpLChCKSwwVUwpCiAjZW5kaWYKIApk aWZmIC11ciBzeXMub2xkL25ldC96bGliLmggc3lzL25ldC96bGliLmgKLS0tIHN5cy5vbGQvbmV0 L3psaWIuaAkyMDEwLTAzLTAyIDA3OjU4OjU4LjAwMDAwMDAwMCArMDEwMAorKysgc3lzL25ldC96 bGliLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xMzU5MDY1MjUgKzAxMDAKQEAgLTUxMCw3ICs1MTAs NyBAQAogICAgZG9uZSBieSBpbmZsYXRlKCkuCiAqLwogCi0jaWYgZGVmaW5lZChfX0ZyZWVCU0Rf XykgJiYgZGVmaW5lZChfS0VSTkVMKQorI2lmIChkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoX0tFUk5FTCkKICNkZWZpbmUgaW5m bGF0ZSAgICAgICBpbmZsYXRlX3BwcCAgICAgLyogRnJlZUJTRCBhbHJlYWR5IGhhcyBhbiBpbmZs YXRlIDotKCAqLwogI2VuZGlmCiAKZGlmZiAtdXIgc3lzLm9sZC9uZXQ4MDIxMS9pZWVlODAyMTFf aW9jdGwuaCBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX2lvY3RsLmgKLS0tIHN5cy5vbGQvbmV0ODAy MTEvaWVlZTgwMjExX2lvY3RsLmgJMjAxMS0wNi0xNiAxMTozNzoyMC4wMDAwMDAwMDAgKzAyMDAK KysrIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfaW9jdGwuaAkyMDExLTExLTEzIDE0OjEyOjQxLjEz NzkwNzc3NyArMDEwMApAQCAtNTY5LDcgKzU2OSw3IEBACiAJdWludDE2X3QJc3ZfdmxhbjsKIH07 CiAKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmlu ZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogLyoKICAqIEZyZWVCU0Qtc3R5bGUgaW9jdGxzLgogICov CmRpZmYgLXVyIHN5cy5vbGQvbmV0ODAyMTEvaWVlZTgwMjExX3Zhci5oIHN5cy9uZXQ4MDIxMS9p ZWVlODAyMTFfdmFyLmgKLS0tIHN5cy5vbGQvbmV0ODAyMTEvaWVlZTgwMjExX3Zhci5oCTIwMTEt MDYtMjAgMTM6NDY6MDMuMDAwMDAwMDAwICswMjAwCisrKyBzeXMvbmV0ODAyMTEvaWVlZTgwMjEx X3Zhci5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTQxOTA5NzIxICswMTAwCkBAIC0zNCw3ICszNCw3 IEBACiAvKiBOQjogcG9ydGFiaWxpdHkgZ2x1ZSBtdXN0IGdvIGZpcnN0ICovCiAjaWYgZGVmaW5l ZChfX05ldEJTRF9fKQogI2luY2x1ZGUgPG5ldDgwMjExL2llZWU4MDIxMV9uZXRic2QuaD4KLSNl bGlmIGRlZmluZWQoX19GcmVlQlNEX18pCisjZWxpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBk ZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICNpbmNsdWRlIDxuZXQ4MDIxMS9pZWVlODAyMTFf ZnJlZWJzZC5oPgogI2VsaWYgZGVmaW5lZChfX2xpbnV4X18pCiAjaW5jbHVkZSA8bmV0ODAyMTEv aWVlZTgwMjExX2xpbnV4Lmg+CmRpZmYgLXVyIHN5cy5vbGQvbmV0aW5ldC9zY3RwX2NvbnN0YW50 cy5oIHN5cy9uZXRpbmV0L3NjdHBfY29uc3RhbnRzLmgKLS0tIHN5cy5vbGQvbmV0aW5ldC9zY3Rw X2NvbnN0YW50cy5oCTIwMTEtMDktMTcgMTA6NTA6MjkuMDAwMDAwMDAwICswMjAwCisrKyBzeXMv bmV0aW5ldC9zY3RwX2NvbnN0YW50cy5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTQ1OTA4ODcyICsw MTAwCkBAIC0xMDIwLDcgKzEwMjAsNyBAQAogI2RlZmluZSBTQ1RQX0dFVFRJTUVfVElNRVZBTCh4 KQkoZ2V0bWljcm91cHRpbWUoeCkpCiAjZGVmaW5lIFNDVFBfR0VUUFRJTUVfVElNRVZBTCh4KQko bWljcm91cHRpbWUoeCkpCiAjZW5kaWYKLS8qI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRl ZmluZWQoX19BUFBMRV9fKSovCisvKiNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVk KF9fRnJlZUJTRF9rZXJuZWxfXykgfHwgZGVmaW5lZChfX0FQUExFX18pKi8KIC8qI2RlZmluZSBT Q1RQX0dFVFRJTUVfVElNRVZBTCh4KSB7IFwqLwogLyoJKHgpLT50dl9zZWMgPSB0aWNrcyAvIDEw MDA7IFwqLwogLyoJKHgpLT50dl91c2VjID0gKHRpY2tzICUgMTAwMCkgKiAxMDAwOyBcKi8KZGlm ZiAtdXIgc3lzLm9sZC9uZXRpbmV0L3NjdHBfcGNiLmggc3lzL25ldGluZXQvc2N0cF9wY2IuaAot LS0gc3lzLm9sZC9uZXRpbmV0L3NjdHBfcGNiLmgJMjAxMS0wOS0xNCAxMDoxNToyMS4wMDAwMDAw MDAgKzAyMDAKKysrIHN5cy9uZXRpbmV0L3NjdHBfcGNiLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4x NDg5MDk2MzIgKzAxMDAKQEAgLTI0MCw3ICsyNDAsNyBAQAogCSAqIEFsbCBzdGF0aWMgc3RydWN0 dXJlcyB0aGF0IGFuY2hvciB0aGUgc3lzdGVtIG11c3QgYmUgaGVyZS4KIAkgKi8KIAlzdHJ1Y3Qg c2N0cF9lcGluZm8gc2N0cHBjYmluZm87Ci0jaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgJiYgZGVm aW5lZChTTVApICYmIGRlZmluZWQoU0NUUF9VU0VfUEVSQ1BVX1NUQVQpCisjaWYgKGRlZmluZWQo X19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKSkgJiYgZGVmaW5lZChT TVApICYmIGRlZmluZWQoU0NUUF9VU0VfUEVSQ1BVX1NUQVQpCiAJc3RydWN0IHNjdHBzdGF0ICpz Y3Rwc3RhdDsKICNlbHNlCiAJc3RydWN0IHNjdHBzdGF0IHNjdHBzdGF0OwpAQCAtNjMyLDcgKzYz Miw3IEBACiAgICAgc3RydWN0IHNjdHBfaW5wY2IgKiwKICAgICB1aW50OF90IGNvX29mZik7CiAK LSNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSAmJiBkZWZpbmVkKFNDVFBfTUNPUkVfSU5QVVQpICYm IGRlZmluZWQoU01QKQorI2lmIChkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJl ZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoU0NUUF9NQ09SRV9JTlBVVCkgJiYgZGVmaW5lZChT TVApCiB2b2lkCiAgICAgIHNjdHBfcXVldWVfdG9fbWNvcmUoc3RydWN0IG1idWYgKm0sIGludCBv ZmYsIGludCBjcHVfdG9fdXNlKTsKIApkaWZmIC11ciBzeXMub2xkL25ldGluZXQvc2N0cF9zdHJ1 Y3RzLmggc3lzL25ldGluZXQvc2N0cF9zdHJ1Y3RzLmgKLS0tIHN5cy5vbGQvbmV0aW5ldC9zY3Rw X3N0cnVjdHMuaAkyMDExLTEwLTEwIDE4OjMxOjE4LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL25l dGluZXQvc2N0cF9zdHJ1Y3RzLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xNTA5MDc1MzEgKzAxMDAK QEAgLTEwOCw3ICsxMDgsNyBAQAogdHlwZWRlZiBpbnQgKCppbnBfZnVuYykgKHN0cnVjdCBzY3Rw X2lucGNiICosIHZvaWQgKnB0ciwgdWludDMyX3QgdmFsKTsKIHR5cGVkZWYgdm9pZCAoKmVuZF9m dW5jKSAodm9pZCAqcHRyLCB1aW50MzJfdCB2YWwpOwogCi0jaWYgZGVmaW5lZChfX0ZyZWVCU0Rf XykgJiYgZGVmaW5lZChTQ1RQX01DT1JFX0lOUFVUKSAmJiBkZWZpbmVkKFNNUCkKKyNpZiAoZGVm aW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pKSAmJiBkZWZp bmVkKFNDVFBfTUNPUkVfSU5QVVQpICYmIGRlZmluZWQoU01QKQogLyogd2hhdHMgb24gdGhlIG1j b3JlIGNvbnRyb2wgc3RydWN0ICovCiBzdHJ1Y3Qgc2N0cF9tY29yZV9xdWV1ZSB7CiAJVEFJTFFf RU5UUlkoc2N0cF9tY29yZV9xdWV1ZSkgbmV4dDsKZGlmZiAtdXIgc3lzLm9sZC9uZXRpbmV0L3Nj dHBfdWlvLmggc3lzL25ldGluZXQvc2N0cF91aW8uaAotLS0gc3lzLm9sZC9uZXRpbmV0L3NjdHBf dWlvLmgJMjAxMS0wOC0xNCAyMjo1NTozMi4wMDAwMDAwMDAgKzAyMDAKKysrIHN5cy9uZXRpbmV0 L3NjdHBfdWlvLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xNTI5MDU5ODkgKzAxMDAKQEAgLTEwNTYs NyArMTA1Niw3IEBACiAKICNkZWZpbmUgU0NUUF9TVEFUX0lOQ1IoX3gpIFNDVFBfU1RBVF9JTkNS X0JZKF94LDEpCiAjZGVmaW5lIFNDVFBfU1RBVF9ERUNSKF94KSBTQ1RQX1NUQVRfREVDUl9CWShf eCwxKQotI2lmIGRlZmluZWQoX19GcmVlQlNEX18pICYmIGRlZmluZWQoU01QKSAmJiBkZWZpbmVk KFNDVFBfVVNFX1BFUkNQVV9TVEFUKQorI2lmIChkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoU01QKSAmJiBkZWZpbmVkKFNDVFBf VVNFX1BFUkNQVV9TVEFUKQogI2RlZmluZSBTQ1RQX1NUQVRfSU5DUl9CWShfeCxfZCkgKFNDVFBf QkFTRV9TVEFUU1tQQ1BVX0dFVChjcHVpZCldLl94ICs9IF9kKQogI2RlZmluZSBTQ1RQX1NUQVRf REVDUl9CWShfeCxfZCkgKFNDVFBfQkFTRV9TVEFUU1tQQ1BVX0dFVChjcHVpZCldLl94IC09IF9k KQogI2Vsc2UKZGlmZiAtdXIgc3lzLm9sZC9zeXMvZGV2aWNlX3BvcnQuaCBzeXMvc3lzL2Rldmlj ZV9wb3J0LmgKLS0tIHN5cy5vbGQvc3lzL2RldmljZV9wb3J0LmgJMjAwNS0wMS0xOSAwMjozMToz My4wMDAwMDAwMDAgKzAxMDAKKysrIHN5cy9zeXMvZGV2aWNlX3BvcnQuaAkyMDExLTExLTEzIDE0 OjEyOjQxLjE1MzkwNzE3NCArMDEwMApAQCAtMjksNyArMjksNyBAQAogCiAjaWYgZGVmaW5lZChf X05ldEJTRF9fKQogIyBpbmNsdWRlIDxzeXMvZGV2aWNlLmg+Ci0jZWxpZiBkZWZpbmVkKF9fRnJl ZUJTRF9fKQorI2VsaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rf a2VybmVsX18pCiAjIGluY2x1ZGUgPHN5cy9tb2R1bGUuaD4KICMgaW5jbHVkZSA8c3lzL2J1cy5o PgogI2VuZGlmCkBAIC00Myw3ICs0Myw3IEBACiAjIGRlZmluZSBERVZQT1JUX0RFVk5BTUUoZGV2 KQkJKGRldikuZHZfeG5hbWUKICMgZGVmaW5lIERFVlBPUlRfREVWVU5JVChkZXYpCQkoZGV2KS5k dl91bml0CiAKLSNlbGlmIGRlZmluZWQoX19GcmVlQlNEX18pCisjZWxpZiBkZWZpbmVkKF9fRnJl ZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIC8qCiAgKiBGcmVlQlNEIChj b21wYXRpYmlsaXR5IGZvciBzdHJ1Y3QgZGV2aWNlKQogICovCmRpZmYgLXVyIHN5cy5vbGQvc3lz L3RpbWV4Lmggc3lzL3N5cy90aW1leC5oCi0tLSBzeXMub2xkL3N5cy90aW1leC5oCTIwMDUtMDEt MDcgMDM6Mjk6MjcuMDAwMDAwMDAwICswMTAwCisrKyBzeXMvc3lzL3RpbWV4LmgJMjAxMS0xMS0x MyAxNDoxMjo0MS4xNTU5MDc1ODcgKzAxMDAKQEAgLTIxOCw3ICsyMTgsNyBAQAogCWxvbmcJc3Ri Y250OwkJLyogc3RhYmlsaXR5IGxpbWl0IGV4Y2VlZGVkIChybykgKi8KIH07CiAKLSNpZmRlZiBf X0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNE X2tlcm5lbF9fKQogCiAjaWZkZWYgX0tFUk5FTAogdm9pZAludHBfdXBkYXRlX3NlY29uZChpbnQ2 NF90ICphZGp1c3RtZW50LCB0aW1lX3QgKm5ld3NlYyk7Cg== --90e6ba6e836c3e770904b1dd6a9a-- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 16 18:07: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 1F23A1065676; Wed, 16 Nov 2011 18:07:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 030D68FC14; Wed, 16 Nov 2011 18:07:16 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 5A6793581; Wed, 16 Nov 2011 10:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1321466835; bh=jkJZaJhX/rrEb0YD/QYLuIEo+8OTJy3BAaSuUsRvJbc=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YFrq1LZwtR8fpuzwW1+bPyCOMO0G7rDYrcSFxEdJjywyBcv7sd+re5tockDUrmdlT 9Dtsb61soQNZMpndXW0L3Kaue0USEluiDGzD45W8IVyTcu1lUC7l12LYZkEbWQE95O jp97XT4JbE1UMDRYcDbQffEmxkPES0Dak3bcX8bE= Message-ID: <4EC3FBD2.4070009@delphij.net> Date: Wed, 16 Nov 2011 10:07:14 -0800 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: Robert Millan References: In-Reply-To: OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:07:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/16/11 09:27, Robert Millan wrote: > Hi! > > Out of the kernel headers that are installed in /usr/include/ > hierracy, there are some which include support multiple operating > systems (usually FreeBSD and other *BSD flavours). > > This patch adds support to detect GNU/kFreeBSD as well. In all > cases, we match the same declarations as FreeBSD does (which is to > be expected in kernel headers, since both systems share the same > kernel). > > Does it look fine? Just my $0.02 -- I think we should probably do it in a more centralized place -- otherwise in case someone imported some new code, they have to do the same defined(__FreeBSD__) || defined(__FreeBSD_kernel__)? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOw/vSAAoJEATO+BI/yjfBozIIAMuqmkNkDkWG4Kra/mQ5HQXZ Oe/bndGzfUl9H6epFZWc+eeT2zxnlvVUGwVf5si3THU23dZkmynbPj1NnY+oDewt TwB5nbG0tcClMMesK8L9lJB5AxKHsRtILK8l8xMzsJEj6fRjb8+yrjj8LLK7zUNk gTQA/sOVR2a4ZARkUlvbgNsE/BBx7NijxFS3uMA91AgsXAniBp4ND6dDwAudQIpW MqLH4DxJX/6EC2E9ibM5IBB8wguaUWF52oHLGnRAs2JkXzNS/qj6aSepjivSIUzh gtKKteCpRNexnWq+2pym9OE6tmxW8uoPNUuBxZqOP+laabcn392silZrE0yElh8= =XHtJ -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Wed Nov 16 18:26:10 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 5F7CC106564A; Wed, 16 Nov 2011 18:26:10 +0000 (UTC) (envelope-from rmh.aybabtu@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 EE3968FC18; Wed, 16 Nov 2011 18:26:09 +0000 (UTC) Received: by iakl21 with SMTP id l21so1417055iak.13 for ; Wed, 16 Nov 2011 10:26:09 -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=JqcReVnpsxN2/UqYZ4ljiP6p1hGT8tlS/83h2PRmvlM=; b=g3SX/IoACSD1+sg1kJwQP+7No2zwkSRSZSGj8gcoJ84hEvGfvkc/1fYk9bBCW78a4D mXzCUfSUT2Ea/j1ga0L8DfznGz9Ed9uvKwrM+6bc0e9b9DPs0X0Y0vENLRv6nQg0+pSu eMmu5V8vDYPoHU9jRTExma2ScIv6GZEolyskI= MIME-Version: 1.0 Received: by 10.42.135.66 with SMTP id o2mr33643126ict.0.1321467969092; Wed, 16 Nov 2011 10:26:09 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Wed, 16 Nov 2011 10:26:09 -0800 (PST) In-Reply-To: <4EC3FBD2.4070009@delphij.net> References: <4EC3FBD2.4070009@delphij.net> Date: Wed, 16 Nov 2011 19:26:09 +0100 X-Google-Sender-Auth: ebUx-h__hYYpl6-mAj8rVFShKug Message-ID: From: Robert Millan To: d@delphij.net Content-Type: text/plain; charset=UTF-8 Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 16 Nov 2011 18:26:10 -0000 2011/11/16 Xin LI : > Just my $0.02 -- I think we should probably do it in a more > centralized place -- otherwise in case someone imported some new code, > they have to do the same defined(__FreeBSD__) || > defined(__FreeBSD_kernel__)? How about something like: #if defined(__FreeBSD__) && !defined(__FreeBSD_kernel__) #define __FreeBSD_kernel__ #endif it can be placed at beginning of each header, then the rest becomes much simpler. Note this has the side-effect of defining __FreeBSD_kernel__ on FreeBSD, which I suspect some people won't be fond of. An alternative could be to come up with an ad-hoc macro that means "this system is either FreeBSD or uses the same kernel as FreeBSD" and define it where needed. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 16 18:39:14 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 DE1B2106564A; Wed, 16 Nov 2011 18:39:14 +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 8743E8FC08; Wed, 16 Nov 2011 18:39:14 +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 pAGIWdJD001766 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 11:32:41 -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: Wed, 16 Nov 2011 11:32:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Millan 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, 16 Nov 2011 11:32:41 -0700 (MST) Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 16 Nov 2011 18:39:15 -0000 Hey Robert, Thanks for jumping into this. Sadly, it is a bit of a mess. Many of = the "multiple BSD flavor" support #ifdefs are actually quite stale by = now, so they should be cleaned up. That's not something you have to = cope with, unless you want, but it colors my first reaction :) My second reaction was why not have #ifndef __FreeBSD_kernel__ #define __FreeBSD_kernel__ __FreeBSD__ #endif in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in = the headers that are affected? But I'm not quite sure what effects that = would have on your environment. Thanks for considering the above modification. Warner On Nov 16, 2011, at 10:27 AM, Robert Millan wrote: > Hi! >=20 > Out of the kernel headers that are installed in /usr/include/ = hierracy, there > are some which include support multiple operating systems (usually = FreeBSD and > other *BSD flavours). >=20 > This patch adds support to detect GNU/kFreeBSD as well. In all cases, = we > match the same declarations as FreeBSD does (which is to be expected = in kernel > headers, since both systems share the same kernel). >=20 > Does it look fine? > = _______________________________________________= > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Wed Nov 16 18:40: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 C22FF106566B; Wed, 16 Nov 2011 18:40:36 +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 6C3998FC21; Wed, 16 Nov 2011 18:40:36 +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 pAGIWdJE001766 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 11:33:37 -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: Wed, 16 Nov 2011 11:33:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC3FBD2.4070009@delphij.net> To: Robert Millan 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, 16 Nov 2011 11:33:38 -0700 (MST) Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, d@delphij.net, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 16 Nov 2011 18:40:36 -0000 On Nov 16, 2011, at 11:26 AM, Robert Millan wrote: > 2011/11/16 Xin LI : >> Just my $0.02 -- I think we should probably do it in a more >> centralized place -- otherwise in case someone imported some new = code, >> they have to do the same defined(__FreeBSD__) || >> defined(__FreeBSD_kernel__)? >=20 > How about something like: >=20 > #if defined(__FreeBSD__) && !defined(__FreeBSD_kernel__) > #define __FreeBSD_kernel__ > #endif >=20 > it can be placed at beginning of each header, then the rest becomes > much simpler. >=20 > Note this has the side-effect of defining __FreeBSD_kernel__ on > FreeBSD, which I suspect some people won't be fond of. An alternative > could be to come up with an ad-hoc macro that means "this system is > either FreeBSD or uses the same kernel as FreeBSD" and define it where > needed. I had a similar suggestion... Why do you think people wouldn't be fond of the __FreeBSD_kernel__ being = defined? Warner From owner-freebsd-arch@FreeBSD.ORG Wed Nov 16 18:41: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 623181065672; Wed, 16 Nov 2011 18:41:01 +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 ED3838FC28; Wed, 16 Nov 2011 18:41:00 +0000 (UTC) Received: by vws11 with SMTP id 11so9531vws.13 for ; Wed, 16 Nov 2011 10:41:00 -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=3W/FTZltOIEIE8YP+TWBUcpi6czuk4wujwFySUOnu6I=; b=jaG+oXuLdKwcOsM47FNpNbzs/eoVq3XYy/sICKpi2I8zl/XoYrjm0eaMtOSX9pyOzx Kat6AVhUOjMQFxeRNC+PJ/PhzqKAAXjGubcP/+gBb2lhVBpiNfY6OaFnQHsA/OJPh56C vdxxO9MPdjh2M8T4AFW+NcFhoPbUh1v6Z9o0A= MIME-Version: 1.0 Received: by 10.52.92.84 with SMTP id ck20mr52164707vdb.88.1321468860328; Wed, 16 Nov 2011 10:41:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Wed, 16 Nov 2011 10:41:00 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 10:41:00 -0800 X-Google-Sender-Auth: ROGF-iUxe-RhCETRLlA9mA7GKOc Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Robert Millan Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 16 Nov 2011 18:41:01 -0000 .. my suggestion (high level, fluffy) is to try to get approval/consensus on fixing the immediate problem so things are consistently horrible, then a second pass to make them consistently unhorrible. Adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 17 06:46: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 D1892106564A; Thu, 17 Nov 2011 06:46:41 +0000 (UTC) (envelope-from rmh.aybabtu@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 6962A8FC12; Thu, 17 Nov 2011 06:46:35 +0000 (UTC) Received: by iakl21 with SMTP id l21so2447280iak.13 for ; Wed, 16 Nov 2011 22:46:35 -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=k+M9Osvwlg6dTn3Exvf1g0+ocege0lVkUDWNtpVVqdQ=; b=lol/jPao/F6MahaL2Viu6PtX0TkpS6fvdy7Ij2hME9hXDhdObZ9chlC/eKTnsqLtru /Dyp2zsDza8NYl5LZmVKfNnqCKygapnH2uIEAQ9RKIXFtY5TjtthPOCEdBNzkSX6TYOT keL4HeXaeZ69eATfAG6OpHsIEilC00R1c316w= MIME-Version: 1.0 Received: by 10.42.150.135 with SMTP id a7mr38899287icw.53.1321512393803; Wed, 16 Nov 2011 22:46:33 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Wed, 16 Nov 2011 22:46:33 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Nov 2011 07:46:33 +0100 X-Google-Sender-Auth: AiIl9JZNGtYPSiLuDzTOwqEBN1Q Message-ID: From: Robert Millan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 17 Nov 2011 06:46:41 -0000 2011/11/16 Warner Losh : > My second reaction was why not have > > #ifndef __FreeBSD_kernel__ > #define __FreeBSD_kernel__ __FreeBSD__ > #endif > > in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in = the headers that are affected? =C2=A0But I'm not quite sure what effects th= at would have on your environment. I'm fine with this. > Why do you think people wouldn't be fond of the __FreeBSD_kernel__ being = defined? See archived discussion: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035721.html particularly this mail in which you participated: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035823.html From owner-freebsd-arch@FreeBSD.ORG Thu Nov 17 14:59:58 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 CE3A71065677; Thu, 17 Nov 2011 14:59:58 +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 A23498FC1B; Thu, 17 Nov 2011 14:59:58 +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 4F2AC46B0A; Thu, 17 Nov 2011 09:59:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DC1A78A053; Thu, 17 Nov 2011 09:59:57 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 17 Nov 2011 09:59:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111170959.56767.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 09:59:58 -0500 (EST) Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org, Robert Millan Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 17 Nov 2011 14:59:58 -0000 On Thursday, November 17, 2011 1:46:33 am Robert Millan wrote: > 2011/11/16 Warner Losh : > > My second reaction was why not have > > > > #ifndef __FreeBSD_kernel__ > > #define __FreeBSD_kernel__ __FreeBSD__ > > #endif > > > > in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in the headers that are affected? But I'm not quite sure what effects that would have on your environment. > > I'm fine with this. > > > Why do you think people wouldn't be fond of the __FreeBSD_kernel__ being defined? > > See archived discussion: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035721.html > > particularly this mail in which you participated: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035823.html I recall the discussion from earlier. I can't recall if I had replied to it though. :-/ In my current opinion, I think it would be fine to define __FreeBSD_kernel__ on FreeBSD and to do it in for now until all the compilers we use have been updated to define it automatically (which may be a long time). I think it will also be fine to patch in-system headers to use __FreeBSD_kernel__ once is defined. Unfortunately headers in 3rd party software are going to have to check for both __FreeBSD__ and __FreeBSD_kernel__ to support both GNU/kFreeBSD and older FreeBSD for the foreseeable future. I think that is fine, but that the sooner we add __FreeBSD_kernel__ on FreeBSD the sooner we get the clock started for a day when those extra checks can go away. I would also be fine with MFC'ing the addition of __FreeBSD_kernel__ to older branches (at least 7 - 9) as well. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Nov 17 16:42: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 4EB211065675 for ; Thu, 17 Nov 2011 16:42:05 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 117538FC19 for ; Thu, 17 Nov 2011 16:42:04 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 34CB1613F for ; Thu, 17 Nov 2011 16:24:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E8E158010; Thu, 17 Nov 2011 17:24:37 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: arch@freebsd.org Date: Thu, 17 Nov 2011 17:24:37 +0100 Message-ID: <868vnepvi2.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Subject: Different CFLAGS for shared and static libraries 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, 17 Nov 2011 16:42:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The attached patch adds support for using different CFLAGS for shared and static libraries. Specifically, it adds SHARED_{C,CXX}FLAGS variables which are added to the cc / cxx command line when building shared libraries, and STATIC_{C,CXX}FLAGS which are used when building static libraries. The rationale is that certain libraries (libpam, possibly also libnss) contain code which is specific to either shared or static libraries. It is possible (with some effort) to detect this by inspecting certain preprocessor macros, but not in a reliable or portable manner, whether across platforms or compilers. For instance, IIRC, MIPS code is always compiled with -DPIC. The downside is that the .c.o rule is no longer implicit. Using this patch, I was able to greatly simplify the libpam build. It is no longer a prebuild lib and no longer needs to be built twice. This also means that certain other libraries - libssh, for one - can move out of _prebuild_libs. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=static_cflags.diff Index: share/mk/bsd.lib.mk =================================================================== --- share/mk/bsd.lib.mk (revision 227616) +++ share/mk/bsd.lib.mk (working copy) @@ -67,23 +67,29 @@ PO_FLAG=-pg +.c.o: + ${CC} ${STATIC_CFLAGS} ${CFLAGS} -c ${.IMPSRC} -o ${.TARGET} + .c.po: - ${CC} ${PO_FLAG} ${PO_CFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CC} ${PO_FLAG} ${STATIC_CFLAGS} ${PO_CFLAGS} -c ${.IMPSRC} -o ${.TARGET} @[ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] || \ (${ECHO} ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} && \ ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}) .c.So: - ${CC} ${PICFLAG} -DPIC ${CFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CC} ${PICFLAG} -DPIC ${SHARED_CFLAGS} ${CFLAGS} -c ${.IMPSRC} -o ${.TARGET} @[ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] || \ (${ECHO} ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} && \ ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}) +.cc.o: + ${CXX} ${STATIC_CXXFLAGS} ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + .cc.po .C.po .cpp.po .cxx.po: - ${CXX} ${PO_FLAG} ${PO_CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CXX} ${PO_FLAG} ${STATIC_CXXFLAGS} ${PO_CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} .cc.So .C.So .cpp.So .cxx.So: - ${CXX} ${PICFLAG} -DPIC ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} + ${CXX} ${PICFLAG} -DPIC ${SHARED_CXXFLAGS} ${CXXFLAGS} -c ${.IMPSRC} -o ${.TARGET} .f.po: ${FC} -pg ${FFLAGS} -o ${.TARGET} -c ${.IMPSRC} --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 17 17:28: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 2687A1065673; Thu, 17 Nov 2011 17:28:24 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id D239A8FC17; Thu, 17 Nov 2011 17:28:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id C776B446004; Thu, 17 Nov 2011 12:11:24 -0500 (EST) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqOiyXUH4ZgV; Thu, 17 Nov 2011 12:11:23 -0500 (EST) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 7E560446003; Thu, 17 Nov 2011 12:11:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> Date: Thu, 17 Nov 2011 12:11:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0850D6DB-386B-4588-A362-D53637D25F7D@averesystems.com> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1084) Cc: arch@freebsd.org, current@freebsd.org, avg@freebsd.org Subject: Re: Stop scheduler on panic 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, 17 Nov 2011 17:28:24 -0000 On Nov 13, 2011, at 3:32 AM, Kostik Belousov wrote: > I was tricked into finishing the work by Andrey Gapon, who developed > the patch to reliably stop other processors on panic. The patch > greatly improves the chances of getting dump on panic on SMP host. > Several people already saw the patchset, and I remember that Andrey > posted it to some lists. >=20 > The change stops other (*) processors early upon the panic. This way, > no parallel manipulation of the kernel memory is performed by CPUs. > In particular, the kernel memory map is static. Patch prevents the > panic thread from blocking and switching out. >=20 > * - in the context of the description, other means not current. >=20 > Since other threads are not run anymore, lock owner cannot release a > lock which is required by panic thread. Due to this, we need to fake > a lock acquisition after the panic, which adds minimal overhead to the > locking cost. The patch tries to not add any overhead on the fast path > of the lock acquire. The check for the after-panic condition was > reduced to single memory access, done only when the quick cas lock > attempt failed, and braced with __unlikely compiler hint. >=20 > For now, the new mode of operation is disabled by default, since some > further USB changes are needed to make USB keyboard usable in that > environment. >=20 > With the patch, getting a dump from the machine without debugger > compiled in is much more realistic. Please comment, I will commit the > change in 2 weeks unless strong reasons not to are given. >=20 > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch >=20 We have many systems running Andriy's latest version of the patch under = 8.2. I also brought in the related USB patch; without it, the system = hangs up while dumping almost every time. With both patches in place* = it has worked flawlessly for us. -Andrew * - with one change: always do the critical_enter() / critical_exit(). = Using spinlock_enter() blocks the software watchdog, which needs to = still be active in case the dump hangs for other reasons. This is = obviously not ideal but the best solution I have right now. We also = stop all of the network interfaces at the beginning of boot(). -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-arch@FreeBSD.ORG Thu Nov 17 19:02:04 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 5A64B106566B; Thu, 17 Nov 2011 19:02:04 +0000 (UTC) (envelope-from rmh.aybabtu@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 EAA148FC0C; Thu, 17 Nov 2011 19:02:02 +0000 (UTC) Received: by iakl21 with SMTP id l21so3645416iak.13 for ; Thu, 17 Nov 2011 11:02: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; bh=8LwgUESB/Z7RfXwnSrQ7hBbBfbrOQZxR/t8gOgpcY2U=; b=WgihhmTattVPMjmNKoYt8jyHq/aXZmm7agj45g3VTjHas9UMCdFlRCul2aivCXoZIA 7MFPEiMw6lJv0uu699fyO0rEnnND+qTg/KpFBAwkfWUofzfie6xktEwWlP3+EpwO2J+P fLiHxNVGLvHwLKJ31DvIbZYuP3dDwp1knrnL8= MIME-Version: 1.0 Received: by 10.42.96.132 with SMTP id j4mr103194icn.50.1321556522642; Thu, 17 Nov 2011 11:02:02 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Thu, 17 Nov 2011 11:02:02 -0800 (PST) In-Reply-To: <201111170959.56767.jhb@freebsd.org> References: <201111170959.56767.jhb@freebsd.org> Date: Thu, 17 Nov 2011 20:02:02 +0100 X-Google-Sender-Auth: aY09Fz8sb6SxrRzTrLVeJbcrTAg Message-ID: From: Robert Millan To: John Baldwin Content-Type: multipart/mixed; boundary=20cf303ea614152c2d04b1f2db2b Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 17 Nov 2011 19:02:04 -0000 --20cf303ea614152c2d04b1f2db2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2011/11/17 John Baldwin : > I recall the discussion from earlier. =C2=A0I can't recall if I had repli= ed to it > though. :-/ =C2=A0In my current opinion, I think it would be fine to defi= ne > __FreeBSD_kernel__ on FreeBSD and to do it in for now until= all > the compilers we use have been updated to define it automatically (which = may > be a long time). =C2=A0I think it will also be fine to patch in-system he= aders to > use __FreeBSD_kernel__ once is defined. =C2=A0Unfortunately= headers > in 3rd party software are going to have to check for both __FreeBSD__ and > __FreeBSD_kernel__ to support both GNU/kFreeBSD and older FreeBSD for the > foreseeable future. =C2=A0I think that is fine, but that the sooner we ad= d > __FreeBSD_kernel__ on FreeBSD the sooner we get the clock started for a d= ay > when those extra checks can go away. =C2=A0I would also be fine with MFC'= ing the > addition of __FreeBSD_kernel__ to older branches (at least 7 - 9) as well= . Well, here's a patch then. I wrote a comment in it trying to explain the situation. Please let me know what you think. --20cf303ea614152c2d04b1f2db2b Content-Type: text/x-diff; charset=US-ASCII; name="freebsd_kernel.diff" Content-Disposition: attachment; filename="freebsd_kernel.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv44mibq0 SW5kZXg6IHN5cy9zeXMvcGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3BhcmFtLmgJKHJl dmlzaW9uIDIyNzU4MCkKKysrIHN5cy9zeXMvcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtNjAs NiArNjAsMjMgQEAKICN1bmRlZiBfX0ZyZWVCU0RfdmVyc2lvbgogI2RlZmluZSBfX0ZyZWVCU0Rf dmVyc2lvbiAxMDAwMDAxCS8qIE1hc3RlciwgcHJvcGFnYXRlZCB0byBuZXd2ZXJzICovCiAKKy8q CisgKiBfX0ZyZWVCU0Rfa2VybmVsX18gaW5kaWNhdGVzIHRoYXQgdGhpcyBzeXN0ZW0gdXNlcyB0 aGUga2VybmVsIG9mIEZyZWVCU0QsCisgKiB3aGljaCBieSBkZWZpbml0aW9uIGlzIGFsd2F5cyB0 cnVlIG9uIEZyZWVCU0QgOi0pLiBUaGlzIG1hY3JvIG1heSBhbHNvCisgKiBiZSBkZWZpbmVkIG9u IG90aGVyIHN5c3RlbXMgdGhhdCB1c2UgdGhlIGtlcm5lbCBvZiBGcmVlQlNELCBzdWNoIGFzCisg KiBHTlUva0ZyZWVCU0QuCisgKgorICogSXQgaXMgdGVtcHRpbmcgdG8gdXNlIHRoaXMgbWFjcm8g aW4gdXNlcmxhbmQgY29kZSB3aGVuIHdlIHdhbnQgdG8gZW5hYmxlCisgKiBrZXJuZWwtc3BlY2lm aWMgcm91dGluZXMsIGFuZCBpbiBmYWN0IGl0J3MgZmluZSB0byBkbyB0aGlzIGluIGNvZGUgdGhh dAorICogaXMgcGFydCBvZiBGcmVlQlNEIGl0c2VsZi4gIEhvd2V2ZXIsIGJlIGF3YXJlIHRoYXQg YXMgcHJlc2VuY2Ugb2YgdGhpcworICogbWFjcm8gaXMgc3RpbGwgbm90IHdpZGVzcHJlYWQgKGUu Zy4gb2xkZXIgRnJlZUJTRCB2ZXJzaW9ucywgM3JkIHBhcnR5CisgKiBjb21waWxlcnMsIGV0Yyks IGl0IGlzIFNUUk9OR0xZIERJU0NPVVJBR0VEIHRvIGNoZWNrIGZvciB0aGlzIG1hY3JvIGluCisg KiBleHRlcm5hbCBhcHBsaWNhdGlvbnMgd2l0aG91dCBhbHNvIGNoZWNraW5nIGZvciBfX0ZyZWVC U0RfXyBhcyBhbgorICogYWx0ZXJuYXRpdmUuCisgKi8KKyN1bmRlZiBfX0ZyZWVCU0Rfa2VybmVs X18KKyNkZWZpbmUgX19GcmVlQlNEX2tlcm5lbF9fIF9fRnJlZUJTRF9fCisKICNpZmRlZiBfS0VS TkVMCiAjZGVmaW5lCVBfT1NSRUxfU0lHV0FJVAkJNzAwMDAwCiAjZGVmaW5lCVBfT1NSRUxfU0lH U0VHVgkJNzAwMDA0Cg== --20cf303ea614152c2d04b1f2db2b-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 17 21:32: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 B1C551065673; Thu, 17 Nov 2011 21:32:36 +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 850F18FC0C; Thu, 17 Nov 2011 21:32:36 +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 2218946B06; Thu, 17 Nov 2011 16:32:36 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A27508A050; Thu, 17 Nov 2011 16:32:35 -0500 (EST) From: John Baldwin To: Robert Millan Date: Thu, 17 Nov 2011 16:32:34 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111170959.56767.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111171632.34979.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 16:32:35 -0500 (EST) Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 17 Nov 2011 21:32:36 -0000 On Thursday, November 17, 2011 2:02:02 pm Robert Millan wrote: > 2011/11/17 John Baldwin : > > I recall the discussion from earlier. I can't recall if I had replied to it > > though. :-/ In my current opinion, I think it would be fine to define > > __FreeBSD_kernel__ on FreeBSD and to do it in for now until all > > the compilers we use have been updated to define it automatically (which may > > be a long time). I think it will also be fine to patch in-system headers to > > use __FreeBSD_kernel__ once is defined. Unfortunately headers > > in 3rd party software are going to have to check for both __FreeBSD__ and > > __FreeBSD_kernel__ to support both GNU/kFreeBSD and older FreeBSD for the > > foreseeable future. I think that is fine, but that the sooner we add > > __FreeBSD_kernel__ on FreeBSD the sooner we get the clock started for a day > > when those extra checks can go away. I would also be fine with MFC'ing the > > addition of __FreeBSD_kernel__ to older branches (at least 7 - 9) as well. > > Well, here's a patch then. I wrote a comment in it trying to explain > the situation. Please let me know what you think. Hmm, I wonder if it's better to use the #ifndef approach rather than #undef so that when compilers are updated to DTRT we will honor their settings? (And eventually this could be maybe removed from param.h altogether.) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Nov 18 06:47: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 4AEAF106568C; Fri, 18 Nov 2011 06:47:21 +0000 (UTC) (envelope-from rmh.aybabtu@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 E00C28FC0A; Fri, 18 Nov 2011 06:47:20 +0000 (UTC) Received: by iakl21 with SMTP id l21so4680114iak.13 for ; Thu, 17 Nov 2011 22:47:19 -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=Wya4bzIxnif0+Z1je+0QPhKvYLh5o6dnK4POQj8O5Os=; b=Mav0/furJu7zn7RK/Z6xhnPy+VB8pJRcGbqbrb1WqygfvhecEIyg56WAbGNtSt2ZoH lUi8m8mGLPo34IIPkWpUYQ/fkDbZi9hNMsoK4k4LZAB+4ZBCnGKn81Fzo989z31GBhjy HjrdjgkhxRFqhgiJGHx7hh3NePxLk8y6LA1YQ= MIME-Version: 1.0 Received: by 10.42.135.66 with SMTP id o2mr1295447ict.0.1321598839444; Thu, 17 Nov 2011 22:47:19 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Thu, 17 Nov 2011 22:47:19 -0800 (PST) In-Reply-To: <201111171632.34979.jhb@freebsd.org> References: <201111170959.56767.jhb@freebsd.org> <201111171632.34979.jhb@freebsd.org> Date: Fri, 18 Nov 2011 07:47:19 +0100 X-Google-Sender-Auth: 7GOt4SHay_RPr6AKNyeK6txG96U Message-ID: From: Robert Millan To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 18 Nov 2011 06:47:21 -0000 2011/11/17 John Baldwin : > Hmm, I wonder if it's better to use the #ifndef approach rather than #undef > so that when compilers are updated to DTRT we will honor their settings? Well, the compiler is supposed to know better than sys/param.h, because it inherited this number from the runtime kernel when it was built. However, __FreeBSD__ comes from the compiler already so if you "#define __FreeBSD_kernel__ __FreeBSD__" you get the information from the compiler anyway. As both approaches do the same thing, I really don't mind either way. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 18 18:24:46 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 105CD1065791; Fri, 18 Nov 2011 18:24:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 18BC78FC12; Fri, 18 Nov 2011 18:24:44 +0000 (UTC) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAIGBm5c016865; Sat, 19 Nov 2011 03:11:48 +1100 Received: from c211-28-227-231.carlnfd1.nsw.optusnet.com.au (c211-28-227-231.carlnfd1.nsw.optusnet.com.au [211.28.227.231]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pAIGBhIT014972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2011 03:11:45 +1100 Date: Sat, 19 Nov 2011 03:11:43 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Wemm In-Reply-To: Message-ID: <20111119003059.V5050@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1274663310-1321632703=:5050" 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: Fri, 18 Nov 2011 18:24:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1274663310-1321632703=:5050 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 10 Nov 2011, 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? "They" (TIOC[SG]PGRP) aren't deprecated. They are fundamental ioctls used to implement tc[sg]etpgrp(3). There are no specific syscalls for the latter. The ioctls are probably deprecated, or even never supported for direct use. >>>> FYI FIFO doesn't support them. These interfaces are for job control. What they mean for pipes and fifos is unclear. I don't really understand what sys_pipe.c does for them. It just makes TIOC[SG]PRGP the same as FIO[SG]ETOWN with the arg negated. That makes some sense -- pgrps are normally represented as negative pids, so if the underlying setown functions support both prgps and processes as they should, using the usual sign hack to distinguish pgrps for procs, then a sign change is needed to meet the API of the under underlying functions. >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=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. */ These "deprecated" comments were written by truckman. He fixed many bugs in the [gs]etown interfaces. I made some comments about this. AFAIR we only tried to fix only parts of [gs]etown including F_SETOWN (part of fcntl()), and changes to the [gs]etpgroup interfaces were mainly side effects, including the above fairly-misleading comment. >>>> - =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; I think what these comments mean is: "TIOC[SG]PGRP should only be used on ttys (and then only via tc[gs]etpgrp()), but in case something abused it on pipes, keep doing things the old way as above)." Diffs for the above between 2.2.9 and 3.final: % Index: sys_pipe.c % =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D % RCS file: /home/ncvs/src/sys/kern/sys_pipe.c,v % retrieving revision 1.21 % retrieving revision 1.46.2.5 % diff -u -2 -r1.21 -r1.46.2.5 % --- sys_pipe.c=0911 Oct 1996 02:27:30 -0000=091.21 % +++ sys_pipe.c=0924 Mar 2000 00:48:57 -0000=091.46.2.5 % @@ -962,10 +952,18 @@ % =09=09return (0); %=20 % -=09case TIOCSPGRP: % -=09=09mpipe->pipe_pgid =3D *(int *)data; % +=09case FIOSETOWN: % +=09=09return (fsetown(*(int *)data, &mpipe->pipe_sigio)); % + % +=09case FIOGETOWN: % +=09=09*(int *)data =3D fgetown(mpipe->pipe_sigio); % =09=09return (0); %=20 % +=09/* This is deprecated, FIOSETOWN should be used instead. */ % +=09case TIOCSPGRP: % +=09=09return (fsetown(-(*(int *)data), &mpipe->pipe_sigio)); % + % +=09/* This is deprecated, FIOGETOWN should be used instead. */ % =09case TIOCGPGRP: % -=09=09*(int *)data =3D mpipe->pipe_pgid; % +=09=09*(int *)data =3D -fgetown(mpipe->pipe_sigio); % =09=09return (0); So the old way was to only support the TIOC* interfaces, presumably with the same semantics as now modulo bugs that are hopefully fixed now. Note that we usually get here, at least now, for fcntl(fd, F_[SG]ETOWN, ...= ). This converts to the FIO[SG]ETOWN ioctls. Direct use of these ioctls is or should be deprecated. The bugs hopefully fixed by truckman are caused by the ioctls being device-specific while the fcntl()s are file-descriptor or file-specific (I can never remember which). Old code used a single pid or pgid per device. This more or less works for devices, but it cannot work for multiple fd's or files open on the same device. The fcntl() APIs support both processes and process groups encoded in a single arg using the usual sign hack, but the old TIOC[SG]PGRP should be limited by their very name to only supporting process groups. I think they aren't actually limited. The current one, especially, blindly flips the sign and does no range checking before getting to the lower level function which accept all values (with originally negative pgids being becoming positive and being interpreted as pids). That's another reason why TIOC[SG]PGRP is garbage for pipes. Another reason is that POSIX requires tcsetprgrp() "shall fail" if the calling process does not have a controlling terminal, or the file is not the controlling terminal, or the controlling terminal is no longer associated with the session of the calling process. The error for this is ENOTTY. Since FreeBSD's implementation of tcsetprgrp() uses ioctl(), it will return this error automatically if the device is not a tty, provided TIOC[SG]PRGP is not bogusly referenced in files for non-tty devices. None of these ioctls or fcntl()s is used often (except the TIOC* ones for ttys). Perhaps the TIOC* ones have never been abused (to give FIO*/fcntl() ones) for pipes. >>> 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. Well, not really. TIOC[SG]PGRP never gave job control for pipes. >>> 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. This stuff in sys_pipe.c is simple compared with tty.c :-). tty.c actually understands controlling terminals. In particular, it checks all the POSIX conditions stated above for tcsetprgrp(). Its handling of FIO[GS]ETOWN is quite different from its handling of TIOC[GS]PGRP. There are fewer restrictions for the former, and the complications are in the f[sg]etown() functions. >>> 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 f= ifos. > this is a classic BSD job control API. Not really on pipes -- see above. Even less on sockets: - sockets don't seem to ever have abused TIOC[SG]PGRP - instead, for sockets, there is SIOC[SG]PGRP. This is used in sys_socket.= c in exactly the same way that TIOC[SG]PGRP is abused in sys_pipe.c. - since its name is spelled with an 'S' (strictly, since its number is spelled with an 's'), job control code like tcstpgrp() can't reach the socket layer even if it is misapplied to a socket fd, and so it can't bogusly succeed. - SIOC[SG]PGRP shouldn't exist, since like TIOC[SG]PGRP on pipes, it just reverses the sign, so it was superseded by FIO[SG]ETOWN (or better the fcntl()). As for pipes, it now bogusly works on non-pgrps. - SIOC[SG]PGRP is not documented in any man page. This matches its supersedence, but was probably a bug -- it is a very old interface; FreeBSD-1 has it for sockets. (FreeBSD-1 also has TIOC*PGRP for the log device and perhaps for some other devices outside of kern, but not for pipes). It also has the following messy translations between FIO* and TIOC*, which must have been cleaned up by truckman, and show that the old way was probably not for these TIOC and FIO ioctls to actually be used; instead, what always sort of worked was the fcntl(), using these messy translations to get to older internals using TIOC or FIO: =09FreeBSD-1 ioctl(): % =09case FIOSETOWN: % =09=09tmp =3D *(int *)data; % =09=09if (fp->f_type =3D=3D DTYPE_SOCKET) { % =09=09=09((struct socket *)fp->f_data)->so_pgid =3D tmp; =09This starts with the FIOSETOWN ioctl. (Unfortunately, that is =09a very old ioctl, so we can't just remove it.) This is =09apparently not supported by socket code (it wants SIOCSPGRP?), =09so hack up something here. % =09=09=09error =3D 0; % =09=09=09break; % =09=09} % =09=09if (tmp <=3D 0) { % =09=09=09tmp =3D -tmp; % =09=09} else { % =09=09=09struct proc *p1 =3D pfind(tmp); % =09=09=09if (p1 =3D=3D 0) { % =09=09=09=09error =3D ESRCH; % =09=09=09=09break; % =09=09=09} % =09=09=09tmp =3D p1->p_pgrp->pg_id; % =09=09} % =09=09error =3D (*fp->f_ops->fo_ioctl) % =09=09=09(fp, (int)TIOCSPGRP, (caddr_t)&tmp, p); =09For ttys but not much else, TIOCSPGRP exists and sort of =09corresponds to FIOSETOWN. There is some overlap, but =09especially for ttys, TIOCSPGRP has very different semantics, =09so this call caused problems if anyone actually makes it. =09It is likely to just fail, but I added workarounds to problems =09near here in some versions of FreeBSD. These have been =09replaced by better methods. E.g., pass FIOSETOWN to lower =09levels here (done by truckman?). % =09=09break; =09FreeBSD-1 fcntl(): % =09case F_SETOWN: % =09=09if (fp->f_type =3D=3D DTYPE_SOCKET) { % =09=09=09((struct socket *)fp->f_data)->so_pgid =3D uap->arg; % =09=09=09return (0); % =09=09} % =09=09if (uap->arg <=3D 0) { % =09=09=09uap->arg =3D -uap->arg; % =09=09} else { % =09=09=09struct proc *p1 =3D pfind(uap->arg); % =09=09=09if (p1 =3D=3D 0) % =09=09=09=09return (ESRCH); % =09=09=09uap->arg =3D p1->p_pgrp->pg_id; % =09=09} % =09=09return ((*fp->f_ops->fo_ioctl) % =09=09=09(fp, (int)TIOCSPGRP, (caddr_t)&uap->arg, p)); =09Essentially the same as for the ioctl. The ioctl() is essentially =09an archaic spelling of the fcntl(). This must be supported, but =09hopefully its misimplementation details (mainly the translation =09to a PGRP ioctl) don't need to be. ) - the garbage or implementaion-detail TIOC[SG]PGRP ioctls are unfortunately documented in many places: - tap(4), tun(4), tty(4) (legit there), mdoc(7) (bad example) and is used in the correspoding source places and others (now checking more than kern but not all of sys): - kern/subr_log.c, net/bpf.c: like sys/pipe.c - net/if_tap.c, net/if_tun.c: like sys/pipe.c, except the ioctl is actually documented. > 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. POSIX requires tcsetpgrp() etc to restrict to more than a tty (requires controlling terminal and more), so libc must check if the kernel doesn't, but this is very hard to do in libc. > The API is equivalent to FIOSETOWN etc and sockets and pipes use > common code to implement both ioctl() calls. Actually, very different. Even F_SETOWN is merely similar to FIOSETOWN, since the former operates on open files while the latter operates on devices, at least logically. > The proposed patch was to remove the TIOCSPGRP -> FIOSETOWN mapping > for pipes only, to sync them with fifos. ttys and sockets would be > unaffected. No reason to remove it for pipes but not for logs, bpfs, taps or tuns. Or break POSIX consistently and make the exceptional cases match pipes: - fifos are missing support for TIOC[SG]PGRP in 2 ways: - it is not passed to the socket layer - the socket layer doesn't support it anyway, unless it is translated to the socket layer spelling - for sockets, it is spelled SIOC[SG]PGRP and undocumented. Does POSIX specify sockets yet? If so it should disallow tiocsetpgrp() on them, and give more details about how FSETOWN works on them. > 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. And it has nothing to do with what is deprecated :-). Bruce --0-1274663310-1321632703=:5050-- From owner-freebsd-arch@FreeBSD.ORG Sat Nov 19 09:32:52 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 E6EBA106566B; Sat, 19 Nov 2011 09:32:51 +0000 (UTC) (envelope-from rmh.aybabtu@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 83E048FC13; Sat, 19 Nov 2011 09:32:51 +0000 (UTC) Received: by iakl21 with SMTP id l21so6968002iak.13 for ; Sat, 19 Nov 2011 01:32:50 -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=IBpB9xe8t6fN3MPJ8zOJtiwDnLxth/0H0Bqjoy59rIA=; b=rCEu1Etv6kMjKoVUQLj8sKfE4BMLCOkoCNDyeNQ9AAdYUGGexBH6vXJjbcRcfhUSAt VKl0iQOWjJdI4GwfZyMV1tzh0oKVrov68QfYKn2/ql3dN04HM6cj8NGdqghcXvtgRoqj afh2VshF0xVWYNNOAKtnlTEaytB3yzDkuRAKY= MIME-Version: 1.0 Received: by 10.42.135.66 with SMTP id o2mr6220493ict.0.1321695170889; Sat, 19 Nov 2011 01:32:50 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Sat, 19 Nov 2011 01:32:50 -0800 (PST) In-Reply-To: References: <201111170959.56767.jhb@freebsd.org> <201111171632.34979.jhb@freebsd.org> Date: Sat, 19 Nov 2011 10:32:50 +0100 X-Google-Sender-Auth: 5ZcxXZGkHpU2HiuEor9e23h8dik Message-ID: From: Robert Millan To: John Baldwin Content-Type: multipart/mixed; boundary=90e6ba6e89d62986f104b21323a0 Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 19 Nov 2011 09:32:52 -0000 --90e6ba6e89d62986f104b21323a0 Content-Type: text/plain; charset=UTF-8 2011/11/18 Robert Millan : > 2011/11/17 John Baldwin : >> Hmm, I wonder if it's better to use the #ifndef approach rather than #undef >> so that when compilers are updated to DTRT we will honor their settings? > > Well, the compiler is supposed to know better than sys/param.h, I gave this a bit more thought.... The compiler knows about the system it was intended to build for, but sys/param.h *is* part of the system we're building for. It's impossible for sys/param.h to have the wrong information unless it's out of sync with the rest of the headers. As for the compiler, on FreeBSD it's hard for the compiler to be out of sync, because the system (in comparison with others) is tightly packaed and upgrade procedures are well defined. But if you take Debian, for example, we use the same compiler to build 8-STABLE, 9-STABLE and 10-CURRENT kernels. The compiler has no idea which version of FreeBSD the sources it is building come from. I wouldn't put compilers in general in a position where they're forced to know the FreeBSD major version beforehand because sys/param.h will give preference to the information coming from compiler. I propose this alternate patch which derives the major number from __FreeBSD_version instead. --90e6ba6e89d62986f104b21323a0 Content-Type: text/x-diff; charset=US-ASCII; name="freebsd_kernel.diff" Content-Disposition: attachment; filename="freebsd_kernel.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv6f4hap0 SW5kZXg6IHN5cy9zeXMvcGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3BhcmFtLmgJKHJl dmlzaW9uIDIyNzU4MCkKKysrIHN5cy9zeXMvcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtNjAs NiArNjAsMjMgQEAKICN1bmRlZiBfX0ZyZWVCU0RfdmVyc2lvbgogI2RlZmluZSBfX0ZyZWVCU0Rf dmVyc2lvbiAxMDAwMDAxCS8qIE1hc3RlciwgcHJvcGFnYXRlZCB0byBuZXd2ZXJzICovCiAKKy8q CisgKiBfX0ZyZWVCU0Rfa2VybmVsX18gaW5kaWNhdGVzIHRoYXQgdGhpcyBzeXN0ZW0gdXNlcyB0 aGUga2VybmVsIG9mIEZyZWVCU0QsCisgKiB3aGljaCBieSBkZWZpbml0aW9uIGlzIGFsd2F5cyB0 cnVlIG9uIEZyZWVCU0QgOi0pLiBUaGlzIG1hY3JvIG1heSBhbHNvCisgKiBiZSBkZWZpbmVkIG9u IG90aGVyIHN5c3RlbXMgdGhhdCB1c2UgdGhlIGtlcm5lbCBvZiBGcmVlQlNELCBzdWNoIGFzCisg KiBHTlUva0ZyZWVCU0QuCisgKgorICogSXQgaXMgdGVtcHRpbmcgdG8gdXNlIHRoaXMgbWFjcm8g aW4gdXNlcmxhbmQgY29kZSB3aGVuIHdlIHdhbnQgdG8gZW5hYmxlCisgKiBrZXJuZWwtc3BlY2lm aWMgcm91dGluZXMsIGFuZCBpbiBmYWN0IGl0J3MgZmluZSB0byBkbyB0aGlzIGluIGNvZGUgdGhh dAorICogaXMgcGFydCBvZiBGcmVlQlNEIGl0c2VsZi4gIEhvd2V2ZXIsIGJlIGF3YXJlIHRoYXQg YXMgcHJlc2VuY2Ugb2YgdGhpcworICogbWFjcm8gaXMgc3RpbGwgbm90IHdpZGVzcHJlYWQgKGUu Zy4gb2xkZXIgRnJlZUJTRCB2ZXJzaW9ucywgM3JkIHBhcnR5CisgKiBjb21waWxlcnMsIGV0Yyks IGl0IGlzIFNUUk9OR0xZIERJU0NPVVJBR0VEIHRvIGNoZWNrIGZvciB0aGlzIG1hY3JvIGluCisg KiBleHRlcm5hbCBhcHBsaWNhdGlvbnMgd2l0aG91dCBhbHNvIGNoZWNraW5nIGZvciBfX0ZyZWVC U0RfXyBhcyBhbgorICogYWx0ZXJuYXRpdmUuCisgKi8KKyN1bmRlZiBfX0ZyZWVCU0Rfa2VybmVs X18KKyNkZWZpbmUgX19GcmVlQlNEX2tlcm5lbF9fIChfX0ZyZWVCU0RfdmVyc2lvbiAvIDEwMDAw MCkKKwogI2lmZGVmIF9LRVJORUwKICNkZWZpbmUJUF9PU1JFTF9TSUdXQUlUCQk3MDAwMDAKICNk ZWZpbmUJUF9PU1JFTF9TSUdTRUdWCQk3MDAwMDQK --90e6ba6e89d62986f104b21323a0-- From owner-freebsd-arch@FreeBSD.ORG Sat Nov 19 17:56: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 D14461065673; Sat, 19 Nov 2011 17:56:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5915F8FC15; Sat, 19 Nov 2011 17:56:28 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAJHuKtU091923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2011 19:56:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAJHuKtm027532; Sat, 19 Nov 2011 19:56:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAJHuKLL027531; Sat, 19 Nov 2011 19:56:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Nov 2011 19:56:20 +0200 From: Kostik Belousov To: Robert Millan Message-ID: <20111119175620.GV50300@deviant.kiev.zoral.com.ua> References: <201111170959.56767.jhb@freebsd.org> <201111171632.34979.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U9/8TDFnS6G07P4u" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers 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, 19 Nov 2011 17:56:30 -0000 --U9/8TDFnS6G07P4u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 19, 2011 at 10:32:50AM +0100, Robert Millan wrote: > 2011/11/18 Robert Millan : > > 2011/11/17 John Baldwin : > >> Hmm, I wonder if it's better to use the #ifndef approach rather than #= undef > >> so that when compilers are updated to DTRT we will honor their setting= s? > > > > Well, the compiler is supposed to know better than sys/param.h, >=20 > I gave this a bit more thought.... >=20 > The compiler knows about the system it was intended to build for, but > sys/param.h *is* part of the system we're building for. It's > impossible for sys/param.h to have the wrong information unless it's > out of sync with the rest of the headers. >=20 > As for the compiler, on FreeBSD it's hard for the compiler to be out > of sync, because the system (in comparison with others) is tightly > packaed and upgrade procedures are well defined. >=20 > But if you take Debian, for example, we use the same compiler to build > 8-STABLE, 9-STABLE and 10-CURRENT kernels. The compiler has no idea > which version of FreeBSD the sources it is building come from. >=20 > I wouldn't put compilers in general in a position where they're forced > to know the FreeBSD major version beforehand because sys/param.h will > give preference to the information coming from compiler. >=20 > I propose this alternate patch which derives the major number from > __FreeBSD_version instead. I fully agree with an idea that compiler is not an authorative source of the knowledge of the FreeBSD version. Even more, I argue that we shall not rely on compiler for this at all. Ideally, we should be able to build FreeBSD using the stock compilers without local modifications. Thus relying on the symbols defined by compiler, and not the source is the thing to avoid and consistently remove. We must do this to be able to use third-party tooldchain for FreeBSD builds. That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ? And then make more strong wording about other systems that use the macro, e.g. remove 'may' from the kFreeBSD example. Also, please remove the smile from comment. --U9/8TDFnS6G07P4u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7H7cQACgkQC3+MBN1Mb4jt8QCeKe7cMDkJUgAl1cprocxvpoE9 khMAniVomr/Laq0OfqDRj4yk5wB1Cbog =WiER -----END PGP SIGNATURE----- --U9/8TDFnS6G07P4u--