From: Guillaume Nault <g.nault@alphalink.fr>
To: Sedat Dilek <sedat.dilek@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>
Subject: Re: [Linux-v4.4-LTS] ppp: Backport of rtnetlink device handling
Date: Fri, 8 Jan 2016 12:54:35 +0100 [thread overview]
Message-ID: <20160108115435.GT18510@alphalink.fr> (raw)
In-Reply-To: <CA+icZUWrK+jO7PBkvRqHQoNJEDsGgzHnM1fod+zzXdKXWHdHCg@mail.gmail.com>
On Fri, Jan 08, 2016 at 10:28:39AM +0100, Sedat Dilek wrote:
> On Mon, Jan 4, 2016 at 1:55 PM, Guillaume Nault <g.nault@alphalink.fr> wrote:
> > On Mon, Jan 04, 2016 at 08:47:30AM +0100, Sedat Dilek wrote:
> >> Hi Guillaume,
> >>
> >> which patches do I need to backport "ppp: rtnetlink device handling"
> >> to Linux v4.4 which will be a LongTerm-Supported (LTS) Linux-kernel
> >> [0]?
> >>
> > Quite frankly, backporting this series doesn't look like a good idea.
> > It only provides a new ABI for creating ppp devices and your control
> > plane most likely hasn't been updated to use it. So it won't bring any
> > benefit.
> >
>
> What do you mean by "control plane"?
>
For the purpose of this discussion, I mean the PPP daemon running in
user space (programs like pppd or accel-ppp).
They implement control protocols like LCP, authentication and various
NCPs, used to negociate PPP encapsulation parameters. They also have to
report on these parameters to the kernel, so that it can properly
handle data exchanged over the established PPP connections. This
generally includes creating a ppp device.
My patch set allows user space to create ppp devices using rtnetlink,
which is more flexible than the current PPP specific ioctl(). But the
PPP daemon needs to be updated or it won't know about the new rtnetlink
and will continue to use the ioctl (which is fine as long as the added
features brought by rtnetlink aren't necessary). That's why I wonder
why do you want to backport this series. I brings no value if user
space isn't able to take advantage of PPP's rtnetlink API.
FYI, the plan is to use the rtnl interface to handle things like
network isolation (with network namespaces) and deterministic ppp
device names in accel-ppp.
> Does anything speak against to have these patches for upcoming Linux v4.5?
> AFAICS, the merge-window will open next week.
>
The patch set has been deferred due to lack of external reviews. I'll
repost after the merge window, so that interested people will have
enough time to comment on it. Therefore it won't be in v4.5. If
everything goes fine with the new submission, it could go into v4.6.
prev parent reply other threads:[~2016-01-08 11:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-04 7:47 [Linux-v4.4-LTS] ppp: Backport of rtnetlink device handling Sedat Dilek
2016-01-04 12:55 ` Guillaume Nault
2016-01-08 9:28 ` Sedat Dilek
2016-01-08 11:54 ` Guillaume Nault [this message]
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=20160108115435.GT18510@alphalink.fr \
--to=g.nault@alphalink.fr \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=sedat.dilek@gmail.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;
as well as URLs for NNTP newsgroup(s).