LWN: Comments on "EPOLL_CTL_DISABLE, epoll, and API design"

Re API (and ABI) design and maintenance

k3ninho — 2012-11-19T06:44:15+00:00

This article itself supplies an example where an older interface design has caused internal plumbing designs to be less than the best. This will happen again, and will cause a kind-of scarring to the structure of the Linux Kernel. Wouldn't you like to be able to offer end-users of the Kernel a clean set of interfaces, easy to comprehend and unhindered by history's quirks?

K3n.

Re API (and ABI) design and maintenance

nix — 2012-11-15T17:15:31+00:00

That's pointless. With memory sizes continuing to shoot up as they are, the memory overhead of maintaining old interfaces is minimal: and as long as the interfaces have no significant maintenance overhead, why not maintain them? I mean, Linux still supports uselib(), which is IIRC useless unless you're still using a.out shared libraries and libc4!

Re API (and ABI) design and maintenance

k3ninho — 2012-11-13T12:39:02+00:00

> We did have to manage it, and we had to do a fair bit of work behind the scenes to make it invisible to the users, but we succeeded at evolution.

I suspect that Linus' view on never, ever, binning old binary interfaces will mean that there will be (un)dead interfaces supported forever. My thoughts on a management plan look like:
(*) build a test suite round existing, in-use interfaces to maintain their intended functionality
(*) build a versioning API where a version-aware program can call in to use versioned interfaces
(*) attach version info to the existing APIs and handle a 'this interface is not implemented in your version of Linux' error
(*) develop a plumbing metalanguage to support disabled/legacy interface functionality via newer intefaces
(*) have all the interfaces configurable in the makefile, defaulting to enabled
(*) stop talking and show you some code

K3n.

EPOLL_CTL_DISABLE, epoll, and API design

Karellen — 2012-11-01T13:19:02+00:00

I thought we already had one, and his name was Linus

EPOLL_CTL_DISABLE, epoll, and API design

kevinm — 2012-11-01T00:45:04+00:00

By now, the time seems ripe for there to be a kernel-user-space API maintainer—someone whose job it is to actively review and ack every kernel-user-space API change, and to ensure that test cases and sufficient documentation are supplied with the implementation of those changes.

Hark, is that the sound of volunteering? ;)

EPOLL_CTL_DISABLE, epoll, and API design

dirtyepic — 2012-10-27T02:54:46+00:00

Yep, and that's handy. But I'd like a better way to follow comments than bookmarking individual articles and scanning through the whole list periodically.

Re API (and ABI) design and maintenance

davecb — 2012-10-26T18:31:02+00:00

Creating new versions is one *step* in a disciplined (anal) process of evolution. It's been done continuously since the days of the mainframe, but people don't realize it's happening.

I spent three years at the (late, lamented) Sun Microsystems doing ABI stability, and ended up sensitized enough that I notice it when it happens.

An easy example was a company's linker, which needed a different data structure for a method call that it had. We added a new "record type" in tghe linker, and converted the compilers to produce only it. We supported the old format for a year, then made its use produce a warning, and a year after that, made it require a link-line option.

We got two complaints, total, about the option. Out of all our customers, only two were so very very far behind that they ran one of the old compilers. A year or two later a hardware change made those compilers produce impossibly lousy code, and the two outliers upgraded to the new compilers. Then we retired the old interface.

If we had moved any faster, we would have annoyed at least two customers. If we had moved any slower in switching the compilers over, we would have made the OS developers unhappy. The time between the first switch and the final stages of the retirement made the maintainers unhappy, but there weren't many bugs in that interface nor were there many user of it, so the time cost of maintaining it was low.

We did have to manage it, and we had to do a fair bit of work behind the scenes to make it invisible to the users, but we succeeded at evolution.

Just as with humans, if you don't evolve, you might just die out. Homo habilis, anyone?

--dave

EPOLL_CTL_DISABLE, epoll, and API design

Jandar — 2012-10-26T17:03:45+00:00

For me there is no visual difference between old and new comments. In "LWN account customization" there is a setting "Old (seen) comment background color" but this doesn't work, neither in konqueror nor in iceweasel.

Greasemonkeys fancyLWNComments is the first working method to tell read and unread apart.

EPOLL_CTL_DISABLE, epoll, and API design

dlang — 2012-10-26T06:00:03+00:00

if you are reading while logged in, you should see that when you revisit an article, new posts show up with an orange border while old posts show up with a grey border.

EPOLL_CTL_DISABLE, epoll, and API design

