On 16/04/2014 5:00 pm, Sebastian Huber wrote:
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.
Yes this is true. Can the error message please be changed to:
"CONFIGURE_UNLIMITED_OBJECTS requires a unified work area, an executive
RAM size, or a defined workspace memory overhead"
The fact we have an error message implies it does not make sense.
I see this patch and discussion as a side effect of requiring confdefs
to configure a system. A goal of confdefs is to accurately determine the
workspace size given the exact number of resources required however
confdefs is not perfect and never will be and users needs to be aware of
this, for example stack space allocation in a separate workspace
environment cannot be estimated and managed automatically. You could
argue not having unified work areas and not defining a memory overhead
will cause problems and enforcing it removes the need for this patch.
Another larger step is to only support a unified work space removing the
need for confdefs to make any memory calculations. You either have the
memory or you do not.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
