From: Jakub Kicinski <kuba@kernel.org>
To: Mat Martineau <mathew.j.martineau@linux.intel.com>
Cc: netdev@vger.kernel.org, Ossama Othman <ossama.othman@intel.com>,
davem@davemloft.net, pabeni@redhat.com, edumazet@google.com,
matthieu.baerts@tessares.net, mptcp@lists.linux.dev
Subject: Re: [PATCH net-next 1/2] mptcp: fix conflict with <netinet/in.h>
Date: Fri, 10 Jun 2022 11:16:07 -0700 [thread overview]
Message-ID: <20220610111607.38b003e1@kernel.org> (raw)
In-Reply-To: <d4c74484-da9-8af3-e25b-93de29443840@linux.intel.com>
On Fri, 10 Jun 2022 11:00:28 -0700 (PDT) Mat Martineau wrote:
> This is a minor "fix" to be sure, which I thought did not meet the bar for
> net and therefore submitted for net-next. It's not prep for another
> change, it's something Ossama and I noticed when doing code review for a
> userspace program that included the header. There's no problem with kernel
> compilation, and there's also no issue if the userspace program happens to
> include netinet/in.h before linux/mptcp.h
>
>
> If my threshold for the net branch is too high, I have no objection to
> having this patch applied there and will recalibrate :)
>
> Do you prefer to have no Fixes: tags in net-next, or did that just seem
> ambiguous in this case?
The important point is that the middle ground of marking things as fixes
and at the same time putting them in -next, to still get them
backported but with an extended settling time -- that middle ground
does not exist.
If we look at the patch from the "do we want it backported or not"
perspective I think the answer is yes, hence I'd lean towards net.
If you think it doesn't matter enough for backport - we can drop the
fixes tag and go with net-next. Unfortunately I don't have enough
direct experience to tell how annoying this will be to the user space.
netinet/in.h vs linux/in.h is a mess :(
next prev parent reply other threads:[~2022-06-10 18:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-08 19:19 [PATCH net-next 0/2] mptcp: Header fixups Mat Martineau
2022-06-08 19:19 ` [PATCH net-next 1/2] mptcp: fix conflict with <netinet/in.h> Mat Martineau
2022-06-10 5:59 ` Jakub Kicinski
2022-06-10 18:00 ` Mat Martineau
2022-06-10 18:16 ` Jakub Kicinski [this message]
2022-06-10 19:59 ` Mat Martineau
2022-06-08 19:19 ` [PATCH net-next 2/2] mptcp: move MPTCPOPT_HMAC_LEN to net/mptcp.h Mat Martineau
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=20220610111607.38b003e1@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=mathew.j.martineau@linux.intel.com \
--cc=matthieu.baerts@tessares.net \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=ossama.othman@intel.com \
--cc=pabeni@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.