Exactly the problem that we have with machine/vmparam.h.  Lsof suffers from
this problem by way of uvm/uvm.h, which includes machine/vmparam.h without
the _SUN3X_ define set, and we lose.  I had to modify an lsof header file
to define _SUN3X_ just before uvm/uvm.h was included to fix the problem.
If we can't think of a better way to do this, my suggestion would be at least
have those header files produce compiler errors if neither _SUN3_ nor _SUN3X_
are defined, that way we know if there was a problem in the event the compiler
didn't catch it (i.e. with lkm's).

-Mark

On Fri, Sep 15, 2000 at 10:38:30PM -0400, Brad Spencer wrote:
> 
> I think that the base system has some trouble in this area.  If I recall
> correctly, some of the LKMs that are created from /sys/lkm won't work
> properly on the Sun 3/3x port because in some cases neither the define
> SUN3 nor SUN3X is defined, and some of them include
> /usr/include/machine/param.h.  Without either of those two defines set,
> you will not get the proper /usr/include/machine/param3.h or
> /usr/include/machine/param3x.h include.
> 
> Basically, in the current design, as far as I can tell, you can't always
> mix LKMs that were compiled on a Sun 3 v.s. a Sun 3x.  LKMs are a little
> bit of an odd case, but I suspect that any userland program that wants
> access to those same defines will also have trouble.
> 
> 
> 
> [An example from a running 1.4Y Sun 3/80 system:
> 
> pippin# modload /usr/lkm/procfs.o
> /usr/lkm/procfs.o: Undefined symbol `_KERNBASE' referenced from text segment
> modload: can't prelink `/usr/lkm/procfs.o' creating `/usr/lkm/procfs'
> 
> KERNBASE is defined in /usr/include/machine/param3.h and
> /usr/include/machine/param3x.h.  Other systems just have one of these, so
> this all works for them
> 
> ]
> 
> 
> 
> Brad Spencer - brad@anduin.eldar.org
> http://anduin.eldar.org  - & -  http://mellon.ipv6.eldar.org [IPv6 only]
> [finger brad@anduin.eldar.org for PGP public key]
> 
>