Subject: NetBSD/mac68k kernel without nubus ?
To: None <port-mac68k@NetBSD.ORG>
From: Erik Bertelsen <erik@sockdev.uni-c.dk>
List: port-mac68k
Date: 02/25/1997 09:08:17
My question is: Is it (or rather: should it be) possible to install and
use a NetBSD/mac68k-current kernel without the nubus entry in the kernel
configuration file.

My first answer is: yes! I have a Q610 running NetBSD without a NuBus (it
requires an adapter card to convert the PDS slot into a NuBus slot if
needed).

The second thought is: Is the nubus entry really needed anyway? I ask this
question because sometimes the kernel uses a fictive "pseudo-nubus" slot
and its address space for e.g. internal video. The answer to this question
may go beyond my experiment described in the next paragraph...

Well, anyway, I tried to do it. The kernel linking failed because of
references to tmp_vpages from pmap.c and pmap_bootstrap.c (all file names
refer to files in arch/mac68k/*/*). This variable is defined in nubus.c.
To solve this, I added a "needs-count" (that might be substituted by
"needs-flag", i don't know the rules for using these keywords) keyword for
the nubus declaration in files.mac68k to have configure(8) generate a
nubus.h header in the compile directory defining NNUBUS. I changed pmap.c
and pmap_bootstrap.c to include "nubus.h" and to make the code depending
on tmp_vpages dependant on NNUBUS being non-zero. In one case I made a
complete function dependant on this flag, and in the other case, I just
removed the code using tmp_vpages. 

I have been running with this patch for the last couple of days, and it
does not seem to hurt anything.

If the people knowing about the interference between the nubus code and
the internal video code have nothing to say against my change, I'll
probably clean it up and send-pr a patch in about a week's time. 

One thing that I don't like about my own patch is that it generates and
uses a nubus.h header file in the compile directory in addition to the
existing (and completely different) mac68k/dev/nubus.h header. Maybe this
is just a non-problem, but I'd just mention it...

regards
Erik Bertelsen