Re: [PATCH 09/29] tools/xenlogd: add 9pfs open request support

[Juergen Gross <jgross@xxxxxxxx>]

On 06.11.23 20:33, Jason Andryuk wrote:
> On Wed, Nov 1, 2023 at 6:13 AM Juergen Gross <jgross@xxxxxxxx> wrote:
> > Add the open request of the 9pfs protocol.
> >
> > Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> > ---
> >   tools/xenlogd/io.c      | 130 ++++++++++++++++++++++++++++++++++++++++
> >   tools/xenlogd/xenlogd.h |   4 ++
> >   2 files changed, 134 insertions(+)
> >
> > diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
> > index 778e1dc2c9..c2b259f42e 100644
> > --- a/tools/xenlogd/io.c
> > +++ b/tools/xenlogd/io.c
> > @@ -734,6 +745,121 @@ static void p9_walk(device *device, struct p9_header *hdr)
> >       free(names);
> >   }
> >
> > +static int open_flags_from_mode(uint8_t mode)
> > +{
> > +    int flags;
> > +
> > +    switch ( mode & P9_OMODEMASK )
> > +    {
> > +    case P9_OREAD:
> > +        flags = O_RDONLY;
> > +        break;
> > +
> > +    case P9_OWRITE:
> > +        flags = O_WRONLY;
> > +        break;
> > +
> > +    case P9_ORDWR:
> > +        flags = O_RDWR;
> > +        break;
> > +
> > +    default:
> > +        return -1;
> > +    }
> > +
> > +    if ( mode & P9_OTRUNC )
> > +        flags |= O_TRUNC;
> """
> In addition, if mode has the OTRUNC (0x10) bit set, the file is to be
> truncated, which requires write permission (if the file is
> append-only, and permission is granted, the open succeeds but the file
> will not be trun- cated);
> """
>
> This relies on libc O_TRUNC handling - I think that is probably better
> than something custom so you get the libc semantics.
That was my thinking, yes.

> > +
> > +    return flags;
> > +}
> > +
> > +static unsigned int get_iounit(device *device, struct stat *st)
> > +{
> > +    return (device->max_size - st->st_blksize) & ~(st->st_blksize - 1);
> > +}
> > +
> > +static void p9_open(device *device, struct p9_header *hdr)
> > +{
> > +    uint32_t fid;
> > +    uint8_t mode;
> > +    struct p9_fid *fidp;
> > +    struct stat st;
> > +    struct p9_qid qid;
> > +    uint32_t iounit;
> > +    int flags;
> > +    int ret;
> > +
> > +    ret = fill_data(device, "Ub", &fid, &mode);
> > +    if ( ret != 2 )
> > +    {
> > +        p9_error(device, hdr->tag, EINVAL);
> > +        return;
> > +    }
> > +    if ( mode & ~(P9_OMODEMASK | P9_OTRUNC | P9_OREMOVE) )
> > +    {
> > +        p9_error(device, hdr->tag, EINVAL);
> > +        return;
> > +    }
> > +
> > +    fidp = find_fid(device, fid);
> > +    if ( !fidp )
> > +    {
> > +        p9_error(device, hdr->tag, ENOENT);
> If the host_path points at a populated directory, there is nothing
> that populates the fids for pre-existing files and directories?  So
> those files cannot be opened?  I guess that's not needed for
> Xenstore-stubdom?
It is the guest which is associating a fid with a file. For opening an
existing file the guest should use the WALK command to walk the path from
a known fid (e.g. the root fid associated at ATTACH time) to the target
file.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature