On 14/09/2020 00:30, Chris Johns wrote:
On 14/9/20 12:11 am, Sebastian Huber wrote:
Hello Joel,
On 12/09/2020 05:38, Joel Sherrill wrote:
Hi
Starting another thread just to discuss this method's name. I wonder if the
config part is more important than the static allocation of resources part.
Which should be emphasized in the name?
From config puts focus on the attributes part. With static resources or
similar puts emphasis on the other part.
With config is more general but is there another mode of operation? Seems the
static nature is more important and the name should.emohasize that.
I don't really like the name rtems_task_create_from_config(). The key feature of
this directive is that a user-provided thread storage area is used instead of a
system-provided. That the parameters for this new directive are contained in a
configuration structure is just an API choice. We could also use a function with
nine parameters.
I also don't like the wording "static" in this context. What we need is a
directive name for "create an Classic API task with a user-provided thread
storage area".
rtems_task_create_with_storage()
rtems_task_create_with_managed_storage()
Tasks always have a storage. It is always managed, the question is by whom?
rtems_task_create_user_storage()
rtems_task_create_user_managed_storage()
rtems_task_create_user_provided_storage()
What does it create, a task or a user storage?
They are created using the words from your sentence above :)
My favorite is still rtems_task_build().
Not mine. Do you create, build then start? I think it needs create and it lacks
the storage bit.
Maybe we should use a synonym of "create" (build is not a synonym of
create) such as "make":
rtems_task_make()
rtems_message_queue_make()
--
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 : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
