Thread (1 message) flat view 1 message, 1 author, 16h ago

Re: [PATCH] bfs: remove the filesystem

From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Date: 2026-09-04 09:15:49
Also in: linux-doc, linux-fsdevel, linux-kselftest, linux-mips

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 [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help