rust: Consider whether we want long names for types

[ojeda]

The kernel uses short names for some things, e.g. chrdev, mm, fs, pr_info, etc. On the other hand, we have common functions like platform_device_unregister, not to mention private functions like jornada720_pcmcia_configure_socket.

Rust also employs short names for very common things (e.g. i32, str, Rc, Vec, std, sync...), which makes a lot of sense. On the other hand, namespacing is very common in Rust -- but Rust projects typically avoid fully-qualifying names unless it is ambiguous.

Thus, for commonly used things, it is clear we want short names. However, the question is whether we want to shorten names that are not used too much (or, when used, they do not need to be repeated more than once or twice).

For instance, some may complain FileDescriptorReservation is overly verbose, thus suggesting FileDescReservation or FdReservation (see #313).

Of course, if some name is well-established in the C side, we should go with that. This is more about new names that we will need, e.g. for wrapper types etc.

[ojeda]

Personally, I find long names clearer, especially when dealing with unknown APIs, as long as they are not too common or repetitive.

So e.g. I do not mind things functions like GetLongPathNameW or types like VkCommandBufferBeginInfo, and I prefer them vs. things like getlpathw or VkCmdBgnInfo.