dirtyepic — 2012-10-26T05:01:01+00:00

What would be really useful is a way to mark an article as watched and have any new comments on it sent by email. Seeing all unread comments is just too much noise for me.

EPOLL_CTL_DISABLE, epoll, and API design

Jandar — 2012-10-26T01:22:22+00:00

I was logged in while reading this weekly edition. Next week I make a few tests and see if a bug is reproducible.

I use konqueror not firefox but greasemonkey with fancyLWNComments seems to be a reason to switch for reading LWN. Thanks for pointing me to it.

EPOLL_CTL_DISABLE, epoll, and API design

dlang — 2012-10-26T00:46:31+00:00

If you were logged in when you saw those other comments, and still see them on the /unread page, there is a bug that you should send to lwn@lwn.net

However, I suspect that if you go to the unread page again, you will not see all those comment any more and you will find it much more useful.

you should also look at the greasemonkey script for lwn, I think it does more of what you are looking for.

EPOLL_CTL_DISABLE, epoll, and API design

Jandar — 2012-10-26T00:21:20+00:00

Nearly all content of https://lwn.net/Comments/unread I have already seen.

I read LWN in the "One big page" mode and go to the comments (in a new tab) with the "Comments (xxx posted)" button. After I have read the comments for one article I close the tab. Is there something I can do to make Comments/unread more useful?

What I would really like would be some means to hop from one unread comment to the next within the complete comment-section to see the surrounding context. It could be a link at each unread comment pointing to an anchor at the next. E.g. http://lwn.net/Articles/520198/#Comments-UnRead42.

EPOLL_CTL_DISABLE, epoll, and API design

dlang — 2012-10-25T22:03:00+00:00

take a look at https://lwn.net/Comments/unread

it shows you comments for all stories that you haven't read since the last time you viewed that page (and that you haven't read by going to the specific article page)

EPOLL_CTL_DISABLE, epoll, and API design

Jandar — 2012-10-25T21:57:41+00:00

I had missed this comment in the original article, reading LWN too early has it's disadvantages. There should be a way to step later through unread comments.

The solution using the cookie is simple and elegant. I don't understand the comments about not using the cookie because someone would like to use it otherwise. This line of reason means nobody should use the cookie.

EPOLL_CTL_DISABLE, epoll, and API design

dgm — 2012-10-25T09:45:25+00:00

A good start would be to find out how is that some do a better job that others, and how we can get that to happen more often.

EPOLL_CTL_DISABLE, epoll, and API design

dgm — 2012-10-25T09:42:16+00:00

> However, I agree that in general maintaining multiple API versions, where the old one is not a simple subset of the new one, is not likely to go well.

For that reason we should be putting much more effort into API design. In fact, tacking into account that API _will_ outlive its implementation (maybe several of them), most of the effort should be towards getting the API right.

EPOLL_CTL_DISABLE, epoll, and API design

ncm — 2012-10-25T09:05:53+00:00

I'm coming around to wahern's position noted in comments on the previous article: it's an architectural design error for threads to share a resource but not keep track of which are using it. If you design that way, no amount of EPOLL_CTL_DISABLE can make your design good. No end of similar problems will be waiting to surface.

I'm also much more impressed with kjp's solution than is our esteemed author. It attacks the problem at the root, even enabling rescue of such poorly architected designs (anyway until the next flaw uncloaks). Using the field suggested doesn't "burn" it: other uses can piggyback on the same hash node. By such reasoning any use at all would burn it, so no use can be deserving enough, and it never gets used for anything.

Unless I am misunderstanding the argument...

EPOLL_CTL_DISABLE, epoll, and API design

kjp — 2012-10-25T00:02:14+00:00

See my comment about 'weak reference' in the comments of the original article. I agree, that this looks fundamentally like a solution in search of a problem.

EPOLL_CTL_DISABLE, epoll, and API design

michaeljt — 2012-10-24T16:30:13+00:00

This should probably have been a comment on the previous article, but I'm not sure if anyone is watching that any more.

I am sure that there is a good reason why it won't work, but couldn't the original problem be solved, in user space, if the user space file descriptor cache included not just a "should be deleted" flag, but also a reference count of threads currently using a file descriptor? Then, before accessing the descriptor, a thread could check the "should be deleted" flag and if it is set decrease the reference count instead of accessing it, freeing the resources if the count reached zero.

EPOLL_CTL_DISABLE, epoll, and API design

mkerrisk — 2012-10-24T10:51:40+00:00

