> Wouldn't it be superior to detect and prevent the stack overflow? This
> could happen on other architectures at some point, and the overflow
> might go past the user structure...

Also:

One of the long-known (at least to me 8-) problems with the new
autoconfiguration code is that it _does_ get rather deep call stacks.

For instance, consider an alpha with, say, a PCI expansion box (i've
got one) with a 4-port ether card sitting on the PCI bus in the
expansion box.  The PCI expansion box is done with two PPBs (one on
the primary pci bus directly attached to another ppb via long cable).
Typically, 4-port ether cards are done with a PPB.  that means that
you've got something like:

	mainbus
	-> chipset (cia,lca,apecs)
	   -> pci (primary bus)
	      -> ppb (on primary)
		 -> pci
		    -> ppb (in expansion box)
		       -> pci (expansion box bus)
			  -> ppb (on quad ether card)
			     -> pci (quad ether card 'bus')
				-> de (an actual ethernet chip).

if you figure that you have to go through _at least_ an 'attach'
function, config_found_sm(), and config_attach() (invoked by
config_found()) at each of those levels, you end up going through
three frames per level.

That means, for the example above, you're talking about a call stack
30 frames deep.

obviously, on the sparc that's "too deep."  8-)


I can imagine several ways to flatten the call stack, but none of them
are particularly attractive to me since the require changes to the
autoconfiguration interfaces, some of which are potentially
non-trivial.  (If anybody thinks they want to work on it, send me
mail.  8-)



chris