Question about select and poll system call

[richard clark]

Adding more people...

I did some homework and found that the FD_SETSIZE question seems
related with below 2 commits:
1. 4e6fd33b7560 ("enforce RLIMIT_NOFILE in poll()")
"POSIX states that poll() shall fail with EINVAL if nfds > OPEN_MAX.
In this context, POSIX is referring to sysconf(OPEN_MAX), which is the
value of current->signal->rlim[RLIMIT_NOFILE].rlim_cur in the linux
kernel...". IOW, the nfds suggested by POSIX is kind of configurable,
making sense for Linux kernel to link it with rlimit.
2. bbea9f69668a ("fdtable: Make fdarray and fdsets equal in size")
This commit uses the fdt->max_fds instead of FD_SETSIZE suggested by
POSIX, but gives no reason to do that.

Curiously I did some tests on Linux and macOS, the testing code snippet:

static int test(void)
{
    int err = 0;
    int nfds = FD_SETSIZE;
    fd_set rfds, wfds, efds;

    FD_ZERO(&rfds);
    FD_ZERO(&wfds);
    FD_ZERO(&efds);

    err = select(nfds + 1, &rfds, &wfds, &efds, NULL);
    if (err < 0)
        perror("select failed");
    return err;

}

The test results as:
Linux
~~~~
Blocked at select

macOS
~~~~~~
select failed: Invalid argument

Thanks!

On Tue, Mar 14, 2023 at 10:31 AM richard clark
<richard.xnu.clark at gmail.com> wrote:
>
> Adding linux-arm-kernel at lists.infradead.org ... for more possible feedback:)
>
> On Tue, Mar 14, 2023 at 10:28 AM richard clark
> <richard.xnu.clark at gmail.com> wrote:
> >
> > Hi, (Sorry, not find the maintainers for this subsystem, so to the lkml)
> >
> > There're two questions about these system calls:
> > 1. According to https://pubs.opengroup.org/onlinepubs/7908799/xsh/select.html:
> > ERRORS
> > [EINVAL]
> >       The nfds argument is less than 0 or greater than FD_SETSIZE.
> > But the current implementation in Linux like:
> >        if (nfds > FD_SETSIZE)
> >                nfds = FD_SETSIZE
> > What's the rationale behind this?
> >
> > 2. Can we unify the two different system calls? For example, using
> > poll(...) to implement the frontend select call(...), is there
> > something I'm missing for current implementation? The Cons and Pros,
> > etc
> >
> > Thanks,