[Xenomai] rt_print_auto_init()

[Xenomai] rt_print_auto_init()

[Philippe Gerum]

Hi Jan,

Do you still have a use case for calling rt_print_auto_init(false) or
not calling rt_print_auto_init(true) from libcobalt's bootstrap code?

-- 
Philippe.

Re: [Xenomai] rt_print_auto_init()

[Jan Kiszka]

On 2015-07-23 11:24, Philippe Gerum wrote:
> 
> Hi Jan,
> 
> Do you still have a use case for calling rt_print_auto_init(false) or
> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
> 

Huh, that was a day-one feature, now 8 years old, barely remember the
details. I'm currently not aware of a concrete scenario. It definitely
makes sense to revisit this think.

I guess one, if not the major problem back then was that the implicit
malloc of the initialization step was not consistently causing a
SIGDEBUG warning. That is now different.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] rt_print_auto_init()

[Philippe Gerum]

On 07/23/2015 11:37 AM, Jan Kiszka wrote:
> On 2015-07-23 11:24, Philippe Gerum wrote:
>>
>> Hi Jan,
>>
>> Do you still have a use case for calling rt_print_auto_init(false) or
>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>
> 
> Huh, that was a day-one feature, now 8 years old, barely remember the
> details. I'm currently not aware of a concrete scenario. It definitely
> makes sense to revisit this think.
> 
> I guess one, if not the major problem back then was that the implicit
> malloc of the initialization step was not consistently causing a
> SIGDEBUG warning. That is now different.
> 

Since the current thread won't be notified until XNWARN is armed in its
TCB, any objection to move that call as a nop placeholder to the compat
section in libtrank, leaving the implicit init to libcobalt as currently?

-- 
Philippe.

Re: [Xenomai] rt_print_auto_init()

[Jan Kiszka]

On 2015-07-23 11:45, Philippe Gerum wrote:
> On 07/23/2015 11:37 AM, Jan Kiszka wrote:
>> On 2015-07-23 11:24, Philippe Gerum wrote:
>>>
>>> Hi Jan,
>>>
>>> Do you still have a use case for calling rt_print_auto_init(false) or
>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>>
>>
>> Huh, that was a day-one feature, now 8 years old, barely remember the
>> details. I'm currently not aware of a concrete scenario. It definitely
>> makes sense to revisit this think.
>>
>> I guess one, if not the major problem back then was that the implicit
>> malloc of the initialization step was not consistently causing a
>> SIGDEBUG warning. That is now different.
>>
> 
> Since the current thread won't be notified until XNWARN is armed in its
> TCB, any objection to move that call as a nop placeholder to the compat
> section in libtrank, leaving the implicit init to libcobalt as currently?

Ack.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] rt_print_auto_init()

[Gilles Chanteperdrix]

Philippe Gerum wrote:
>
> Hi Jan,
>
> Do you still have a use case for calling rt_print_auto_init(false) or
> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>

At some point, I added a pre-allocation of a few buffers which avoided the
need for malloc, and forced the call to rt_print_auto_init(true) in the
POSIX skin library. I do not know whether all this has survived the
Xenomai 3 cleanup though.

-- 
                                            Gilles.
https://click-hack.org

Re: [Xenomai] rt_print_auto_init()

[Philippe Gerum]

On 07/23/2015 03:27 PM, Jan Kiszka wrote:
> On 2015-07-23 11:45, Philippe Gerum wrote:
>> On 07/23/2015 11:37 AM, Jan Kiszka wrote:
>>> On 2015-07-23 11:24, Philippe Gerum wrote:
>>>>
>>>> Hi Jan,
>>>>
>>>> Do you still have a use case for calling rt_print_auto_init(false) or
>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>>>
>>>
>>> Huh, that was a day-one feature, now 8 years old, barely remember the
>>> details. I'm currently not aware of a concrete scenario. It definitely
>>> makes sense to revisit this think.
>>>
>>> I guess one, if not the major problem back then was that the implicit
>>> malloc of the initialization step was not consistently causing a
>>> SIGDEBUG warning. That is now different.
>>>
>>
>> Since the current thread won't be notified until XNWARN is armed in its
>> TCB, any objection to move that call as a nop placeholder to the compat
>> section in libtrank, leaving the implicit init to libcobalt as currently?
> 
> Ack.
> 

Ok, let's see how deep you can dive into your context stack these days:
what about rt_print_cleanup() now? I see no in-tree callers, and I
wonder whether there is any use case for an application to stop the
stdio support during runtime.

-- 
Philippe.

Re: [Xenomai] rt_print_auto_init()

[Jan Kiszka]

