Existing sentence on cross-compilation that mentions ppc64 does not
make much sense in today's perspective.
Expand it for the benefits of testing against architectures of
different word sizes and endianness.
Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
---
v2: Split out change in the English doc from v1 [1].
Keep Randy's Rb tag (as it was meant for the change in English doc).
[1] https://lore.kernel.org/20250128102805.112691-2-akiyks@xxxxxxxxx/
--
Documentation/process/submit-checklist.rst | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst
index e531dd504b6c..88b6358258d7 100644
--- a/Documentation/process/submit-checklist.rst
+++ b/Documentation/process/submit-checklist.rst
@@ -91,9 +91,12 @@ Build your code
fix any issues.
2) Builds on multiple CPU architectures by using local cross-compile tools
- or some other build farm. Note that ppc64 is a good architecture for
- cross-compilation checking because it tends to use ``unsigned long`` for
- 64-bit quantities.
+ or some other build farm.
+ Note that testing against architectures of different word sizes
+ (32- and 64-bit) and different endianness (big- and little-) is effective
+ in catching various portability issues due to false assumptions on
+ representable quantity range, data alignment, or endianness, among
+ others.
3) Newly-added code has been compiled with ``gcc -W`` (use
``make KCFLAGS=-W``). This will generate lots of noise, but is good
base-commit: 35ddd9f3c132a36856f58088bab06e873c1af871
--
2.34.1
