On 24/02/26 04:56PM, Jonathan Cameron wrote:
> On Mon, 26 Feb 2024 10:44:43 -0600
> John Groves <John@xxxxxxxxxx> wrote:
>
> > On 24/02/26 12:39PM, Jonathan Cameron wrote:
> > > On Fri, 23 Feb 2024 11:41:51 -0600
> > > John Groves <John@xxxxxxxxxx> wrote:
> > >
> > > > Add uapi include file for famfs. The famfs user space uses ioctl on
> > > > individual files to pass in mapping information and file size. This
> > > > would be hard to do via sysfs or other means, since it's
> > > > file-specific.
> > > >
> > > > Signed-off-by: John Groves <john@xxxxxxxxxx>
> > > > ---
> > > > include/uapi/linux/famfs_ioctl.h | 56 ++++++++++++++++++++++++++++++++
> > > > 1 file changed, 56 insertions(+)
> > > > create mode 100644 include/uapi/linux/famfs_ioctl.h
> > > >
> > > > diff --git a/include/uapi/linux/famfs_ioctl.h b/include/uapi/linux/famfs_ioctl.h
> > > > new file mode 100644
> > > > index 000000000000..6b3e6452d02f
> > > > --- /dev/null
> > > > +++ b/include/uapi/linux/famfs_ioctl.h
> > > > @@ -0,0 +1,56 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > > +/*
> > > > + * famfs - dax file system for shared fabric-attached memory
> > > > + *
> > > > + * Copyright 2023-2024 Micron Technology, Inc.
> > > > + *
> > > > + * This file system, originally based on ramfs the dax support from xfs,
> > > > + * is intended to allow multiple host systems to mount a common file system
> > > > + * view of dax files that map to shared memory.
> > > > + */
> > > > +#ifndef FAMFS_IOCTL_H
> > > > +#define FAMFS_IOCTL_H
> > > > +
> > > > +#include <linux/ioctl.h>
> > > > +#include <linux/uuid.h>
> > > > +
> > > > +#define FAMFS_MAX_EXTENTS 2
> > > Why 2?
> >
> > You catch everything!
> >
> > This limit is in place to avoid supporting somethign we're not testing. It
> > will probably be raised later.
> >
> > Currently user space doesn't support deleting files, which makes it easy
> > to ignore whether any clients have a stale view of metadata. If there is
> > no delete, there's actually no reason to have more than 1 extent.
> Then have 1. + a Comment on why it is 1.
Actually we test the 2 case. That seemed important to testing ioctl and
famfs_meta_to_dax_offset(). It just doesn't yet happen in the wild. Will
clarify with a comment.
> >
> > > > +
> > > > +enum extent_type {
> > > > + SIMPLE_DAX_EXTENT = 13,
> > >
> > > Comment on this would be good to have
> >
> > Done. Basically we anticipate there being other types of extents in the
> > future.
>
> I was more curious about the 13!
I think I was just being feisty that day. Will drop that...
>
> >
> > >
> > > > + INVALID_EXTENT_TYPE,
> > > > +};
> > > > +
> > > > +struct famfs_extent {
> > > > + __u64 offset;
> > > > + __u64 len;
> > > > +};
> > > > +
> > > > +enum famfs_file_type {
> > > > + FAMFS_REG,
> > > > + FAMFS_SUPERBLOCK,
> > > > + FAMFS_LOG,
> > > > +};
> > > > +
> > > > +/**
> > > > + * struct famfs_ioc_map
> > > > + *
> > > > + * This is the metadata that indicates where the memory is for a famfs file
> > > > + */
> > > > +struct famfs_ioc_map {
> > > > + enum extent_type extent_type;
> > > > + enum famfs_file_type file_type;
> > >
> > > These are going to be potentially varying in size depending on arch, compiler
> > > settings etc. Been a while, but I though best practice for uapi was always
> > > fixed size elements even though we lose the typing.
> >
> > I might not be following you fully here. User space is running the same
> > arch as kernel, so an enum can't be a different size, right? It could be
> > a different size on different arches, but this is just between user/kernel.
>
> I can't remember why, but this has bitten me in the past.
> Ah, should have known Daniel would have written something on it ;)
> https://www.kernel.org/doc/html/next/process/botching-up-ioctls.html
>
> It's the fun of need for compat ioctls with 32bit userspace on 64bit kernels.
>
> The alignment one is key as well. That bit me more than once due to
> 32bit x86 aligning 64 bit integers at 32 bits.
>
> We could just not support these cases but it's easy to get right so why
> bother with complexity of ruling them out.
Makes sense. Will do.
>
> >
> > I initially thought of XDR for on-media-format, which file systems need
> > to do with on-media structs (superblocks, logs, inodes, etc. etc.). But
> > this struct is not used in that way.
> >
> > In fact, famfs' on-media/in-memory metadata (superblock, log, log entries)
> > is only ever read read and written by user space - so it's the user space
> > code that needs XDR on-media-format handling.
> >
> > So to clarify - do you think those enums should be u32 or the like?
>
> Yes. As it's userspace, uint32_t maybe or __u32. I 'think'
> both are acceptable in uapi headers these days.
Roger that.
Thanks,
John
