Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp850153imi; Fri, 22 Jul 2022 10:50:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s+uBSRZllXHM/lwfQwKp2tnhc8iIFQbLPYH4NpVJtdXjoXFh98X+xhZfZlR5k0KoFskWW8 X-Received: by 2002:a63:b341:0:b0:40d:677:881a with SMTP id x1-20020a63b341000000b0040d0677881amr736747pgt.407.1658512216984; Fri, 22 Jul 2022 10:50:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658512216; cv=none; d=google.com; s=arc-20160816; b=Bu8SDEF5p2F24f5l7tQoO2DEztKmvv0LZyrx8Wws+kqPHg//4b3MB8jX0+b6SPb06f WX7TucS/4uJuhCTpfxp/7YKhLHOU7NzcFkvZGZMYXz6KMupCsokydudGuz9+xfjcUfx0 SL0cCH6DkL/oteoUCHv/kWZ6zIQvNd2HovkfyIKAiwKUIbmwO6/z5C/KO+u+TDEC75C1 CT90Q6oHcbTv0ZBfGRUi0PouZzPcKtLJ1W/zTUEmjYemVUkEpWG8i8MY6Xc4qpjfnPRx KWIepp8597Ar4lnsofrXEK0PRKxbMexzwXqJ7Y9v+KjGOyxw7IKyHLdel14cLflcJF0e GbiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=izuQdvtPbLusxei9zcb6ofNQnLYCg6bTPBfAVtJ3qdU=; b=gH0A3OHK5ETyv33rMhbkekT9ArUB1kW3rIBvXxCVpDYT0NfBS1gOJ2kOfxqNTL7+oA huFoVyx+3CNlhUQCjAJKD4xfUWhWd0/Fqm0xeMir3TKe8nfR8IurjYmR1ipCUPBGBi6w FTzyMmivXpkrOcTrZLW2JBBok8q4Mrri2lMvwLSSSO1w/RuCfMaRltGQabCW2pQpugc9 BzEGYQuGmA10aMIHsFqHU7aBaHX01JlSVC0OxiJH4jpIy8ANhU3yMPqQEdx9+OA1VXMt CQwnxWDn6CMZIbE/TNUNovRjs6vbTku3uPOH7YpqeV9s5EQKR04+N6V+taWyar4m9eIV pCWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=oF79YoCi; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e34-20020a635462000000b0040d464c972bsi6216318pgm.329.2022.07.22.10.49.57; Fri, 22 Jul 2022 10:50:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=oF79YoCi; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230453AbiGVRqI (ORCPT + 99 others); Fri, 22 Jul 2022 13:46:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235585AbiGVRqH (ORCPT ); Fri, 22 Jul 2022 13:46:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07F312ED5A; Fri, 22 Jul 2022 10:46:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B0BF2B829D7; Fri, 22 Jul 2022 17:46:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E327C341C6; Fri, 22 Jul 2022 17:46:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658511963; bh=XZZJmzeJO/5mk40jvpARF6vwsesp+pzNXLCOtSZI65Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oF79YoCi2IgeGTUYIDgHVMfWe9u4z1PIXD1k6fpjw0vmpUlQwkAy4wrFO/aTG71SR aRJNbpLp4jWA+kIAf/J7kjBixjOh1aNRNkSTgPlXzOtnDH8tFS3hHv+ss5xVbor6DI txLxprNUAnhHN5p6WU26cn2NCL47pSfWgD9sKW/p8gXKDgNkblHiT4Wq5d2LBcZS7k 7OOMFtCy42cqiAicYxzAqjwjsEd973IfdhVlsFwz9iZUmnxdRrlrhKs9PnbpIXNWXd og/xhF7oUKkY5CGMj5Vd7+LAsr2zr4TTdV3vM8Qg26EdLpn95UBJjI2H6wkzJnKvSp BOXPZc7/DMLFQ== Date: Fri, 22 Jul 2022 10:46:02 -0700 From: "Darrick J. Wong" To: Alejandro Colomar Cc: Theodore Ts'o , Jeremy Bongio , linux-ext4@vger.kernel.org, linux-man@vger.kernel.org Subject: Re: [PATCH v2] Add manpage for get/set fsuuid ioctl for ext4 filesystem. Message-ID: References: <20220720234512.354076-1-bongiojp@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri, Jul 22, 2022 at 04:32:45PM +0200, Alejandro Colomar wrote: > Hi Ted, > > On 7/22/22 15:55, Theodore Ts'o wrote: > > On Fri, Jul 22, 2022 at 12:03:23PM +0200, Alejandro Colomar (man-pages) wrote: > > > > SEE ALSO > > > > ioctl(2) > > > > > > > > at the end of an ioctl_XXX manpage like this one. > > > > > > > > > > Okay. Then may I ask for an EXAMPLES section with a program that > > > unequivocally shows users how to use it? > > > > I'll note that existing ioctl man pages don't have an explicit > > statement that a libc is required --- nor do we do this for open(2), > > stat(2), etc. I think you and I missed that discussion: https://lore.kernel.org/linux-man/20210911160117.552617-1-alx.manpages@gmail.com/ > That's because there hasn't been a man-pages release in around a year. > If you see the man-pages git repo, you'll see that (almost) all man pages in > sections 2 and 3 have a new LIBRARY section. > > ioctl(2) pages now have this LIBRARY section: > > > This was based on FreeBSD's man pages: > > > (And that's especially necessary for stat(2), BTW!) > > stat(2) now says : > > LIBRARY > Standard C library (libc, -lc) > > > If you would like to improve on that, I'm open to ideas, or patches from > programmers who know the syscalls much better than I do. I still think it's redundant to say that you have to link against the standard C library -- it's a standard feature on Linux, and you have to pass -nolibc to opt out of it. Libraries that have to be opted-into (e.g. -lpthread) should be documented here, but not stuff that's enabled by default. Oh well, you're the maintainer, it is your prerogative. > > Many of the ioctl man pages (or other system call man pages, for that > > matter) also don't have an EXAMPLES section, either. > > > > Perhaps it would be useful to have a discussion over what the > > standards are for man pages in section 2, and when we need to state > > things that seem to be rather obvious (like "you must have a C > > library") and when there should be things like an EXAMPLES section? > > Now that you say it, I forgot to document the LIBRARY section in > man-pages(7). There's something about it, but I forgot to add a paragraph > describing it in detail. That would've helped, since I scanned https://man7.org/linux/man-pages/man7/man-pages.7.html and didn't see much about what goes in this section... > Regarding the EXAMPLES section, every page in man2 or man3 should have an > example program, IMO. Consider that there are programmers that may find it > easier to learn a function by experimenting with a working example of C > code, rather than a dense textual description in a language that may not be > native to the programmer. Frankly I'd rather push people to have example code over documenting that standard C library functions require the standard C library. :) That said, I don't always enjoy the textbook examples that have been slimmed down for manpages -- I prefer a link to a real implementation in (say) the test suite so that I can see code that (one would hope) exercises all the functionality exposed through the interface. But I guess that's really up to the manpage author to decide. > There are many pages that lack examples, but that's not something I would > consider a good thing. > > > > > Some the suggestions you are making don't seem to be adhered to by > > the existing man pages, and more text is not always better. > > The next release of the man-pages is certainly going to be an important one. > It may be hated by many, loved by many others. I hope overall I did a > significant improvement in both improving the transmission of information > and simplifying maintenance. I'm not convinced that having to open *two* manpages just to figure out how to call an ioctl is going to simplify maintenance unless the struct is shared across more than one manpage, but I've already made that point. (There isn't any magical way to #include a manpage within another manpage, is there?) --D > > > > > https://www.npr.org/sections/13.7/2014/02/03/270680304/this-could-have-been-shorter > > Sorry, but I'm not able to read that page. It prompts the usual GPDR > notice, and doesn't give me the option to reject cookies (only accept). > > Anyway, I guess what it says. I hope I wasn't too much verbose with my many > changes. > > Cheers, > > Alex > > -- > Alejandro Colomar >