On 06.11.23 20:33, Jason Andryuk wrote:
On Wed, Nov 1, 2023 at 6:13 AM Juergen Gross <jgr...@suse.com> wrote:Add the open request of the 9pfs protocol. Signed-off-by: Juergen Gross <jgr...@suse.com> --- 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
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
