5 ms·

Removing a kernel driver does not break userspace. I mean, yes, your filesystem becomes inaccessible, but any programs that you could run if you could access t

Removing a kernel driver does not break userspace. I mean, yes, your filesystem becomes inaccessible, but any programs that you could run if you could access that filesystem by some other means would still function. None of them depend on ReiserFS specifically for their function. Userspace breakage is more about changing interfaces in such a way that applications using that interface change their behaviour somehow. This does not apply to removed drivers.

mrweasel 5y ago
You're technically correct, but it would be a "fun" surprise to update your operating system and then not be able to boot because your filesystem isn't supported anymore.
- samus 5y ago
  Such big changes rarely happen overnight. If someone really knows about and runs ReiserFS, they can be expected to read up on release notes for major upgrades of their distro. And it's far from an everyday event to even consider deprecating a filesystem. The fact that we are having this conversation rather proves that.
- chungy 5y ago
  If you're running a rolling release, you should already expect this kind of experience. If you run a stable distribution, you stay on the older kernel series until you upgrade the entire OS, by which time the release notes would say "Removed support for ReiserFS" And then there you can do the "tar -c -C /reiserfs . | tar -x -C /ext4" dance (or whatever other preferred copying mechanism), before the OS upgrade.
selfhoster11 5y ago
If your application interfaces with ReiserFS directly (fsck/servicing scripts), or you expect to see certain performance patterns (like high speed on lots of smaller files), then I would consider this userspace breakage.
- djur 5y ago
  In the same sense, Linux broke userspace for 386 users in 3.8 because the users expected Linux to run on their computer. An optional build-time feature being removed does not break userspace.
  - selfhoster11 5y ago
    Arguably yes, abandoning an architecture is breaking userspace. At least for those that are still using it.
    - djur 5y ago
      It isn't breaking userspace under the definition intended by "we do not break userspace". In that thread, Linus was referring to a kernel change that changed the error returned from an ioctl, which caused a program not just to fail (as it might if it tried to use a feature not compiled into the kernel) but to break (by entering an infinite loop).

mrweasel 5y ago

You're technically correct, but it would be a "fun" surprise to update your operating system and then not be able to boot because your filesystem isn't supported anymore.

samus 5y ago
Such big changes rarely happen overnight. If someone really knows about and runs ReiserFS, they can be expected to read up on release notes for major upgrades of their distro. And it's far from an everyday event to even consider deprecating a filesystem. The fact that we are having this conversation rather proves that.
chungy 5y ago
If you're running a rolling release, you should already expect this kind of experience. If you run a stable distribution, you stay on the older kernel series until you upgrade the entire OS, by which time the release notes would say "Removed support for ReiserFS" And then there you can do the "tar -c -C /reiserfs . | tar -x -C /ext4" dance (or whatever other preferred copying mechanism), before the OS upgrade.

selfhoster11 5y ago

If your application interfaces with ReiserFS directly (fsck/servicing scripts), or you expect to see certain performance patterns (like high speed on lots of smaller files), then I would consider this userspace breakage.

djur 5y ago
In the same sense, Linux broke userspace for 386 users in 3.8 because the users expected Linux to run on their computer. An optional build-time feature being removed does not break userspace.
- selfhoster11 5y ago
  Arguably yes, abandoning an architecture is breaking userspace. At least for those that are still using it.
  - djur 5y ago
    It isn't breaking userspace under the definition intended by "we do not break userspace". In that thread, Linus was referring to a kernel change that changed the error returned from an ioctl, which caused a program not just to fail (as it might if it tried to use a feature not compiled into the kernel) but to break (by entering an infinite loop).