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=-3.8 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 D0973C4363D for ; Fri, 2 Oct 2020 06:29:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 91F30206DD for ; Fri, 2 Oct 2020 06:29:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725995AbgJBG3b (ORCPT ); Fri, 2 Oct 2020 02:29:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbgJBG3b (ORCPT ); Fri, 2 Oct 2020 02:29:31 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B6B4C0613D0 for ; Thu, 1 Oct 2020 23:29:31 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1kOEZM-00F5Qq-St; Fri, 02 Oct 2020 08:29:29 +0200 Message-ID: Subject: Re: [PATCH net-next v2 00/10] genetlink: support per-command policy dump From: Johannes Berg To: Jakub Kicinski , davem@davemloft.net Cc: netdev@vger.kernel.org, andrew@lunn.ch, jiri@resnulli.us, mkubecek@suse.cz, dsahern@kernel.org, pablo@netfilter.org Date: Fri, 02 Oct 2020 08:29:27 +0200 In-Reply-To: <20201001173644.74ed67da@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> References: <20201001225933.1373426-1-kuba@kernel.org> <20201001173644.74ed67da@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 2020-10-01 at 17:36 -0700, Jakub Kicinski wrote: > On Thu, 1 Oct 2020 15:59:23 -0700 Jakub Kicinski wrote: > > Hi! > > > > The objective of this series is to dump ethtool policies > > to be able to tell which flags are supported by the kernel. > > Current release adds ETHTOOL_FLAG_STATS for dumping extra > > stats, but because of strict checking we need to make sure > > that the flag is actually supported before setting it in > > a request. > > Do we need support for separate .doit and .dumpit policies? > Or is that an overkill? I suppose you could make an argument that only some attrs might be accepted in doit and somewhat others in dumpit, or perhaps none in dumpit because filtering wasn't implemented? But still ... often we treat filtering as "advisory" anyway (except perhaps where there's no doit at all, like the dump_policy thing here), so it wouldn't matter if some attribute is ending up ignored? johannes