All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: tools/libacpi printf output to logging instead of console/stdout ?
Date: Thu, 8 Mar 2018 19:32:30 +0000	[thread overview]
Message-ID: <62b348cb-1cab-342a-276c-104df7d6cd2a@citrix.com> (raw)
In-Reply-To: <5def13d3-591a-277d-bbe0-1ad26dfebbc7@eikelenboom.it>

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

      reply	other threads:[~2018-03-08 19:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 20:52 tools/libacpi printf output to logging instead of console/stdout ? Sander Eikelenboom
2018-03-08  9:09 ` Jan Beulich
2018-03-08 19:23   ` Sander Eikelenboom
2018-03-08 19:32     ` Andrew Cooper [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=62b348cb-1cab-342a-276c-104df7d6cd2a@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=linux@eikelenboom.it \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.