How implementation details become ABI: a case study [LWN.net]

How implementation details become ABI: a case study

Posted Oct 2, 2014 15:47 UTC (Thu) by tomgj (guest, #50537)
Parent article: How implementation details become ABI: a case study

Another sad case of "hack something together, and whatever ends up being exposed gets called the 'interface'". This as opposed to the "actually write down what the interface is" school.

Tellingly, the article does not refer to any interface specifications for the interface elements that are relevant in this "user-visible behaviour". This is not a criticism of the article, but rather of the development process it describes: one where the philosophy of specified interfaces is not understood, and where no proper distinction is made between an actual interface, and a piece of implementation that happens to be visible.

The test should be whether the interface consumer was depending on incidental behaviour, rather than specified behaviour, of the interface. However, since there is not in Linux a culture of adequately specifying interfaces in the first place, we are not in a position where this test could be applied.

It is interesting how bad Linux is at this. The old, proprietary Unixes came with manuals properly describing the interface specifications of each system, even if they were not always compatible with one another. Windows does better than Linux on this front, as do the BSDs.

It's a good job the original API design approach of Linux was to implement a more or less coherent API that had already been specified (POSIX). It's unfortunate this hasn't carried through into a culture of properly writing down specifications for new interface elements as (or rather, before) they're introduced.

to post comments

How implementation details become ABI: a case study

Posted Oct 3, 2014 1:28 UTC (Fri) by giraffedata (guest, #1954) [Link]

How would it have made a difference if the interface were written down? Surely they would have written down that this unusual symbolic link value should give a name the file had when it had one, so this change would still be a bug and have to be fixed.

I guess I'm missing the article's thesis, that this is a case of "unintended behaviors can become part of the kernel's ABI over time." It looks to me like the designers deliberately put the former name of the file in the symbolic link value; they didn't mean to put arbitrary garbage in there, that just happened by accident of implementation to be the former name of the file.

How implementation details become ABI: a case study

Posted Oct 9, 2014 12:53 UTC (Thu) by kevinm (guest, #69913) [Link]

It wouldn't matter if the original interface had been specified ("The value returned by readlink(2) is for presentational purposes only and should not be parsed.") or not: people would still have ignored it and written scripts depending on the implementation details, and those scripts would still have to be supported.

The Linux culture is not to say "that userspace depended on something we didn't intend to be ABI, so it's OK to break it". ABI is de facto, not de jure.