Commit 404a5ad7 authored by Randy Dunlap's avatar Randy Dunlap Committed by Jakub Kicinski

Documentation: networking: correct possessive "its"

Change occurrences of "it's" that are possessive to "its"
so that they don't read as "it is".
Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20220829235414.17110-1-rdunlap@infradead.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
parent 8fc29ff3
...@@ -67,7 +67,7 @@ The ``netdevsim`` driver supports rate objects management, which includes: ...@@ -67,7 +67,7 @@ The ``netdevsim`` driver supports rate objects management, which includes:
- setting tx_share and tx_max rate values for any rate object type; - setting tx_share and tx_max rate values for any rate object type;
- setting parent node for any rate object type. - setting parent node for any rate object type.
Rate nodes and it's parameters are exposed in ``netdevsim`` debugfs in RO mode. Rate nodes and their parameters are exposed in ``netdevsim`` debugfs in RO mode.
For example created rate node with name ``some_group``: For example created rate node with name ``some_group``:
.. code:: shell .. code:: shell
......
...@@ -8,7 +8,7 @@ Transmit path guidelines: ...@@ -8,7 +8,7 @@ Transmit path guidelines:
1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under 1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under
any normal circumstances. It is considered a hard error unless any normal circumstances. It is considered a hard error unless
there is no way your device can tell ahead of time when it's there is no way your device can tell ahead of time when its
transmit function will become busy. transmit function will become busy.
Instead it must maintain the queue properly. For example, Instead it must maintain the queue properly. For example,
......
...@@ -11,7 +11,7 @@ Initial Release: ...@@ -11,7 +11,7 @@ Initial Release:
================ ================
This is conceptually very similar to the macvlan driver with one major This is conceptually very similar to the macvlan driver with one major
exception of using L3 for mux-ing /demux-ing among slaves. This property makes exception of using L3 for mux-ing /demux-ing among slaves. This property makes
the master device share the L2 with it's slave devices. I have developed this the master device share the L2 with its slave devices. I have developed this
driver in conjunction with network namespaces and not sure if there is use case driver in conjunction with network namespaces and not sure if there is use case
outside of it. outside of it.
......
...@@ -530,7 +530,7 @@ its tunnel close actions. For L2TPIP sockets, the socket's close ...@@ -530,7 +530,7 @@ its tunnel close actions. For L2TPIP sockets, the socket's close
handler initiates the same tunnel close actions. All sessions are handler initiates the same tunnel close actions. All sessions are
first closed. Each session drops its tunnel ref. When the tunnel ref first closed. Each session drops its tunnel ref. When the tunnel ref
reaches zero, the tunnel puts its socket ref. When the socket is reaches zero, the tunnel puts its socket ref. When the socket is
eventually destroyed, it's sk_destruct finally frees the L2TP tunnel eventually destroyed, its sk_destruct finally frees the L2TP tunnel
context. context.
Sessions Sessions
......
...@@ -159,7 +159,7 @@ tools such as iproute2. ...@@ -159,7 +159,7 @@ tools such as iproute2.
The switchdev driver can know a particular port's position in the topology by The switchdev driver can know a particular port's position in the topology by
monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
bond will see it's upper master change. If that bond is moved into a bridge, bond will see its upper master change. If that bond is moved into a bridge,
the bond's upper master will change. And so on. The driver will track such the bond's upper master will change. And so on. The driver will track such
movements to know what position a port is in in the overall topology by movements to know what position a port is in in the overall topology by
registering for netdevice events and acting on NETDEV_CHANGEUPPER. registering for netdevice events and acting on NETDEV_CHANGEUPPER.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment