SEGA Dreamcasts come with a "visual memory unit" (VMU) which contains a slab
of flash memory to save games playable on the VMU or data from Dreamcast games.

The VMU uses a file allocation based filesystem - which we label VMUFAT - to
organise the data. With a control block, a file allocation table and a directory.

All physical VMUs are of the same size (256 blocks of 512 octets) but the
filesystem itself is extendable to other sizes and need not be tied to the VMU.

These patches implement VMUFAT as a Linux filesystem independent of hardware.

It seems obvious almost all users will be those working with Linux on
Dreamcasts or Dreamcast emulators but there is no dependence on SH or on the
MTD layer.

VMUFAT has been tested on a 32 bit Dreamcast and on x86_64 systems.

Tools to format a filesystem are available here: 
https://github.com/mcmenaminadrian/mkfs.vmufat

Signed-off-by: Adrian McMenamin <adrianmcmenamin@gmail.com>

Adrian McMenamin (5):
  Add vmufat super.c
  Add vmufat inode.c
  Add vmufat header
  Add vmufat documentation
  miscellaneous vmufat changes and additions

 Documentation/filesystems/index.rst  |    1 +
 Documentation/filesystems/vmufat.rst |  127 ++++
 fs/Kconfig                           |    1 +
 fs/Makefile                          |    1 +
 fs/vmufat/Kconfig                    |   14 +
 fs/vmufat/Makefile                   |    7 +
 fs/vmufat/inode.c                    | 1017 ++++++++++++++++++++++++++
 fs/vmufat/super.c                    |  581 +++++++++++++++
 fs/vmufat/vmufat.h                   |  126 ++++
 include/uapi/linux/magic.h           |    1 +
 10 files changed, 1876 insertions(+)
 create mode 100644 Documentation/filesystems/vmufat.rst
 create mode 100644 fs/vmufat/Kconfig
 create mode 100644 fs/vmufat/Makefile
 create mode 100644 fs/vmufat/inode.c
 create mode 100644 fs/vmufat/super.c
 create mode 100644 fs/vmufat/vmufat.h

-- 
2.43.0

On Sat, Apr 11, 2026 at 04:11:34PM +0100, Adrian McMenamin wrote:
> SEGA Dreamcasts come with a "visual memory unit" (VMU) which contains a slab
> of flash memory to save games playable on the VMU or data from Dreamcast games.
> 
> The VMU uses a file allocation based filesystem - which we label VMUFAT - to
> organise the data. With a control block, a file allocation table and a directory.
> 
> All physical VMUs are of the same size (256 blocks of 512 octets) but the
> filesystem itself is extendable to other sizes and need not be tied to the VMU.
> 
> These patches implement VMUFAT as a Linux filesystem independent of hardware.

Isn't this filesystem a great target for FUSE? You definitely don't need
super high performance here.

Also, you're missing the fs maintainers. Adding them.

> 
> It seems obvious almost all users will be those working with Linux on
> Dreamcasts or Dreamcast emulators but there is no dependence on SH or on the
> MTD layer.
> 
> VMUFAT has been tested on a 32 bit Dreamcast and on x86_64 systems.
> 
> Tools to format a filesystem are available here: 
> https://github.com/mcmenaminadrian/mkfs.vmufat
> 
> Signed-off-by: Adrian McMenamin <adrianmcmenamin@gmail.com>
> 
> Adrian McMenamin (5):
>   Add vmufat super.c
>   Add vmufat inode.c
>   Add vmufat header
>   Add vmufat documentation
>   miscellaneous vmufat changes and additions
> 
>  Documentation/filesystems/index.rst  |    1 +
>  Documentation/filesystems/vmufat.rst |  127 ++++
>  fs/Kconfig                           |    1 +
>  fs/Makefile                          |    1 +
>  fs/vmufat/Kconfig                    |   14 +
>  fs/vmufat/Makefile                   |    7 +
>  fs/vmufat/inode.c                    | 1017 ++++++++++++++++++++++++++
>  fs/vmufat/super.c                    |  581 +++++++++++++++
>  fs/vmufat/vmufat.h                   |  126 ++++
>  include/uapi/linux/magic.h           |    1 +
>  10 files changed, 1876 insertions(+)
>  create mode 100644 Documentation/filesystems/vmufat.rst
>  create mode 100644 fs/vmufat/Kconfig
>  create mode 100644 fs/vmufat/Makefile
>  create mode 100644 fs/vmufat/inode.c
>  create mode 100644 fs/vmufat/super.c
>  create mode 100644 fs/vmufat/vmufat.h
> 
> -- 
> 2.43.0
> 

