Re: [PATCH v2 27/29] tools/xenstored: add helpers for filename handling

[Juergen Gross <jgross@xxxxxxxx>]

On 28.11.23 21:42, Jason Andryuk wrote:
> On Wed, Nov 15, 2023 at 1:14 AM Juergen Gross <jgross@xxxxxxxx> wrote:
> > On 14.11.23 21:53, Julien Grall wrote:
> > > Hi Juergen,
> > >
> > > On 14/11/2023 09:26, Juergen Gross wrote:
> > > > On 14.11.23 10:10, Julien Grall wrote:
> > > > > Hi Juergen,
> > > > >
> > > > > On 14/11/2023 06:45, Juergen Gross wrote:
> > > > > > On 13.11.23 23:25, Julien Grall wrote:
> > > > > > > Hi Juergen,
> > > > > > >
> > > > > > > On 10/11/2023 16:08, Juergen Gross wrote:
> > > > > > > > diff --git a/tools/xenstored/lu_daemon.c b/tools/xenstored/lu_daemon.c
> > > > > > > > index 71bcabadd3..6351111ab0 100644
> > > > > > > > --- a/tools/xenstored/lu_daemon.c
> > > > > > > > +++ b/tools/xenstored/lu_daemon.c
> > > > > > > > @@ -24,7 +24,7 @@ void lu_get_dump_state(struct lu_dump_state *state)
> > > > > > > >        state->size = 0;
> > > > > > > >        state->filename = talloc_asprintf(NULL, "%s/state_dump",
> > > > > > > > -                      xenstore_daemon_rundir());
> > > > > > > > +                      xenstore_rundir());
> > > > > > > ... call and ...
> > > > > > >
> > > > > > > >        if (!state->filename)
> > > > > > > >            barf("Allocation failure");
> > > > > > > > @@ -65,7 +65,7 @@ FILE *lu_dump_open(const void *ctx)
> > > > > > > >        int fd;
> > > > > > > >        filename = talloc_asprintf(ctx, "%s/state_dump",
> > > > > > > > -                   xenstore_daemon_rundir());
> > > > > > > > +                   xenstore_rundir());
> > > > > > > ... this one could be replaced with absolute_filename().
> > > > > > No, I don't think this is a good idea.
> > > > > >
> > > > > > I don't want the daemon to store trace files specified as relative files
> > > > > > to be stored in /var/run/xen, while I want all files of the stubdom to be
> > > > > > stored under /var/lib/xen.
> > > > > Why? This is a bit odd to have a different behavior between stubdom and
> > > > > daemon. It would be much easier for the user if they knew all the files would
> > > > > be at the same place regardless the version used.
> > > > The main difference is that stubdom has access to only _one_ directory in dom0.
> > > Would you be able to explain why we can only give access to a single directory?
> > > Is this because of the 9pfs protocol?
> > Yes. I can mount a specific dom0 directory in the guest.
> I'm fine with a single directory being used for stubdom.  Two
> directories could be exported, and mini-os would need to use the "tag"
> to differentiate the two.  That may not be worth the added code.  QEMU
> can provide multiple 9pfs exports and Linux can mount them by tag
> name.
The main thing is that the daemon is meant to solve exactly one problem:
having a way to enable infrastructure domains (Xenstore-stubdom, driver
domains, device-model stubdoms) to access some few files in dom0, e.g. for
logging or config purposes.

The daemon should be as simple as possible and, of course, have ways to
control resource usage (file system space) used by the domUs configured to
use it.

It should _not_ be a a replacement of the full-blown backend in e.g. qemu.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature