Re: [PATCH V5 09/19] famfs_fuse: magic.h: Add famfs magic numbers

[John Groves]

On 26/01/27 01:55PM, Joanne Koong wrote:
> On Fri, Jan 16, 2026 at 11:52 AM John Groves <john@xxxxxxxxxxxxxx> wrote:
> >
> > From: John Groves <john@xxxxxxxxxx>
> >
> > Famfs distinguishes between its on-media and in-memory superblocks. This
> > reserves the numbers, but they are only used by the user space
> > components of famfs.
> >
> > Signed-off-by: John Groves <john@xxxxxxxxxx>
> > ---
> >  include/uapi/linux/magic.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
> > index 638ca21b7a90..712b097bf2a5 100644
> > --- a/include/uapi/linux/magic.h
> > +++ b/include/uapi/linux/magic.h
> > @@ -38,6 +38,8 @@
> >  #define OVERLAYFS_SUPER_MAGIC  0x794c7630
> >  #define FUSE_SUPER_MAGIC       0x65735546
> >  #define BCACHEFS_SUPER_MAGIC   0xca451a4e
> > +#define FAMFS_SUPER_MAGIC      0x87b282ff
> > +#define FAMFS_STATFS_MAGIC      0x87b282fd
> 
> Could you explain why this needs to be added to uapi? If they are used
> only by userspace, does it make more sense for these constants to live
> in the userspace code instead?
> 
> Thanks,
> Joanne

Hi Joanne,

I think this is where it belongs; one function of uapi/linux/magic.h is as
a "registry" of magic numbers, which do need to be unique because they're
the first step of recognizing what is on a device.

This is a well-established ecosystem with block devices. Blkid / libblkid
scan block devices and keep a database of what devices exist and what
appears to be on them. When one adds a magic number that applies to block
devices, one sends a patch to util-linux (where blkid lives) to add ability
to recognize your media format (which IIRC includes the second recognition
step - if the magic # matches, verify the superblock checksum).

For character dax devices the ecosystem isn't really there yet, but the 
pattern is the same - and still makes sense.

Also, 2 years ago in the very first public famfs patch set (pre-fuse),
Christian Brauner told me they belong here [1].

But if the consensus happens to have moved since then, NP...

Regards,
John

[1] https://lore.kernel.org/linux-fsdevel/20240227-kiesgrube-couch-77ee2f6917c7@brauner/