[rocqua]

I think, technically, file systems are not part of user-space. All of the code for file-systems lives in the Kernel.

In some technical sense, the filesystem is just an implementation detail of the kernel for things like 'read', 'write', and 'mmap'. Since this is an implementation detail, it can be considered 'not part of the public API of the kernel'.

Put differently, the promise not to break userspace is aimed at developers and not at actual users. The case of changing defaults is then a problem of developers because their programs are all of a sudden behaving differently.

[TheDong]

I disagree that filesystem support is not part of userspace.

In userspace, I run "mount -t reiserfs ....", and it mounts a filesystem. If the kernel deletes the reiserfs code, the userspace mount command / kernel 'mount' syscall will fail.

That seems like a very clear userspace thing that breaks.

Is there a reason that the mount syscall no longer accepting a previously valid argument isn't a userspace breaking change?

[djur]

`mount -t reiserfs` will also fail if ReiserFS isn't built for the running kernel. mount(2) fails with ENODEV and prints an accurate message: "unknown filesystem type 'reiserfs'". This isn't breaking userspace. The syscall and program do the correct thing based on the capabilities of the current kernel.

In any case, the ship has long since sailed on removing filesystems from the kernel. The original extfs is no longer available, nor is xiafs, nor are some virtual filesystems like devfs, etc. "A command that used to do something no longer does because the feature is no longer in the kernel" is commonplace in Linux history and is not considered "breaking userspace".