From owner-svn-src-all@freebsd.org Wed Apr 6 17:56:42 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28CA1B0673D; Wed, 6 Apr 2016 17:56:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0054914EB; Wed, 6 Apr 2016 17:56:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1EB35B987; Wed, 6 Apr 2016 13:56:41 -0400 (EDT) From: John Baldwin To: Baptiste Daroussin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r297597 - in head/sys: amd64/linux amd64/linux32 i386/linux Date: Wed, 06 Apr 2016 07:59:05 -0700 Message-ID: <1589418.nsqxoJzOlo@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160406064002.GJ49864@ivaldir.etoilebsd.net> References: <201604052236.u35ManwQ076790@repo.freebsd.org> <2270129.DEqYKEiVDZ@ralph.baldwin.cx> <20160406064002.GJ49864@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 Apr 2016 13:56:41 -0400 (EDT) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:56:42 -0000 On Wednesday, April 06, 2016 08:40:02 AM Baptiste Daroussin wrote: > On Tue, Apr 05, 2016 at 06:32:16PM -0700, John Baldwin wrote: > > On Tuesday, April 05, 2016 10:36:49 PM Baptiste Daroussin wrote: > > > Author: bapt > > > Date: Tue Apr 5 22:36:48 2016 > > > New Revision: 297597 > > > URL: https://svnweb.freebsd.org/changeset/base/297597 > > > > > > Log: > > > Add kern.features flags for linux and linux64 modules > > > > > > kern.features.linux: 1 meaning linux 32 bits binaries are supported > > > kern.features.linux64: 1 meaning linux 64 bits binaries are supported > > > > > > The goal here is to help 3rd party applications (including ports) to determine > > > if the host do support linux emulation > > > > > > Reviewed by: dchagin > > > MFC after: 1 week > > > Relnotes: yes > > > Differential Revision: D5830 > > > > Other parts of the system (e.g. libsysdecode, the various symbols exported by > > the modules, etc.) use "linux" to mean supporting Linux binaries of the same > > ABI as the host (so x86-64 on amd64 and i386 on i386) and "linux32" to mean > > supporting 32-bit Linux binaries on a 64-bit host. Note that we used to > > have linux.ko on Alpha which was a 64-bit ABI, not 32-bit. It is unfortunate > > that we called linux32.ko linux.ko, but we shouldn't perpetuate that mistake > > further IMO. For example, I think if we grow Linux/aarch64 ABI support on > > FreeBSD/arm64, that should be called 'linux.ko', not 'linux64.ko'. > > Similarly, Linux/armv6 on FreeBSD/armv6 would also be 'linux.ko'. > > > > I would also list the names in the feature description (so Linux/i386, not > > Linux 32-bit, since Linux/armv6 is a 32-bit binary, but linux.ko on > > FreeBSD/i386 can't run it). > > > Well I tried to be consistent with the other example we have which is cloudabi. > > I considered the x86 case and tried to generalize: > > linux => my arch (x86) in 32bit > linux64 => my arch (x86) in 64bit > > Let's consider aarch64 which is supposed to also have support for 32bits (one > would be happy to run linux armv6 on top of it ,no?) > > linux => my arm in 32bits > linux64 => my arch in 64bits > > That said, I have no strong feelings about it Note that we don't call FreeBSD/amd64 binaries 'freebsd64', we call them 'freebsd' and use 'freebsd32' for FreeBSD/i386 binaries. If we had gone the route of /usr/lib64 for amd64 binaries leaving /usr/lib for i386, then I think your naming would be more consistent, but that's not what we do. As I said above, I would expect Linux/armv6 binaries on aarch64 to be a 'linux32', not 'linux'. Using 'linux.ko' instead of 'linux32.ko' on amd64 was just a mistake of expedience. The files are all named 'linux32'. The global symbols have recently all been named 'linux32', and the DTrace systrace kernel module was recently renamed from 'systrace_linux.ko' to 'systrace_linux32.ko'. (systrace_linux.ko holds the x86-64 system call names). If we could rename 'linux.ko' to 'linux32.ko' on amd64 without suffering a huge POLA violation I would push for that as well. In the future we might very well have platforms that are primarily 64-bit and may not implement 32-bit at all (FreeBSD/riscv is 64-bit only right now, and if we grow Linux ABI support for that I suspect it will be 64-bit only as well). Those should have 'linux.ko' to be the 'native' ABI IMO, not a linux64.ko without a linux.ko. -- John Baldwin