Re: [PATCH net-next 2/3] ppp: unify two channel structs
From: Qingfang Deng
Date: Thu May 07 2026 - 01:53:59 EST
On 2026/5/5 19:16, Paolo Abeni wrote:
On 4/30/26 11:05 AM, Qingfang Deng wrote:This is indeed too big. But how do I split it without breaking the build?
Historically, PPP maintained two separate structures for a channel:This patch is IMHO a bit too big and should be split. Also this kind of
'struct channel' was internal to ppp_generic.c, while 'struct ppp_channel'
was the public interface that drivers were required to embed. This
duplication was redundant and forced drivers to manage the lifecycle of
the public structure.
Unify these two structures into a single 'struct ppp_channel', which is
now internal to ppp_generic.c. Drivers now use a 'ppp_channel_conf'
structure to specify registration parameters and receive an opaque
pointer to the allocated channel.
Key changes:
- ppp_register_channel() and ppp_register_net_channel() now return
a 'struct ppp_channel *' instead of taking a pointer to a driver-
embedded structure.
- 'struct ppp_channel_ops' methods now take the driver's 'private'
pointer directly as their first argument, simplifying driver logic.
- ppp_unregister_channel() now takes the opaque pointer.
- Multilink-specific fields are unified and handled via the new
configuration structure.
This cleanup simplifies the driver interface and makes the channel
lifecycle management more robust by centralizing allocation in the PPP
generic layer.
Assisted-by: Gemini:gemini-3-flash
Signed-off-by: Qingfang Deng <qingfang.deng@xxxxxxxxx>
---
drivers/net/ppp/ppp_async.c | 51 +++++-----
drivers/net/ppp/ppp_generic.c | 161 +++++++++++++++----------------
drivers/net/ppp/ppp_synctty.c | 51 +++++-----
drivers/net/ppp/pppoe.c | 34 ++++---
drivers/net/ppp/pppox.c | 4 +-
drivers/net/ppp/pptp.c | 40 ++++----
drivers/tty/ipwireless/network.c | 30 +++---
include/linux/if_pppox.h | 2 +-
include/linux/ppp_channel.h | 49 ++++++----
net/atm/pppoatm.c | 61 ++++++------
net/l2tp/l2tp_ppp.c | 34 ++++---
11 files changed, 271 insertions(+), 246 deletions(-)
refactor looks very invasive and potentially regression prone. I think
it should include a signficant self-test coverage increase.