[markjdb]

The same is true of kqueue/kevent though... the driver just needs to decide which filters it wants to implement. There's no need to extend kqueue when adding some custom driver or fd type. One just needs to define some semantics for the existing filters.

[ajross]

> the driver just needs to decide

That's pretty much the definition of technical debt though. "This interface works fine for you if you take steps to handle it specially according to its requirements". It makes kqueue into a point of friction for everything in the system wanting to provide a file descriptor-like API.

[markjdb]

Well, no, it's "this interface works fine for you if you implement it."

The kernel doesn't magically know whether your device file has data available to read, your device file has to define what that means. That's all I'm referring to. Hooking that up to kqueue usually involves writing 5-10 lines of code.

[netbsdusers]

No it isn't. Letting files be poll/select/epoll'd isn't free either. They don't get support for that by magic. A poll operation has to be coded, and this is just as a much a "point of friction" then as supporting kqueue. (It bears mentioning as well that on at least DragonFly BSD and OpenBSD, they have reimplemented poll()/select() to use kqueue's knotes mechanism, and so now you only have to write a VOP_KQFILTER implementation and not a VOP_POLL too.)

[ajross]

> Letting files be poll/select/epoll'd isn't free either.

Yes, but those slashes are showing the lie in the statement. Letting files be polled/selected isn't "free", but it's standard. The poll() method has been in struct file_operations for literally decades[1]. Adding "epoll support" requires no meaningful changes to the API, for any device that ever supported select().

That kind of evolutionary flexibility (the opposite of "technical debt") is generally regarded as good design. And it's something that epoll had designed in and something that queue lacks, having decided to go its own way. And it's not unreasonable to call that out, IMHO.

[1] It's present in commit 1da177e4c3f4 ("Linux-2.6.12-rc2"), which is the very first git commit. I know people maintain archives of older trees, but I'm too lazy to dig. Suffice it to say that epoll relies on an interface that is likely older than many of the driver developers using it.

[markjdb]

The article clearly isn't talking about technical debt within the kernel implementations of epoll and kqueue, and if one wanted, it'd be easy to define fallback EVFILT_READ/WRITE filters using a device's poll implementation.

I don't really understand what argument you're making. Is io_uring also a bad design because it requires new file_operations?

[ajross]

> if one wanted, it'd be easy to

Which, again, is a statement that gets to the root of the idea of "technical debt". You can excuse almost anything like that. It still doesn't make it better than a design that works by default. I remain shocked that this seems to be controversial.

FWIW: io_uring has been very loudly criticized for being hard to implement, maintain and use, via some of this same logic, yes. This isn't a senseless platform flame. Linux does bad stuff too. There are good designs and bad designs everywhere, and io_uring is probably not one (though to be fair it does have some extremely attractive performance characteristics, so I guess one might be tempted to forgive a few warts in the interface layers).

[markjdb]

A design that works by default isn't automatically better either though. You have to look at the details.

> I guess one might be tempted to forgive a few warts in the interface layers

... well, yeah, that's exactly my sentiment about kqueue here. What you're talking about is basically a small wart that no one's bothered to address because it's inconsequential.