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

[Julien Grall <julien@xxxxxxx>]

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?
> 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.
Cheers,

--
Julien Grall