forked from ~ljy/RK356X_SDK_RELEASE

blame | history | patch | commit | commitdiff
hc
2023-12-11 d2ccde1c8e90d38cee87a1b0309ad2827f3fd30d 
 kernel/Documentation/networking/netdev-FAQ.rst
....@@ -34,8 +34,8 @@
3434 mainline tree from Linus, and ``net-next`` is where the new code goes
3535 for the future release.  You can find the trees here:
3636 
37
-- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
38
-- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
37
+- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
38
+- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
3939 
4040 Q: How often do changes from these trees make it to the mainline Linus tree?
4141 ----------------------------------------------------------------------------
....@@ -110,7 +110,7 @@
110110 Q: How can I tell whether it got merged?
111111 A: Start by looking at the main patchworks queue for netdev:
112112 
113
-  http://patchwork.ozlabs.org/project/netdev/list/
113
+  https://patchwork.kernel.org/project/netdevbpf/list/
114114 
115115 The "State" field will tell you exactly where things are at with your
116116 patch.
....@@ -131,77 +131,26 @@
131131 version that should be applied. If there is any doubt, the maintainer
132132 will reply and ask what should be done.
133133 
134
-Q: How can I tell what patches are queued up for backporting to the various stable releases?
135
---------------------------------------------------------------------------------------------
136
-A: Normally Greg Kroah-Hartman collects stable commits himself, but for
137
-networking, Dave collects up patches he deems critical for the
138
-networking subsystem, and then hands them off to Greg.
134
+Q: I made changes to only a few patches in a patch series should I resend only those changed?
135
+---------------------------------------------------------------------------------------------
136
+A: No, please resend the entire patch series and make sure you do number your
137
+patches such that it is clear this is the latest and greatest set of patches
138
+that can be applied.
139139 
140
-There is a patchworks queue that you can see here:
140
+Q: I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do?
141
+-------------------------------------------------------------------------------------------------------------------------------------------
142
+A: There is no revert possible, once it is pushed out, it stays like that.
143
+Please send incremental versions on top of what has been merged in order to fix
144
+the patches the way they would look like if your latest patch series was to be
145
+merged.
141146 
142
-  http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
143
-
144
-It contains the patches which Dave has selected, but not yet handed off
145
-to Greg.  If Greg already has the patch, then it will be here:
146
-
147
-  https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
148
-
149
-A quick way to find whether the patch is in this stable-queue is to
150
-simply clone the repo, and then git grep the mainline commit ID, e.g.
151
-::
152
-
153
-  stable-queue$ git grep -l 284041ef21fdf2e
154
-  releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
155
-  releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
156
-  releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
157
-  stable/stable-queue$
158
-
159
-Q: I see a network patch and I think it should be backported to stable.
160
------------------------------------------------------------------------
161
-Q: Should I request it via stable@vger.kernel.org like the references in
162
-the kernel's Documentation/process/stable-kernel-rules.rst file say?
163
-A: No, not for networking.  Check the stable queues as per above first
164
-to see if it is already queued.  If not, then send a mail to netdev,
165
-listing the upstream commit ID and why you think it should be a stable
166
-candidate.
167
-
168
-Before you jump to go do the above, do note that the normal stable rules
169
-in :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
170
-still apply.  So you need to explicitly indicate why it is a critical
171
-fix and exactly what users are impacted.  In addition, you need to
172
-convince yourself that you *really* think it has been overlooked,
173
-vs. having been considered and rejected.
174
-
175
-Generally speaking, the longer it has had a chance to "soak" in
176
-mainline, the better the odds that it is an OK candidate for stable.  So
177
-scrambling to request a commit be added the day after it appears should
178
-be avoided.
179
-
180
-Q: I have created a network patch and I think it should be backported to stable.
181
---------------------------------------------------------------------------------
182
-Q: Should I add a Cc: stable@vger.kernel.org like the references in the
183
-kernel's Documentation/ directory say?
184
-A: No.  See above answer.  In short, if you think it really belongs in
185
-stable, then ensure you write a decent commit log that describes who
186
-gets impacted by the bug fix and how it manifests itself, and when the
187
-bug was introduced.  If you do that properly, then the commit will get
188
-handled appropriately and most likely get put in the patchworks stable
189
-queue if it really warrants it.
190
-
191
-If you think there is some valid information relating to it being in
192
-stable that does *not* belong in the commit log, then use the three dash
193
-marker line as described in
194
-:ref:`Documentation/process/submitting-patches.rst <the_canonical_patch_format>`
195
-to temporarily embed that information into the patch that you send.
196
-
197
-Q: Are all networking bug fixes backported to all stable releases?
198
-------------------------------------------------------------------
199
-A: Due to capacity, Dave could only take care of the backports for the
200
-last two stable releases. For earlier stable releases, each stable
201
-branch maintainer is supposed to take care of them. If you find any
202
-patch is missing from an earlier stable branch, please notify
203
-stable@vger.kernel.org with either a commit ID or a formal patch
204
-backported, and CC Dave and other relevant networking developers.
147
+Q: Are there special rules regarding stable submissions on netdev?
148
+---------------------------------------------------------------
149
+While it used to be the case that netdev submissions were not supposed
150
+to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer
151
+the case today. Please follow the standard stable rules in
152
+:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
153
+and make sure you include appropriate Fixes tags!
205154 
206155 Q: Is the comment style convention different for the networking content?
207156 ------------------------------------------------------------------------
....@@ -241,6 +190,32 @@
241190 minimum, your changes should survive an ``allyesconfig`` and an
242191 ``allmodconfig`` build without new warnings or failures.
243192 
193
+Q: How do I post corresponding changes to user space components?
194
+----------------------------------------------------------------
195
+A: User space code exercising kernel features should be posted
196
+alongside kernel patches. This gives reviewers a chance to see
197
+how any new interface is used and how well it works.
198
+
199
+When user space tools reside in the kernel repo itself all changes
200
+should generally come as one series. If series becomes too large
201
+or the user space project is not reviewed on netdev include a link
202
+to a public repo where user space patches can be seen.
203
+
204
+In case user space tooling lives in a separate repository but is
205
+reviewed on netdev  (e.g. patches to `iproute2` tools) kernel and
206
+user space patches should form separate series (threads) when posted
207
+to the mailing list, e.g.::
208
+
209
+  [PATCH net-next 0/3] net: some feature cover letter
210
+   └─ [PATCH net-next 1/3] net: some feature prep
211
+   └─ [PATCH net-next 2/3] net: some feature do it
212
+   └─ [PATCH net-next 3/3] selftest: net: some feature
213
+
214
+  [PATCH iproute2-next] ip: add support for some feature
215
+
216
+Posting as one thread is discouraged because it confuses patchwork
217
+(as of patchwork 2.2.2).
218
+
244219 Q: Any other tips to help ensure my net/net-next patch gets OK'd?
245220 -----------------------------------------------------------------
246221 A: Attention to detail.  Re-read your own work as if you were the