On Wed, 18 Nov 2020 21:24:53 +0100 Guillaume Nault wrote:
> Here's a high level view of:
> * the protocol,
> * the kernel implementation,
> * the context of this RFC,
> * and a few pointers at the end :)
>
> Hope this helps. I've tried to keep it short. Feel free to ask for
> clarification
On Tue, Nov 10, 2020 at 08:47:40AM -0800, Jakub Kicinski wrote:
> On Tue, 10 Nov 2020 10:28:34 +0100 Guillaume Nault wrote:
> > On Mon, Nov 09, 2020 at 03:52:37PM -0800, Jakub Kicinski wrote:
> > > On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> > > > This small RFC series implements a sug
On Tue, 17 Nov 2020 12:54:22 + Tom Parkin wrote:
> > > I think the question is more about long term maintainance. Do we want
> > > to keep PPP related module self contained, with low maintainance code
> > > (the current proposal)? Or are we willing to modernise the
> > > infrastructure, add sup
On Tue, Nov 17, 2020 at 12:54:22PM +, Tom Parkin wrote:
> On Tue, Nov 10, 2020 at 08:47:40 -0800, Jakub Kicinski wrote:
> > On Tue, 10 Nov 2020 10:28:34 +0100 Guillaume Nault wrote:
> > > I think the question is more about long term maintainance. Do we want
> > > to keep PPP related module sel
On Tue, Nov 10, 2020 at 08:47:40 -0800, Jakub Kicinski wrote:
> On Tue, 10 Nov 2020 10:28:34 +0100 Guillaume Nault wrote:
> > On Mon, Nov 09, 2020 at 03:52:37PM -0800, Jakub Kicinski wrote:
> > > On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> > > > This small RFC series implements a sugg
On Sun, Nov 15, 2020 at 12:59:59 +0100, Guillaume Nault wrote:
> On Tue, Nov 10, 2020 at 11:54:07AM +, Tom Parkin wrote:
> > On Mon, Nov 09, 2020 at 23:51:53 +0100, Guillaume Nault wrote:
> > > BTW, shouldn't we have an "UNBRIDGE" command to remove the bridge
> > > between two channels?
> >
On Tue, Nov 10, 2020 at 11:54:07AM +, Tom Parkin wrote:
> On Mon, Nov 09, 2020 at 23:51:53 +0100, Guillaume Nault wrote:
> > BTW, shouldn't we have an "UNBRIDGE" command to remove the bridge
> > between two channels?
>
> I'm not sure of the usecase for it to be honest. Do you have
> somethin
On Tue, 10 Nov 2020 10:28:34 +0100 Guillaume Nault wrote:
> On Mon, Nov 09, 2020 at 03:52:37PM -0800, Jakub Kicinski wrote:
> > On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> > > This small RFC series implements a suggestion from Guillaume Nault in
> > > response to my previous submission
On Tue, Nov 10, 2020 at 12:42:24PM +, Tom Parkin wrote:
> On Tue, Nov 10, 2020 at 10:28:34 +0100, Guillaume Nault wrote:
> > On Mon, Nov 09, 2020 at 03:52:37PM -0800, Jakub Kicinski wrote:
> > > On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> > > > This small RFC series implements a sug
On Tue, Nov 10, 2020 at 10:28:34 +0100, Guillaume Nault wrote:
> On Mon, Nov 09, 2020 at 03:52:37PM -0800, Jakub Kicinski wrote:
> > On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> > > This small RFC series implements a suggestion from Guillaume Nault in
> > > response to my previous submis
On Mon, Nov 09, 2020 at 23:51:53 +0100, Guillaume Nault wrote:
> > * I believe that the fact we're not explicitly locking anything in the
> >ppp_input path for access to the channel bridge field is OK since:
> >
> > - ppp_input is called from the socket backlog recv
> >
> > - ppp
On Mon, Nov 09, 2020 at 03:52:37PM -0800, Jakub Kicinski wrote:
> On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> > This small RFC series implements a suggestion from Guillaume Nault in
> > response to my previous submission to add an ac/pppoe driver to the l2tp
> > subsystem[1].
> >
> > Fo
On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> This small RFC series implements a suggestion from Guillaume Nault in
> response to my previous submission to add an ac/pppoe driver to the l2tp
> subsystem[1].
>
> Following Guillaume's advice, this series adds an ioctl to the ppp code
> to a
On Fri, Nov 06, 2020 at 06:16:45PM +, Tom Parkin wrote:
> This small RFC series implements a suggestion from Guillaume Nault in
> response to my previous submission to add an ac/pppoe driver to the l2tp
> subsystem[1].
>
> Following Guillaume's advice, this series adds an ioctl to the ppp code
14 matches
Mail list logo