From: Guillaume Nault <gnault@redhat.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
Paul Mackerras <paulus@samba.org>,
"David S. Miller" <davem@davemloft.net>,
linux-ppp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ppp: Add rtnl attribute IFLA_PPP_UNIT_ID for specifying ppp unit id
Date: Thu, 12 Aug 2021 19:12:57 +0000 [thread overview]
Message-ID: <20210812191257.GB10725@pc-23.home> (raw)
In-Reply-To: <20210812140918.lfll55przd4ajtc7@pali>
On Thu, Aug 12, 2021 at 04:09:18PM +0200, Pali Rohár wrote:
> The problem is that ppp from rtnl is of the same class as ppp from
> ioctl. And if you want to use ppp, you still have to use lot of ioctl
> calls as rtnl does not implement them. And these ioctl calls use ppp
> unit id, not interface id / interface name.
Indeed, the netlink api only replaces ioctl(PPPIOCNEWUNIT). It's
technically feasible to implement other ppp unit ioctls with netlink,
but I didn't do that because:
* some of them make no sense,
* netlink wouldn't bring any advantage over ioctl() for these cases
(and ppp is ioctl-centric anyway, so users will have to write
ioctl() calls no matter what).
If there was a bright future for ppp in sight, I'd certainly work on a
new modern ioctl-less api. But in the current situation, that'd be just
feature duplication and code churn.
> So in the end you can use RTM_NEWLINK and then control ppp via ioctls.
> And for controlling you have to known that ppp unit id.
>
> If you are using ppp over serial devices, you can "simplify" it by
> forcing mapping that serial number device matches ppp unit id. And then
> you do not have to use dynamic ids (and need for call PPPIOCGUNIT).
How is dropping a single PPPIOCGUNIT call going to simplify the code
while you have to write netlink message handlers?
> With dynamic unit id allocation (which is currently the only option when
> creating ppp via rtnl) for single ppp connection you need to know:
> * id of serial tty device
> * id of channel bound to tty device
> * id of network interface
> * id of ppp unit bound to network interface
I see you're not working with L2TPv2 :). A few more things you'd need
to add to the list:
* a UDP socket,
* a tunnel id,
* a session id,
* a tunnel file descriptor,
* a session file descriptor,
* a new ioctl() to figure out which channel id is assigned to your
L2TP session,
* a bunch of setsockopt() to configure the whole thing,
* ...
(and I'm not counting the ioctl() calls necessary to set up the channel,
which also apply to your use case).
Really, I'm sorry, but the possibility to drop a single PPPIOCGUNIT
call isn't going to simplify the ppp landscape.
> > As I already proposed, we can add an attribute to make the interface
> > name independant from the unit id.
>
> I agree, that above proposal with a new attribute which makes interface
> name independent from the ppp unit id is a good idea. Probably it should
> have been default rtnl behavior (but now it is too late for changing
> default behavior).
Well, it was the default, until a collegue complained and I accepted to
align the default device name with the original ioctl() behaviour. But
the beauty of netlink is that we can revise this behaviour without
breaking compatibility.
> But prior adding this attribute, we first need a way how to retrieve
> interface name of newly created interface. Which we agreed that
> NLM_F_ECHO for RTM_NEWLINK/NLM_F_CREATE is needed.
Yes, that'd be ideal. That might require quite some work though (I
haven't looked in detail). At last resort, if adding NLM_F_ECHO
support to rtnl proves too hard, it might be possible to add a call to
get the device name associated to a ppp unit file descriptor.
At least know I understand why we had this conversation about
NLM_F_ECHO :).
next prev parent reply other threads:[~2021-08-12 19:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-07 16:37 [PATCH] ppp: Add rtnl attribute IFLA_PPP_UNIT_ID for specifying ppp unit id Pali Rohár
2021-08-09 19:25 ` Jakub Kicinski
2021-08-09 19:31 ` Pali Rohár
2021-08-10 15:39 ` Guillaume Nault
2021-08-10 16:04 ` Pali Rohár
2021-08-11 17:19 ` Guillaume Nault
2021-08-11 17:54 ` Pali Rohár
2021-08-12 9:19 ` Guillaume Nault
2021-08-12 14:09 ` Pali Rohár
2021-08-12 19:12 ` Guillaume Nault [this message]
[not found] ` <BN0P223MB0327A247724B7AE211D2E84EA7F79@BN0P223MB0327.NAMP223.PROD.OUTLOOK.COM>
2021-08-10 17:16 ` Pali Rohár
2021-08-10 18:11 ` James Carlson
2021-08-11 17:38 ` Guillaume Nault
2021-08-11 18:04 ` Pali Rohár
2021-08-12 9:28 ` Guillaume Nault
2021-08-12 13:48 ` Pali Rohár
2021-08-12 18:26 ` Guillaume Nault
2021-08-12 19:04 ` Pali Rohár
2021-08-16 16:11 ` Guillaume Nault
2021-08-16 16:23 ` Pali Rohár
2021-08-17 16:05 ` Guillaume Nault
2021-08-17 16:21 ` Pali Rohár
2022-07-09 12:09 ` Pali Rohár
2022-07-12 17:34 ` Guillaume Nault
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=20210812191257.GB10725@pc-23.home \
--to=gnault@redhat.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ppp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pali@kernel.org \
--cc=paulus@samba.org \
/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).