Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <[email protected]>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <[email protected]>' v5.7..master
(Actually letting a shell for loop submit all this stuff for me.)
If there are any URLs to be removed completely
or at least not (just) HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
Sorry again to all maintainers who complained about subject lines.
Now I realized that you want an actually perfect prefixes,
not just subsystem ones.
I tried my best...
And yes, *I could* (at least half-)automate it.
Impossible is nothing! :)
net/sched/sch_cake.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index ebaeec1e5c82..2f6c0daa2337 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -363,7 +363,7 @@ static const u8 bulk_order[] = {1, 0, 2, 3};
#define REC_INV_SQRT_CACHE (16)
static u32 cobalt_rec_inv_sqrt_cache[REC_INV_SQRT_CACHE] = {0};
-/* http://en.wikipedia.org/wiki/Methods_of_computing_square_roots
+/* https://en.wikipedia.org/wiki/Methods_of_computing_square_roots
* new_invsqrt = (invsqrt / 2) * (3 - count * invsqrt^2)
*
* Here, invsqrt is a fixed point number (< 1.0), 32bit mantissa, aka Q0.32
--
2.27.0
Please don't do this "for v5.9" stuff.
There is no precendence for this and it looks like -stable patch
series to just about anyone.
There are well defined, established, ways to write Subject lines for
proper patch submissions.
Please do not invent your own way of doing this. It is very
frustrating for me personally, especially with the amount of
patches I have to process and review, to watch how you wildly
change your patch submission formatting over and over again.
Just do what other developers are doing and you'll be fine. Don't
invent your own way.
I'm ignoring all of your "for v5.9" formatted patches, sorry.
Thanks.