On 2015-07-24 16:29, Philippe Gerum wrote:
> On 07/23/2015 03:27 PM, Jan Kiszka wrote:
>> On 2015-07-23 11:45, Philippe Gerum wrote:
>>> On 07/23/2015 11:37 AM, Jan Kiszka wrote:
>>>> On 2015-07-23 11:24, Philippe Gerum wrote:
>>>>>
>>>>> Hi Jan,
>>>>>
>>>>> Do you still have a use case for calling rt_print_auto_init(false) or
>>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>>>>
>>>>
>>>> Huh, that was a day-one feature, now 8 years old, barely remember the
>>>> details. I'm currently not aware of a concrete scenario. It definitely
>>>> makes sense to revisit this think.
>>>>
>>>> I guess one, if not the major problem back then was that the implicit
>>>> malloc of the initialization step was not consistently causing a
>>>> SIGDEBUG warning. That is now different.
>>>>
>>>
>>> Since the current thread won't be notified until XNWARN is armed in its
>>> TCB, any objection to move that call as a nop placeholder to the compat
>>> section in libtrank, leaving the implicit init to libcobalt as currently?
>>
>> Ack.
>>
> 
> Ok, let's see how deep you can dive into your context stack these days:
> what about rt_print_cleanup() now? I see no in-tree callers, and I
> wonder whether there is any use case for an application to stop the
> stdio support during runtime.

I used to have one recently that was specifically interested in
terminating the associated thread. But that case was modified later on
due to other reasons. In principle, the value of this cleanup function
is in the printer thread control, even if that means cutting of wrapped
I/O (you could still print via unwrapped services then).

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] rt_print_auto_init()

[Philippe Gerum]

On 07/24/2015 04:56 PM, Jan Kiszka wrote:
> On 2015-07-24 16:29, Philippe Gerum wrote:
>> On 07/23/2015 03:27 PM, Jan Kiszka wrote:
>>> On 2015-07-23 11:45, Philippe Gerum wrote:
>>>> On 07/23/2015 11:37 AM, Jan Kiszka wrote:
>>>>> On 2015-07-23 11:24, Philippe Gerum wrote:
>>>>>>
>>>>>> Hi Jan,
>>>>>>
>>>>>> Do you still have a use case for calling rt_print_auto_init(false) or
>>>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>>>>>
>>>>>
>>>>> Huh, that was a day-one feature, now 8 years old, barely remember the
>>>>> details. I'm currently not aware of a concrete scenario. It definitely
>>>>> makes sense to revisit this think.
>>>>>
>>>>> I guess one, if not the major problem back then was that the implicit
>>>>> malloc of the initialization step was not consistently causing a
>>>>> SIGDEBUG warning. That is now different.
>>>>>
>>>>
>>>> Since the current thread won't be notified until XNWARN is armed in its
>>>> TCB, any objection to move that call as a nop placeholder to the compat
>>>> section in libtrank, leaving the implicit init to libcobalt as currently?
>>>
>>> Ack.
>>>
>>
>> Ok, let's see how deep you can dive into your context stack these days:
>> what about rt_print_cleanup() now? I see no in-tree callers, and I
>> wonder whether there is any use case for an application to stop the
>> stdio support during runtime.
> 
> I used to have one recently that was specifically interested in
> terminating the associated thread. But that case was modified later on
> due to other reasons. In principle, the value of this cleanup function
> is in the printer thread control, even if that means cutting of wrapped
> I/O (you could still print via unwrapped services then).
> 

Ok. Was it part of a broader feature aimed at moving the per-process rt
support to a quiescent state?

-- 
Philippe.

Re: [Xenomai] rt_print_auto_init()

[Jan Kiszka]

