svn commit: r297597 - in head/sys: amd64/linux amd64/linux32 i386/linux

[John Baldwin]

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