On Wed, Sep 06, 2000 at 12:16:44PM -0400, Karim Yaghmour wrote:
>
> Even though some of your points are quite interesting, to me the real question
> is whether the RT subsystem should decide a policy or provide a capability. From
> what I see, some think that rt-mem-management is a bad policy, whereas others
> think that rt-mem-management is a very interesting capability.
Providing a capability often also imposes a policy. Once a memory allocator
is part of the standard toolset, it may work its way into e.g. semaphore
allocation and stack allocation. An IPC mechanism that relies on extending
the thread structure imposes that additional cost on code that may not
need the IPC mechanism. "Many features" is a policy as much as "few features".
For RTLinux, if someone wants to write a malloc module that calls down to
Linux kmalloc (this is absolutely trivial), then there is no problem and we
would most likely include it in the distribution. But basic RTLinux
services do not use dynamic allocators so that there will be as
few surprises as possible.
--
---------------------------------------------------------
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/
