Syscalls that affect resource use: Any sort of object creation: + sys_net_create + sys_container_alloc + sys_gate_create + sys_thread_create + sys_segment_create + sys_segment_copy + sys_as_create Hardlink creation: + sys_self_addref [[ replace with halt-and-copy? ]] + sys_segment_addref Object deletion: + sys_obj_unref Objects changing size: + sys_segment_resize + sys_as_set + anything that puts things in containers -- can resize container [[ so effectively all of the above ]] sys_self_enable_fp Label operations: sys_handle_create sys_gate_enter sys_thread_start sys_self_set_label sys_self_set_clearance *** How to deal with label objects taking up space? Seems like we have to make them explicit then.. Cannot do this -- the rule has to be that space is reserved in the system for every hard link. Thus, since every object has a hard link to its label, every object has to claim space for it. Similar to resource allocation for hard-linked segments. MLTs will be collections of these symlink/blob objects so they don't have any interesting resource properties of their own.. Floating point register state can potentially grow a thread..? Likely punt for now; force user to explicitly enable FP support. --- Probably the right thing to do is to define a resource trap, and trap the thread when it runs out of resources in some container. Pass the container as an argument to the trap handler, and how many more bytes it needs in that container. Actually, traps should only be used for cases when there isn't an explicit error channel to user code. In this case we have a perfectly good return value, and the user syscall wrapper just needs to vector to the resource allocator when it gets -E_RESOURCE; for every operation there is just one container whose resources are being used (hopefully?) so we know what container to grow. Then the only question is knowing how much space we need -- but maybe this doesn't matter very much since we will transfer large amounts of disk space quota anyway.