That comes out as sloppy, but is really more a sign of a development process in the need of improvement.

Yes. Having watched what goes on for quite a while now, I consider this mainly a process problem, rather than a problem of individual developers (though obviously some do a better job than others).

EPOLL_CTL_DISABLE, epoll, and API design

Yorick — 2012-10-24T10:40:29+00:00

As the article points out, changes to the internal kernel code tend to get much more scrutiny than those that affect user-visible interfaces, despite the fact that those are the ones that really need to be right from the start. That comes out as sloppy, but is really more a sign of a development process in the need of improvement.

When we suffer from badly thought-out APIs made by Microsoft, say, we pour scorn over the developers who designed the mess and call them incompetent, fairly or not. Linux kernel programmers are not exempt and should not be.

EPOLL_CTL_DISABLE, epoll, and API design

daniels — 2012-10-24T04:25:23+00:00

the developers here come out as bumbling amateurs

Err? They made a mistake, which in the context of something as complex and genuinely impressive as the Linux kernel, can be forgiven. How many kernels which scale from embedded to clusters have you written?

EPOLL_CTL_DISABLE, epoll, and API design

nybble41 — 2012-10-23T23:04:44+00:00

In cases like this one, where the problem is just unused parameters which weren't checked, it seems like a simple enough thing to fix. Just create a new API for new applications that follow the rules, and make the old one forward to the new one after masking out the unused parts. For example, epoll_ctl(epfd, op, fd, event) could call epoll_ctl_v2(epfd, op, fd, NULL), ignoring event; anything that wants to use the last parameter would call epoll_ctl_v2 directly. The same principle would work for bitfields. The new API could easily be made automatic for new programs through versioned library symbols.

However, I agree that in general maintaining multiple API versions, where the old one is not a simple subset of the new one, is not likely to go well.

EPOLL_CTL_DISABLE, epoll, and API design

dlang — 2012-10-23T21:07:58+00:00

I disagree.

If applications will be broken, then the API shouldn't change.

If there are no applications using an API, that API can be removed.

But If applications are using that API, creating new versions of the API doesn't solve the problem. Existing applications are not going to disappear.

This attitude that "the APIs are versioned, we can drop support for old versions" is exactly what's causing the problems in the Linux Desktop Environment world.

It doesn't matter how justified you think you are in getting rid of an old version, if it breaks users it's a regression and you should not do so.

Maintaining lots of different, incompatible versions of an API is a huge amount of work, so just versioning the API isn't nearly enough, and it's questionable if it really helps in the long run.

EPOLL_CTL_DISABLE, epoll, and API design

Yorick — 2012-10-23T21:01:05+00:00

You are right, but there is not much we can do about that other than devising more sophisticated mechanisms for API evolution than the rather simplistic policy in Linux. User-space libraries (with versioned symbols or similar ways of evolving APIs) provide one possible answer, but from what I understand, the kernel maintainers aren't too keen on such layers.

EPOLL_CTL_DISABLE, epoll, and API design

dlang — 2012-10-23T20:30:20+00:00

even working applications aren't going to identify all the drawbacks and problems with an API.

The early applications that use an API are going to be written by people who are very familiar with the API and know not only what the API does, but how it _should_ be used.

a few years later, you get applications developed by people who don't know how it _should_ be used, and as they start trying to use it in other ways (some of them very good ways), they expose limitations that the people who were involved with the development, testing, and reviews of the API missed.

EPOLL_CTL_DISABLE, epoll, and API design

Yorick — 2012-10-23T20:27:10+00:00

This is unfortunate. There is nothing more important to review than immutable interfaces (except for security audits). I'm going to be grossly unfair here, but in neglecting basic software engineering principles, the developers here come out as bumbling amateurs. (Of course I've made similar mistakes myself, but with slightly less severe consequences.)

With a cast-in-stone policy, these APIs must be subject to extreme scrutiny. I would like to go further than the editor of the excellent article: There should be working applications present, not just tiny test cases or proofs of concept, in addition to full documentation, before any proposals can be accepted. It's not just a matter of verifying that the APIs work, but that they are useful and complete as well.

The importance of checking unused parameter bits was learned dearly in the 1960s, over and over again, both for hardware and software. We should know this by know.

EPOLL_CTL_DISABLE, epoll, and API design

dankamongmen — 2012-10-23T16:19:12+00:00

https://raw.github.com/dankamongmen/libtorque/master/doc/...

I really wish I'd have followed this out to its conclusion back in 2010. :/