xen: drop writing error messages to xenstore

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 <[email protected]>

---
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.

---
 drivers/xen/xenbus/xenbus_client.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

drivers/xen/xenbus/xenbus_client.c +0 -0

index a1c17000129b..e17ca8156171 100644
@@ -278,10 +278,8 @@ static void xenbus_va_dev_error(struct xenbus_device *dev, int err,
 	dev_err(&dev->dev, "%s\n", printf_buffer);
 

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 <[email protected]>

---
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.

---
 drivers/xen/xenbus/xenbus_client.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

drivers/xen/xenbus/xenbus_client.c +2 -4

index a1c17000129b..e17ca8156171 100644
@@ -278,10 +278,8 @@ static void xenbus_va_dev_error(struct xenbus_device *dev, int err,
 	dev_err(&dev->dev, "%s\n", printf_buffer);
 
 	path_buffer = kasprintf(GFP_KERNEL, "error/%s", dev->nodename);
-	if (!path_buffer ||
-	    xenbus_write(XBT_NIL, path_buffer, "error", printf_buffer))
-		dev_err(&dev->dev, "failed to write error node for %s (%s)\n",
-			dev->nodename, printf_buffer);
+	if (path_buffer)
+		xenbus_write(XBT_NIL, path_buffer, "error", printf_buffer);
 
 	kfree(printf_buffer);
 	kfree(path_buffer);

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 27 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 2 lines

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?

I believe you'll have to look into the guest anyway, so there is no need to have a message in the guest and one in Xenstore. The messages are text only and can be evaluated only if you know guest internals.

blkfront for example prints an errno value into the message. I guess a windows guest wouldn't do that, or it could use other values for the same problem.

Juergen

Quoted 27 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 2 lines

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?

I believe you'll have to look into the guest anyway, so there is no need to have a message in the guest and one in Xenstore. The messages are text only and can be evaluated only if you know guest internals.

blkfront for example prints an errno value into the message. I guess a windows guest wouldn't do that, or it could use other values for the same problem.

Juergen

Quoted 28 lines · Juergen Gross

Quoted 27 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 5 lines

Quoted 2 lines

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.

Quoted 28 lines · Juergen Gross

Quoted 27 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 5 lines

Quoted 2 lines

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.

Quoted 31 lines · Boris Ostrovsky

Quoted 30 lines · Juergen Gross

Quoted 29 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 5 lines

Quoted 3 lines

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.

Quoted 31 lines · Boris Ostrovsky

Quoted 30 lines · Juergen Gross

Quoted 29 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 5 lines

Quoted 3 lines

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.

Quoted 32 lines · Juergen Gross

Quoted 31 lines · Boris Ostrovsky

Quoted 30 lines · Juergen Gross

Quoted 29 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 9 lines

Quoted 5 lines

Quoted 3 lines

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.

But I think nothing stops people from using their own hotplug script that could use this error node (or even something else).

Quoted 3 lines

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

You're right in all of it: it doesn't convey the error in a agnostic manner, ATM doesn't report all errors involved in the device setup, and when a xenbus_dev_fatal happens you might end up looking at the guest anyways. But there might be users right now of this node e.g. cases where you have a bunch of known/trusted Linux guests working as backends (which also use this error node, it's not just frontends *I think*) which you would be able to recognize the error messages to inform the admin e.g. maybe QubesOS? It is merely an informative error message node, but it seems better than just a simple XenbusClosed state, with many reasons that it could lead to. Anyhow, just my 2c.

Quoted 32 lines · Juergen Gross

Quoted 31 lines · Boris Ostrovsky

Quoted 30 lines · Juergen Gross

Quoted 29 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 9 lines

Quoted 5 lines

Quoted 3 lines

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.

But I think nothing stops people from using their own hotplug script that could use this error node (or even something else).

Quoted 3 lines

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

You're right in all of it: it doesn't convey the error in a agnostic manner, ATM doesn't report all errors involved in the device setup, and when a xenbus_dev_fatal happens you might end up looking at the guest anyways. But there might be users right now of this node e.g. cases where you have a bunch of known/trusted Linux guests working as backends (which also use this error node, it's not just frontends *I think*) which you would be able to recognize the error messages to inform the admin e.g. maybe QubesOS? It is merely an informative error message node, but it seems better than just a simple XenbusClosed state, with many reasons that it could lead to. Anyhow, just my 2c.

Quoted 46 lines · Joao Martins

Quoted 30 lines · Juergen Gross

Quoted 29 lines · Boris Ostrovsky

Quoted 28 lines · Juergen Gross

Quoted 27 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

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.

But I think nothing stops people from using their own hotplug script that could use this error node (or even something else).

Quoted 3 lines

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

Quoted 9 lines

You're right in all of it: it doesn't convey the error in a agnostic manner, ATM doesn't report all errors involved in the device setup, and when a xenbus_dev_fatal happens you might end up looking at the guest anyways. But there might be users right now of this node e.g. cases where you have a bunch of known/trusted Linux guests working as backends (which also use this error node, it's not just frontends *I think*) which you would be able to recognize the error messages to inform the admin e.g. maybe QubesOS? It is merely an informative error message node, but it seems better than just a simple XenbusClosed state, with many reasons that it could lead to. Anyhow, just my 2c.

If there are any users this will be in rather old Xen versions only, as writing the Xenstore node is _failing_ with newer Xen versions (that was the original reason for writing that patch).

So back to my patch: any reason not to take it? After all it will only remove the not very helpful kernel message that writing the Xenstore node failed.

Quoted 46 lines · Joao Martins

Quoted 30 lines · Juergen Gross

Quoted 29 lines · Boris Ostrovsky

Quoted 28 lines · Juergen Gross

Quoted 27 lines · Joao Martins

Quoted 8 lines · Juergen Gross

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.

Quoted 8 lines

So remove the additional message when writing to Xenstore failed as a minimum step.

Signed-off-by Juergen Gross <[email protected]>

---
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?

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

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.

But I think nothing stops people from using their own hotplug script that could use this error node (or even something else).

Quoted 3 lines

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

Quoted 9 lines

You're right in all of it: it doesn't convey the error in a agnostic manner, ATM doesn't report all errors involved in the device setup, and when a xenbus_dev_fatal happens you might end up looking at the guest anyways. But there might be users right now of this node e.g. cases where you have a bunch of known/trusted Linux guests working as backends (which also use this error node, it's not just frontends *I think*) which you would be able to recognize the error messages to inform the admin e.g. maybe QubesOS? It is merely an informative error message node, but it seems better than just a simple XenbusClosed state, with many reasons that it could lead to. Anyhow, just my 2c.

If there are any users this will be in rather old Xen versions only, as writing the Xenstore node is _failing_ with newer Xen versions (that was the original reason for writing that patch).

So back to my patch: any reason not to take it? After all it will only remove the not very helpful kernel message that writing the Xenstore node failed.