Received-SPF: pass (google.com: domain of linux-kernel+bounces-62476-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 12 Feb 2024 23:21:55 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Tom Parkin <tparkin@katalix.com>
Cc: James Chapman <jchapman@katalix.com>, edumazet@google.com,
	gnault@redhat.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: [PATCHv3] PPPoL2TP: Add more code snippets
Message-ID: <20240212222155.shiacjlqupqoliym@begin>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Tom Parkin <tparkin@katalix.com>,
	James Chapman <jchapman@katalix.com>, edumazet@google.com,
	gnault@redhat.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
References: <20240203223513.f2nfgaamgffz6dno@begin>
 <ZcqMzP1RQye9o4eB@katalix.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZcqMzP1RQye9o4eB@katalix.com>
Organization: I am not organized
User-Agent: NeoMutt/20170609 (1.8.3)

Hello,

Thanks for reviewing, I'll send a v4.

Tom Parkin, le lun. 12 févr. 2024 21:25:32 +0000, a ecrit:
> > +        ret = ioctl(session_fd1, PPPIOCGCHAN, &chindx1);
> > +        if (ret < 0)
> > +                return -errno;
> > +
> > +        ret = ioctl(session_fd2, PPPIOCGCHAN, &chind2x);
> 
> I think we need to be clear here in this example what session_fd1 and
> session_fd2 are, and how they have come to be, since they haven't been
> mentioned in the examples so far.

Right (though it's called session_fd above), I have added explicit input
descriptions.

> I'm not sure whether it helps or not, but when we were working on l2tp-ktest
> initially we had tests for the bridge ioctl.  The tests bridged a PPPoE
> channel with a PPPoL2TP one (which was the original motivation for
> PPPIOCBRIDGECHAN).  The code is here:
> 
> https://github.com/katalix/l2tp-ktest/blob/master/src/util.c#L592
> 
> So in that codebase we have a pppoe fd and a pppol2tp fd, both of
> which have had been attached using PPPIOCATTCHAN.
> 
> We then bridge those two channels using PPPIOCBRIDGECHAN.
> 
> I think the bridging is a complex use-case for what is already quite
> an involved API (lots of file descriptors and indices to keep track
> of!).  So I think the code snippet needs to be as clear as we can make
> it.

Yes, I kept the simple l2tp-to-l2tp example, but mentioned that other
types of ppp channels can also be bridged.  The important part is that
the code snippets show exactly what kind of fd is expected where :)

Samuel