Hacker News Reader

Comment by cesarb | Hacker News Reader

The lesson is "be strict in what you accept, since the beginning".

For instance, a lesson learned by the Linux kernel developers: when adding a new system call to an operating system, if you have a flags parameter (and you should, which is another lesson they learned), if any unknown flag is set, fail with -EINVAL (or equivalent). Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features.

But it has to be since the beginning; once the protocol is "in the field", you can't increase the strictness without pain.

View on HN

Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features.

I don't understand why that's true. Just add the new flag and use it for your new feature. Aren't buggy programs who were already sending the flag responsible for their own bugs?

Yes and no. If you push an update and sysadmins all over the world dutifully upgrade and immediately notice programs breaking, their first thought is not going to be "oh, those programs must have had latent bugs." No, they're going to blame you. Besides, having stuff work correctly is always more fun than assigning blame, and validating flags is an easy way to avoid these scenarios.

Hm, fair enough. To be clear, I wasn't arguing against validating flags. I was commenting about "This kernel function only gets 32 possible bitflags, but since they never validated their flags, they can no longer add any additional flags, ever, because it might break other programs which may or may not even exist."

That sort of mentality seems like it would push designers in the direction of poor design decisions. If a bitflag is the best design for a new feature, but they're prevented from using it out of a sense of "Let's not ever break anything ever," then the result may be a bad design that people are stuck with for the next 50+ years, which seems objectively worse.

But my reaction is based on theory and not backed by experience, so it's probably unfounded.

Aren't buggy programs who were already sending the flag responsible for their own bugs?

When the kernel breaks userspace, it's a kernel bug. It's a philosophy for system robustness that the kernel has and other operating systems tend to adopt as well. As you get higher up the stack into 3rd party libraries and other programming tools the maintainers often take a more cavalier approach to maintaining compatibility.

I would tend to agree with you, but from what I recall Linus' policy is user-space breaking changes are kernel bugs.

No: https://lkml.org/lkml/2012/12/23/75

Reply on news.ycombinator.com