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 82653C433F5 for ; Wed, 18 May 2022 13:10:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237500AbiERNKy (ORCPT ); Wed, 18 May 2022 09:10:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237519AbiERNKt (ORCPT ); Wed, 18 May 2022 09:10:49 -0400 Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 094C622517; Wed, 18 May 2022 06:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1652879444; s=strato-dkim-0002; d=hartkopp.net; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=6TMF40b1ulLF+Snq+k1FxHMJfQT/QbJmSUwGUPENt/A=; b=MjS6sLULLYotqBREueexxg3tM61MnhbxRILC/AcAgTTW8LJWA5JLXqx/RXsoPYHx9Z 76lIH7sldeDkaBgsvkMursM8nMz0w30DcgE0p1XKajFlctskn7ydBEMavo8VK8uX5CRk 7NRKcY82gYCSx73FsG23C+GFFBySdKGYus7DAC/J62jIJDhwwAL5vG1FXxPR13V9IO4/ pST4Ocf0MbNQ68o4maftQ8CkitzeWNhwZfdwzsRatojM4xAnMyzlJevuU1d2KhtdyEud QWAPfGDDlyh0E1C0WE4EHRLid9fskgjNUGSAmZuQfpugEvnTO6mp5sYG6P53vuUDfTve mQWw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P2MHfkW8eP4Mre39l357AZT/I7AY/7nT2yrDxb8mjG14FZxedJy6qgO1qCHSa1GLptZHusx3hdBqPeOuh2krLEWFUg==" X-RZG-CLASS-ID: mo00 Received: from [IPV6:2a00:6020:1cff:5b00::b82] by smtp.strato.de (RZmta 47.45.0 AUTH) with ESMTPSA id R0691fy4IDAiHUw (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 18 May 2022 15:10:44 +0200 (CEST) Message-ID: <43768ff7-71f8-a6c3-18f8-28609e49eedd@hartkopp.net> Date: Wed, 18 May 2022 15:10:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Content-Language: en-US To: Vincent MAILHOL Cc: Max Staudt , Marc Kleine-Budde , linux-can@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org 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> <20220517143921.08458f2c.max@enpas.org> <0b505b1f-1ee4-5a2c-3bbf-6e9822f78817@hartkopp.net> From: Oliver Hartkopp In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-can@vger.kernel.org On 18.05.22 14:03, Vincent MAILHOL wrote: > I didn't think this would trigger such a passionate discussion! :-D Maybe your change was the drop that let the bucket run over ;-) >> But e.g. the people that are running Linux instances in a cloud only >> using vcan and vxcan would not need to carry the entire infrastructure >> of CAN hardware support and rx-offload. > > Are there really some people running custom builds of the Linux kernel > in a cloud environment? The benefit of saving a few kilobytes by not > having to carry the entire CAN hardware infrastructure is blown away > by the cost of having to maintain a custom build. When looking to the current Kconfig and Makefile content in drivers/net/can(/dev) there is also some CONFIG_CAN_LEDS which "depends on BROKEN" and builds a leds.o from a non existing leds.c ?!? Oh leds.c is in drivers/net/can/leds.c but not in drivers/net/can/dev/leds.c where it could build ... ? So what I would suggest is that we always build a can-dev.ko when a CAN driver is needed. Then we have different options that may be built-in: 1. netlink hw config interface 2. bitrate calculation 3. rx-offload 4. leds E.g. having the netlink interface without bitrate calculation does not make sense to me too. > I perfectly follow the idea to split rx-offload. Integrators building > some custom firmware for an embedded device might want to strip out > any unneeded piece. But I am not convinced by this same argument when > applied to v(x)can. It does. I've seen CAN setups (really more than one or two!) in VMs and container environments that are fed by Ethernet tunnels - sometimes also in embedded devices. > A two level split (with or without rx-offload) is what makes the most > sense to me. > > Regardless, having the three level split is not harmful. And because > there seems to be a consensus on that, I am fine to continue in this > direction. Thanks! Should we remove the extra option for the bitrate calculation then? And what about the LEDS support depending on BROKEN? That was introduced by commit 30f3b42147ba6f ("can: mark led trigger as broken") from Uwe as it seems there were some changes in 2018. Best regards, Oliver