From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 549F0C433E6 for ; Fri, 17 Jul 2020 08:17:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3431020737 for ; Fri, 17 Jul 2020 08:17:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727853AbgGQIRd (ORCPT ); Fri, 17 Jul 2020 04:17:33 -0400 Received: from mx2.suse.de ([195.135.220.15]:55866 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726113AbgGQIRd (ORCPT ); Fri, 17 Jul 2020 04:17:33 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 68C1AADF0; Fri, 17 Jul 2020 08:17:36 +0000 (UTC) Date: Fri, 17 Jul 2020 10:17:52 +0200 From: Cyril Hrubis To: Aleksa Sarai Cc: Kees Cook , Pavel Begunkov , Miklos Szeredi , Matthew Wilcox , Andy Lutomirski , Jann Horn , Stefano Garzarella , Christian Brauner , strace-devel@lists.strace.io, io-uring@vger.kernel.org, Linux API , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Michael Kerrisk Subject: Re: strace of io_uring events? Message-ID: <20200717081752.GA23090@yuki.lan> References: <20200715171130.GG12769@casper.infradead.org> <7c09f6af-653f-db3f-2378-02dca2bc07f7@gmail.com> <48cc7eea-5b28-a584-a66c-4eed3fac5e76@gmail.com> <202007151511.2AA7718@keescook> <20200716131755.l5tsyhupimpinlfi@yavin.dot.cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200716131755.l5tsyhupimpinlfi@yavin.dot.cyphar.com> Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org 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@suse.cz