Re: proc extension request: p_sched

[Peter Kadau <peter.kadau@xxxxxxxxxxxxxxxx>]

Hi !

>     I will commit the pointer to sys/proc.h so your proc
>     size doesn't change. 
That's a good starting point, yes, thanks. :-)

> ...You'll have to maintain the
>     rest of the stuff as a patch set for now... it looks
>     like the structural topology needs some work so I'd rather
>     not commit it all now.  For example, it is more likely that
>     either p_sched would not be allocated and freed,  or
>     there would be two pointers hanging off the proc...
>     one describing the scheduler and another describing
>     per-process extension info.
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.

> ...  I would prefer that no
>     dynamic allocations be necessary for the default 
>     scheduler  but I can see their use for module-loaded
>     schedulers... perhaps a union is a good compromise:
>
>     struct proc {
> 	...
> 	struct scheduler *p_scheduler;	/* (static) describe scheduler */
> 	union sched	     p_sched; 		/* per-process scheduler info */
>     }
>
>     Then union sched would be:
>
>     union sched {
> 	void	*s_ext;
> 	struct fubar_sched *s_fubar;
> 	struct {
> 	     ... embedded elements ...
> 	} bat_sched;
> 	struct {
> 	     ... embedded elements ...
> 	} bar_sched;
>     }
>
>     That is, it could accomodate both built-in non-dynamic schedulers
>     and KLD schedulers, which would give us the flexibility of coming to
>     a final decision later on down the line without sacrificing flexibility
>     now.
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@xxxxxxxxxxxxxxxx>

Campus der Max-Planck-Institute Tübingen
Netzwerk- und Systemadministration

Tel: +49 7071 601 598
Fax: +49 7071 601 616