proc extension request: p_sched

[Peter Kadau]

Hi !

    Theoretically any thread can set itself up to preempt mainline kernel threads,
    the DFly preemption mechanism is generalized, but only interrupt threads use that
    API right now (and I expect, generally speaking, only interrupt threads will
    ever do this).
So which gives: hard real-time is not part of DF plans ? But theoretically
possible to implement (modulo the critical sections cleanup you were mentioning) ?
Don't get me wrong, I'm not heading towards this, I just want to understand your
remark about the possibility for userland schedulers.
    Or, (3) Make the idle and realtime schedulers separate schedulers.  It
    just happens that these schedulers can simply schedule threads at slightly
    different LWKT priorities so an idle thread *always* has a lower priority
    then the threads scheduled by other schedulers and a realtime thread *always*
    has a higher priority then the threads scheduled by other schedulers, while
    running in userland.
But you need the - currently implicit - ordering information e.g. in chooseproc.
(First check rtqueuebits etc.)
You couldn't let them just be handled by different schedulers, since lwkt-priorities
are fine for seperating the rtpriority types, but not for choosing a process
to be scheduled in the first place.
That's why I was speaking about nesting - otherwise this would have to be
hardcoded in the dispatcher functions like it is already in the current ones.
Since these semantics probably will never ever be subject to change
one could do that of course...
Cheers
Peter
--
<peter.kadau at xxxxxxxxxxxxxxxx>
Campus der Max-Planck-Institute Tübingen
Netzwerk- und Systemadministration
Tel: +49 7071 601 598
Fax: +49 7071 601 616