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

[Juergen Gross <jgross@xxxxxxxx>]

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:
> > > > > > Add some helpers for handling filenames which might need different
> > > > > > implementations between stubdom and daemon environments:
> > > > > >
> > > > > > - expansion of relative filenames (those are not really defined today,
> > > > > >    just expand them to be relative to /var/lib/xen/xenstore)
> > > > > > - expansion of xenstore_daemon_rundir() (used e.g. for saving the state
> > > > > >    file in case of live update - needs to be unchanged in the daemon
> > > > > >    case, but should result in /var/lib/xen/xenstore for stubdom)
> > > > > >
> > > > > > Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> > > > > > Reviewed-by: Jason Andryuk <jandryuk@xxxxxxxxx>
> > > > > > ---
> > > > > >   tools/xenstored/core.c      | 9 ++++++++-
> > > > > >   tools/xenstored/core.h      | 3 +++
> > > > > >   tools/xenstored/lu_daemon.c | 4 ++--
> > > > > >   tools/xenstored/minios.c    | 5 +++++
> > > > > >   tools/xenstored/posix.c     | 5 +++++
> > > > > >   5 files changed, 23 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c
> > > > > > index 4a9d874f17..77befd24c9 100644
> > > > > > --- a/tools/xenstored/core.c
> > > > > > +++ b/tools/xenstored/core.c
> > > > > > @@ -158,6 +158,13 @@ void trace_destroy(const void *data, const char *type)
> > > > > >           trace("obj: DESTROY %s %p\n", type, data);
> > > > > >   }
> > > > > > +char *absolute_filename(const void *ctx, const char *filename)
> > > > > Can the return be const?
> > > > I'll have a look.
> > > >
> > > > > > +{
> > > > > > +    if (filename[0] != '/')
> > > > > > +        return talloc_asprintf(ctx, XENSTORE_LIB_DIR "/%s", filename);
> > > > > Looking at the rest of patch, you will be using xenstore_rundir(). I wonder 
> > > > > whether it would not be better to switch to xenstore_rundir() so...
> > > > > > +    return talloc_strdup(ctx, filename);
> > > > > > +}
> > > > > > +
> > > > > >   /**
> > > > > >    * Signal handler for SIGHUP, which requests that the trace log is reopened
> > > > > >    * (in the main loop).  A single byte is written to reopen_log_pipe, to 
> > > > > > awaken
> > > > > > @@ -2983,7 +2990,7 @@ int main(int argc, char *argv[])
> > > > > >       signal(SIGHUP, trigger_reopen_log);
> > > > > >       if (tracefile)
> > > > > > -        tracefile = talloc_strdup(NULL, tracefile);
> > > > > > +        tracefile = absolute_filename(NULL, tracefile);
> > > > > >   #ifndef NO_LIVE_UPDATE
> > > > > >       /* Read state in case of live update. */
> > > > > > diff --git a/tools/xenstored/core.h b/tools/xenstored/core.h
> > > > > > index a0d3592961..51e1dddb22 100644
> > > > > > --- a/tools/xenstored/core.h
> > > > > > +++ b/tools/xenstored/core.h
> > > > > > @@ -393,6 +393,9 @@ void early_init(void);
> > > > > >   void mount_9pfs(void);
> > > > > >   #endif
> > > > > > +const char *xenstore_rundir(void);
> > > > > > +char *absolute_filename(const void *ctx, const char *filename);
> > > > > > +
> > > > > >   /* Write out the pidfile */
> > > > > >   void write_pidfile(const char *pidfile);
> > > > > > 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 /could/ give it access to "/", but do we really want that?
> I don't think we want to give access to "/".
>
> > We can't get rid of the /var/run/xen access in xenstored, as it is used for
> > live update, so the old and the new xenstored need to agree on the location of
> > the state file.
> Well, Xenstored Live-Update is technically a tech preview feature. So we *could* 
> break it and allow the state file to be specified on the command line.
> Anyway, I am ok if you want them to have the live-update state in a separate 
> however...
>
> > And we can't drop the possibility of specifying absolute paths
> > for e.g. trace files, as those might be in use by users already.
> >
> > > Also, regarding the background of my question. You are introducing a function 
> > > call absolute_filename(). From the name, there is nothing indicating that 
> > > this should only be used for trace files. If this is only indented for 
> > > tracefile, then I think this should be renamed to something like 
> > > absolute_tracefile(...).
> > After the last patch of this series "xenstore-control memreport <file>" will use
> > it, too.
> ... this doesn't change my point here. The function name doesn't *tell* me why 
> it can't be used for live-update files.
> If this can't be clarified in the name, then it should be clarified in a 
> comment. Maybe one top of the Live-Update code.
I think a comment before the absolute_filename() function would be the best
fit.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature