[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200717081752.GA23090@yuki.lan>
Date: Fri, 17 Jul 2020 10:17:52 +0200
From: Cyril Hrubis <chrubis@...e.cz>
To: Aleksa Sarai <cyphar@...har.com>
Cc: Kees Cook <keescook@...omium.org>,
Pavel Begunkov <asml.silence@...il.com>,
Miklos Szeredi <miklos@...redi.hu>,
Matthew Wilcox <willy@...radead.org>,
Andy Lutomirski <luto@...capital.net>,
Jann Horn <jannh@...gle.com>,
Stefano Garzarella <sgarzare@...hat.com>,
Christian Brauner <christian.brauner@...ntu.com>,
strace-devel@...ts.strace.io, io-uring@...r.kernel.org,
Linux API <linux-api@...r.kernel.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: strace of io_uring events?
Hi!
> > - Why aren't the io_uring syscalls in the man-page git? (It seems like
> > they're in liburing, but that's should document the _library_ not the
> > syscalls, yes?)
>
> I imagine because using the syscall requires specific memory barriers
> which we probably don't want most C programs to be fiddling with
> directly. Sort of similar to how iptables doesn't have a syscall-style
> man page.
Call me old fashioned but I would vote for having all syscalls
documented in man pages. At least for me it makes my life much easier as
I do not have to fish for documentation or read library source code when
debugging. Think of all the poor kernel QA folks that will cry in
despair when you decided not to submit manual pages.
There is plenty of stuff documented there that most C programmers
shouldn't touch, I do not consider this to be a valid excuse.
--
Cyril Hrubis
chrubis@...e.cz
Powered by blists - more mailing lists