Charles,

As i said before: if you'd wanted to discuss these points at length,
you should have said _something_ -- _anything_, even -- when i sent
you the proposed interface > a week ago.  (No, i didn't send the whole
set of diffs, i wanted comments on the basic interface first.  You
provided no feedback whatsoever.)  If you wish to continue this
discussion, please do so not on current-users (as it has very little
to do with users of NetBSD-current), and cc: either 'core' or the
developers' mailing list on the discussion.


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

To be honest, someone writing machine-indepedent support for a
non-standard bridge will likely be screwed in any case.

To support non-standard bridges with complete generality, you
need a potentially very large number of nested function calls -- up to
255 -- and the implementation of some or all of those (depending on
compiler) may require stack linkages, etc...  leading you to the case
where, for the worst case, you end up with potential kernel stack
overflows...  There are more general solutions that the one that i
implemented, which are a fair bit more complex to implement but which
still don't get necessarily all the functionality one might need.
Therefore, i chose an implementation that I knew would work an all the
hardware that i'd seen and which was described in the relevant
standards.

I think non-conformant "machine-independent" PPBs will be very few and
quite far between, especially since a reasonably good standard exists.
PPBs used by only a single machine could be relatively easily handled,
for all of the obvious cases that i can think of, in the MD mapping
code.


I figured it was better to implement something that would definitely
work in the worst case, on the 'standard' hardware, than implement
something that could easily work on really weird hardware but may
spontaneously reboot in a way that's difficult to debug, in the worst
case on _any_ hardware.


> I don't buy that.
> Even if I did, the internals should be documented.

Should be, yes.  Have been, no, except what documentation is in the
code (which, for the interrupt 'swizzling,' amounts to a couple of
lines of cryptic comments).  Don't critique something that's not 
an internals document as if it were one.





cgd