public inbox for llvm@lists.linux.dev
 help / color / mirror / Atom feed
From: Max Staudt <max@enpas.org>
To: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Cc: kernel test robot <lkp@intel.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	llvm@lists.linux.dev, kbuild-all@lists.01.org,
	linux-can@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c
Date: Sat, 14 May 2022 13:17:26 +0200	[thread overview]
Message-ID: <20220514131726.55fbbcdb.max@enpas.org> (raw)
In-Reply-To: <CAMZ6RqLU-Wg0Cau3cM=QsU-t-7Lyzmo1nJ_VAA4Mbw3u0jnNtw@mail.gmail.com>

On Sat, 14 May 2022 14:16:09 +0900
Vincent MAILHOL <mailhol.vincent@wanadoo.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

      reply	other threads:[~2022-05-14 11:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220513153606.302464-2-mailhol.vincent@wanadoo.fr>
2022-05-14  4:20 ` [PATCH v2 1/2] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c kernel test robot
2022-05-14  5:16   ` Vincent MAILHOL
2022-05-14 11:17     ` Max Staudt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220514131726.55fbbcdb.max@enpas.org \
    --to=max@enpas.org \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=mkl@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox