On 2014-04-16 05:55, Chris Johns wrote:
On 15/04/2014 9:33 pm, Sebastian Huber wrote:
---
cpukit/sapi/include/confdefs.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index c8a9d0e..8b9b3e1 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -1583,6 +1583,12 @@ const rtems_libio_helper rtems_fs_init_helper =
* classic or posix objects that have not already been given resource limits.
*/
#if defined(CONFIGURE_UNLIMITED_OBJECTS)
+ #if !defined(CONFIGURE_UNIFIED_WORK_AREAS) && \
+ !defined(CONFIGURE_EXECUTIVE_RAM_SIZE) && \
+ !defined(CONFIGURE_MEMORY_OVERHEAD)
+ #error "Using CONFIGURE_UNLIMITED_OBJECTS with a pre-calculated work
space size makes no sense"
+ #endif
+
#if !defined(CONFIGURE_UNLIMITED_ALLOCATION_SIZE)
/**
* This macro specifies a default allocation size for when auto-extending
The use case is (was?) a fixed size or bounded pool of memory that can be used
in different ways depending on what is being run depending on how the app is
configured. I am not fussed either way what happens here as the unified work
areas is a nice feature.
Use case for CONFIGURE_UNLIMITED_OBJECTS is to enable the unlimited option for
all objects. This makes only sense if we have a work space which has some free
space. There are three means to do this as far as I know.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : [email protected]
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
