On Tue, 7 Dec 1999, Richard Henderson wrote:
>(3) I think you should continue to manage _alpha_irq_masks from
>generic code instead of having a separate instance of cached_irq_mask
>from virtually every sys_foo.c.
Not only from every sys_foo.c but for every irq controller driver. It make
sense that each controller manages its own local caching of the masking
because they are all per-controller caches. So each controller is free to
cache the information in its preferred way. But yes, by sharing the
_alpha_irq_mask we would avoid to waste some byte of memory. I did such
choice to generate the cleaner code possible and to left local things that
are local (so I didn't had to bother about side effects of the changes
inside each irq controller driver and I could basically cut-and-paste
arch/i386/kernel/i8259.c). If there won't be side effects and advantages
I'll agree to replace the per-irq cache with a global cache of course.
>(6)
> case 1:
>- handle_irq(RTC_IRQ, -1, ®s);
>+ handle_irq(RTC_IRQ, ®s);
>
>A timer tick that comes in through entInt(1,...) need not
>and should not be acked. PALcode has already done that.
>I don't see a mechanism for this.
I know very well of such problem and infact my code is still very
experimental and I _don't_ use the RTC as timer interrupt so I don't care
about its acking and masking right now (I noticed the purpose of passing
-1 as ack in the old code was to skip the mask and ack).
Of course I'll have to implement a special RTC hw_interrupt_type vector
that does nothing in the ack and mask callback. I can set the handler in
the common code for all platforms. This looks very cleaner than passing a
magic value to the irq main routine to differentiate between irq types.
>That's all I see for now. If I get ambitious this evening
>I may see about updating the patch for all of sys_foo.c and
>try it out on some other systems.
Many thanks! IMHO another option would be to ignore the other sys_*.c
until the tsunami platform (the one I use for developement) will be
completly stable (so addressing the RTC case plus the SMP case that
doesn't boot here). So we won't risk having to fix two times the other
platforms if we'll need to redesign something. In other words I would
suggest to update only the platform necessary for the developement until
we'll be completly happy. Of course if you'll do the update your patch
will be _very_ welcome even now! But beware: we'll risk a bit having to do
it again later...
I'll address your other points ASAP.
Thanks for your comments!
Andrea
