So for objects...all caps go poof means the object is deleted. But if all the caps for a memory frame go poof, the memory effectively has no owner and becomes abandoned and permanently orphaned from the system?
Hmm...what about the master I/O capability? I assume that if that one went, nobody could do I/O? On Thu, Nov 19, 2015 at 3:33 PM, Gerwin Klein <[email protected]> wrote: > Just to make sure we keep the terminology straight: seL4 only has master > capabilities, no master objects. > > The master cap is the cap that you get when you create the object. It > confers full rights to that object. You can copy the cap, i.e. create > derived caps to the same object, potentially with restricted rights, so > that there is still only the one object, but potentially many caps to it. > > If you revoke+delete this master cap, all caps derived from it are > deleted, the object is deleted, and the memory can be reused (if there is > still an untyped capability around that covers that memory, which allows > you to create objects). If you also remove all untyped caps to that memory, > the memory becomes inaccessible to the system. > > In general, an object is deleted and made available for reuse if the last > typed cap to that object is deleted. Memory is available for reuse if there > is an untyped cap that covers that memory (potentially existing children of > that untyped cap might have to be revoked first as well). > > In case of the root thread, it may actually hold the only caps to some > objects in the system. For instance, it might have created a frame and > mapped it into some thread’s address space, but never given the frame cap > to that thread, because it doesn’t want to give the thread any power to > remap, unmap, or share the frame. If you now delete the frame cap in the > root thread, that frame gets unmapped and made available for reuse. If > nobody else has an untyped cap that covers this memory, it becomes > inaccessible. If you keep the frame cap in an inert CNode, you force it to > be static and available for the entire lifetime of the system. If you give > it instead to a trusted OS server personality, it could be reused > dynamically during runtime. Just depends on what you want to do and how you > set things up. > > Cheers, > Gerwin > > On 20 Nov 2015, at 10:06 am, Raymond Jennings <[email protected]> wrote: > > What happens to those master objects if the capabilities go poof? Do they > get locked up forever, or...as I suspect...do they just escheat to the > public as abandoned? > > On Thu, Nov 19, 2015 at 2:50 PM, Gerwin Klein <[email protected]> > wrote: > >> Hi Robbie, >> >> it depends on how your root thread is set up. >> >> If it holds remaining master capabilities to objects in the system, you >> need to make sure those are not destroyed, because deleting them would >> delete those objects. >> >> If you don’t want to hand out these master caps and untyped caps to the >> rest of the system (often there are good reasons for that), you would >> usually leave them in an inert CNode that also has a capability to itself. >> That CNode could just be the root thread CNode. >> >> You can then safely destroy the root thread, e.g. make it suspend itself. >> If nobody else has a capability to it, it can never run again. >> >> Cheers, >> Gerwin >> >> > On 20 Nov 2015, at 3:34 am, Robert VanVossen < >> [email protected]> wrote: >> > >> > Hello, >> > >> > I was wondering if I can safely destroy my application root thread >> after I have >> > setup the capabilities and memory mappings for all of my other threads >> in the >> > system? >> > >> > Thanks, >> > Robbie VanVossen >> > DornerWorks >> > >> > _______________________________________________ >> > Devel mailing list >> > [email protected] >> > https://sel4.systems/lists/listinfo/devel >> >> >> ________________________________ >> >> The information in this e-mail may be confidential and subject to legal >> professional privilege and/or copyright. National ICT Australia Limited >> accepts no liability for any damage caused by this email or its attachments. >> _______________________________________________ >> Devel mailing list >> [email protected] >> https://sel4.systems/lists/listinfo/devel >> > > >
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
