[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] tools/libacpi printf output to logging instead of console/stdout ?



On 08/03/18 10:09, Jan Beulich wrote:
>>>> On 07.03.18 at 21:52, <linux@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.