All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Joao Martins <joao.m.martins@oracle.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] xen: drop writing error messages to xenstore
Date: Thu, 11 Oct 2018 07:05:53 +0200	[thread overview]
Message-ID: <ff88433c-e808-9491-c5a7-ebc5600c7920@suse.com> (raw)
In-Reply-To: <b1e130bc-983f-f8df-0f5f-66971cc60454@oracle.com>

On 10/10/2018 18:57, Boris Ostrovsky wrote:
> On 10/10/18 11:53 AM, Juergen Gross wrote:
>> On 10/10/2018 17:09, Joao Martins wrote:
>>> On 10/09/2018 05:09 PM, Juergen Gross wrote:
>>>> xenbus_va_dev_error() will try to write error messages to Xenstore
>>>> under the error/<dev-name>/error node (with <dev-name> something like
>>>> "device/vbd/51872"). This will fail normally and another message
>>>> about this failure is added to dmesg.
>>>>
>>>> I believe this is a remnant from very ancient times, as it was added
>>>> in the first pvops rush of commits in 2007.
>>>>
>>>> So remove the additional message when writing to Xenstore failed as
>>>> a minimum step.
>>>>
>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> ---
>>>> I am considering removing the Xenstore write altogether, but I'm
>>>> not sure it isn't needed e.g. by xend based installations. So please
>>>> speak up in case you know why this write is there.
>>> So this:
>>>
>>> "This will fail normally and another message about this failure is added to dmesg."
>>>
>>> Brings me to the question: What about {stub,driver}domains? Ideally you
>>> shouldn't be looking at domU's dmesg as a control domain no? I can't remember
>>> any other error node, but if something fails e.g. netfront fails to allocate an
>>> unbound event channel - how do you know the cause from the control domain
>>> perspective?
>>>
>>> Irrespective of xend or not: isn't this 'error' node the only one that
>>> propagates error causes per device from domU?
>> What does it help you in dom0 if you have an error message in Xenstore
>> if a frontend driver couldn't do its job? Is there anything you can do
>> as a Xen admin?
> 
> The admin may want to know, for example, that a hotplug in the guest failed.

Shouldn't he ask the guest for that? There are dozens of other possible
problems letting hotplug fail which won't write anything to Xenstore.

This might be interesting for development/test purposes, but I really
question it to stay in mature code.


Juergen

  reply	other threads:[~2018-10-11  5:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09 16:09 [PATCH] xen: drop writing error messages to xenstore Juergen Gross
2018-10-10 15:09 ` [Xen-devel] " Joao Martins
2018-10-10 15:53   ` Juergen Gross
2018-10-10 16:57     ` Boris Ostrovsky
2018-10-10 16:57     ` [Xen-devel] " Boris Ostrovsky
2018-10-11  5:05       ` Juergen Gross [this message]
2018-10-11 11:03         ` Joao Martins
2018-10-11 11:03         ` [Xen-devel] " Joao Martins
2018-10-25 12:36           ` Juergen Gross
2018-10-25 12:36           ` [Xen-devel] " Juergen Gross
2018-10-25 15:50             ` Boris Ostrovsky
2018-10-25 15:50             ` Boris Ostrovsky
2018-10-11  5:05       ` Juergen Gross
2018-10-10 15:53   ` Juergen Gross
2018-10-10 15:09 ` Joao Martins

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=ff88433c-e808-9491-c5a7-ebc5600c7920@suse.com \
    --to=jgross@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=joao.m.martins@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.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.