[seL4] Re: More about Objects (was: General Question On Object Methods)

On 11 Sep 2024, at 00:18, Indan Zupancic wrote:

I'd like to improve the manual to make the above clearer, but not sure how to approach it. Call everything an object, even if it doesn't require state? Does that make things clearer or more confusing? The manual sidesteps the issue by not really mentioning it at all currently. Or call everything a resource and only resources that require storage objects? Or call the stateless ones kernel services and make an explicit list of them? But in a sense it's an implementation detail whether something needs state and whether that fits in the cap or not, so why call it differently?

There is always a difference between an object and the cap to the object, no matter if the object is a memory-backed object or a pseudo object. The only time there is no observable difference (where it’s just an implementation detail) is if there exists exactly one cap to the object. The difference is similar to the difference between memory and a point to that memory. When you copy a pointer, it still points to the same memory, and changes in that memory are observable via both (then aliased) pointers. Same for caps and objects. While the manual currently is attempting to shortcut this difference and mostly just talks about objects, I think it is important to make the difference explicit even though it does sound cumbersome to spell it out each time. It is also the case that almost all caps in seL4 carry additional information (for instance access rights). Two copies of a cap to the same object can have different access rights, no matter if that object is memory-backed or not. So, from my side the important distinction to make is between cap and object. Some objects need memory resources, some don’t. We could call those pseudo objects, but I think that distinction is less important. And we should decide whether we are invoking caps or objects. That part doesn’t really matter, so I’m sure there will be strong opinions about it ;-). I think it makes sense to say that we are invoking object methods because people are familiar with that concept from OO, and to do that you need to present a cap to the object, which may provide additional state (access rights, mapping info, etc). This is the same for all kinds of objects. Cheers, Gerwin