> 		   u_int           pa_intrswiz;
   > 		   pcitag_t        pa_intrtag;
   > 
   > You haven't specified what these two values *are*.

   They are only to be used in the way specified, by drivers.  drivers
   and driver-writers are specifically _not_ supposed to know or care
   what they are, except that they are to use them in the way mentioned.

I suppose that `driver-writers' doesn't include, for example, someone
writing support for a non-standard bridge, then?  I don't buy that.
Even if I did, the internals should be documented.  I'd also like to
see the convention I started of documenting specific interpretations
of the standard continued (although this isn't specific to the PCI
code).

   > 	   This function is always successful.  If the arguments are
   > 	   invalid, behaviour is undefined.
   > 
   > Those two statements seem to conflict.  If the input values don't make
   > any sense, doing something is almost certainly worse than panicking,
   > and doing nothing could allow a bug to go unnoticed or some more
   > obscure error to occur.

   Success or failure implies return.  "behaviour is undefined" means,
   among other things, that it may never return.

Precisely.  If it's `always successful', then it must return, which
means that the behaviour is at least partially defined.  Your response
gives me the impression that you simply misworded the original
statement.