From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Guillaume Nault <gnault@redhat.com>
Cc: James Chapman <jchapman@katalix.com>,
tparkin@katalix.com, edumazet@google.com, davem@davemloft.net,
kuba@kernel.org, pabeni@redhat.com, corbet@lwn.net,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PPPoL2TP: Add more code snippets
Date: Tue, 18 Apr 2023 16:18:20 +0200 [thread overview]
Message-ID: <20230418141820.gxueo5pz2vvre442@begin> (raw)
In-Reply-To: <ZD6dON0gl3DE8mYr@debian>
Guillaume Nault, le mar. 18 avril 2023 15:38:00 +0200, a ecrit:
> On Tue, Apr 18, 2023 at 01:54:09PM +0200, Samuel Thibault wrote:
> > Guillaume Nault, le mar. 18 avril 2023 13:25:38 +0200, a ecrit:
> > > As I said in my previous reply, a simple L2TP example that goes until PPP
> > > channel and unit creation is fine. But any more advanced use of the PPP
> > > API should be documented in the PPP documentation.
> >
> > When it's really advanced, yes. But here it's just about tunnel
> > bridging, which is a very common L2TP thing to do.
>
> I can't undestand why you absolutely want this covered in l2tp.rst.
Because that's where people working on L2TP software will look for it.
> This feature also works on PPPoE.
Then PPPoE documentation shouls also contain mentions of it.
Note (and I'll repeat myself again below) I'm not talking about
*documentation* (which belongs to ppp_generic.rst, but *mentions* of it.
Networking is complex. If each protocol only speaks for itself and
doesn't take the effort of showing how they glue with others, it's hard
for people to grasp the whole ideas.
> Also, it's probably a desirable feature, but certainly not a common
> thing on Linux. This interface was added a bit more than 2 years ago,
> which is really recent considering the age of the code.
Yes, and in ISPs we have been in need for it for something like
decades. I can find RFC drafts around 2000.
Or IPs have just baked their own kernel implementation (xl2tpd,
accel-ppp, etc.)
> Appart from maybe go-l2tp, I don't know of any user.
Because it's basically undocumented from the point of view of L2TP
people.
> > > I mean, these files document the API of their corresponding modules,
> > > their scope should be limitted to that (the PPP and L2TP layers are
> > > really different).
> >
> > I wouldn't call
> >
> > + ret = ioctl(ppp_chan_fd, PPPIOCBRIDGECHAN, &chindx2);
> > + close(ppp_chan_fd);
> > + if (ret < 0)
> > + return -errno;
> >
> > documentation...
>
> The documentation is in ppp_generic.rst.
Yes. and I *definitely* agree on that, and exactly what I'm all talking
about. I'm here just arguing about putting these _*_4 lines of code_*_
example in l2tp.rst, _*_nothing more_*_. See the subject of this thread:
"code snippets". Not documentation.
> Does it really make sense to you to have the doc there
There is basically no doc in what I am proposing.
> and the sample code in l2tp.rst?
Yes, because then L2TP people can be sure to understand how things plug
altogether before writing code...
... instead of having to try various things until understanding how it's
all supposed to fit altogether.
Samuel
next prev parent reply other threads:[~2023-04-18 14:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-16 22:07 [PATCH] PPPoL2TP: Add more code snippets Samuel Thibault
2023-04-16 22:26 ` Dominique Martinet
2023-04-16 22:43 ` Samuel Thibault
2023-04-18 8:03 ` Guillaume Nault
2023-04-18 8:14 ` Guillaume Nault
2023-04-18 8:34 ` Guillaume Nault
2023-04-18 8:53 ` Samuel Thibault
2023-04-18 9:06 ` Guillaume Nault
2023-04-18 9:11 ` Samuel Thibault
2023-04-18 10:17 ` Guillaume Nault
2023-04-18 10:31 ` Samuel Thibault
2023-04-18 11:25 ` Guillaume Nault
2023-04-18 11:54 ` Samuel Thibault
2023-04-18 13:38 ` Guillaume Nault
2023-04-18 14:18 ` Samuel Thibault [this message]
2023-04-19 10:49 ` Tom Parkin
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=20230418141820.gxueo5pz2vvre442@begin \
--to=samuel.thibault@ens-lyon.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gnault@redhat.com \
--cc=jchapman@katalix.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tparkin@katalix.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