>    > Based on current practice, it seems that including either of
   >    > <machine/psl.h> or <machine/cpu.h> should do it.  Whether or not
   >    > including both should be allowed is outside the scope of my message.
   >    > I find it bad form to gratuitously #include extra files, so I'd
   >    > recommend not making psl.h idempotent unless there is a pressing need
   >    > to.
   > 
   >    So, is the answer to include them via <machine/cpu.h>?
   > 
   >    And, if so, is it still mandatory to put them in <machine/psl.h>?
   > 
   > I already answered both questions in the text you quoted.

   Yes, and you also declared your definition to be in "bad form", [...]

That's not what I was referring to.  I was referring specifically to
drivers pulling in more files than they need.  There is already
precedent for cpu.h pulling in psl.h.

   If people want their drivers to be portable to the Alpha, they will
   access these constants by getting them via <machine/cpu.h>.

That's poor.  Drivers should be able to access those constants (and,
I'd say, the spl*() prototypes and/or inline definitions) without the
rest of the cruft in cpu.h.

I propose the creation of <machine/intr.h>, which would contain the
IPL_* and IST_* constants, as well as any definitions necessary to use
the spl*() and setsoft*() functions/macros.