On 2015-07-24 17:08, Philippe Gerum wrote:
> On 07/24/2015 04:56 PM, Jan Kiszka wrote:
>> On 2015-07-24 16:29, Philippe Gerum wrote:
>>> On 07/23/2015 03:27 PM, Jan Kiszka wrote:
>>>> On 2015-07-23 11:45, Philippe Gerum wrote:
>>>>> On 07/23/2015 11:37 AM, Jan Kiszka wrote:
>>>>>> On 2015-07-23 11:24, Philippe Gerum wrote:
>>>>>>>
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> Do you still have a use case for calling rt_print_auto_init(false) or
>>>>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>>>>>>
>>>>>>
>>>>>> Huh, that was a day-one feature, now 8 years old, barely remember the
>>>>>> details. I'm currently not aware of a concrete scenario. It definitely
>>>>>> makes sense to revisit this think.
>>>>>>
>>>>>> I guess one, if not the major problem back then was that the implicit
>>>>>> malloc of the initialization step was not consistently causing a
>>>>>> SIGDEBUG warning. That is now different.
>>>>>>
>>>>>
>>>>> Since the current thread won't be notified until XNWARN is armed in its
>>>>> TCB, any objection to move that call as a nop placeholder to the compat
>>>>> section in libtrank, leaving the implicit init to libcobalt as currently?
>>>>
>>>> Ack.
>>>>
>>>
>>> Ok, let's see how deep you can dive into your context stack these days:
>>> what about rt_print_cleanup() now? I see no in-tree callers, and I
>>> wonder whether there is any use case for an application to stop the
>>> stdio support during runtime.
>>
>> I used to have one recently that was specifically interested in
>> terminating the associated thread. But that case was modified later on
>> due to other reasons. In principle, the value of this cleanup function
>> is in the printer thread control, even if that means cutting of wrapped
>> I/O (you could still print via unwrapped services then).
>>
> 
> Ok. Was it part of a broader feature aimed at moving the per-process rt
> support to a quiescent state?

No, rather about ensuring that if you terminate only the main thread in
an application that believes this thread was the last one, the
application as a whole terminates.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] rt_print_auto_init()

[Philippe Gerum]

On 07/24/2015 05:23 PM, Jan Kiszka wrote:
> On 2015-07-24 17:08, Philippe Gerum wrote:
>> On 07/24/2015 04:56 PM, Jan Kiszka wrote:
>>> On 2015-07-24 16:29, Philippe Gerum wrote:
>>>> On 07/23/2015 03:27 PM, Jan Kiszka wrote:
>>>>> On 2015-07-23 11:45, Philippe Gerum wrote:
>>>>>> On 07/23/2015 11:37 AM, Jan Kiszka wrote:
>>>>>>> On 2015-07-23 11:24, Philippe Gerum wrote:
>>>>>>>>
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> Do you still have a use case for calling rt_print_auto_init(false) or
>>>>>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>>>>>>>
>>>>>>>
>>>>>>> Huh, that was a day-one feature, now 8 years old, barely remember the
>>>>>>> details. I'm currently not aware of a concrete scenario. It definitely
>>>>>>> makes sense to revisit this think.
>>>>>>>
>>>>>>> I guess one, if not the major problem back then was that the implicit
>>>>>>> malloc of the initialization step was not consistently causing a
>>>>>>> SIGDEBUG warning. That is now different.
>>>>>>>
>>>>>>
>>>>>> Since the current thread won't be notified until XNWARN is armed in its
>>>>>> TCB, any objection to move that call as a nop placeholder to the compat
>>>>>> section in libtrank, leaving the implicit init to libcobalt as currently?
>>>>>
>>>>> Ack.
>>>>>
>>>>
>>>> Ok, let's see how deep you can dive into your context stack these days:
>>>> what about rt_print_cleanup() now? I see no in-tree callers, and I
>>>> wonder whether there is any use case for an application to stop the
>>>> stdio support during runtime.
>>>
>>> I used to have one recently that was specifically interested in
>>> terminating the associated thread. But that case was modified later on
>>> due to other reasons. In principle, the value of this cleanup function
>>> is in the printer thread control, even if that means cutting of wrapped
>>> I/O (you could still print via unwrapped services then).
>>>
>>
>> Ok. Was it part of a broader feature aimed at moving the per-process rt
>> support to a quiescent state?
> 
> No, rather about ensuring that if you terminate only the main thread in
> an application that believes this thread was the last one, the
> application as a whole terminates.
> 

We could probably tell the existing atexit() handler to wipe the helper
thread too.

-- 
Philippe.

Re: [Xenomai] rt_print_auto_init()

[Philippe Gerum]

