[gentoo-dev] Test request: linux-mod support for arches with 64-bit kernel/32-bit userland

[gentoo-dev] Test request: linux-mod support for arches with 64-bit kernel/32-bit userland

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

This is a testing request aimed at all arches that have differing
kernel/userspace bit counts. My short list so far is:
- ppc64 - 64/32 (tested myself, but more testing needed)
- sparc64 - 64/32
- mips64 - 64/32 [1]

Other possibles (they should be theoretically capable of it, but the
profile is marked broken, or doesn't exist in Gentoo presently):
- s390x - 64/31
- amd64 - 64/32 (the profile is marked as broken)
- superh - 64/32
- hppa - 64/32

Additionally, I'd like some testing under pure 32, pure 64, and multilib
systems, just to be 100% certain it doesn't break existing
functionality. I have tested x86 myself, and had reports that pure ppc64
work fine.

This patch uses multilib.eclass to bring linux-mod support much further
forward in allowing kernel modules in the portage tree to be built on
64/32 split systems.

It would be nice to have this in 2006.1 (I suspect catalyst/genkernel
could probably benefit greatly from it).

There's two parts to it:
1. get-KERNEL_CC support and usage in linux-mod.eclass
2. Profile changes: Each user needs to define KERNEL_ABI, and then
   CHOST_*, CFLAGS_*, LDFLAGS_* for the value of KERNEL_ABI.
   For a platform with a biarch compiler, you'd use CFLAGS_xxxx64="-m64"
   (or 32), and LDFLAGS_xxxx64="-m TARGETNAME".
   For a platform with two separate compilers (kgcc64), but a single
   binutils, use the same LDFLAGS, but instead of CFLAGS, do
   CHOST_xxxx64="......." instead.

Example for ppc64 with 32-bit userland.
+KERNEL_ABI="ppc64"
+LDFLAGS_ppc64="-m elf64ppc"
+CHOST_ppc64="powerpc64-unknown-linux-gnu"

Now the bug with the patch:
Bug 133382:
http://bugs.gentoo.org/show_bug.cgi?id=133382

Test cases (some of them may not compile if built into your kernel):
sys-block/iscsitarget-0.4.13
net-wireless/zd1211-80
x11-base/x11-drm-20060608
sys-fs/cowloop-2.15-r1
sys-fs/fuse

Notes.
1. Mips: with your triple ABI stuff, you might want to look very closely
   at this.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Test request: linux-mod support for arches with 64-bit kernel/32-bit userland

[Kumba]

Robin H. Johnson wrote:

> Notes.
> 1. Mips: with your triple ABI stuff, you might want to look very closely
>    at this.

The triple ABI stuff doesn't really affect things.  o32 userland on a 64bit box 
is the only case where you have to worry about split compilers.  In a 
theoretical n32 or n64 userland, your system compiler (and therefore CHOST) is 
already 64bit, so it's one compiler for both kernel and userland.


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Test request: linux-mod support for arches with 64-bit kernel/32-bit userland

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

On Tuesday 04 July 2006 06:08, Robin H. Johnson wrote:
> - superh - 64/32

i wouldnt ever worry about this since, afaik, the sh64 port is still really 
developmental and no one really has hardware for end users to worry about ... 
plus they werent really designed to be compatible
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Test request: linux-mod support for arches with 64-bit kernel/32-bit userland

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On Tue, 2006-07-04 at 03:08 -0700, Robin H. Johnson wrote:
> It would be nice to have this in 2006.1 (I suspect catalyst/genkernel
> could probably benefit greatly from it).

We've already made the snapshot.  Also, catalyst uses genkernel for all
of the external modules builds, and we've already got things in place in
genkernel to do this, though it is a manual process on the part of the
Release Engineer.

This will definitely help us around 2007.0, though.  It will require
*much* more testing from us, though, as our current methods are very
well tested and I'm not comfortable squeezing in a change such as this
at the last minute with minimal testing, as it will definitely impact
our release schedule.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]