-- 
Pedro

On Mon, 13 Apr 2026 at 16:09, Pedro Falcato <pfalcato@suse.de> wrote:
>
> On Sat, Apr 11, 2026 at 04:11:34PM +0100, Adrian McMenamin wrote:
> > SEGA Dreamcasts come with a "visual memory unit" (VMU) which contains a slab
> > of flash memory to save games playable on the VMU or data from Dreamcast games.
> >
...
> >
> > These patches implement VMUFAT as a Linux filesystem independent of hardware.
>
> Isn't this filesystem a great target for FUSE? You definitely don't need
> super high performance here.
>
> Also, you're missing the fs maintainers. Adding them.
>

Apologies for the long delay in replying - I was hoping that maybe
someone else would have a view rather than my rather inevitable "can
this go in mainline, please?".

I'm not saying you've done this, but in some online fora, this patch
has been discussed solely as a Dreamcast add-on - when the key point
is it is hardware independent. Dreamcast users who really want to can
already get what's on their VMU via the VMU mtd layer code and then,
again if they really wanted to, manipulate that at the byte level.
Having a file system is about people on other platforms being able to
access and manipulate VMU contents (easily) too.

It's not a complex piece of code so the maintenance requirement is low
and if it were to break in future it wouldn't drag anything else down,
and nor is it an impediment to general kernel development (so the
other comparison I've seen, with the i486 code) also seems misplaced
to me.

My contribution to Linux is small - this is the first patch from me
for over a decade but I'd hope the pioneering spirit of "because its
there" still lives on.

> Pedro


Adrian

On Wed 15-04-26 21:08:21, Adrian McMenamin wrote:
> On Mon, 13 Apr 2026 at 16:09, Pedro Falcato <pfalcato@suse.de> wrote:
> >
> > On Sat, Apr 11, 2026 at 04:11:34PM +0100, Adrian McMenamin wrote:
> > > SEGA Dreamcasts come with a "visual memory unit" (VMU) which contains a slab
> > > of flash memory to save games playable on the VMU or data from Dreamcast games.
> > >
> ...
> > >
> > > These patches implement VMUFAT as a Linux filesystem independent of hardware.
> >
> > Isn't this filesystem a great target for FUSE? You definitely don't need
> > super high performance here.
> >
> > Also, you're missing the fs maintainers. Adding them.
> 
> Apologies for the long delay in replying - I was hoping that maybe
> someone else would have a view rather than my rather inevitable "can
> this go in mainline, please?".

Thanks for your work and the filesystem driver but I have to say I agree
with Pedro here. A FUSE driver is a much better way of providing access to
a filesystem like this. Each filesystem in the kernel adds certain
maintenance burden to treewide changes as it needs to be adapted as well
and over the years the niche filesystems that have accumulated in the
kernel make the treewide changes rather painful and we are rather slowly
removing such filesystems from the kernel than adding more.

With a FUSE driver you get very similar user experience as with in-kernel
driver - you can just mount the device and tinker with the content - while
keeping your code in a userspace library which removes the maintenance
burden for the kernel and frankly makes your life simpler as well. The
performance is somewhat lower due to additional communication and process
switching but for cases like your filesystem I don't expect it to matter.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

On Thu, 16 Apr 2026 at 11:36, Jan Kara <jack@suse.cz> wrote:
>
>
> With a FUSE driver you get very similar user experience as with in-kernel
> driver - you can just mount the device and tinker with the content - while
> keeping your code in a userspace library which removes the maintenance
> burden for the kernel and frankly makes your life simpler as well. The
> performance is somewhat lower due to additional communication and process
> switching but for cases like your filesystem I don't expect it to matter.



Well, I have to admit defeat.

I have discovered there is already a FUSE implementation -
https://github.com/RossMeikleham/FUSE-VMU (I've not tested it but have
no reason to think it doesn't work)

I will be keeping my code as an out of tree kernel option for now
though/therefore.

Adrian