[ On Thu, October 8, 1998 at 12:45:26 (-0700), Curt Sampson wrote: ]
> Subject: Re: Another changer, another changer problem
>
> Uh oh. This gets big pretty quickly, in the PCI situation. On a
> PCI bus we may have up to thirty-two packages (a package being a
> single on-board device, or a device on a card inserted into a slot),
> each of which may have up to eight functions. So that's 256 potential
> locations for SCSI controllers right there. However, we may also
> have up to 256 PCI buses on a system, giving us 65536 potential
> locations for a SCSI controller in our system. (This, of course,
> assumes that we have only a PCI bus, and don't support any other
> buses.)

I realize what you're saying, but generally speaking most systems will
not have more than the maximum of four physical devices attached to any
given PCI bus....

Perhaps a compile-time flag to select whether or not muliple controllers
per slot is supported or not would help here.  The same problem might
occur for Sbus machines, esp. since they usually have a seriously
limited number of slots.

Of course if you've got a machine with 256 physical PCI buses, and you
do have dual or quad bus host adapter cards, then I'm guessing you'll
also have a gigabyte or more of RAM and a *really* fast CPU (or more),
so having support for 64K controllers in your kernel shouldn't be a
terrible burden to bear.

Naturally sparse data structures and a dynamic virtual devfs filesystem
nicely reduce the resourses required to manage a fixed configuration
scheme such as this.

This is a problem mainframes have handled for some time.  Although I'm
not familiar with their exact approaches, I can point at the "obvious"
solution people with such experience took when they wanted to get rid of
the tuning problems in traditional unix kernels:  AIX -- make everything
as big as it can be and build in efficient virtual memory support for
the kernel too.  It might not be "pretty", but it definitely works, and
if you get a really big and honkin' machine you don't really care anyway.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>