From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6287 invoked from network); 25 Sep 2020 19:07:08 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 Sep 2020 19:07:08 -0000 Received: (qmail 3181 invoked by uid 550); 25 Sep 2020 19:07:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3142 invoked from network); 25 Sep 2020 19:07:05 -0000 Date: Fri, 25 Sep 2020 15:06:53 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200925190653.GO3265@brightrain.aerifal.cx> References: <20200925091828.306644-1-Tony.Ambardar@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200925091828.306644-1-Tony.Ambardar@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH v1] nftw: support FTW_ACTIONRETVAL extension On Fri, Sep 25, 2020 at 02:18:28AM -0700, Tony Ambardar wrote: > Add the FTW_ACTIONRETVAL mode for walking file trees, a commonly used glibc > extension. This updates the existing musl nftw/ftw code to support the new > mode and include options e.g. to prune trees and skip tree siblings. > > This patch is based on one originally submitted to musl's mailing list [1], > which was reviewed with interest but received no follow-up. It has since > been cleaned up, and tested on OpenWRT for building Linux's 'bpftool' > utility (the primary tool for BPF introspection and manipulation). > > Including this extension should also further reduce any need for fts(3) > support. > > [1] https://www.openwall.com/lists/musl/2018/12/16/1 This isn't a decision on your patch in itself, but the reason that was not followed up on was that it became apparent that the point of the whole series was just trying to add everything to musl that systemd happened to be using. In general, there's policy (that should be expanded upon and moved to somewhere more visible!) on criteria for including or excluding nonstandard functionality from musl. The best write-up of it I could find is in: https://www.openwall.com/lists/musl/2014/07/19/8 I'm pretty sure there's a more detailed version somewhere but I didn't immediately find it. Since we haven't encountered any other programs (see 2A) that needed this extension, is there a reason you think it's particularly important to have, vs just fixing bpftool not to need it? Rich