Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 996D9C61DA4 for ; Fri, 3 Feb 2023 08:04:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232320AbjBCIEf (ORCPT ); Fri, 3 Feb 2023 03:04:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232487AbjBCIDr (ORCPT ); Fri, 3 Feb 2023 03:03:47 -0500 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5A931B304 for ; Fri, 3 Feb 2023 00:02:56 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id hx15so13033850ejc.11 for ; Fri, 03 Feb 2023 00:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nR20600SL7g35fm438V0laRpWELfS254RVEtCaDlTWI=; b=GOq88P8N+614+l+UcGLkDVoY6H4UAaFRqI1zfr9wpu7rXaJ7UM562Pht5e+QEYlEpN +JGx7q7DnWX0wyB+cVmtvBhNEZbfuzZbk2JfhqCA8dOyRCZyj2ITRs+34hqwHzsyeQ2r 4muu3ifR+aIjiX2uOG/r8TWcoANREf5Ge6/da90kS2jtFc7RTgajA37gLstI1UFqtY1y 1vQ2sumOp01Lc/6klXOO6c3cxyltlZ3McMM1W5B4AkgFSuYLtaMMy85PQ3IF8Vxm/eJB Gc0Lo8sLFqGdEZEvkGMjSeIH2+gekOqwSjRpCzl79s+vOT8aJU9BRcFD/c5HLdky2mU3 f/+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nR20600SL7g35fm438V0laRpWELfS254RVEtCaDlTWI=; b=PSUhuuX/cS+78PmNhqDRgABEjS34TkYiRtE7AnDoBV9Fvxpflff1EF0dS17KGSFGcs 1csedggmT79vnkfC9nPWZTRfxd9HfeNruo0lImH8x4intj6qtLZFyFNzkBHKwW0mk+l6 hzrc8A5lo7F0MT/Wfu0svRYTGWZ+jHaoloyy9Dlfia+F4qH2I46dyO4rkRNrQPUdth4C MBznm+4V50RXYyzAjmUwWcRtjU5Q35nvH1beSWezsN8HJxl9VONqrU4NCqEytokuY/nv 59A+7uqryYPFMzwaHYoDloeLz5kzD+ZuyQP9htAoiNAuk2DfDi8XJCJreOKBPnm6iNvp hEZQ== X-Gm-Message-State: AO0yUKVzxF11W8PUZsIlX0V8EPbkkLrZi/LhERcSwGKJzh7ZKJIcYprT c1YbNG8heBvhwcZ/m4gBgPPAdQ== X-Google-Smtp-Source: AK7set8HkdTykRTt6XwdlZ2GwJb9SmCOtcLgcSBKli3qD9uHZRhnoHdhb6uPbxsFzhfCOjpx59UXdw== X-Received: by 2002:a17:906:c2d3:b0:854:6e3:2388 with SMTP id ch19-20020a170906c2d300b0085406e32388mr9530349ejb.12.1675411375276; Fri, 03 Feb 2023 00:02:55 -0800 (PST) Received: from localhost ([86.61.181.4]) by smtp.gmail.com with ESMTPSA id f6-20020a17090660c600b0088ad82a8de4sm1004941ejk.34.2023.02.03.00.02.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 00:02:54 -0800 (PST) Date: Fri, 3 Feb 2023 09:02:53 +0100 From: Jiri Pirko To: Jakub Kicinski Cc: Moshe Shemesh , "David S. Miller" , Jiri Pirko , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 7/7] devlink: Move devlink dev selftest code to dev Message-ID: References: <1675349226-284034-1-git-send-email-moshe@nvidia.com> <1675349226-284034-8-git-send-email-moshe@nvidia.com> <20230202101712.15a0169d@kernel.org> <52392558-f79e-5980-4f10-47f111d69fc0@nvidia.com> <20230202114621.3f32dae1@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230202114621.3f32dae1@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thu, Feb 02, 2023 at 08:46:21PM CET, kuba@kernel.org wrote: >On Thu, 2 Feb 2023 21:33:52 +0200 Moshe Shemesh wrote: >> On 02/02/2023 20:17, Jakub Kicinski wrote: >> > On Thu, 2 Feb 2023 16:47:06 +0200 Moshe Shemesh wrote: >> >> Move devlink dev selftest callbacks and related code from leftover.c to >> >> file dev.c. No functional change in this patch. >> > selftest I'd put in its own file. We don't want every command which >> > doesn't have a specific sub-object to end up in dev.c, right? >> > At least that was my initial thinking. I don't see any dependencies >> > between the selftest code and the rest of the dev code either. >> > WDYT? >> >> I thought as it is devlink dev selftest, the sub-object is dev. >> Otherwise, what should be the rule here ? >> >> How do we decide if it should get its own file ? > >My thinking was that it should be much easier for newcomers to grok >"what does it take to implement a devlink command" if most of the >subcommands where in their own files, like in ethtool. > >The implementation could have as well made selftest a subobject. >But I don't feel strongly, if noone agrees we can apply as is and >see if dev.c does indeed start to grow out of proportion. I think that per-object separation is good for now. I see no point of having per-cmd files of sometimes 50 lines. IDK. No strong opinion. I would start with per-object.