[1/5] doc: replace nocast-vs-bitwise document with its lore link

Commit Message

Luc Van Oostenryck Aug. 9, 2020, 2:17 p.m. UTC

The nocast-vs-bitwise document was copied here to be sure
to remain accessible but isn't really useful here now because:
1) the original document have also been archived to lore.kernel.org
2) nocast & bitwise have now been documented
3) 2) contains a link to 1)

So, remove this redundant document.

Signed-off-by: Luc Van Oostenryck <[e-mail]>
---
 Documentation/index.rst            |  1 -
 Documentation/nocast-vs-bitwise.md | 43 ------------------------------
 2 files changed, 44 deletions(-)

Patch

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 9c76419ba5dd..cbe0521b7091 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -69,7 +69,6 @@  User documentation
    :maxdepth: 1
 
    annotations
-   nocast-vs-bitwise
 
 Developer documentation
 -----------------------
diff --git a/Documentation/nocast-vs-bitwise.md b/Documentation/nocast-vs-bitwise.md
deleted file mode 100644
index 9ba5a789fc26..000000000000
--- a/Documentation/nocast-vs-bitwise.md
+++ /dev/null
@@ -1,43 +0,0 @@ 
-__nocast vs __bitwise
-=====================
-
-`__nocast` warns about explicit or implicit casting to different types.
-HOWEVER, it doesn't consider two 32-bit integers to be different
-types, so a `__nocast int` type may be returned as a regular `int`
-type and then the `__nocast` is lost.
-
-So `__nocast` on integer types is usually not that powerful. It just
-gets lost too easily. It's more useful for things like pointers. It
-also doesn't warn about the mixing: you can add integers to `__nocast`
-integer types, and it's not really considered anything wrong.
-
-`__bitwise` ends up being a *stronger integer separation*. That one
-doesn't allow you to mix with non-bitwise integers, so now it's much
-harder to lose the type by mistake.
-
-So the basic rule is:
-
-- `__nocast` on its own tends to be more useful for *big* integers
-  that still need to act like integers, but you want to make it much
-  less likely that they get truncated by mistake. So a 64-bit integer
-  that you don't want to mistakenly/silently be returned as `int`, for
-  example. But they mix well with random integer types, so you can add
-  to them etc without using anything special. However, that mixing also
-  means that the `__nocast` really gets lost fairly easily.
-
-- `__bitwise` is for *unique types* that cannot be mixed with other
-  types, and that you'd never want to just use as a random integer (the
-  integer `0` is special, though, and gets silently accepted - it's
-  kind of like `NULL` for pointers). So `gfp_t` or the `safe endianness`
-  types would be `__bitwise`: you can only operate on them by doing
-  specific operations that know about *that* particular type.
-
-Generally, you want `__bitwise` if you are looking for type safety.
-`__nocast` really is pretty weak.
-
-Reference:
-----------
-
-* Linus' e-mail about `__nocast` vs `__bitwise`:
-
-  <https://marc.info/?l=linux-mm&m=133245421127324&w=2>