Dedicated flag instead of BUS1_HANDLE_INVALID about bus1

[dvdhrm]

The kernel is not allowed to allocate or reserve IDs in the user's namespace, but 0 would be exactly that. Hence, we went with -1. Care to elaborate why 0 would be better?

[dvdhrm]

Also, why is it wrong to set the REMOTE flag on the invalid handle?

[l0kod]

Hum, an invalid handle is then a remote and a managed handle. I didn't thought that this flags were meaningful if an handle was invalid. This code bus1-rust/bus1-rs@de5a826 is then wrong, right?

Setting all bits to 1 is the same as setting the managed and remote flags (2 bits), plus having an ID. Because of the invalid handle exception, the handle ID is in fact not 62 bits but 61 bits, which seems weird. I think it would be clearer to have a dedicated/documented bit for this exception.

In a userland code, would you check either if the handle is invalid and/or managed?

[dvdhrm]

So conceptually there is only a single ID namespace, and it is managed by the kernel. Whenever you create a node, the kernel allocates a new ID for you, which will never be re-used, even if you destroy the node (i.e., the ID namespace is not sparse, unlike FD numbers). This ID uniquely identifies your object, and it is a 64bit ID, completely opaque to user-space. That is, do not treat it as a 62bit ID with flags! The namespace is kernel managed, and the kernel gives you the guarantee that an ID is never re-used. Ever.

Additionally, the kernel gives you the following guarantees: Every ID it allocates has the LSB set, and it never allocates -1. You can safely rely on this. But you should never put any other assumptions on the IDs the kernel returns. They're opaque.

The problem with this approach was that user-space now has to do ID lookups manually on every message they receive, even though the kernel technically does that already. Hence, we provide a separate ID namespace for user-space to pick IDs from whenever they create a node. This ID namespace has the LSB not set. Furthermore, this ID namespace is fully under user-space control. They can decide whether to use the same logic as the kernel (simply increment a counter for each new ID you allocate), or to implement a sparse-namespace like FDs, or to simply pass memory pointers unchanged. The last part is particularly interesting for C programmers. Pointers never have the LSB set (they're aligned), hence you can just pass in pointers to the kernel, and the kernel returns them to you whenever you retrieve a message.

I cannot tell you how to design your Rust accessors, since this is a design decision. Preferably you would not deal with IDs at all, but instead provide real Rust objects to the user. But I am not to tell you how to do this. Just as an example: It is completely valid in C to malloc() an object and pass that pointer to a bus1 ioctl. It will end up as unmanaged ID of a local node of the peer.

Whenever you end up checking whether the invalid ID is managed or remote, I would assert you are doing something wrong, since this is not an interesting question to ask. That situation should not happen. This is like invoking member functions of your class on a NULL pointer. It is simply undefined.
You are free to avoid NULL pointers and instead have dummy objects, but then you are also responsible to decide how that dummy behaves. I cannot decide that for you, without knowing the overall design of the API.

[l0kod]

Thanks for this in-depth explanation!

cc @Siosm