The ABI status of filesystem formats [LWN.net]

The ABI status of filesystem formats

Posted Oct 11, 2020 19:55 UTC (Sun) by NYKevin (subscriber, #129325)
In reply to: The ABI status of filesystem formats by error27
Parent article: The ABI status of filesystem formats

> So probably that approach is a waste of time.

I find this remark deeply confusing, so much so that I think I must have misunderstood you.

I proposed creating a formal spec, and declaring that to be the defining line of "what the kernel is prepared to support." In response to this, you described what happens if you don't have a spec and/or don't care about said spec, and then ambiguously said "that approach is a waste of time."

It sounds as if you were trying to refute my suggestion, but your argument before this line appears to *agree* with me, because it describes problems that arise when you don't have a spec. So, if you could clarify your position, that would help me to understand your argument a lot better.

to post comments

The ABI status of filesystem formats

Posted Oct 12, 2020 13:46 UTC (Mon) by error27 (subscriber, #8346) [Link]

I didn't mean writing a spec is a waste of time. Specs are good because they encourage rigorous thinking. I meant it would be very difficult and a waste of time to try detect filesystems like Josh's in advance and prevent them from mounting.

But although specs have their uses, in the kernel, specs cannot work in the way you have said. The rule is never "You can't break the spec." The rule is "You can't break userspace."

Here is an example. Ten years ago glibc changed memcpy(). https://lwn.net/Articles/414467/ The spec said that the new implementation of memcpy() was valid but kernel developers find this attitude rage inducing. We would never do that in the kernel. You could theoretically still change memcpy(), but first you would have to fix all the applications that rely on the old behavior.

In the glibc example, it's not the flash developers who suffered, it's the regular Linux users. For the users, they had a program which worked and now it doesn't work. They don't care about specs. As kernel developers we care about users first and the spec second.