On Mon, Sep 04, 2000 at 09:19:35AM -0500, Sheldon Hoffman wrote:
> It turns out, according to Victor, that the amount of stack memory
> available to RTLinux code is, well, unpredictable (non-deterministic?)
Interrupt code runs on the stack of whatever was running when the interrupt
happened.
> Why can't I define the stack size for my RTL interrupt service routine?
The theory is that interrupt service routines will need minimal
resources. It is quite simple for a ISR to trigger a thread or
even to force a switch to a thread.
> Isn't the stack for an RTL interrupt service routine a RTL system
> resource that should be managed by the RTLinux system? Wouldn't
> that make it more robust (ie deterministic) than having to hope and
> pray that other Linux drivers don't intermittently use "too much"
> stack?
There is a tradeoff here. If we automatically switched stacks, we would
have a performance penalty -- not much of one, but our experience is that
little delays are easy to accumulate and difficult to clear. So we give you
an easy option -- .e.g you could all rtl_wakeup_np(mythread) and it will
automatically run right away, on its own stack, if it is higher priority
than the current thread (and on the same processer).
> I can use the pthread_attr_setstacksize() to define the stack for my
> RTLinux processes but how do I do this for a fifo handler? For
> init_module() and cleanup_module() code? For my RTL interrupt
> service routine?
The init_module and cleanup_module codes run on a close to empty standard
8K linux stack (I think it's 8k these days).
> I'm beginning to realize that there are quite a number of different
> execution contexts, each with its own largely undocumented set of
> rules. I would like to find out what "rules" there are for stack
> usage in each of these contexts.
There are only a few:
Linux user mode
Linux kernel mode
Linux interrupt context in kernel model
Linux thread context in kernel mode (system calls, preemption from user mode )
RTLinux RT thread mode
RTLinux RT interrupt mode
standard interrupt
rtlinux_sigaction interrupt -- where a mmu switch is made to the context of
the user process.
Again: the rule for ISRs is, keep them very simple and switch to a thread (or Linux)
whenever
you start to need things that are not there.
>
> Here's what I count (so far) for execution contexts:
>
> Standard Linux
> USER MODE
> 1. linux processes
>
> KERNEL MODE
> 2. init_module()
> 3. cleanup_module()
> 4. linux device driver code
> 5. linux interrupt service routine
>
> RT Linux (all of the above plus:)
> KERNEL MODE
> 6. RTL init_module() (additional rtl_xxx functions are available)
> 7. RTL cleanup_module() "
> 8. RTL fifo handler
> 9. RTL interrupt service routine
> 10 RTL processes (stack size set with pthread_attr_setstacksize())
>
> There may actually be more execution contexts ("environments"?) that these.
>
> RTLinux seems to have undocumented "rules" such as (in my words):
>
> The stack size for an RTL interrupt service routine is extremely
> limited and is not settable by the application programmer. To
> be on the safe side, an RTL ISR should use no more than 10 or 20
> bytes of stack. If an ISR overflows the stack, a system crash
> will result. It is not possible for an ISR to determine how
> much stack space it has available to it.
>
> The stack size for an RTL process can be defined in the processes's
> attribute block with the pthread_attr_setstacksize() function
> before calling pthread_create(). pthread_attr_setstacksize() is
> not found by the "man" program.
>
> In otherwords, I think the stack should be a RTL system controlled
> resource. Its use is unavoidable.
>
> My wish: I would like to see RTLinux provide a way for me, the
> application programmer, to define the stack size for each of these
> contexts (#6-#9 above).
>
> Interestingly, I did not find any information about the stack in
> Rubini's Linux Device Drivers book.
>
> Well, I feel that what I'm trying to do constitues a "real case" and
> I am definitely interested in learning more about the using of the
> stack in the RTLinux system.
>
> I haven't had the chance to review RTAI but I would also be interested
> in a discussion from that camp.
>
> Finally, I want to thank Victor for all of his generous help!
>
> -------------------------
> Shel Hoffman
> -------------------------
>
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
