:    :    [Yes, there's a port-sparc64 list]
      :    : [yes, but it should be just an alias for this list, but isn't (yet)]
      :    
      :    And why is that?
      : 
      : because the ultimate plan (tm) is to eventually have just /sys/arch/sparc
      : with both 32-bit & 64-bit support all in here.  also because we want it
      : that way and have been asking for it for a year or more.

      This has some serious implications for the uses of MACHINE and MACHINE_ARCH.  
      Were you planning to keep those as "sparc64" for a 64-bit-native system?


   of course.  the only thing that really will change is the location
   of files.  the point of the change is that >90% of the code is the
   same still and re-sharing it is a sane thing to do.


The Sun3 and Sun3x merge is kind of nice...  except in one annoying way...

Certain LKMs will not build properly as all things that grovel through
kernel space or are a part of kernel space, be it the kernel itself, an
LKM or things of the same nature as 'top' [although, I am not certain
'top', specifically has this issue] must define, on the 'cc' line, the
symbol _SUN3_ or _SUN3X_.  This is required as there are a number of
include files in /usr/include/machine [i.e. really /usr/include/sun3] that
use those mentioned symbols as a key to include the Sun3 or Sun3x versions
of the files.  Stuff like the following is all over the place:

#ifdef  _SUN3_
#include <machine/vmparam3.h>
#endif  /* SUN3 */
#ifdef  _SUN3X_
#include <machine/vmparam3x.h>
#endif  /* SUN3X */
#ifdef  _LKM
#define USRSTACK KERNBASE
extern  char KERNBASE[];
#endif  /* _LKM */

As far as I can tell, it is not actually possible to build an entire /usr
that includes a common /usr/lkm for the Sun3 and Sun3x machine types.  In
addition, I am pretty certain that a number of the LKMs in /usr/lkm don't
really work on either a Sun3 or Sun3x machine type, as the /usr/lkm
Makefiles define neither of those symbols.  I am pretty certain that I
had to hand build a couple of the VFS based LKMs and there was a discusion
of this issue with a groveling userland program on the Sun3 mailing list a
few weeks back.

If the Sparc and Sparc64 trees do merge one should attempt to avoid stuff
like the above.



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]