epoll_pwait broken?

[Carlos O'Donell]

On 1/24/07, Davin McCall <davmac@davmac.org> wrote:
> > Is there a binary compatibility aspect we haven't covered?
> > What if sigset_t grows larger in the future?
>
> Exactly. As you said yourself, if the user passes in the wrong size the kernel returns EINVAL. So what do they pass in? At the moment sizeof(sigset_t) is 128 in glibc. According to the kernel, it's 8. The glibc sigset size allows for future growth; to expose the real set size to the user would inhibit that, even if it would allow calling epoll_pwait with the 6th argument.
>

The con in a slim interface is that the user is not insulated from
kernel structure changes. The kernel is not responsible for
maintaining compatibility. I didn't list this con on purpose. You were
unbiased, enthusiastic, and might have come up with another reason
that a slim kernel interface was a bad idea. I appreciate you being a
good sport when it comes to design discussions :-)

> It's not possible to change the size of sigset_t in glibc anyway; it would break binary compatibility.

You *can* change it, but you need to version the interfaces and
provide the old sigset_t.

Cheers,
Carlos.