From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Tue 23 Sep 2003 - 13:53:03 BST
On Tue, Sep 23, 2003 at 07:54:13AM -0400, Rik van Riel wrote:
> On Tue, 23 Sep 2003, Sam Vilain wrote:
>
> > Excellent, so we'd take the problem of allocating a syscall, which
> > translates to performing an action based on the value of a CPU
>
> > Seriously, though - I don't think this is necessarily a good idea
>
> The problem is that currently vserver has NO syscalls
> allocated to it and that Linus would be reluctant to
> hand out half a dozen syscalls for a special application
> like vserver ...
If I look at the syscall table in 2.6 I see
sys_io 5 syscalls
sys_epoll 3 syscalls
sys_timer 5 syscalls
sys_clock 4 syscalls
and all of those above 240, so I guess it shouldn't
be too hard to get one or two syscalls above 270 ...
look for the xattr stuff, it uses 12 (in words twelve)
syscalls in the range 225-240 ...
> Also, in order to get vserver merged in the upstream
> kernel or in distros, it will need to get an official
> syscall number.
maybe if we cut out everything and just do a CLONE_NS
in userspace, we have an excellent chance of getting
merged (100% at 0% changes to the kernel) ...
sorry I guess some of us don't want to merge at any cost ;)
in my opinion, we should try to get one or two syscalls
reserved for 'virtual context operations' one for
control operations, the other for context switches
if linus/andrew/marcello don't want this stuff in, so
be it, if they don't want to reserve any syscalls for
this, we'll continue to update the syscall numbers ...
best,
Herbert
> Rik
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan