Re: Heads up, changes to modules/exec/etc, note for portmasters/developers

[Andrew Doran <ad%netbsd.org@localhost>]

On Fri, Nov 21, 2008 at 04:34:25PM +0100, Havard Eidnes wrote:

> [[ Moved to port-powerpc from current-users ]]
> 
> > NOTE TO PORTMASTERS: to make the compat stuff loadable as modules, COMPAT_
> > ifdefs have to be purged from arch/${port}. Generally speaking, if the
> > compat ifdef is in a file that is to be loaded as part of a compat module,
> > say compat_16_machdep.c then it's ok. If it's elsewhere, like vm_machdep.c,
> > then it needs to be neutralized - either removed or moved or replaced with a
> > hook. I have done this for x86 and touched on the other ports but have not
> > completely verified any ports other than the x86 ones. If you plan to
> > support only !modular kernels there is no need to do anything.
> 
> I'm looking at possibly committing this to fix the build breakage for
> powerpc ports:
...
> +#ifdef _KERNEL_OPT
>  #include "opt_compat_netbsd.h"
>  #include "opt_altivec.h"
>  #include "opt_ppcarch.h"
> +#endif
...
> as an immediate fix for build breakage uncovered by modularizing the
> compat code.
> 
> However, the options defined in these option files are used elsewhere
> in the compat source code, e.g.
> 
> 
> #ifdef PPC_HAVE_FPU
>         utf->srr1 |= l->l_addr->u_pcb.pcb_flags & (PCB_FE0|PCB_FE1);
> #endif
> #ifdef ALTIVEC
>         utf->srr1 |= l->l_addr->u_pcb.pcb_flags & PCB_ALTIVEC ? PSL_VEC : 0;
> #endif
> #ifdef PPC_OEA
>         utf->vrsave = tf->tf_xtra[TF_VRSAVE];
>         utf->mq = tf->tf_xtra[TF_MQ];
> #endif
> 
> 
> Would not this make it essentially impossible to build a compat_16
> module which is processor-variant-neutral?  Or... one that will work
> at all on any of these variants by default...?

I think processor-variant-neutral might be difficult to achieve generally.
It's not technically difficult but is laborious, especially because of the
number of ports, and needs someone with interest to work on it. We key on
$MACHINE for the module build/install/etc. I wonder if this might be
problematic due to shared base.tgz?

It can be done for xen/x86 because there is someone interested and the
differences are few in number.

> While on the subject of build-breakage for the powerpc ports, the
> evbppc port is also in that group because it attempts to build modules
> which end up including machine/intr.h (because _KERNEL is defined),
> which contains
> 
> #include PPC_INTR_IMPL
> 
> and that macro is not defined in a module build.  This is yeat another
> instance of the "there are many different processor variants in this
> family" issue for the powerpc ports.

Hmm, see this:

http://nxr.homeunix.org/source/xref/sys/Makefile#9

Do you see it trying to build them?
 
Andrew