> > (1) the first argument is a struct device *, which would mandate
> > changing the calling interfaces for all (except possibly tc; i forget
> > what that looks like) xxx_intr_establish() functions.
> 
> 	Yes.
> 
> 	How do you think about changing last argument of
> 	xxx_intr_establish() and argument of interrupt handler from
> 	(void *) to (struct device *) ?
> 	On i386, it is straightforward except few devices. (clock,
> 	npx, if_fea, ...)

This is a bad idea; there's no reason to believe that that is at all
the right thing to be passing to interrupt handlers.  (On the Alpha,
for devices which can be console, for instance, i can't and don't pass
the struct device *, even for e.g. PCI devices.)


> 	Or, how about adding another argument (struct device *) to
> 	xxx_intr_establish() ?

This seems unnecessary, since the device could, and i would say
_should_ do the evcnt handling itself.


> > (3) where do you get the storage for the evcnt?  per-interrupt-line?
> > you lose, if you have interrupt sharing.
> 
> 	one evcnt per "struct intrhand".

So, you think think that the low-level machinery should handle _all_
of the interrupt counting details?  "Yuck."

I disagree with this; (as you've acknowledged) it can't handle the
case i proposed below, and that case _is not_ an unreasonable one.

That also doesn't take into account the possibility of a device that
gets an interrupt on one unit, and then polls _all_ of its units to
see if they've got work to do.  I don't particularly like that style
of driver, but people have proposed it in the past...  With that kind
of driver, using this scheme there's no way to indicate which devices
"would have" caused interrupts.


> > (4) what do you do for 'weird' cases, like multi-port serial cards,
> > where you potentially want to know how often each 'com' thinks it
> > took an interrupt (to see load on each port), how often each _card_
> > took an interrupt (to see if you want to reassign a serial line to
> > another card, i.e. swap cables with a more lightly loaded line), and
> > how often the IRQ took an interrupt (to see if you want to move the
> > card to a different IRQ, if it's shared).
> 	
> 	each 'com':	In this case, driver level accounting is needed,
> 			and it is not in my scope.
> 	each 'card':	accounting on "struct intrhand" can cope with this.
> 	each IRQ:	old style counter is needed.

"see above" for comment re: not being able to count interrupts for
each 'com'.


> > So, in my opinion, the "Right" thing to do is fix evcnt interrupt
> > counters to be more useful, and, failing that, just use old-style
> > counters.
> 
> How about using both evcnt (per intrhand) and old-style counter (per line) ?

That's not unreasonable.  However, it has a couple of drawbacks:
	(1) If a good interrupt counting mechanism existed, this would
	    not be necessary.

	(2) It screws up the totals.

Any scheme which doesn't bother to take hierarchy into account will do
(2)...


cgd