Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for 
qemu-xen runnning in a Linux-based stubdomain."):
> From those two options I'd prefer multiple xenstore keys as much
> cleaner. We do have them as an array in libxl already.
> 
> So, let image/dmargs be actually a directory with entries like:
>  - image/dmargs/000 = -xen-domid
>  - image/dmargs/001 = 123
>  - image/dmargs/002 = -nodefaults
>
> I wonder if there needs to be arguments count, or iterating until ENOENT
> is enough?

xenstore-read doesn't seem to provide an easy way for a shell script
to tell ENOENT apart from "everything is doomed".  Here is its
(frankly, very poor) error handling:

            char *val = xs_read(xsh, xth, argv[optind], &len);
            if (val == NULL) {
                warnx("couldn't read path %s", argv[optind]);
                return 1;
            }

It doesn't even print the errno value, let alone change the exit
status or provide a way to tolerate ENOENT without bulrbing to stderr.

If I were you I'd send a shell string but it's entirely up to you.

> > Yes.  Or teaching qemu about libvchan.
> 
> That's also an option. I'll see how hard it would be to add this to
> qemu.

Good luck.

Ian.

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