[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.