From: Paolo Abeni <pabeni@redhat.com>
To: Stefan Metzmacher <metze@samba.org>, netdev@vger.kernel.org
Cc: "David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Kuniyuki Iwashima <kuniyu@google.com>,
Willem de Bruijn <willemb@google.com>,
Steve French <smfrench@gmail.com>, Tom Talpey <tom@talpey.com>,
Long Li <longli@microsoft.com>,
Namjae Jeon <linkinjeon@kernel.org>,
Xin Long <lucien.xin@gmail.com>,
linux-kernel@vger.kernel.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org, linux-rdma@vger.kernel.org
Subject: Re: [PATCH] net: define IPPROTO_SMBDIRECT and SOL_SMBDIRECT constants
Date: Thu, 27 Nov 2025 17:34:49 +0100 [thread overview]
Message-ID: <3dd5c950-e3e4-42b8-a40b-f0ee04feb563@redhat.com> (raw)
In-Reply-To: <20251126111407.1786854-1-metze@samba.org>
On 11/26/25 12:14 PM, Stefan Metzmacher wrote:
> In order to avoid conflicts with the addition of IPPROTO_QUIC,
> the patch is based on netdev-next/main + the patch adding
> IPPROTO_QUIC and SOL_QUIC [2].
>
> [2]
> https://lore.kernel.org/quic/0cb58f6fcf35ac988660e42704dae9960744a0a7.1763994509.git.lucien.xin@gmail.com/T/#u
>
> As the numbers of IPPROTO_QUIC and SOL_QUIC are already used
> in various userspace applications it would be good to have
> this merged to netdev-next/main even if the actual
> implementation is still waiting for review.
Let me start from here... Why exactly? such applications will not work
(or at least will not use IPPROTO_QUIC) without the actual protocol
implementation.
Build time issues are much more easily solved with the usual:
#ifndef IPPROTO_*
#define IPPROTO_
#endif
that the application code should still carry for a bit of time (until
all the build hosts kernel headers are updated).
The above considerations also apply to this patch. What is the net
benefit? Why something like the above preprocessor's macros are not enough?
We need at least to see the paired implementation to accept this patch,
and I personally think it would be better to let the IPPROTO definition
and the actual implementation land together.
Cheers,
Paolo
next prev parent reply other threads:[~2025-11-27 16:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 11:14 Stefan Metzmacher
2025-11-27 16:34 ` Paolo Abeni [this message]
2025-11-27 17:47 ` Stefan Metzmacher
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=3dd5c950-e3e4-42b8-a40b-f0ee04feb563@redhat.com \
--to=pabeni@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=lucien.xin@gmail.com \
--cc=metze@samba.org \
--cc=netdev@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
--cc=smfrench@gmail.com \
--cc=tom@talpey.com \
--cc=willemb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®