tools/libacpi printf output to logging instead of console/stdout ?

tools/libacpi printf output to logging instead of console/stdout ?

[Sander Eikelenboom]

L.S.,

When starting a guest with the 'xl create' command (non-verbose) i get
this extra output on PVH guest types only:

S3 disabled
S4 disabled
CONV disabled


It seems libacpi/* only contains normal printf's, so for the other guest
types i probably just never triggered one of them.

Shouldn't these printf's go to logging instead of console/stdout ?

--
Sander

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: tools/libacpi printf output to logging instead of console/stdout ?

[Jan Beulich]

>>> On 07.03.18 at 21:52, <linux@eikelenboom.it> wrote:
> When starting a guest with the 'xl create' command (non-verbose) i get
> this extra output on PVH guest types only:
> 
> S3 disabled
> S4 disabled
> CONV disabled
> 
> 
> It seems libacpi/* only contains normal printf's, so for the other guest
> types i probably just never triggered one of them.
> 
> Shouldn't these printf's go to logging instead of console/stdout ?

I think it's the responsibility of the executable linking to that library
to suitably set up / redirect stdout. There not being anything like
"stdlog", I'm also not sure where you would think libacpi should
send them (if it was to control this itself) - surely not stderr.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: tools/libacpi printf output to logging instead of console/stdout ?

[Sander Eikelenboom]

On 08/03/18 10:09, Jan Beulich wrote:
>>>> On 07.03.18 at 21:52, <linux@eikelenboom.it> wrote:
>> When starting a guest with the 'xl create' command (non-verbose) i get
>> this extra output on PVH guest types only:
>>
>> S3 disabled
>> S4 disabled
>> CONV disabled
>>
>>
>> It seems libacpi/* only contains normal printf's, so for the other guest
>> types i probably just never triggered one of them.
>>
>> Shouldn't these printf's go to logging instead of console/stdout ?
> 
> I think it's the responsibility of the executable linking to that library
> to suitably set up / redirect stdout. There not being anything like
> "stdlog", I'm also not sure where you would think libacpi should
> send them (if it was to control this itself) - surely not stderr.

The extra output seems only informational, not even a warning, so stderr
seems wrong indeed.

With my novice C skills it seems that:
The difference between HVM and PVH is that 
in the HVM case the code of libacpi is linked to and gets run by
the hvmloader binary, which libxl captures all the output from
and only prints on verbose invocation of the xl tool and/or the xen log
(on debug builds).

In the PVH case the acpi tables are generated by libxl it
self (libxl_x86_acpi.c: libxl__dom_load_acpi()), which is linked to libacpi directly, 
hence the output can't be captured separately since it is not a separate binary.

Would probably be hard to align the logging with those 2 different way of using libacpi ?

--
Sander
 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: tools/libacpi printf output to logging instead of console/stdout ?

[Andrew Cooper]

On 08/03/18 19:23, Sander Eikelenboom wrote:
> On 08/03/18 10:09, Jan Beulich wrote:
>>>>> On 07.03.18 at 21:52, <linux@eikelenboom.it> wrote:
>>> When starting a guest with the 'xl create' command (non-verbose) i get
>>> this extra output on PVH guest types only:
>>>
>>> S3 disabled
>>> S4 disabled
>>> CONV disabled
>>>
>>>
>>> It seems libacpi/* only contains normal printf's, so for the other guest
>>> types i probably just never triggered one of them.
>>>
>>> Shouldn't these printf's go to logging instead of console/stdout ?
>> I think it's the responsibility of the executable linking to that library
>> to suitably set up / redirect stdout. There not being anything like
>> "stdlog", I'm also not sure where you would think libacpi should
>> send them (if it was to control this itself) - surely not stderr.
> The extra output seems only informational, not even a warning, so stderr
> seems wrong indeed.
>
> With my novice C skills it seems that:
> The difference between HVM and PVH is that 
> in the HVM case the code of libacpi is linked to and gets run by
> the hvmloader binary, which libxl captures all the output from
> and only prints on verbose invocation of the xl tool and/or the xen log
> (on debug builds).
>
> In the PVH case the acpi tables are generated by libxl it
> self (libxl_x86_acpi.c: libxl__dom_load_acpi()), which is linked to libacpi directly, 
> hence the output can't be captured separately since it is not a separate binary.
>
> Would probably be hard to align the logging with those 2 different way of using libacpi ?

libxl has no interaction with hvmloader's logging, as hvmloader runs in
guest context.

I see no purpose for those three printks.  I'd drop them completely,
rather than worrying about how to plumb together the logging for the
multiple scenarios.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel