From: Alex Lyashkov (shadow_at_psoft.net)
Date: Tue 27 May 2003 - 17:15:21 BST
sorry for unanswered mail. I test RSS limit, and after testers answer - i
> Suggestions for readjustments:
> - context creation/destruction should be independant
> of the actual processes (within the context)
> what I mean: create a context, set its properties
> (limits, rootpath, capabilities, ...), THEN fork
> some process into this context ...
hm.. no problem. add one function to new_s_context syscall.
it function must call alloc_s_context for created context with default
assigneds. Examle this - read inode from fs.
> - vroot (chroot path), capabilites and limits should
> become implicit features of a context
hm.. i think if add check contexts access in namei.c:vfs_permission (as check
in Herbert quotas) it not need add hack "dir 000" for disable escape from
> - chroot jail (and the permissions)
> - vserver root path (location)
> - quota files & support
> - disk limits (virtual on shared partition)
yes. but if vps have only one partition. if need more one partions in vps have
1) map all partitions to one virtual. but we can add per partions limits.
2) add list for maping vps:partion:super_block to
all ways need change little code - functions
> - capability issues (venter vs. native)
hm. if task entered to context - all lmits for this task switched to context
limits. or you speak about other ?
> - process handling (freeze/stop/kill a vs)
on snapshot. CPU QoS beetwen context in process.
> - accounting/statistics across vs reboot
statistics save from kernel and restored on start.
> - networking (interfaces, iptables, ...)
devices, iptables - yes.
network packet scheduler - not.
network QoS beetwen context in process.
> - scheduling
scheduling per context ? as "Fair CPU scheduler" in ASPCompleate ?
I work on this way.
-- With best regards, Alex