On 23 Sep 2024, at 12:05, Indan Zupancic wrote:
On 2024-09-23 09:53, Gerwin Klein wrote:
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.
The big shortcut is not mentioning pseudo objects at all currently.
Right, I agree that this needs to change.
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.
That is totally different, access rights are properties of the cap, not the object they point to.
That is clear to everyone and doesn't cause confusion. It's a concept people are familiar with.
I’ll concede that people are familiar with it and therefore not confused, but it is cap state :-) The other cap state is also not for properties of the object the cap points to. That’s probably where the main confusion is, because it sounds like object state. Maybe one analogy is that it is state of a "view" of the object.
What does make things weird is if object state is stored in caps, because that causes for the user unexpected limitation to what you can do with the caps.
Hm, I think it comes down to a question of design perspective in the end.
In terms of behaviour, there is no object state stored in caps in seL4, it’s always been cap state. You fundamentally can’t really store object state in caps, because caps and objects are observationally different — to change actual object state stored in caps you’d have to find all caps for that object and change it there as well.
But you can choose to stretch the concept of capability and represent an additional concept with a cap, usually something that is similar to authority and where you might have multiple different views to the same object.
E.g. the mapping info for a page is where the concept of "cap" is stretched a little. The mapping info is a property of the mapping, not of the frame object the cap points to. I.e. the mapping is represented by the cap, not the frame object. You could choose to not represent the mapping with a cap, and instead use a new kind of object or some other mechanism (that’s where it’s a question of design perspective), but the cap state is not trying to represent object state of the frame object. It’s something in addition to the object that can be different in each cap to the object.
Because frames can be mapped in multiple locations and address spaces, and all these mappings point to the same frame and represent authority to read/write etc, modelling that situation as state in the cap was a reasonable fit, but it does stretch the concept a bit, because it’s now more than just pointer + authority.
The restrictions on copying are mostly not because of the cap state (some are), but because of the limited depth of the capability derivation tree (CDT). If we added another pointer to all caps (which would double cap size), the CDT could be a proper tree and we could remove a lot of these strange restrictions. Currently the cap state sometimes doubles as indication on which level in the CDT a cap is, and that’s where a lot of the copying restrictions come in.
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.
In that case I'll add all the missing objects to the Kernel Objects chapter.
👍
Cheers,
Gerwin
