[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220514131726.55fbbcdb.max@enpas.org>
Date: Sat, 14 May 2022 13:17:26 +0200
From: Max Staudt <max@...as.org>
To: Vincent MAILHOL <mailhol.vincent@...adoo.fr>
Cc: kernel test robot <lkp@...el.com>,
Marc Kleine-Budde <mkl@...gutronix.de>, llvm@...ts.linux.dev,
kbuild-all@...ts.01.org, linux-can@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and
can_skb_headroom_valid to skb.c
On Sat, 14 May 2022 14:16:09 +0900
Vincent MAILHOL <mailhol.vincent@...adoo.fr> wrote:
> OK, so the issue is that VCAN and VXCAN are users of
> can_dropped_invalid_skb() but do not depend on CAN_DEV. Above error
> will appear if CONFIG_CAN_DEV is not set (or if CONFIG_V{,X}CAN is set
> to "yes" and CAN_DEV is set to "module").
> I see three choices here:
> 1. move can_dropped_invalid_skb() outside of drivers/net/can (i.e.
> move it somewhere in net/can).
> 2. split CAN_DEV into one additional sub module: CAN_SKB and add a
> dependency to it in VCAN and VXCAN.
> 3. Add a dependency to CAN_DEV in VCAN and VXCAN
>
> 1. is I think the worse, 2. the best, 3. is the laziest option and is
> kind of acceptable.
> @Marc (and anyone else), what are your thoughts?
I think that having v(x)can depend on can-dev isn't half bad - for the
user, they are CAN devices, anyway, and modprobe does the dependency
resolution magic.
Splitting into too many modules is something I'd avoid because of the
overhead involved.
Max
Powered by blists - more mailing lists