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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FF7DC433F5 for ; Tue, 17 May 2022 12:39:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346168AbiEQMjl (ORCPT ); Tue, 17 May 2022 08:39:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346190AbiEQMj0 (ORCPT ); Tue, 17 May 2022 08:39:26 -0400 X-Greylist: delayed 30417 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Tue, 17 May 2022 05:39:25 PDT Received: from mail.enpas.org (zhong.enpas.org [IPv6:2a03:4000:2:537::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 14E8E4C7BB; Tue, 17 May 2022 05:39:25 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.enpas.org (Postfix) with ESMTPSA id ED400FF9D7; Tue, 17 May 2022 12:39:23 +0000 (UTC) Date: Tue, 17 May 2022 14:39:21 +0200 From: Max Staudt To: Marc Kleine-Budde Cc: Oliver Hartkopp , Vincent MAILHOL , linux-can@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Message-ID: <20220517143921.08458f2c.max@enpas.org> In-Reply-To: <20220517122153.4r6n6kkbdslsa2hv@pengutronix.de> References: <20220513142355.250389-1-mailhol.vincent@wanadoo.fr> <20220514141650.1109542-1-mailhol.vincent@wanadoo.fr> <20220514141650.1109542-4-mailhol.vincent@wanadoo.fr> <7b1644ad-c117-881e-a64f-35b8d8b40ef7@hartkopp.net> <20220517060821.akuqbqxro34tj7x6@pengutronix.de> <20220517104545.eslountqjppvcnz2@pengutronix.de> <20220517141404.578d188a.max@enpas.org> <20220517122153.4r6n6kkbdslsa2hv@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-can@vger.kernel.org On Tue, 17 May 2022 14:21:53 +0200 Marc Kleine-Budde wrote: > On 17.05.2022 14:14:04, Max Staudt wrote: > > > After looking through drivers/net/can/Kconfig I would probably > > > phrase it like this: > > > > > > Select CAN devices (hw/sw) -> we compile a can_dev module. E.g. > > > to handle the skb stuff for vcan's. > > > > > > Select hardware CAN devices -> we compile the netlink stuff into > > > can_dev and offer CAN_CALC_BITTIMING and CAN_LEDS to be compiled > > > into can_dev too. > > > > > > In the latter case: The selection of flexcan, ti_hecc and > > > mcp251xfd automatically selects CAN_RX_OFFLOAD which is then also > > > compiled into can_dev. > > > > > > Would that fit in terms of complexity? > > > > IMHO these should always be compiled into can-dev. Out of tree > > drivers are fairly common here, and having to determine which kind > > of can-dev (stripped or not) the user has on their system is a > > nightmare waiting to happen. > > I personally don't care about out-of-tree drivers. I know that this is the official stance in the kernel. But out-of-tree drivers do happen on a regular basis, even when developing with the aim of upstreaming. And if a developer builds a minimal kernel to host a CAN driver, without building in-tree hardware CAN drivers, then can-dev will be there but behave differently from can-dev in a full distro. Leading to heisenbugs and wasting time. The source of heisenbugs really are the suggested *hidden* Kconfigs. On another note, is the module accounting overhead in the kernel for two new modules with relatively little code in each, code that almost always is loaded when CAN is used, really worth it? Okay, I think I'm out of 2 cent pieces now :) Max