xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: fix locations of several documents that got moved

Browse Source 
The previous patch renamed several files that are cross-referenced
along the Kernel documentation. Adjust the links to point to
the right places.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This commit is contained in:
Mauro Carvalho Chehab
2016-10-18 10:12:27 -02:00
parent 9d85025b04
commit 8c27ceff36
103 changed files with 280 additions and 278 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
Documentation/networking/netdev-FAQ.txt
View File

@@ -136,14 +136,14 @@ A: Normally Greg Kroah-Hartman collects stable commits himself, but
Q: I see a network patch and I think it should be backported to stable.
Should I request it via "stable@vger.kernel.org" like the references in
the kernel's Documentation/stable_kernel_rules.txt file say?
the kernel's Documentation/process/stable-kernel-rules.rst file say?
A: No, not for networking. Check the stable queues as per above 1st to see
if it is already queued. If not, then send a mail to netdev, listing
the upstream commit ID and why you think it should be a stable candidate.
Before you jump to go do the above, do note that the normal stable rules
in Documentation/stable_kernel_rules.txt still apply. So you need to
in Documentation/process/stable-kernel-rules.rst still apply. So you need to
explicitly indicate why it is a critical fix and exactly what users are
impacted. In addition, you need to convince yourself that you _really_
think it has been overlooked, vs. having been considered and rejected.
@@ -165,7 +165,7 @@ A: No. See above answer. In short, if you think it really belongs in
If you think there is some valid information relating to it being in
stable that does _not_ belong in the commit log, then use the three
dash marker line as described in Documentation/SubmittingPatches to
dash marker line as described in Documentation/process/submitting-patches.rst to
temporarily embed that information into the patch that you send.
Q: Someone said that the comment style and coding convention is different
@@ -220,5 +220,5 @@ A: Attention to detail. Re-read your own work as if you were the
If it is your first patch, mail it to yourself so you can test apply
it to an unpatched tree to confirm infrastructure didn't mangle it.
Finally, go back and read Documentation/SubmittingPatches to be
Finally, go back and read Documentation/process/submitting-patches.rst to be
sure you are not repeating some common mistake documented there.