@pid_eins seems nobody yet pointed it out or I missed it. But note the "we don't break userspace" rule doesn't mean it can't ever happen - that would mean no bugs can ever happen as well. What it means is that if it happens and is reported (the sooner the better), it has to be fixed (with some exceptions that I think wouldn't apply here).
@vbabka well, i a actually somewhat OK with braking APIs if need be. I am just a bit annoyed of carrying this claim "we don't break userspace" around all the time and not actually being really any good at it at all, and when it comes to actually breaking things, we are usually brushed off, called "whiney", and told that we "did it wrong" in the first place, and theat kernel's own docs where just "unfortunate", and it's not a bug, because the docs should not have been written like that anyway.
@vbabka I mean, systemd has APIs too, it's hard to keep them stable, we try, and every now and then we fuck up. But we never made it our frickin' mantra, and claimed we actually were really good at it. We do have invested a bit in trying to be OK at it though, i.e. have test suites, integration tests and shit, that validate the APIs automatically. It's not perfect, but it exists.
So, if the kernel would actually try to live up to its claim that they don't break userspace
@vbabka … then maybe have a testsuite for this, that actually checks this, and make maintainers care, to google for their interfaces before dropping them to see if they are used.
But as it appears right now, there's a massive difference between what the kernel community claims and what it actually does about it.
The "unbind" uevent thing was by far worse btw, showed total ignorance from kernel folks about any userspace API issues.
So this isn't really an isolated event, it's happens regularly
@pid_eins@vbabka There is in theory full coverage of at least the syscalls interface (I don’t think I trust it since it was churned out to spec but it’s there), I’m never sure why the people doing that stuff aren’t as excited by stuff like sysfs
Anyone knows where the kernel's github/gitlab project is? Would love to file an issue or placeholder revert PR, but somehow I cannot find it! Anyone?
(Yes, this is a joke, I am fully aware of the concept of mailing lists – as a historical concept from the 2005 era... Yes, I am too lazy to figuring out how to report this properly. Hence social media it is.)
@ljs Look at the docs link I provided. It documents literally that the documentation for the bits is to be found in include/linux/genhd.h.
Sorry, but the ship has sailed. Adding such a comment to the documentation and expecting this not to be public API doesn't work.
Also, iirc the way I understood Linus the "we don't break userspace" actually is supposed to mean "we don't break userspace". Here it ceratinly breaks things all over the place.
It's not great that that's referenced, and the doc page in general isn't wonderful (nor was the idea of 'just exposing' something without abstracting in uAPI).
But at the same time, surely relying on you hardcoding kernel-specific value might be a clue that it's not a great interface to use?
So on one hand I agree with you the doc is bad and shouldn't have implied you can do that, but on the other hand a user relying on this should have been more than a little wary.
@ljs Well, how are userspace folks supposed to navigate kernel apis then? I mean, a good chunk of kernel apis are not documented at all, another chunk is pretty badly documented, and the stuff that actually is somehwat documented is something one should not have trusted, as you say?
I mean, the stuff is not just documented, it's also part of sysfs, i.e. one of the primary concepts for exposing kernel APIs to userspace which even has a rough concept of introspection and evrything
@ljs this is not a frickin ioctl of some niche subsys. It's very very core stuff exposed via sysfs, and documented (yes, badly documented, but still documented), with no other known way to get this very basic info.
Add comment