Re: [PATCH 0/1] ioctl_epoll.2: Add epoll ioctl documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 06, 2024 at 11:44:10PM +0200, Alejandro Colomar wrote:
> On Tue, Jun 04, 2024 at 06:17:39PM GMT, Joe Damato wrote:
> > Greetings:
> 
> Greetings!
> 
> > This is my first contribution to the man-pages project, so please excuse
> > any obvious issues; I am happy to take feedback and send updated patches as
> > needed.
> 
> Sure; no problem.
> 
> > This change documents a new ioctl interface for epoll added to Linux kernel
> > 6.9 [1] and glibc [2] for controlling busy poll on a per-epoll fd basis.
> 
> Thanks!
> 
> > I noted that other ioctls have ioctl_*.2 files, so I followed that
> > pattern in this change.
> 
> Sure.  I used a different pattern with prctl(2)s, so let's use a mix.
> Do the ioctl_*.2 tradition, but also add link pages with the names of
> the actual operations (which will allow to search directly for the man
> pages of the individual operations).

Thanks for your careful review. I will make the changes you
suggested for the v2.

> > Based on the current status of glibc, I would assume that this change will
> > be part of glibc 2.40 (it is listed under 2.40 in the NEWS section), which
> > may be released in a few months [3].
> 
> If you're certain that this will be part of glibc 2.40, I'm fine merging
> it already.  We can always patch it if something changes.

I have no idea if I can be certain of that. I am not a maintainer
nor do I have commit access to glibc, so I truly have no idea.

I suppose it is possible that they may decide to cut glibc 2.40 from
before my patch went in? It does not seem there is any 2.40 tag yet,
AFAICT.

How about I proceed by making all the changes you've requested and
get the patch into a shape where it can be merged. Hopefully,
that'll only take one (or two ;) more revisions.

Once the patch is in good shape, then we can decide whether to merge
or wait for glibc 2.40? If they are releasing it in 8/2024, it's not
too long to wait.

Does that seem OK to you?

> > Given that, I am not sure if I should wait until glibc 2.40 has been
> > released before sending this change to this project or not.
> > 
> > Please let me know.
> > 
> > Thanks,
> > Joe
> > 
> 
> Cheers,
> Alex
> 
> > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/eventpoll.c?h=v6.9&id=18e2bf0edf4dd88d9656ec92395aa47392e85b61
> > [2]: https://sourceware.org/git/?p=glibc.git;a=commit;h=92c270d32caf3f8d5a02b8e46c7ec5d9d0315158
> > [3]: https://sourceware.org/glibc/wiki/Glibc%20Timeline
> > 
> > Joe Damato (1):
> >   ioctl_epoll.2: New page describing ioctl(2) operations for epoll fds
> > 
> >  man/man2/epoll_create.2 |   1 +
> >  man/man2/epoll_ctl.2    |   1 +
> >  man/man2/ioctl_epoll.2  | 203 ++++++++++++++++++++++++++++++++++++++++
> >  man/man7/epoll.7        |   1 +
> >  4 files changed, 206 insertions(+)
> >  create mode 100644 man/man2/ioctl_epoll.2
> > 
> > -- 
> > 2.34.1
> > 
> > 
> 
> -- 
> <https://www.alejandro-colomar.es/>






[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux