This was an undocumented extension introduced in 468485b8d2bbf in
- It caused more problems than value (see kern/94772). Its
use in kernel almost disappeared in 11ac7ec0769c. Fortunately,
no software uses it (exp-run 284529).
PR: 284529
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 62277 Build 59161: arc lint + arc unit
Event Timeline
Comment Actions
How do you know that no software uses the flag? Exp run only shows that the current ports do not.
What troubles does the flag cause? Referenced bug only talked about incorrect use of the flag to implement some other features. As far as that attempts were eliminated, what are the kernel problems?
Comment Actions
Should the kernel be a collection of unused ideas? If we never deleted APIs that weren't ever used we'd either bury ourselves under burden of maintaining all of them or we would just fake that we support them (as they aren't covered by tests).
Comment Actions
This is what called ABI stability, which is provided by any OS that tries to be useful. And this is the big reason why an idea needs very good reason before being put into the ABI visible space.
Comment Actions
I totally agree. But 25 years ago ideas were often added without a good judgement. If we didn't axed a good bunch of them later, I'd predict many of improvements that we did by today, won't happen. Basically because of unbearable complexity and fake fragility of the code. With "fake" I mean that at first glance it seems to be so many intertwined features, but in reality some features can be broken w/o anybody noticing that.
Comment Actions
What can be done with POLLINIGNEOF is to hide it from userspace. Brace the bit definition with #ifdef _KERNEL, so no new usage could appear.
Comment Actions
Then I completely don't understand your point. If we do as you suggest, then the added complexity in the kernel remains (which doesn't make me happy) and the userland visible API is going to be deprecated (which makes you unhappy, as I read from your first comment). How putting under the #ifdef _KERNEL would help me or how is it going to help you concern?
Comment Actions
This is the difference between API and ABI.
No OS ever guaranteed API stability, it can and must evolve. Source code needs to adapt to the changed interfaces provided by the systems.
ABI is about the ability to run existing binaries as is on the new system. All major or pretending to be production-quality OS ensure that upgrade does not leave you with a broken application.
Hiding the flag from the header changes API, which is fine. Removing the interpretation of the flag at runtime breaks ABI, which is not fine.