Re: [PATCH] bfs: remove the filesystem

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Sep 04, 2026 at 09:51:10AM +0100, Tigran Aivazian wrote:
> Hi Ethan,
>
> On Fri, 4 Sept 2026 at 09:30, Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
> >
> > BFS (not to be confused with BeFS, the BeOS filesystem) is the
> > filesystem UnixWare uses for its boot partition. It has extremely
> > limited functionality, only supporting contiguous files and no
> > subdirectories. Even though the bfs driver is very small and is
> > unlikely to cause future maintenance problems, given that the only type
> > of data stored on such a partition is likely to be kernels and
> > bootloader settings, there is very little reason anyone would want to
> > access it from Linux. Other old Unix filesystems (efs, freevxfs) have
> > been removed recently, and bfs is highly unlikely to have any users, so
> > remove it as well. Retain the UAPI header to be safe.
> >
>
> You are right that probably no one would want to use BFS for storing
> the actual data today.
> But some things have didactical value, rather than mere pragmatic
> usage. It is the didactic
> value of MINIX (and its limitations wrt making use of the wonderful
> capabilities of i386) that
> has originally triggered the creation of Linux. But back to BFS: it is
> actually used in Steve Pate's
> book "Linux Filesystems" (2024, unfinished yet), which is a sequel to
> his excellent classic
> "UNIX Filesystems" (2003), as an illustration of a particularly simple
> filesystem implementation.

Oh wow! :) Nice to hear a new linux book is coming, as a fellow author [fighting
my way through the editing stage atm :)] that's good to hear.

(I also learned, the hard way, why people don't tend to write kernel books these
days - the modern kernel is too damn big! :)

>
> I remember when Linus accepted my patch with BFS on 28 October 1999
> into 2.3.25 his comment
> was: "this appears to be a particularly simple one".

:)) nice!

We shouldn't be afraid to remove stuff that is less maintained or that
causes maintenance overhead or other headaches (e.g. blocking things from
being developed), as I have often pointed out re: older architectures,
nommu etc.

But I'm not sure if any of that applies here or not, so really one for
VFS maintainers I think.

>
> Kind regards,
> Tigran

--
Cheers, Lorenzo