I’ve been working on a java.nio.channels.Selector for GNU Classpath based on the epoll event notification mechanism, which is available on the 2.6 kernels. David was kind enough to point out that on 2.4 kernels with a newer libc, the sys/epoll.h header, as well as all the epoll functions, all exist, and all do nothing except return ENOSYS.
That’s a stellar failure mode there, guys. Thanks a pantload for that.
You quickly realize that this makes writing autoconf tests for epoll completely impossible: nothing you can test for will give you a real hint at whether or not the function is, in fact, supported. Oh sure, you could run a test program that tries to open an epoll file descriptor (eeech), but that won’t help out people who are cross-compiling, will it?
Oh, well, why not just add a configure switch that lets the user disable it by hand, you ask? Yeah, that’s a swell solution. Let’s introduce more configuration options for the poor user to guess the right values for.
Sub-rant ahoy!
What’s the deal with configure help output? The convention seems to be that you write:
- –enable-FOO if FOO is not normally enabled,
- –disable-FOO if FOO is normally enabled.
Of course, no-one follows this bogus convention anyway, and in the help output you’ll see a line saying “–enable-FOO … (default: yes)”. It’s even better when the help output is “–disable-FOO … (default: yes)”. Does the “yes” mean it’s disabled by default, or not?
Edit, FYI: this is not a debate, I think this behavior is completely stupid, and you have not convinced me otherwise.
Edit: toned down this post. I don’t mind being harsh, and it’s partly a joke, but I don’t want you to think I regard the glibc guys that lowly. I don’t, but they do say some goofy ass things sometimes.
Loading...
Daniel Jacobowitz | 19-Sep-06 at 3:13 pm | Permalink
Sorry, but you’re the one who hasn’t thought this through. Glibc may be weird in other areas, but here it’s dead on.
Here’s a hypothetical for you. Imagine you’re a nice Debian build server, running a recent and well-patched 2.6 kernel. If you build this innocent looking package, and get something which will absolutely fall down when run on a supported system with a 2.4 kernel, can you claim that’s a BETTER failure mode?
The point of returning ENOSYS is to let the application detect operating system support at runtime and degrade gracefully to some other approach.
And it’d be nice if you put (required) next to the antispam question, yaknow, or maybe made it not completely eat submissions and force me to retype this.
csm | 19-Sep-06 at 3:31 pm | Permalink
I don’t know, as a user which error message do I care less about: Function not implemented, or dynamic symbol not found? Oh, that’s right, I don’t give a shit about either.
A sensible build system might either compile something portable across kernel versions (i.e., omit any calls to epoll) or would build a version for 2.4, and a version for 2.6. And there might even be (gasp!) QA involved.
But this is open source, so I’m not looking for sensible build practices or project management.
And you’re missing the whole point of this post, which was that we have a decent enough way to write software that can be compiled on many different systems (autoconf), and this kind of shit makes writing autoconf tests for features *impossible*. And that’s what I’m interested in right now, not your Debian build server strawman.
Daniel Jacobowitz | 20-Sep-06 at 6:27 am | Permalink
It’s not a strawman, thanks, I spent several years as a Debian buildd admin dealing with exactly this sort of thing. also spend much of my day cross compiling programs for Linux targets, where testing for features at runtime is about the evillest thing you can do.
I’m not sure why you think it would be sensible to either ignore new interfaces entirely, or build two copies of everything. Why should otherwise portable software have to build twice just for Linux?
This does _NOT_ make writing autoconf tests for features impossible. You write a link test for the presence of epoll, and then you adjust at runtime to whether it works or not. This makes your software even more portable, in combination with autoconf. This is in fact what the autoconf manual recommends (see section 6.6).
csm | 20-Sep-06 at 11:52 am | Permalink
Adjust at runtime! Yeah! It’s so simple, isn’t it? It’s someone else’s problem to work around features that MIGHT be available. Let’s not only litter our code with #ifdefs, but lets also check all the system calls we use for ENOSYS!
Yeah, awesome.