On 07/24/2015 05:29 PM, Philippe Gerum wrote:
> On 07/24/2015 05:23 PM, Jan Kiszka wrote:
>> On 2015-07-24 17:08, Philippe Gerum wrote:
>>> On 07/24/2015 04:56 PM, Jan Kiszka wrote:
>>>> On 2015-07-24 16:29, Philippe Gerum wrote:
>>>>> On 07/23/2015 03:27 PM, Jan Kiszka wrote:
>>>>>> On 2015-07-23 11:45, Philippe Gerum wrote:
>>>>>>> On 07/23/2015 11:37 AM, Jan Kiszka wrote:
>>>>>>>> On 2015-07-23 11:24, Philippe Gerum wrote:
>>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>>
>>>>>>>>> Do you still have a use case for calling rt_print_auto_init(false) or
>>>>>>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Huh, that was a day-one feature, now 8 years old, barely remember the
>>>>>>>> details. I'm currently not aware of a concrete scenario. It definitely
>>>>>>>> makes sense to revisit this think.
>>>>>>>>
>>>>>>>> I guess one, if not the major problem back then was that the implicit
>>>>>>>> malloc of the initialization step was not consistently causing a
>>>>>>>> SIGDEBUG warning. That is now different.
>>>>>>>>
>>>>>>>
>>>>>>> Since the current thread won't be notified until XNWARN is armed in its
>>>>>>> TCB, any objection to move that call as a nop placeholder to the compat
>>>>>>> section in libtrank, leaving the implicit init to libcobalt as currently?
>>>>>>
>>>>>> Ack.
>>>>>>
>>>>>
>>>>> Ok, let's see how deep you can dive into your context stack these days:
>>>>> what about rt_print_cleanup() now? I see no in-tree callers, and I
>>>>> wonder whether there is any use case for an application to stop the
>>>>> stdio support during runtime.
>>>>
>>>> I used to have one recently that was specifically interested in
>>>> terminating the associated thread. But that case was modified later on
>>>> due to other reasons. In principle, the value of this cleanup function
>>>> is in the printer thread control, even if that means cutting of wrapped
>>>> I/O (you could still print via unwrapped services then).
>>>>
>>>
>>> Ok. Was it part of a broader feature aimed at moving the per-process rt
>>> support to a quiescent state?
>>
>> No, rather about ensuring that if you terminate only the main thread in
>> an application that believes this thread was the last one, the
>> application as a whole terminates.
>>
> 
> We could probably tell the existing atexit() handler to wipe the helper
> thread too.
> 

mm, no. This would not exit, precisely.

-- 
Philippe.

Re: [Xenomai] rt_print_auto_init()

[Philippe Gerum]

On 07/24/2015 05:31 PM, Philippe Gerum wrote:
> On 07/24/2015 05:29 PM, Philippe Gerum wrote:
>> On 07/24/2015 05:23 PM, Jan Kiszka wrote:
>>> On 2015-07-24 17:08, Philippe Gerum wrote:
>>>> On 07/24/2015 04:56 PM, Jan Kiszka wrote:
>>>>> On 2015-07-24 16:29, Philippe Gerum wrote:
>>>>>> On 07/23/2015 03:27 PM, Jan Kiszka wrote:
>>>>>>> On 2015-07-23 11:45, Philippe Gerum wrote:
>>>>>>>> On 07/23/2015 11:37 AM, Jan Kiszka wrote:
>>>>>>>>> On 2015-07-23 11:24, Philippe Gerum wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> Do you still have a use case for calling rt_print_auto_init(false) or
>>>>>>>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Huh, that was a day-one feature, now 8 years old, barely remember the
>>>>>>>>> details. I'm currently not aware of a concrete scenario. It definitely
>>>>>>>>> makes sense to revisit this think.
>>>>>>>>>
>>>>>>>>> I guess one, if not the major problem back then was that the implicit
>>>>>>>>> malloc of the initialization step was not consistently causing a
>>>>>>>>> SIGDEBUG warning. That is now different.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Since the current thread won't be notified until XNWARN is armed in its
>>>>>>>> TCB, any objection to move that call as a nop placeholder to the compat
>>>>>>>> section in libtrank, leaving the implicit init to libcobalt as currently?
>>>>>>>
>>>>>>> Ack.
>>>>>>>
>>>>>>
>>>>>> Ok, let's see how deep you can dive into your context stack these days:
>>>>>> what about rt_print_cleanup() now? I see no in-tree callers, and I
>>>>>> wonder whether there is any use case for an application to stop the
>>>>>> stdio support during runtime.
>>>>>
>>>>> I used to have one recently that was specifically interested in
>>>>> terminating the associated thread. But that case was modified later on
>>>>> due to other reasons. In principle, the value of this cleanup function
>>>>> is in the printer thread control, even if that means cutting of wrapped
>>>>> I/O (you could still print via unwrapped services then).
>>>>>
>>>>
>>>> Ok. Was it part of a broader feature aimed at moving the per-process rt
>>>> support to a quiescent state?
>>>
>>> No, rather about ensuring that if you terminate only the main thread in
>>> an application that believes this thread was the last one, the
>>> application as a whole terminates.
>>>
>>
>> We could probably tell the existing atexit() handler to wipe the helper
>> thread too.
>>
> 
> mm, no. This would not exit, precisely.
> 

However, we do have a TSD on the main thread, so signaling the helper
from the TSD destructor would do.

-- 
Philippe.