Re: [Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Feb 08, 2018 at 01:51:28PM +0000, Joao Martins wrote:
> > We can probably specify a xenstore node in the spec to
> > return some error code and let libxl read it. With that model old tools
> > work the same (extra node ignored) but new tools can utilise the new
> > node. IIRC there could already be some node that can be utilised --
> > xenbus_dev_fatal writes message to xenstore, I think.
> > 
> 
> I almost forgot about xenbus_dev_fatal(). It writes to an "error" entry in the
> backend|frontend path with the errno plus error message. But it also changes 
> the
> device xenbus state to XenbusClosed. Taking into consideration your earlier
> comment you probably meant xenbus_dev_error() instead? netback does allow
> Initialising state to be directly into Closing, but others might not be the 
> same.
> 

Yep, xenbus_dev_error is probably better.

> > What do you think?
> 
> I like the idea of having a similar "error" entry in the config|require
> directory following the same pattern as mentioned in the last paragraph.
> 
> Something like:
> 
> <backend|frontend path>/config/error = "<errno> <message>"
> 
> I would imagine this could be wrapper in a xenbus_config_fatal().
> 
> I had suggested a slightly more complicated version of it in a old reply to 
> Paul
> (at top of this message) with:
> 
> <backend|frontend path>/require/<id>-<feature-name> = "<feature-value>"
> <backend|frontend path>/require/<id>-status = "<error code>"
> 
> But taking morphing it with your comment could also be something like:
> 
> <backend|frontend path>/config/<feature-name> = "<feature-value>"
> <backend|frontend path>/config/<feature-name>/error = "<errno> <message>"
> 
> But either this option or the config/error global one depend on whether people
> here prefer to deliver all configuration errors at once, or one global
> "config/error" which would give the first entry with an error. The latter 
> though
> could lead to the sysadmin having to recreate the domain multiple times to
> see/handle all the errors.
> 

I'm not too opinionated on this really. I just want things to be
properly documented, cover known use cases well and allow for future
extensions.

Wei.

>       Joao
> 
> P.S. s/require/config

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