Commit 472f5975 authored by David S. Miller's avatar David S. Miller

Merge branch 'docs-net-Convert-netdev-FAQ-to-RST'

Tobin C. Harding says:

====================
docs: net: Convert netdev-FAQ to RST

Jon answered all the tree questions on v1 so if you will please take
this through your tree that would be awesome.

v2:
 - Fix typo 'canonical_path_format' (thanks Edward)
 - Add patch fixing references netdev-FAQ
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents d8ad2f31 287f4fa9
...@@ -106,9 +106,9 @@ into the bpf-next tree will make their way into net-next tree. net and ...@@ -106,9 +106,9 @@ into the bpf-next tree will make their way into net-next tree. net and
net-next are both run by David S. Miller. From there, they will go net-next are both run by David S. Miller. From there, they will go
into the kernel mainline tree run by Linus Torvalds. To read up on the into the kernel mainline tree run by Linus Torvalds. To read up on the
process of net and net-next being merged into the mainline tree, see process of net and net-next being merged into the mainline tree, see
the `netdev FAQ`_ under: the :ref:`netdev-FAQ`
`Documentation/networking/netdev-FAQ.txt`_
Occasionally, to prevent merge conflicts, we might send pull requests Occasionally, to prevent merge conflicts, we might send pull requests
to other trees (e.g. tracing) with a small subset of the patches, but to other trees (e.g. tracing) with a small subset of the patches, but
...@@ -125,8 +125,8 @@ request):: ...@@ -125,8 +125,8 @@ request)::
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to? Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
--------------------------------------------------------------------------------- ---------------------------------------------------------------------------------
A: The process is the very same as described in the `netdev FAQ`_, so A: The process is the very same as described in the :ref:`netdev-FAQ`,
please read up on it. The subject line must indicate whether the so please read up on it. The subject line must indicate whether the
patch is a fix or rather "next-like" content in order to let the patch is a fix or rather "next-like" content in order to let the
maintainers know whether it is targeted at bpf or bpf-next. maintainers know whether it is targeted at bpf or bpf-next.
...@@ -184,7 +184,7 @@ ii) run extensive BPF test suite and ...@@ -184,7 +184,7 @@ ii) run extensive BPF test suite and
Once the BPF pull request was accepted by David S. Miller, then Once the BPF pull request was accepted by David S. Miller, then
the patches end up in net or net-next tree, respectively, and the patches end up in net or net-next tree, respectively, and
make their way from there further into mainline. Again, see the make their way from there further into mainline. Again, see the
`netdev FAQ`_ for additional information e.g. on how often they are :ref:`netdev-FAQ` for additional information e.g. on how often they are
merged to mainline. merged to mainline.
Q: How long do I need to wait for feedback on my BPF patches? Q: How long do I need to wait for feedback on my BPF patches?
...@@ -208,7 +208,7 @@ Q: Are patches applied to bpf-next when the merge window is open? ...@@ -208,7 +208,7 @@ Q: Are patches applied to bpf-next when the merge window is open?
----------------------------------------------------------------- -----------------------------------------------------------------
A: For the time when the merge window is open, bpf-next will not be A: For the time when the merge window is open, bpf-next will not be
processed. This is roughly analogous to net-next patch processing, processed. This is roughly analogous to net-next patch processing,
so feel free to read up on the `netdev FAQ`_ about further details. so feel free to read up on the :ref:`netdev-FAQ` about further details.
During those two weeks of merge window, we might ask you to resend During those two weeks of merge window, we might ask you to resend
your patch series once bpf-next is open again. Once Linus released your patch series once bpf-next is open again. Once Linus released
...@@ -372,7 +372,7 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up: ...@@ -372,7 +372,7 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
netdev@vger.kernel.org netdev@vger.kernel.org
The process in general is the same as on netdev itself, see also the The process in general is the same as on netdev itself, see also the
`netdev FAQ`_ document. :ref:`netdev-FAQ`.
Q: Do you also backport to kernels not currently maintained as stable? Q: Do you also backport to kernels not currently maintained as stable?
---------------------------------------------------------------------- ----------------------------------------------------------------------
...@@ -388,9 +388,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well ...@@ -388,9 +388,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
What should I do? What should I do?
A: The same rules apply as with netdev patch submissions in general, see A: The same rules apply as with netdev patch submissions in general, see
`netdev FAQ`_ under: the :ref:`netdev-FAQ`.
`Documentation/networking/netdev-FAQ.txt`_
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
ask the BPF maintainers to queue the patches instead. This can be done ask the BPF maintainers to queue the patches instead. This can be done
...@@ -630,8 +628,7 @@ when: ...@@ -630,8 +628,7 @@ when:
.. Links .. Links
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/ .. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
.. _MAINTAINERS: ../../MAINTAINERS .. _MAINTAINERS: ../../MAINTAINERS
.. _Documentation/networking/netdev-FAQ.txt: ../networking/netdev-FAQ.txt .. _netdev-FAQ: ../networking/netdev-FAQ.rst
.. _netdev FAQ: ../networking/netdev-FAQ.txt
.. _samples/bpf/: ../../samples/bpf/ .. _samples/bpf/: ../../samples/bpf/
.. _selftests: ../../tools/testing/selftests/bpf/ .. _selftests: ../../tools/testing/selftests/bpf/
.. _Documentation/dev-tools/kselftest.rst: .. _Documentation/dev-tools/kselftest.rst:
......
...@@ -138,8 +138,6 @@ multiqueue.txt ...@@ -138,8 +138,6 @@ multiqueue.txt
- HOWTO for multiqueue network device support. - HOWTO for multiqueue network device support.
netconsole.txt netconsole.txt
- The network console module netconsole.ko: configuration and notes. - The network console module netconsole.ko: configuration and notes.
netdev-FAQ.txt
- FAQ describing how to submit net changes to netdev mailing list.
netdev-features.txt netdev-features.txt
- Network interface features API description. - Network interface features API description.
netdevices.txt netdevices.txt
......
...@@ -6,6 +6,7 @@ Contents: ...@@ -6,6 +6,7 @@ Contents:
.. toctree:: .. toctree::
:maxdepth: 2 :maxdepth: 2
netdev-FAQ
af_xdp af_xdp
batman-adv batman-adv
can can
......
This diff is collapsed.
This diff is collapsed.
...@@ -37,7 +37,7 @@ Procedure for submitting patches to the -stable tree ...@@ -37,7 +37,7 @@ Procedure for submitting patches to the -stable tree
- If the patch covers files in net/ or drivers/net please follow netdev stable - If the patch covers files in net/ or drivers/net please follow netdev stable
submission guidelines as described in submission guidelines as described in
Documentation/networking/netdev-FAQ.txt :ref:`Documentation/networking/netdev-FAQ.rst <netdev-FAQ>`
- Security patches should not be handled (solely) by the -stable review - Security patches should not be handled (solely) by the -stable review
process but should follow the procedures in process but should follow the procedures in
:ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`. :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.
......
...@@ -611,6 +611,7 @@ which stable kernel versions should receive your fix. This is the preferred ...@@ -611,6 +611,7 @@ which stable kernel versions should receive your fix. This is the preferred
method for indicating a bug fixed by the patch. See :ref:`describe_changes` method for indicating a bug fixed by the patch. See :ref:`describe_changes`
for more details. for more details.
.. _the_canonical_patch_format:
14) The canonical patch format 14) The canonical patch format
------------------------------ ------------------------------
......
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