Documentation/networking/ppp_generic.rst
Source file repositories/reference/linux-study-clean/Documentation/networking/ppp_generic.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/networking/ppp_generic.rst- Extension
.rst- Size
- 21968 bytes
- Lines
- 457
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
========================================
PPP Generic Driver and Channel Interface
========================================
Paul Mackerras
paulus@samba.org
7 Feb 2002
The generic PPP driver in linux-2.4 provides an implementation of the
functionality which is of use in any PPP implementation, including:
* the network interface unit (ppp0 etc.)
* the interface to the networking code
* PPP multilink: splitting datagrams between multiple links, and
ordering and combining received fragments
* the interface to pppd, via a /dev/ppp character device
* packet compression and decompression
* TCP/IP header compression and decompression
* detecting network traffic for demand dialling and for idle timeouts
* simple packet filtering
For sending and receiving PPP frames, the generic PPP driver calls on
the services of PPP ``channels``. A PPP channel encapsulates a
mechanism for transporting PPP frames from one machine to another. A
PPP channel implementation can be arbitrarily complex internally but
has a very simple interface with the generic PPP code: it merely has
to be able to send PPP frames, receive PPP frames, and optionally
handle ioctl requests. Currently there are PPP channel
implementations for asynchronous serial ports, synchronous serial
ports, and for PPP over ethernet.
This architecture makes it possible to implement PPP multilink in a
natural and straightforward way, by allowing more than one channel to
be linked to each ppp network interface unit. The generic layer is
responsible for splitting datagrams on transmit and recombining them
on receive.
PPP channel API
---------------
See include/linux/ppp_channel.h for the declaration of the types and
functions used to communicate between the generic PPP layer and PPP
channels.
Each channel has to provide two functions to the generic PPP layer,
via the ppp_channel.ops pointer:
* start_xmit() is called by the generic layer when it has a frame to
send. The channel has the option of rejecting the frame for
flow-control reasons. In this case, start_xmit() should return 0
and the channel should call the ppp_output_wakeup() function at a
later time when it can accept frames again, and the generic layer
will then attempt to retransmit the rejected frame(s). If the frame
is accepted, the start_xmit() function should return 1.
* ioctl() provides an interface which can be used by a user-space
program to control aspects of the channel's behaviour. This
procedure will be called when a user-space program does an ioctl
system call on an instance of /dev/ppp which is bound to the
channel. (Usually it would only be pppd which would do this.)
The generic PPP layer provides seven functions to channels:
* ppp_register_channel() is called when a channel has been created, to
notify the PPP generic layer of its presence. For example, setting
a serial port to the PPPDISC line discipline causes the ppp_async
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.