libc_r silliness

[Daniel Eischen]

On Tue, 8 Jul 2003, John Baldwin wrote:
> 
> On 09-Jul-2003 Daniel Eischen wrote:
     ^^ Is there a time lag somewhere :-)

> > On Tue, 8 Jul 2003, John Baldwin wrote:
> >> Another possibility is to have
> >> each thread library provide their own sched_get_{min,max} and
> >> wrap the sched_{get,set}schedparam() syscalls to massage the
> >> thread priority values into their corresponding process priority
> >> values to simulate a single priority space for each policy.
> > 
> > I like this better than the other option, but how do you
> > know that when the application calls sched_setschedparam()
> > with a priority of 10, that it really came from
> > sched_get_priority_min() + 10 (meaning -10) or whether it was
> > hardcoded to 10 and really wants 10.
> 
> You aren't supposed to hard code 10, you're supposed to derive
> your value from the min() and max() functions as far as I can
> tell. :-P

Well, yup, that's what you're _suppose_ to do...  I guess
we can do this.  To summarize:

  sched_get_schedparam(), sched_set_schedparam(),
  sched_get_priority_min(),  sched_get_priority_max()
  will be provided by the thread libraries (unless
  kernel and thread priorities match for all scheduling
  protocols).

  The library functions sched_get_schedparam(),
  sched_get_priority_min(), and sched_get_priority_max()
  will call the respective system calls and convert kernel
  SCHED_OTHER priorities to thread SCHED_OTHER priorities
  before returning.

  The library function sched_set_schedparam() will
  convert thread SCHED_OTHER priorities to kernel
  SCHED_OTHER priorities before making the actual
  system call.

If the thread priority ranges for SCHED_FIFO and SCHED_RR
do not match the kernel priority ranges, the thread libraries
will do similar conversions (they might just as well do
the conversions even if they are the same).

-- 
Dan Eischen