Subject: Re: [linux-audio-dev] rough rough ladspa docs
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon May 15 2000 - 02:26:22 EEST
>Perhaps a LADSPA_PROPERTY_RUN_WITHIN_IRQ/KERNEL_CAPABLE would be handy
>indicating that besides that you are hard RT capable,
>you assure that you don't make ANY syscalls, except code which is allowed to
>be called from an IRQ/kernel)
for RUN_WITHIN_IRQ, I'd say: nice idea, but the wrong
label. LADSPA_PROPERTY_BOUNDED would be more accurate. the talk of
"interrupt context" comes, i think, from james mccartney. when he
first mentioned it to me, i thought "what is he going on about,
nothing like supercollider can ever run in interrupt context under
linux!". then i realized that although the label is wrong, the *idea*
is a good one. what it means to run in an interrupt handler for a
periodically interrupting device is that your execution time is
guaranteed to be bounded.
KERNEL_CAPABLE makes some additional ideas pop up, and i think these
are valid (no library calls, no math calls etc.)
**** BUT **** floating point code is NOT legal inside the Linux
kernel, so this is probably a pretty redundant idea. The kernel does
not save/restore FP flags, and thus if it uses the FPU, it can destroy
user-level FP context when it returns to a process that was using the
FPU. You might have thought someone would come up with a patch for
this, but to date, AFAIK nobody has ever had a need to do so.
> (1) The plugin must not use malloc(), free() or other heap memory
> management within its run() or run_adding() functions. All new
> memory used in run() must be managed via the stack. These
> restrictions only apply to the run() function.
increasing the size of the stack could also cause RT delays. the claim
must really be:
(1) The plugin must not use malloc(), free() or other operations
that cause an increase in the size of the heap OR the stack.
All memory used must already have been claimed by the process,
either via previous calls to increase the heap size, or
through the existence of a large enough stack.
note that under linux, calling brk(2) does NOT allocate memory to a
process. the pages are only allocated when they are touched. this was
the subject of considerable discussion on linux-kernel recently.
--p
> (2) The plugin will not attempt to make use of any library
> functions with the exceptions of functions in the ANSI standard C
This archive was generated by hypermail 2b28 : Mon May 15 2000 - 02:50:44 EEST