From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D661639182D for ; Thu, 16 Apr 2026 08:27:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776328052; cv=none; b=Rex6EwR39FPt6K+VAgaM8xJw1x7wTxjUOR+TQ6LJ83i8Zr4K/SbEmEWerux7mYe8CwBsCGepRzLzR64p1Ig7JGpRe/r/qBNfZNlmZHk4u3wmYYHdB26KVUbMyI2hjtuOaHRNUX33KDIU0EXDmgY6EvJbIJL7Bzs3NVJ/IADRT48= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776328052; c=relaxed/simple; bh=O0kNZNME6liz/PDiFhx17G1oocdPgEZotIhQ2QvF/Sw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=svUVPCmj0DzefaGIBS5SqaEgJvtIRowvk8hPsaioHkO8ZFAxXUnyzVXhhuA9/37U1obVW/PJS7BwpUKnuzKoHXK/RxlFmSlwoP6nchP6htoCJhrogwG9jOlgtEjpmQ5Z6VIku7mSvnh+rsRhj9U+MzJXOAHIYmS5v9Qz7VO96GI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=IzYa+5vX; arc=none smtp.client-ip=91.218.175.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="IzYa+5vX" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1776328049; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=psV3t89J4TYPxkXy1/CDffDJ8IP5u3Jv6+y4DGwPsJ4=; b=IzYa+5vX+NubPHSqYuQNur+6QVDn2L8utATLZdFuy2xbwDKVEyhUc3rzmZL9Bm9FfvDfL2 oJVZvPgDhtEIuNEoX69PGyBy11dCJoHv5peGPIQgSuqqwwcElr0vUiMU8daHOqbqC1U8uL 1yEnstsXcUT4cFkWv/VutHtrwJ5D3wY= From: Qingfang Deng To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan , netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Paul Mackerras , linux-ppp@vger.kernel.org, Jaco Kroon , James Carlson , Qingfang Deng Subject: [RFC net-next 3/3] docs: update ppp_generic.rst for API changes Date: Thu, 16 Apr 2026 16:26:46 +0800 Message-ID: <20260416082656.86963-3-qingfang.deng@linux.dev> In-Reply-To: <20260416082656.86963-1-qingfang.deng@linux.dev> References: <20260416082656.86963-1-qingfang.deng@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Document the new ppp_channel_conf struct and ppp_channel lifecycle management changes. Assisted-by: Gemini:gemini-3-flash Signed-off-by: Qingfang Deng --- Documentation/networking/ppp_generic.rst | 33 ++++++++++-------------- 1 file changed, 13 insertions(+), 20 deletions(-) diff --git a/Documentation/networking/ppp_generic.rst b/Documentation/networking/ppp_generic.rst index 5a10abce5964..8d63f997fb3f 100644 --- a/Documentation/networking/ppp_generic.rst +++ b/Documentation/networking/ppp_generic.rst @@ -124,18 +124,19 @@ presented to the start_xmit() function contain only the 2-byte protocol number and the data, and the skbuffs presented to ppp_input() must be in the same format. -The channel must provide an instance of a ppp_channel struct to -represent the channel. The channel is free to use the ``private`` field -however it wishes. The channel should initialize the ``mtu`` and -``hdrlen`` fields before calling ppp_register_channel() and not change -them until after ppp_unregister_channel() returns. The ``mtu`` field -represents the maximum size of the data part of the PPP frames, that -is, it does not include the 2-byte protocol number. +The channel must provide an instance of a ppp_channel_conf struct to +describe the channel during registration. The generic layer will +allocate a ppp_channel struct and return a pointer to it. The +ppp_channel struct is opaque to the channel driver. The ``mtu`` field +(if multilink is enabled) represents the maximum size of the data part +of the PPP frames, that is, it does not include the 2-byte protocol +number. ppp_channel_update_mtu() can be called by the channel driver +to update the ``mtu`` field once LCP MRU negotiation is complete. If the channel needs some headroom in the skbuffs presented to it for transmission (i.e., some space free in the skbuff data area before the start of the PPP frame), it should set the ``hdrlen`` field of the -ppp_channel struct to the amount of headroom required. The generic +ppp_channel_conf struct to the amount of headroom required. The generic PPP layer will attempt to provide that much headroom but the channel should still check if there is sufficient headroom and copy the skbuff if there isn't. @@ -199,20 +200,12 @@ The PPP generic layer has been designed to be SMP-safe. Locks are used around accesses to the internal data structures where necessary to ensure their integrity. As part of this, the generic layer requires that the channels adhere to certain requirements and in turn -provides certain guarantees to the channels. Essentially the channels -are required to provide the appropriate locking on the ppp_channel -structures that form the basis of the communication between the -channel and the generic layer. This is because the channel provides -the storage for the ppp_channel structure, and so the channel is -required to provide the guarantee that this storage exists and is -valid at the appropriate times. +provides certain guarantees to the channels. The generic layer manages +the ppp_channel object, ensuring it exists and is valid while the +channel is registered. The generic layer requires these guarantees from the channel: -* The ppp_channel object must exist from the time that - ppp_register_channel() is called until after the call to - ppp_unregister_channel() returns. - * No thread may be in a call to any of ppp_input(), ppp_input_error(), ppp_output_wakeup(), ppp_channel_index() or ppp_unit_number() for a channel at the time that ppp_unregister_channel() is called for that @@ -453,4 +446,4 @@ an interface unit are: fragments is disabled. This ioctl is only available if the CONFIG_PPP_MULTILINK option is selected. -Last modified: 7-feb-2002 +Last modified: 16-apr-2026 -- 2.43.0