git: 26795a0378b5 - main - linux(4): Rework Linux ppoll system call.
Dmitry Chagin
dchagin at freebsd.org
Tue Jun 22 16:05:00 UTC 2021
On Tue, Jun 22, 2021 at 11:00:32AM +1200, Thomas Munro wrote:
> Hi Dmitry,
>
> On Tue, Jun 22, 2021 at 4:30 AM Dmitry Chagin <dchagin at freebsd.org> wrote:
> > The branch main has been updated by dchagin:
> >
> > URL: https://cgit.FreeBSD.org/src/commit/?id=26795a0378b58c3e26b68577a4cc446ab527e8b5
> >
> > commit 26795a0378b58c3e26b68577a4cc446ab527e8b5
> > Author: Dmitry Chagin <dchagin at FreeBSD.org>
> > AuthorDate: 2021-06-22 05:06:05 +0000
> > Commit: Dmitry Chagin <dchagin at FreeBSD.org>
> > CommitDate: 2021-06-22 05:06:05 +0000
> >
> > linux(4): Rework Linux ppoll system call.
> >
> > For now the Linux emulation layer uses in kernel ppoll(2) without
> > conversion of user supplied fd 'events', and does not convert the
> > kernel supplied fd 'revents'.
> >
> > At least POLLRDHUP is handled by FreeBSD differently than by
> > Linux. Seems that Linux silencly ignores POLLRDHUP on non socket fd's
> > unlike FreeBSD, which does more strictly check and fails.
>
> For the record, I wondered about adding POLLRDHUP to POLLSTANDARD, but
> that didn't seem right as it's not "standard", and I wondered if the
> POLLSTANDARD check mechanism should event exist at all ((1) POSIX
> doesn't tell us to reject flags, its POLLNVAL is for rejecting bogus
> fds, (2) it was added at the same time as POLLWRITE and other
> extensions that were later reverted), but I wasn't sure enough about
> that to propose those changes when adding POLLRDHUP, or at least it
> seemed like an independent matter for discussion.
>
thank you for clarification
> > Rework the Linux ppoll, using kern_poll and converting 'events'
> > and 'revents' values.
> > While here, move poll events defines to the MI part of code as they
> > mostly identical on all arches except arm.
> >
> > Differential Revision: https://reviews.freebsd.org/D30716
> > MFC after: 2 weeks
>
> Note that the POLLRDHUP support is new (commit 18f21f03) and not yet
> MFC'd. I was planning to MFC to 13 in the next few days if there are
> no objections.
ok, what about stable/12?
More information about the dev-commits-src-all
mailing list