No, although the only one I see in confdefs.h is posix msq queues
On Tue, Apr 29, 2014 at 12:02 PM, Joel Sherrill
<joel.sherr...@oarcorp.com> wrote:
> +1
>
> One odd thought.. Can we detect when objects which are not unlimited are
> configured that way?
>
> On Apr 29, 2014 10:40 AM, Gedare Bloom <ged...@rtems.org> wrote:
> Looks good to me.
>
> On Tue, Apr 29, 2014 at 10:57 AM, Ralf Kirchner
> <ralf.kirch...@embedded-brains.de> wrote:
>> Mark POSIX Keys and POSIX Key Value Pairs as supported.
>> Add list of unsupported object classes.
>> Add hint to unified work areas.
>> Add example.
>> ---
>> doc/user/conf.t | 40 ++++++++++++++++++++++++++++++++++++----
>> 1 Datei geändert, 36 Zeilen hinzugefügt(+), 4 Zeilen entfernt(-)
>>
>> diff --git a/doc/user/conf.t b/doc/user/conf.t
>> index f0aa022..ef40480 100644
>> --- a/doc/user/conf.t
>> +++ b/doc/user/conf.t
>> @@ -355,6 +355,14 @@ software is unknown. In these situations users do not
>> need to control
>> the size of the workspace very tightly because they just want to get
>> the new software to run; later they can tune the workspace size as
>> needed.
>>
>> +The following API-independent object classes can be configured in
>> +unlimited mode:
>> +
>> +@itemize @bullet
>> +@item POSIX Keys
>> +@item POSIX Key Value Pairs
>> +@end itemize
>> +
>> The following object classes in the Classic API can be configured in
>> unlimited mode:
>>
>> @@ -377,7 +385,6 @@ configured in unlimited mode:
>> @item Threads
>> @item Mutexes
>> @item Condition Variables
>> -@item Keys
>> @item Timers
>> @item Message Queues
>> @item Message Queue Descriptors
>> @@ -387,9 +394,34 @@ configured in unlimited mode:
>> @item Spinlocks
>> @end itemize
>>
>> -Due to how the POSIX object memory requirements are configured the
>> -unlimited object support does not provide unlimited size declarations
>> -for POSIX keys or queued signals.
>> +The following object classes can @strong{not} be configured in unlimited
>> mode:
>> +@itemize @bullet
>> +@item Drivers
>> +@item File Descriptors
>> +@item User Extensions
>> +@item Queued Signals
>> +@end itemize
>> +
>> +Due to the memory requirements of unlimited objects it is strongly
>> recommended
>> +to use them only in combination with the unified work areas. See
>> +@ref{Configuring a System Separate or Unified Work Areas} for more
>> information
>> +on unified work areas.
>> +
>> +The following example demonstrates how the two simple configuration
>> defines for
>> +unlimited objects and unified works areas can replace many seperate
>> +configuration defines for supported object classes:
>> +@example
>> +#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>> +#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>> +#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>> +
>> +#define CONFIGURE_UNIFIED_WORK_AREAS
>> +#define CONFIGURE_UNLIMITED_OBJECTS
>> +
>> +#define CONFIGURE_INIT
>> +
>> +#include <rtems/confdefs.h>
>> +@end example
>>
>> Users are cautioned that using unlimited objects is not recommended for
>> production software unless the dynamic growth is absolutely required. It
>> --
>> 1.7.10.4
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel@rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
