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
