proc extension request: p_sched

[Matthew Dillon]

:I'd rather think the userland scheduler would be fixed
:at boot-time so why bother with a pointer in proc ?
:Are you thinking of switching the scheduler in mid-air or
:do I miss some other point entirely ?
:I wasn't talking about userspace threading schedulers, e.g.

    In fact I was talking about kernelspace userland schedulers (what
    you have been working on).  e.g. kern_switch.c and friends.
    And, also, I was indeed talking about being able to switch the scheduler
    on the fly.

    It would actually be very easy to do in DFly because the
    userland scheduler always uses the LWKT scheduler to do the actual
    scheduling, and the LWKT scheduler is fixed.

    This means, theoretically, that you can have multiple userland
    schedulers operating in tandem.  While we would not necessarily use it
    that way (and, certainly there would be issues with one hogging the other),
    the ability operate multiple userland schedulers simultaniously would
    make transitioning to a new scheduler on a live system very easy.

    The same scheme could also theoretically give us the ability to implement
    a hard real-time scheduler that runs in tandem with the 'standard' userland
    scheduler, for example, as well as other sorts of resource-sensitive
    schedulers.

:Yes, but the opaque pointer gives us all the flexibility we need for now
:and we don't have other examples (yet).
:And what about proc0 and forking ? Since IMO the scheduler is fixed
:at boot-time at least struct sched should be known at boot-time
:to fill in proc0. Any hooks that could be used here ?
:
:Cheers
:Peter
:
:-- 
:<peter.kadau at xxxxxxxxxxxxxxxx>

    Yes, the idea would be that p_scheduler would simply be inherited by
    the children (no allocations required), and an API call through
    p_scheduler would be used to allocate p_sched if required.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>