On 13/09/2020 23:17, Joel Sherrill wrote:
On Sun, Sep 13, 2020 at 3:41 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>> wrote:
On 12/09/2020 02:53, Chris Johns wrote:
> On 12/9/20 1:34 am, Sebastian Huber wrote:
>> + * @par Notes
>> + * By default, the calculation for the required memory in the
RTEMS Workspace
>> + * for tasks assumes that all Classic API Tasks are created by
>> + * rtems_task_create(). This configuration option can be used
to reduce the
>> + * required memory for the system-provided task storage areas
since tasks
>> + * created by rtems_task_create_from_config() use a
user-provided task storage
>> + * area.
>> + */
>> +#define CONFIGURE_TASKS_CREATED_FROM_CONFIG
> The documentation does not deal with 0 the default. It is fair
to assume a
> config that controls allocations for an API is consistent with
similar calls. It
> I set message queues to 0 any create call fails. I needed to
check the patch to
> know if 0 meant you could not create any tasks from a config.
>
> If CONFIGURE_TASKS_CREATED_FROM_CONFIG was added to the
configuration table
> (which I am ok with) the rtems_task_create_from_config() could
check for a
> non-zero value before proceeding.
The tasks created by rtems_task_create_from_config() are normal
Classic
API tasks. The only difference is that the thread storage is
provided by
the user. If you get the configuration wrong, you just have a wrong
workspace size. There are lots of other ways to get a wrong workspace
size. I am not sure if we really should add extra code just to check
this option and produce more run-time errors.
>
>> +#ifndef CONFIGURE_TASKS_CREATED_FROM_CONFIG
>> + #define CONFIGURE_TASKS_CREATED_FROM_CONFIG 0
>> +#endif
>> +
>> +#if CONFIGURE_TASKS_CREATED_FROM_CONFIG > CONFIGURE_MAXIMUM_TASKS
>> + #error "CONFIGURE_TASKS_CREATED_FROM_CONFIG shall be less
than or equal to CONFIGURE_MAXIMUM_TASKS"
>> +#endif
>> +
>> #ifndef CONFIGURE_MAXIMUM_POSIX_THREADS
>> #define CONFIGURE_MAXIMUM_POSIX_THREADS 0
>> #endif
>> diff --git a/cpukit/include/rtems/confdefs/wkspace.h
b/cpukit/include/rtems/confdefs/wkspace.h
>> index de476dbf82..215cdcb141 100644
>> --- a/cpukit/include/rtems/confdefs/wkspace.h
>> +++ b/cpukit/include/rtems/confdefs/wkspace.h
>> @@ -100,7 +100,9 @@
>> + _CONFIGURE_POSIX_INIT_THREAD_STACK_EXTRA \
>> + _CONFIGURE_LIBBLOCK_TASKS_STACK_EXTRA \
>> + CONFIGURE_EXTRA_TASK_STACKS \
>> - + rtems_resource_maximum_per_allocation( _CONFIGURE_TASKS ) \
>> + + rtems_resource_maximum_per_allocation( \
>> + _CONFIGURE_TASKS - CONFIGURE_TASKS_CREATED_FROM_CONFIG \
> I am confused by this. Does _CONFIGURE_TASKS have the number of
tasks created
> from config included in it? How was that added in?
>
> I would have assumed I set CONFIGURE_TASKS_CREATED_FROM_CONFIG
and that would be
> added _CONFIGURE_TASKS internally.
>
> Sorry, I think I am not understanding something.
My proposal is to configure the maximum Classic API tasks as usual:
#define CONFIGURE_MAXIMUM_TASKS 123
Then also define how many are created by
rtems_task_create_from_config():
#define CONFIGURE_TASKS_CREATED_FROM_CONFIG 42
An alternative could be to do something like this:
#define CONFIGURE_MAXIMUM_TASKS 81
#define CONFIGURE_MAXIMUM_TASKS_CREATED_FROM_CONFIG 42
However, this has some issues:
1. What happens if you use the unlimited option for both?
Make it clear that CONFIGURE_MAXIMUM_TASKS_CREATED_FROM_CONFIG is a
subset of CONFIGURE_MAXIMUM_TASKS.
CONFIGURE_MAXIMUM_TASKS_CREATED_FROM_CONFIG must be strictly <=
CONFIGURE_MAXIMUM_TASKS.
CONFIGURE_MAXIMUM_TASKS_CREATED_FROM_CONFIG can't have unlimited set.
Check all that from confdefs.h.
2. You need extra code to enforce the individual maximum values.
Macros I think. At compile time.
3. It suggests that the tasks belong to different APIs or object
classes. This is not the case.
Not if explained well.
What about:
CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE
or
CONFIGURE_TASKS_WITH_USER_PROVIDED_STORAGE
I don't like the work maximum for this configuration option. You can
also create more that this value indicates, however, at the expense of a
wasted system-provided stack space.
This new name makes the configuration independent of a directive name
(rtems_task_create_from_config(), rtems_task_build(), rtems_task_make(),
...). Long but descriptive option names a not really an issue since you
write them only once in your application.
This new option has the following constraints:
1. CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE <=
CONFIGURE_MAXIMUM_TASKS
2. The unlimited flag must not be set.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
