On Tue, 25 Feb 1997, Bill Studenmund wrote:

.. > Well, two things. First, even though you don't have a "nubus slot" you still
.. > have a portion of the physical address space set aside for use by the potential
.. > nubus slot. A kernel that doesn't use the nubus code should at least know
.. > where the nubus slots are and not try to map them in. So you'll need at
.. > least a little bit of code to figure out where the slots are.
.. > 
.. > Second, there may be the possibility that when I write the internal video
.. > drivers I might use some code from nubus.c to check the machine's
.. > built-in ROMs so that I can identify the type of internal video in the machine.
.. 
.. Third, Apple has recomended (a long time ago) that all PDS slot card
.. makers configure their roms to look like NuBus slots. I think the idea
.. was that Apple would only have to write one bit of code for scanning
.. for cards.

.. 
.. I too wonder what's the point. If we rip out the nubus code, we loose the
.. ability for a kernel to run on any 68k mac.

As Allen has already mentioned, my intention is to be able to build a
custom kernel with just those devices and bus(ses) that are actually
present. This is done to make a "cleaner" (not just smaller) kernel. This
kernel is definitely just meant to boot one specific computer. As an
analogy, I also have a PC where I have not configured neither PCI nor EISA
as the computer contains neither of these busses.

Furthermore it might help understanding the kernel sources.

If some of the new internal video code needs to call functions related to
the management of nubus address space, we might pull these out of nubus.c
into a new source file and leave nubus.c to handle actual devices
connected to a nubus (or PDS slot card that simulates a nubus device).
This may even be a good idea even if we don't make the nubus configuration
file entry optional.

-- still stirring the water
   Erik