4 ms·

How did Linus not go on a rampage after breaking userspace for an entire year? Is NILFS not part of the kernel mainline, I guess?

yjftsjthsd-h 4y ago
> Is NILFS not part of the kernel mainline, I guess? Good guess, but no: https://github.com/torvalds/linux/tree/master/fs/nilfs2 https://github.com/torvalds/linux/tree/master/fs/nilfs2 > How did Linus not go on a rampage after breaking userspace for an entire year? I would very much like to know that as well. Any chance it didn't get reported (at least, not as "this broke booting")?
- Volundr 4y ago
  I reported it along with a few other users in https://marc.info/?l=linux-nilfs&m=157540765215806&w=2 https://marc.info/?l=linux-nilfs&m=157540765215806&w=2. I think it just isn't widely enough used that Linus noticed we were broken. If I recall correctly it also wasn't directly fixed so much as incidentally. I just kept checking new kernel versions as they were released until one worked. There was never anything in the change-log (that I recall) about fixing the bug, just another change that happened to fix the issue. Edit: Looking through the archives, it looks like my memory was somewhat uncharitable. It was reported in November and directly patched in June (https://marc.info/?l=linux-nilfs&m=159154670627428&w=2 https://marc.info/?l=linux-nilfs&m=159154670627428&w=2) so about 7 months after reporting. Not sure what kernel release that would've landed in, so could've been closer to 8.
jraph 4y ago
If I understand correctly, I don't think this is a userspace-breaking bug, as in: a kernel API changed and made a userspace program not work anymore. It is a bug that prevents the kernel from booting. That's bad, but that's not the same thing. That's not a userspace compatibility issue such as the ones Linus chases. The user space isn't even involved if the kernel cannot boot. Or if it is actually a userspace program that causes a kernel crash, it is a crash, which is not really the same thing as an API change (one could argue, but that's a bit far-fetched, the intents are not the same, etc - I don't see Linus explode on somebody who introduced a crash the way he would explode on someone changing a userspace API).
bityard 4y ago
> How did Linus not go on a rampage after breaking userspace for an entire year? Linus' commandment about not breaking userspace is frequently misunderstood. He wants to ensure that user-space /programs/ do not break (even if they rely on buggy behavior that made it into a release), not that the /user/ will never see any breakage of the system whatsoever, which is of course an impossible goal. Device drivers and filesystems are firmly system-level stuff, bugs and backwards-incompatible changes in those areas are regrettable but happen all the same.

yjftsjthsd-h 4y ago

> Is NILFS not part of the kernel mainline, I guess? Good guess, but no: https://github.com/torvalds/linux/tree/master/fs/nilfs2 https://github.com/torvalds/linux/tree/master/fs/nilfs2 > How did Linus not go on a rampage after breaking userspace for an entire year? I would very much like to know that as well. Any chance it didn't get reported (at least, not as "this broke booting")?

Volundr 4y ago
I reported it along with a few other users in https://marc.info/?l=linux-nilfs&m=157540765215806&w=2 https://marc.info/?l=linux-nilfs&m=157540765215806&w=2. I think it just isn't widely enough used that Linus noticed we were broken. If I recall correctly it also wasn't directly fixed so much as incidentally. I just kept checking new kernel versions as they were released until one worked. There was never anything in the change-log (that I recall) about fixing the bug, just another change that happened to fix the issue. Edit: Looking through the archives, it looks like my memory was somewhat uncharitable. It was reported in November and directly patched in June (https://marc.info/?l=linux-nilfs&m=159154670627428&w=2 https://marc.info/?l=linux-nilfs&m=159154670627428&w=2) so about 7 months after reporting. Not sure what kernel release that would've landed in, so could've been closer to 8.

jraph 4y ago

If I understand correctly, I don't think this is a userspace-breaking bug, as in: a kernel API changed and made a userspace program not work anymore. It is a bug that prevents the kernel from booting. That's bad, but that's not the same thing. That's not a userspace compatibility issue such as the ones Linus chases. The user space isn't even involved if the kernel cannot boot. Or if it is actually a userspace program that causes a kernel crash, it is a crash, which is not really the same thing as an API change (one could argue, but that's a bit far-fetched, the intents are not the same, etc - I don't see Linus explode on somebody who introduced a crash the way he would explode on someone changing a userspace API).

bityard 4y ago

> How did Linus not go on a rampage after breaking userspace for an entire year? Linus' commandment about not breaking userspace is frequently misunderstood. He wants to ensure that user-space /programs/ do not break (even if they rely on buggy behavior that made it into a release), not that the /user/ will never see any breakage of the system whatsoever, which is of course an impossible goal. Device drivers and filesystems are firmly system-level stuff, bugs and backwards-incompatible changes in those areas are regrettable but happen all the same.