Matt Thomas <matt@3am-software.com> wrote:
> 192 - 255       Interrupt (64)
> 160 - 191	Kernel high (32)
> 96 - 159        Real time (64)
> 64 - 95         Kernel low (32)
> 0 - 63          User (64)
It would be good to have Kernel High part, but why add additional 32 levels
for interrupts? In most cases (lets assume x86) we would use only 16 levels
(what means, that we have 16 free levels, thought), in maximal - 32 levels.

Anyway, I have another idea, but as I said - it could be insane :)
Make this architecture-adjustable, by something like:
#define PRI_HIGH_KERN_MIN (MAXPRI - INTR_COUNT) - HIGH_KERNEL_RANGE
In case, when architecture uses less interrupt levels - we will share Kernel
High with unused Interrupt levels range, in case when it uses more interrupt
levels - we would share Kernel High with Real Time range.
At least, I don't see the reason why Kernel High could not intervene and/or
share with those ranges, except this design could look not so clean. Or the
need that Kernel High threads _must_ always preempt Real Time threads, but
must they?

-- 
Best regards,
Mindaugas
www.NetBSD.org