From: Sam Vilain (sam_at_vilain.net)
Date: Fri 07 Nov 2003 - 16:44:17 GMT
On Fri, 07 Nov 2003 03:17, Chandra Seetharaman wrote;
<... in the middle of the CKRM core patch...>
#define __NR_tgkill 270
#define __NR_utimes 271
#define __NR_fadvise64_64 272
+#define __NR_set_tag 273
+#define __NR_res_ctrl 274
My, you've picked the same SysCall number as the one that the Linux
Vserver project has reserved!
What a co-incidence, because we should be working together as we're
approaching facets of the same problem :-). We do virtualisation, you
do resource management.
We have 273 set up as a Virtual Server `syscall switch'. Our current
stable development stream that includes the switch is against
2.4.x. Take a look at how we've set up the syscall switch - it's
extensible and forward thinking, and could easily accommodate CKRM's
We currently use this syscall for virtualisation purposes; things like
hiding processes, blocking inter-context signals, limiting bind(),
We've also got a CPU scheduler that works for the O(1) kernel, that
allows you to set the desired CPU usage level for a context with soft
limits, along with a syscall to adjust the priority .
Is there any chance of co-operation here? If you will let us extend
CKRM for virtualisation, we can share the syscall and end up with a
super-duper virtualisation/resource management system for Linux! And
SysAdmins will appreciate coherance between the numbers used for each.
-- Sam Vilain, sam_at_vilain.net
If youve seen one redwood, youve seen them all. RONALD REAGAN
_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver