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 14DBEC433F5 for ; Tue, 17 May 2022 13:43:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244706AbiEQNnH (ORCPT ); Tue, 17 May 2022 09:43:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240623AbiEQNnG (ORCPT ); Tue, 17 May 2022 09:43:06 -0400 Received: from mail.enpas.org (zhong.enpas.org [IPv6:2a03:4000:2:537::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CE37A4B1F3; Tue, 17 May 2022 06:43:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.enpas.org (Postfix) with ESMTPSA id B6671FF88D; Tue, 17 May 2022 13:43:03 +0000 (UTC) Date: Tue, 17 May 2022 15:43:01 +0200 From: Max Staudt To: Oliver Hartkopp Cc: Marc Kleine-Budde , 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: <20220517154301.5bf99ba9.max@enpas.org> In-Reply-To: <0b505b1f-1ee4-5a2c-3bbf-6e9822f78817@hartkopp.net> 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> 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 15:35:03 +0200 Oliver Hartkopp wrote: > Oh, I didn't want to introduce two new kernel modules but to have > can_dev in different 'feature levels'. Which I agree is a nice idea, as long as heisenbugs can be avoided :) (as for the separate modules vs. feature levels of can-dev - sorry, my two paragraphs were each referring to a different idea. I mixed them into one single email...) Maybe the can-skb and rx-offload parts could be a *visible* sub-option of can-dev in Kconfig, which is normally optional, but immediately force-selected once a CAN HW driver is selected? > 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. Out of curiosity, do you have an example use case for this vcan cloud setup? I can't dream one up... Max