Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2380631ybt; Tue, 16 Jun 2020 04:46:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwgG8hfWRC9hFYBoaaPC4DkgsUHjYH6qyaHlc3AARLt5GIGkw7mLTsUB4WJdnk2hV59Y9h1 X-Received: by 2002:a17:906:1ed2:: with SMTP id m18mr2259926ejj.529.1592307972455; Tue, 16 Jun 2020 04:46:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592307972; cv=none; d=google.com; s=arc-20160816; b=ammdsQVgj+yJqgE7/lB1yIJ9o+GOfHAyska/SknBKsp25C3PgK3xCQETOTlKQpcp86 GdiSTLPYfZsUA2keke0LBpHVOLUssp4fyY4mNi9ZZUIWhJg+t7qjQNXDIK7U+JeB9Oen e78/92WRuIb2k7byYz675nt0kpd9y+6yL1HSjeYovr7doqa0lRZcCpqRLEXYyaFSRDui 2hWstfdKq6TUfDsUU8XpfQHh3aFLC79vahYb8ldC9z3/RziqYWg5yqIOvDwGnc+Cv9Yp 07qGC3eEQPnlIbzWWYzCy16S6YdmYwTkmAdHdsCcmFF3k9JV3NMe3zHfe6TgLQvayp7X NEzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=P04xezv9uvRn7kB2pS9spP3iR85LKzRAaZZy0djL49I=; b=BG+Ow4OmLNobWIW2ghVg6pcuQVhEFz/wHBAV3mhz9J6jtvsT0onfjJeZFsTwTbmzTM FeVLCJyJoQio9TcWfoHOdjogV07IhKjP82/ShhEuBOvt2xkSA0uE3jjBAPXH6p+ENFAw A1k3vg1PkVyUbAXZVppqJK0nAfo8u2SVtB58PT18s/IjoTgeQaMWOhMqJ1hfbGei9UoP 0IBcQfTJyuDTNLt9vqSPMj/Ck5Rp0VW4nJFm42Gd48LTGRVYfYg6Pqwv7bAcNu9uiXED nr5gz0B6Q5bERXG45lib0kbToY7rJU0Y25e6xcFZ9Nuk9KG5f1ACwBKk4mQizisHzv8A PHbA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m9si10123144edp.531.2020.06.16.04.45.49; Tue, 16 Jun 2020 04:46:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727870AbgFPLmA (ORCPT + 99 others); Tue, 16 Jun 2020 07:42:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:35224 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725775AbgFPLmA (ORCPT ); Tue, 16 Jun 2020 07:42:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 84606ADD3; Tue, 16 Jun 2020 11:42:01 +0000 (UTC) Date: Tue, 16 Jun 2020 13:41:56 +0200 From: Petr Mladek To: Jim Cromie Cc: jbaron@akamai.com, linux-kernel@vger.kernel.org, akpm@linuxfoundation.org, gregkh@linuxfoundation.org, linux@rasmusvillemoes.dk, Jonathan Corbet , Andrew Morton , Will Deacon , Orson Zhai , linux-doc@vger.kernel.org Subject: Re: [PATCH v2 17/24] dyndbg: add user-flag, negating-flags, and filtering on flags Message-ID: <20200616114156.GL31238@alley> References: <20200613155738.2249399-1-jim.cromie@gmail.com> <20200613155738.2249399-18-jim.cromie@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200613155738.2249399-18-jim.cromie@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 2020-06-13 09:57:31, Jim Cromie wrote: > 1. Add a user-flag [u] which works like the [pfmlt] flags, but has no > effect on callsite behavior; it allows incremental marking of > arbitrary sets of callsites. > > 2. Add [PFMLTU] flags, which negate their counterparts; P===!p etc. > And in ddebug_read_flags(): > current code does: [pfmltu_] -> flags > copy it to: [PFMLTU_] -> mask > > also disallow both of a pair: ie no 'pP', no true & false. > > 3. Add filtering ops into ddebug_change(), right after all the > callsite-property selections are complete. These filter on the > callsite's current flagstate before applying modflags. > > Why ? > > The 'u' flag lets the user assemble an arbitary set of callsites. > Then using filter flags, user can activate the 'u' set. > > #> echo 'file foo.c +u; file bar.c +u' > control # and repeat > #> echo 'u+p' > control What was the motivation for this please? Is it common to manipulate the same set of callsites again and again? Do you have any usecase, please? Best Regards, Petr