Related: #324, #335.
Orthogonal: whether we need the safe version of these, see #283.

Thinking about the pub(crate) helpers that help us "parse" return values from C functions, I think we can also improve the names for all these helpers:

• They are not constructors, so from_* does not fit too well (i.e. do not confuse with the Error constructors).
• _kernel_ does not add information -- we are also the kernel! Nothing instead (or perhaps _c_ or _bindings_) would be better. I think nothing is OK because these functions are internal to rust/kernel/ and will be relatively well-known, since they will be used by most abstractions, so smaller names are better.

We need names for at least 3 functions:

• decode_ret_ptr() -> Result<*mut T>: Decodes the return value of C functions that return a pointer or an error value (i.e. the C side uses IS_ERR()/ERR_PTR() etc.).
• decode_ret() -> Result: Decodes the return value of C functions that only return 0 on success, but otherwise do not use the positive side.
• decode_ret_value() -> Result<c_uint>: Decodes the return value of C functions that return a positive value on success.
  • Ideally we will specialize this one if some patterns repeat themselves, so that we can directly return the proper Rust-side type (e.g. the unsigned integer is a file descriptor which is then fed into a File, so we could instead have parse_result_fd() or parse_result_file() etc.).

Possible prefixes:

• parse
• interpret
• transform
• to_result
• decode
• ...

Possible middle nouns:

• ret
• result
• return
• c_return
• creturn
• retval
• cretval
• ...

Opinions, suggestions, etc. welcome!