Subject: Re: some diffs to 1.0-current / 1.0 (probably as well)
To: Niklas Hallqvist <firstname.lastname@example.org>
From: None <email@example.com>
Date: 01/04/1995 09:24:09
> It was config.new that was busted! In my config.new/sem.c there are
> uses of the constant "8" instead of MAXPARTITIONS. When I found this
> and changed it everything worked OK! I wonder if this is fixed in
> -current? I'm still at 941225 sources.
Hm, I'm running off 941221 sources, but I think I should have noticed such
a problem as well??? I'll have a look at it at home..
> travelling without net-connectivity until Monday). One thing I
> thought about: Is it really necessary to schedule an AUD3 int?
> Wouldn't it just suffice to block INTF_EXTER, pop the saved a0, keep
> the interrupt frame we have and lower the PSL directly instead. A
I thought about that as well, problem is: the level-6 int will interrupt
any code running at lower priority, thus if some code segment tries to do
x = splclock();
do something atomic
you'll defeat the meaning of raising the IPL, since you WILL interrupt that
code segment with a level 6 interrupt, lowering IPL to 4 afterwards will
not make that go away unless you uncouple the two interrupts truely. That's
why I'm generating a fake level 4 interrupt.
> slight optimization, but it also makes things simpler in the source.
> I also like to start a discussion on how a new interrupt handling
> system should look like. Many of us have been aware that we need a
A new one? Oh, is there one right now...? :-) Yeah, we definitely need one...
> registration possibility, but Markus' changes also shows of the
> interrupt remapping potential, could we make this somewhat more
> flexible to use at a driver level? Suppose, we still want some INT6
> device preempt the serial interface, but lower most other INT6
> devices. Think about it, I will. I may volunteer to write something,
> but I would like a consensus on what needs to be done.
Problem is (pretty specific to the serial interrupt) that you can't have
almost anything reasonable at ipl-6 without considerably bothering the
serial-driver. One possible approach I could see for drivers like the serial
driver, but running off ipl-6, would be to do the thing you suggested at
the beginning, have the ipl-6 handler lower ipl to 4, and execute the driver
with the interrupt itself being blocked. Note that you do this ONLY with
interrupts that don't interact with the rest of the system, as the rest
of the system won't know how to protect itself against interruption from
such a driver.
EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild
Zweierstrasse 35 Hotline: +41 1 291 45 60 firstname.lastname@example.org
CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH
>Solaris 2 is not an upgrade from Solaris 1. They just want you to THINK it is.