On Mon, Aug 31, 2020 at 2:58 AM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > On 31/08/2020 09:39, Chris Johns wrote: > > > On 31/8/20 4:43 pm, Sebastian Huber wrote: > >> On 31/08/2020 02:34, Chris Johns wrote: > >> > >>> On 31/8/20 12:49 am, Sebastian Huber wrote: > >>>> On 22/08/2020 09:49, Chris Johns wrote: > >>>> > >>>>> On 21/8/20 9:51 pm, Sebastian Huber wrote: > >>>>>> In contrast to rtems_task_create() this function creates a task with a > >>>>>> user-provided task storage area. > >>>>> The name is build but it creates a task? I am wondering about > >>>>> rtems_task_create_static or something along this line? > >>>> A function to do a static initialization is a contradiction from my > >>>> point of > >>>> view. Static initialization means for me that you statically initialize > >>>> a data > >>>> structure and then it is ready to use (it may involve a static > >>>> constructor). > >>>> > >>>> The function builds a task from user-provided (stack, attributes, etc.) > >>>> and > >>>> system-provided (thread control block) components. > >>> Build and create are both verbs which means both contradict the idea of > >>> something being static. By tradition we assume a function's naming is in > >>> the > >>> run-time context and we do not consider the fact a compiler may optimise > >>> the > >>> operation and prepare the result before the code runs. > >> Yes, the task creation or building through a function call is not a static > >> initialization. This is why I don't like rtems_task_create_static(). > >>> I am concerned there maybe doubt about how the calls are to be used if > >>> you are > >>> not familiar with the API and it's history. Do I need to create a task > >>> then > >>> build it before I start it? > >> Yes, such a confusion is possible, but I think this can be solved by the > >> documentation. > > Yes it can but why not take a moment to consider what we could use. :) > > > >> Also both functions return an identifier. You cannot use them > >> with an identifier. > > That implies some knowledge of the API. For us this is apparent. > > > >>> The call names I proposed both create a task, one is > >>> static and by default the other is not. > >> If you really want something with create in it, then I suggest > >> rtems_task_create_with_config() and > >> rtems_message_queue_create_with_config(). I > >> think these names are a bit long. > > This is hard. "With" implies having a config, ie created with it attached > > to the > > task. What about rtems_task_create_by_config() as a shorten version of > > rtems_task_create_by_means_of_a_config() or even > > rtems_task_create_using_config()? > So we have currently on the table: > > rtems_task_create_by_config() > > rtems_message_queue_create_by_config() > > vs. > > rtems_task_build() > > rtems_message_queue_build() > > Or long vs. potentially confusing. >
I think it is better to be clear and long. I would also suggest maybe: xxx_create_from_config() The sense is a little better. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
