> >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-)

Some numbers:

the u area is 8k on the sparc, `struct user' is about 2k, leaving
roughly 6k for the stack.

I saw the stack touching the user structure during the scsi `sd' attach.
The "attach chain" on the stack was something like this:
  mainbus
    iommu
      sbus
        espdma
          esp
            scsibus
              sd
                scsi_command_enquire (or so)
                  esp_intr (polled)
                   scsi_msgin
                     printf

Including all config_attach() calls and possibly other glue, I counted
32 frames on the stack. At a "nominal" frame size of about 100-200 bytes
this would just about fit in 6k of stack. But as Chris points out (below)
the `really big romaux' which is an automatic in various bus attachment
routines spoils the fun.

> 
> Actually, you can get that many frames without too much trouble as
> long as each one is small enough.  The problem is that the sun4m
> introduces the `really big romaux'.  I told pk a bit earlier today
> that I had solved this myself (I got bit by it rather a while ago)
> by (a) shrinking some arrays (I took a few things from 16 to 8, I
> think), and (b) allocating the romaux's for the mainbus and sbus
> (and maybe a few more, but I am sure about those two) with malloc
> rather than on the stack.
> 
> Chris

Some devices really have a huge set of registers (like the tcx frame
buffer) or translation tables (such as a VME bus on IOMMU). That was
the reason I increased various `8's to `16's.

I'll probably split the romaux and allocate the `ranges' property
separately for busses that need them.

-pk