Subject: Re: Another changer, another changer problem
To: NetBSD-current Discussion List <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 10/08/1998 21:59:54
[ On Thu, October 8, 1998 at 18:19:40 (-0700), Curt Sampson wrote: ]
> Subject: Re: Another changer, another changer problem
> On Thu, 8 Oct 1998, Greg A. Woods wrote:
> > Ordinary PCI is limited to 4 slots per bus....
> Evidently not. At least, ASUS has no trouble producing five-slot
> motherboards. See
You mean this one that says:
4 32-bit PCI slots
1 Asus MediaBus (Revision 2.0) Slot.
3 16-Bit ISA Slots.
> > ...(and it seems 4 logical units
> > per slot, though I don't yet know much about this part of the spec.).
> No. A package may have up to eight functions in it.
Nine, actually, though I admit I didn't really pay close attention to
the 21150 specs previously and notice this until today....
> I can't even figure out how you intend to map controllers to the
> N in /dev/cN... Perhaps you could explain how this would occur on
> typical PCI bus systems.
Other than the simple one-controller per slot model, the only real way
to handle PCI dynamically is by drawing a tree structure. Every time
you put in a bridge chip you might need to branch the structure.
Without worrying yet about silly things like major/minor numbers (which
*can* go completely away with devfs anyway), this could lead to:
pci_s3-- ... and so on
where "sN" is a physical slot, and "dN" is a device on a card.
Any of the above terminal nodes could branch to a SCSI bus.
Perhaps the problem is trying to make a "generic" i386 kernel in this
scenario. In any given CompactPCI system you'd be unlikely to widely go
adding more bus extenders without a lot of due consideration, so the
only thing you really have to worry about is plugging in a non-system
card that might have mezzanine connectors off on a bridge....
This is why I keep alluding to moving to sparse data structures to
define the device configuration space...
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>