[parisc-linux] syscall number for vserver

[parisc-linux] syscall number for vserver

[Herbert Poetzl]

Hi everyone!

I would like to 'officially' reserve a syscall number
for parisc(64)/vserver ... 

this has been done for i386, x86_64, sparc(64) and s390, 
but not for parisc/parisc64 yet, could you please point
me in the right direction?

x86_64      236     [Andi Kleen]
s390        263     [Martin Schwidefsky]
sparc       267     [David S.Miller]
sparc64     267     [David S.Miller]
i386        273     [Rik/Linus/Andrew]

TIA,
Herbert

PS: see http://linux-vserver.org/ for more details ...

[parisc-linux] syscall number for vserver

[Herbert Poetzl]

Hi everyone!

I would like to 'officially' reserve a syscall number
for parisc(64)/vserver ... 

this has been done for i386, x86_64, sparc(64) and s390, 
but not for parisc/parisc64 yet, could you please point
me in the right direction?

x86_64      236     [Andi Kleen]
s390        263     [Martin Schwidefsky]
sparc       267     [David S.Miller]
sparc64     267     [David S.Miller]
i386        273     [Rik/Linus/Andrew]

TIA,
Herbert

PS: see http://linux-vserver.org/ for more details ...

Re: [parisc-linux] syscall number for vserver

[Christoph Hellwig]

On Wed, Dec 17, 2003 at 11:16:18PM +0100, Herbert Poetzl wrote:
> 
> Hi everyone!
> 
> I would like to 'officially' reserve a syscall number
> for parisc(64)/vserver ... 

The syscall is the typical multiplexer crap, so an actual submission
wouldn't have any chance.  Please fix up your junk beofe trying to
play the reserve a syscall scheme.  This didn't work for afs or
LSM either.

Re: [parisc-linux] syscall number for vserver

[Christoph Hellwig]

On Wed, Dec 17, 2003 at 11:16:18PM +0100, Herbert Poetzl wrote:
> 
> Hi everyone!
> 
> I would like to 'officially' reserve a syscall number
> for parisc(64)/vserver ... 

The syscall is the typical multiplexer crap, so an actual submission
wouldn't have any chance.  Please fix up your junk beofe trying to
play the reserve a syscall scheme.  This didn't work for afs or
LSM either.

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Thu, Dec 18, 2003 at 08:25:06AM +0100, Christoph Hellwig wrote:
> On Wed, Dec 17, 2003 at 11:16:18PM +0100, Herbert Poetzl wrote:
> > 
> > Hi everyone!
> > 
> > I would like to 'officially' reserve a syscall number
> > for parisc(64)/vserver ... 
> 
> The syscall is the typical multiplexer crap, so an actual submission
> wouldn't have any chance.  Please fix up your junk beofe trying to
> play the reserve a syscall scheme.  This didn't work for afs or
> LSM either.

hohoho!

you are a funny guy, and I'm sure you will
explain your statement in all detail ...

just for your information:

vserver folks really do not care whether or not the
syscall is reserved on their architecture, as long 
as it's there, and it will be there anyway, I just 
wanted to be polite and correct, so if you 'think'
we split up the switch just for parisc(64) again, 
then I can assure you, that just won't happen ...

best,
Herbert

PS:

if you are actually interrested _how_ this is done
and _what_ we do to minimize issues, have a look at

 http://vserver.13thfloor.at/Stuff/vswitch.h
 http://vserver.13thfloor.at/Stuff/vswitch.c

some facts:

- the project started with 2 syscalls, and has grown
  to 7-8 syscalls (depending on the version)

- the syscall switch was not my idea, but I have to
  admit, that it simplified development drastically
  (no need to ask 10 people for a new syscall ;)

- we _are_ supporting several different architectures
  and we _are_ trying to avoid issues where possible,
  (for example we use the c99 types for structs)
  
- userspace handles this with a versioned interface


On Sun, Aug 31, 2003 at 10:57:42AM -0400, Rik van Riel wrote:
> How about a sys_vserver multiplexer so we can easily add
> things like setting a new ipv6 root to the interface,
> without needing yet another syscall ?

On Sat, Oct 04, 2003 at 03:31:11PM -0700, David S. Miller wrote:
>>> This interface stinks, system calls should have fixed known types not
>>> depending upon the value of some parameter, anything else is a
>>> disaster waiting to happen ala ioctl().

>> but I have to say, that I see no advantage in
>> using more syscalls, if they have to pass a user
>> space struct anyway ... (not all do)

> Then have a fixed enumeration for the command, and pass in
> as the type argument a union of the various possible structures.
> Then the types are clearly defined and it's much easier to write
> the compat translation layer.

On Sat, Oct 04, 2003 at 04:57:58PM -0700, David S. Miller wrote:
>>> We have like 7 or 8 system calls for posix timers,
>>> so I don't see why we can't have 3 or 4 for vserver
>>> so that we can have a well defined type get passed in
>>> for each specific system call.

>> that was my saying in the first place, please  
>> advise how to proceed on that?
>> (am I running in circles?)

> Ok, I already sent off an email to Linus so that I can have
> a discussion with him about this first.  I'll reply again once
> he replies to me and we discuss things.

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Thu, Dec 18, 2003 at 08:25:06AM +0100, Christoph Hellwig wrote:
> On Wed, Dec 17, 2003 at 11:16:18PM +0100, Herbert Poetzl wrote:
> > 
> > Hi everyone!
> > 
> > I would like to 'officially' reserve a syscall number
> > for parisc(64)/vserver ... 
> 
> The syscall is the typical multiplexer crap, so an actual submission
> wouldn't have any chance.  Please fix up your junk beofe trying to
> play the reserve a syscall scheme.  This didn't work for afs or
> LSM either.

hohoho!

you are a funny guy, and I'm sure you will
explain your statement in all detail ...

just for your information:

vserver folks really do not care whether or not the
syscall is reserved on their architecture, as long 
as it's there, and it will be there anyway, I just 
wanted to be polite and correct, so if you 'think'
we split up the switch just for parisc(64) again, 
then I can assure you, that just won't happen ...

best,
Herbert

PS:

if you are actually interrested _how_ this is done
and _what_ we do to minimize issues, have a look at

 http://vserver.13thfloor.at/Stuff/vswitch.h
 http://vserver.13thfloor.at/Stuff/vswitch.c

some facts:

- the project started with 2 syscalls, and has grown
  to 7-8 syscalls (depending on the version)

- the syscall switch was not my idea, but I have to
  admit, that it simplified development drastically
  (no need to ask 10 people for a new syscall ;)

- we _are_ supporting several different architectures
  and we _are_ trying to avoid issues where possible,
  (for example we use the c99 types for structs)
  
- userspace handles this with a versioned interface


On Sun, Aug 31, 2003 at 10:57:42AM -0400, Rik van Riel wrote:
> How about a sys_vserver multiplexer so we can easily add
> things like setting a new ipv6 root to the interface,
> without needing yet another syscall ?

On Sat, Oct 04, 2003 at 03:31:11PM -0700, David S. Miller wrote:
>>> This interface stinks, system calls should have fixed known types not
>>> depending upon the value of some parameter, anything else is a
>>> disaster waiting to happen ala ioctl().

>> but I have to say, that I see no advantage in
>> using more syscalls, if they have to pass a user
>> space struct anyway ... (not all do)

> Then have a fixed enumeration for the command, and pass in
> as the type argument a union of the various possible structures.
> Then the types are clearly defined and it's much easier to write
> the compat translation layer.

On Sat, Oct 04, 2003 at 04:57:58PM -0700, David S. Miller wrote:
>>> We have like 7 or 8 system calls for posix timers,
>>> so I don't see why we can't have 3 or 4 for vserver
>>> so that we can have a well defined type get passed in
>>> for each specific system call.

>> that was my saying in the first place, please  
>> advise how to proceed on that?
>> (am I running in circles?)

> Ok, I already sent off an email to Linus so that I can have
> a discussion with him about this first.  I'll reply again once
> he replies to me and we discuss things.

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Matthew Wilcox]

On Thu, Dec 18, 2003 at 04:01:29PM +0100, Herbert Poetzl wrote:
> vserver folks really do not care whether or not the
> syscall is reserved on their architecture, as long 
> as it's there, and it will be there anyway, I just 
> wanted to be polite and correct, so if you 'think'
> we split up the switch just for parisc(64) again, 
> then I can assure you, that just won't happen ...

FYI, Christoph does not control syscall allocations on PA-RISC; I do.
I don't yet have a firm opinion on whether we should allocate this
syscall.  I see both sides of this argument, but personally, I believe
sys_vserver is a mistake.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Matthew Wilcox]

On Thu, Dec 18, 2003 at 04:01:29PM +0100, Herbert Poetzl wrote:
> vserver folks really do not care whether or not the
> syscall is reserved on their architecture, as long 
> as it's there, and it will be there anyway, I just 
> wanted to be polite and correct, so if you 'think'
> we split up the switch just for parisc(64) again, 
> then I can assure you, that just won't happen ...

FYI, Christoph does not control syscall allocations on PA-RISC; I do.
I don't yet have a firm opinion on whether we should allocate this
syscall.  I see both sides of this argument, but personally, I believe
sys_vserver is a mistake.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Thu, Dec 18, 2003 at 04:04:50PM +0000, Matthew Wilcox wrote:
> On Thu, Dec 18, 2003 at 04:01:29PM +0100, Herbert Poetzl wrote:
> > vserver folks really do not care whether or not the
> > syscall is reserved on their architecture, as long 
> > as it's there, and it will be there anyway, I just 
> > wanted to be polite and correct, so if you 'think'
> > we split up the switch just for parisc(64) again, 
> > then I can assure you, that just won't happen ...
> 
> FYI, Christoph does not control syscall allocations on PA-RISC; I do.
> I don't yet have a firm opinion on whether we should allocate this
> syscall.  I see both sides of this argument, but personally, I believe
> sys_vserver is a mistake.

thanks for the information, (I almost assumed that,
at least according to 2.6/MAINTAINERS)

maybe you _can_ suggest a _doable_ solution for 
vserver, if so please go ahead, I'm listening ...

personally, I believe that the whole syscall number
allocation per architecture is broken by design, a 
better solution would be to have only one table for
all architectures, automatically blocking ni_syscalls
with strong typed arguments (bitsize), and a simple
way to either version or enable/disable those syscalls

after spending some thoughts on the 'a multiplexer is
a bad thing' argument, I came to the conclusion that,
if well designed, it's probably better than having a
different syscall with differing arguments on every
architecture, especially if the functionality is
completely agnostic regarding architecture ...

best,
Herbert

> -- 
> "Next the statesmen will invent cheap lies, putting the blame upon 
> the nation that is attacked, and every man will be glad of those
> conscience-soothing falsities, and will diligently study them, and refuse
> to examine any refutations of them; and thus he will by and by convince 
> himself that the war is just, and will thank God for the better sleep 
> he enjoys after this process of grotesque self-deception." -- Mark Twain
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Thu, Dec 18, 2003 at 04:04:50PM +0000, Matthew Wilcox wrote:
> On Thu, Dec 18, 2003 at 04:01:29PM +0100, Herbert Poetzl wrote:
> > vserver folks really do not care whether or not the
> > syscall is reserved on their architecture, as long 
> > as it's there, and it will be there anyway, I just 
> > wanted to be polite and correct, so if you 'think'
> > we split up the switch just for parisc(64) again, 
> > then I can assure you, that just won't happen ...
> 
> FYI, Christoph does not control syscall allocations on PA-RISC; I do.
> I don't yet have a firm opinion on whether we should allocate this
> syscall.  I see both sides of this argument, but personally, I believe
> sys_vserver is a mistake.

thanks for the information, (I almost assumed that,
at least according to 2.6/MAINTAINERS)

maybe you _can_ suggest a _doable_ solution for 
vserver, if so please go ahead, I'm listening ...

personally, I believe that the whole syscall number
allocation per architecture is broken by design, a 
better solution would be to have only one table for
all architectures, automatically blocking ni_syscalls
with strong typed arguments (bitsize), and a simple
way to either version or enable/disable those syscalls

after spending some thoughts on the 'a multiplexer is
a bad thing' argument, I came to the conclusion that,
if well designed, it's probably better than having a
different syscall with differing arguments on every
architecture, especially if the functionality is
completely agnostic regarding architecture ...

best,
Herbert

> -- 
> "Next the statesmen will invent cheap lies, putting the blame upon 
> the nation that is attacked, and every man will be glad of those
> conscience-soothing falsities, and will diligently study them, and refuse
> to examine any refutations of them; and thus he will by and by convince 
> himself that the war is just, and will thank God for the better sleep 
> he enjoys after this process of grotesque self-deception." -- Mark Twain
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Grant Grundler]

On Thu, Dec 18, 2003 at 05:28:09PM +0100, Herbert Poetzl wrote:
> personally, I believe that the whole syscall number
> allocation per architecture is broken by design,

No it's definitely not.
Binary compatibility with other OS's is an arch specific problem.

In our case, any chance of support for HPUX would
require reserving HPUX syscall numbers and provide
appropriate wrappers in the kernel to support it.

And I don't see why the value of a syscall matters.
Just use the right header files and it should work on any arch.

grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Grant Grundler]

On Thu, Dec 18, 2003 at 05:28:09PM +0100, Herbert Poetzl wrote:
> personally, I believe that the whole syscall number
> allocation per architecture is broken by design,

No it's definitely not.
Binary compatibility with other OS's is an arch specific problem.

In our case, any chance of support for HPUX would
require reserving HPUX syscall numbers and provide
appropriate wrappers in the kernel to support it.

And I don't see why the value of a syscall matters.
Just use the right header files and it should work on any arch.

grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Thu, Dec 18, 2003 at 12:55:35PM -0700, Grant Grundler wrote:
> On Thu, Dec 18, 2003 at 05:28:09PM +0100, Herbert Poetzl wrote:
> > personally, I believe that the whole syscall number
> > allocation per architecture is broken by design,
> 
> No it's definitely not.

since you removed it from the original context ...

I agree from a technical point of view, but not from 
the developer's perspective (who just want's a syscall 
for whatever arch independant use ...)

> Binary compatibility with other OS's is an arch specific problem.

for sure it is, but I don't see a relation there ...

> In our case, any chance of support for HPUX would
> require reserving HPUX syscall numbers and provide
> appropriate wrappers in the kernel to support it.

so where is the problem, having an additional offset/info
in the macro defining the syscall can handle that, why
has it to be a different numbering for 'linux' syscalls?

> And I don't see why the value of a syscall matters.

it doesn't matter, and it doesn't matter to me ...

> Just use the right header files and it should work on any arch.

right, but getting one syscall for every arch, seems
like a jigsaw puzzle, as the original thread shows ...

best,
Herbert

> grant
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Thu, Dec 18, 2003 at 12:55:35PM -0700, Grant Grundler wrote:
> On Thu, Dec 18, 2003 at 05:28:09PM +0100, Herbert Poetzl wrote:
> > personally, I believe that the whole syscall number
> > allocation per architecture is broken by design,
> 
> No it's definitely not.

since you removed it from the original context ...

I agree from a technical point of view, but not from 
the developer's perspective (who just want's a syscall 
for whatever arch independant use ...)

> Binary compatibility with other OS's is an arch specific problem.

for sure it is, but I don't see a relation there ...

> In our case, any chance of support for HPUX would
> require reserving HPUX syscall numbers and provide
> appropriate wrappers in the kernel to support it.

so where is the problem, having an additional offset/info
in the macro defining the syscall can handle that, why
has it to be a different numbering for 'linux' syscalls?

> And I don't see why the value of a syscall matters.

it doesn't matter, and it doesn't matter to me ...

> Just use the right header files and it should work on any arch.

right, but getting one syscall for every arch, seems
like a jigsaw puzzle, as the original thread shows ...

best,
Herbert

> grant
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Grant Grundler]

On Fri, Dec 19, 2003 at 02:00:35AM +0100, Herbert Poetzl wrote:
...
> I agree from a technical point of view, but not from 
> the developer's perspective (who just want's a syscall 
> for whatever arch independant use ...)

sorry - an "arch independent syscall" sounds like an oxymoron to me.

> > Binary compatibility with other OS's is an arch specific problem.
> 
> for sure it is, but I don't see a relation there ...

ok

> > In our case, any chance of support for HPUX would
> > require reserving HPUX syscall numbers and provide
> > appropriate wrappers in the kernel to support it.
> 
> so where is the problem, having an additional offset/info
> in the macro defining the syscall can handle that, why
> has it to be a different numbering for 'linux' syscalls?

Linux kernel doesn't need of implement any given syscall the same
way for each arch.
gettimeofday/settimeofday are popular ones to re-implement
in glibc with alternative kernel support. performance sensitive
"syscalls" are subject to a high level of customization
given the resources and interest.

> > Just use the right header files and it should work on any arch.
> 
> right, but getting one syscall for every arch, seems
> like a jigsaw puzzle, as the original thread shows ...

ah yes. Open source is self correcting in that regard.
When someone decides it's important to have vserver syscall
implemented on parisc, they can demonstrate it works and
show it's useful.  If it's really arch independent, then
implementing it should be as easy as picking some random
unused __NR_xxx to test with and enabling the kernel config
options, right?

BTW, I visited http://www.linux-vserver.org/ and didn't feel
I understood why it's more useful than say, user mode linux
(another form of virtualization) or vPARs. But I'm no
security expert, just an IO/driver hacker.

grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Grant Grundler]

On Fri, Dec 19, 2003 at 02:00:35AM +0100, Herbert Poetzl wrote:
...
> I agree from a technical point of view, but not from 
> the developer's perspective (who just want's a syscall 
> for whatever arch independant use ...)

sorry - an "arch independent syscall" sounds like an oxymoron to me.

> > Binary compatibility with other OS's is an arch specific problem.
> 
> for sure it is, but I don't see a relation there ...

ok

> > In our case, any chance of support for HPUX would
> > require reserving HPUX syscall numbers and provide
> > appropriate wrappers in the kernel to support it.
> 
> so where is the problem, having an additional offset/info
> in the macro defining the syscall can handle that, why
> has it to be a different numbering for 'linux' syscalls?

Linux kernel doesn't need of implement any given syscall the same
way for each arch.
gettimeofday/settimeofday are popular ones to re-implement
in glibc with alternative kernel support. performance sensitive
"syscalls" are subject to a high level of customization
given the resources and interest.

> > Just use the right header files and it should work on any arch.
> 
> right, but getting one syscall for every arch, seems
> like a jigsaw puzzle, as the original thread shows ...

ah yes. Open source is self correcting in that regard.
When someone decides it's important to have vserver syscall
implemented on parisc, they can demonstrate it works and
show it's useful.  If it's really arch independent, then
implementing it should be as easy as picking some random
unused __NR_xxx to test with and enabling the kernel config
options, right?

BTW, I visited http://www.linux-vserver.org/ and didn't feel
I understood why it's more useful than say, user mode linux
(another form of virtualization) or vPARs. But I'm no
security expert, just an IO/driver hacker.

grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Thu, Dec 18, 2003 at 07:03:52PM -0700, Grant Grundler wrote:
> On Fri, Dec 19, 2003 at 02:00:35AM +0100, Herbert Poetzl wrote:
> ...
> > I agree from a technical point of view, but not from 
> > the developer's perspective (who just want's a syscall 
> > for whatever arch independant use ...)
> 
> sorry - an "arch independent syscall" sounds like an oxymoron to me.

that's probably why most of the syscalls are
implemented outside of linux/arch/* (about 250)

> > > Binary compatibility with other OS's is an arch specific problem.
> > 
> > for sure it is, but I don't see a relation there ...
> 
> ok
> 
> > > In our case, any chance of support for HPUX would
> > > require reserving HPUX syscall numbers and provide
> > > appropriate wrappers in the kernel to support it.
> > 
> > so where is the problem, having an additional offset/info
> > in the macro defining the syscall can handle that, why
> > has it to be a different numbering for 'linux' syscalls?
> 
> Linux kernel doesn't need of implement any given syscall the same
> way for each arch.

sure not, but gettimeofday for example, will
return the current time, and this usually does
not need an architecture specific interface
(for sure it will require an arch specific
implementation ;)

> gettimeofday/settimeofday are popular ones to re-implement
> in glibc with alternative kernel support. performance sensitive
> "syscalls" are subject to a high level of customization
> given the resources and interest.
> 
> > > Just use the right header files and it should work on any arch.
> > 
> > right, but getting one syscall for every arch, seems
> > like a jigsaw puzzle, as the original thread shows ...
> 
> ah yes. Open source is self correcting in that regard.
> When someone decides it's important to have vserver syscall
> implemented on parisc, they can demonstrate it works and
> show it's useful.  

yes ;)

> If it's really arch independent, then implementing it 
> should be as easy as picking some random unused __NR_xxx 
> to test with and enabling the kernel config options, right?

well, yeah, that is what I did to add the parisc(64)
vserver support, except that it doesn't have
a kernel config option yet ;)

> BTW, I visited http://www.linux-vserver.org/ and didn't feel
> I understood why it's more useful than say, user mode linux
> (another form of virtualization) or vPARs. 

hmm, for UML you'll need a kernel for each vps,
which eats up a lot of resources, where vserver
even allow you to share the files between vps

regarding vPARs, I didn't know that they work
for Linux yet, can you give some hints on that?

> But I'm no security expert, just an IO/driver hacker.

security is just one aspect of this project ...
IO/driver hacking is fun sometimes ...

best,
Herbert

> grant
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Thu, Dec 18, 2003 at 07:03:52PM -0700, Grant Grundler wrote:
> On Fri, Dec 19, 2003 at 02:00:35AM +0100, Herbert Poetzl wrote:
> ...
> > I agree from a technical point of view, but not from 
> > the developer's perspective (who just want's a syscall 
> > for whatever arch independant use ...)
> 
> sorry - an "arch independent syscall" sounds like an oxymoron to me.

that's probably why most of the syscalls are
implemented outside of linux/arch/* (about 250)

> > > Binary compatibility with other OS's is an arch specific problem.
> > 
> > for sure it is, but I don't see a relation there ...
> 
> ok
> 
> > > In our case, any chance of support for HPUX would
> > > require reserving HPUX syscall numbers and provide
> > > appropriate wrappers in the kernel to support it.
> > 
> > so where is the problem, having an additional offset/info
> > in the macro defining the syscall can handle that, why
> > has it to be a different numbering for 'linux' syscalls?
> 
> Linux kernel doesn't need of implement any given syscall the same
> way for each arch.

sure not, but gettimeofday for example, will
return the current time, and this usually does
not need an architecture specific interface
(for sure it will require an arch specific
implementation ;)

> gettimeofday/settimeofday are popular ones to re-implement
> in glibc with alternative kernel support. performance sensitive
> "syscalls" are subject to a high level of customization
> given the resources and interest.
> 
> > > Just use the right header files and it should work on any arch.
> > 
> > right, but getting one syscall for every arch, seems
> > like a jigsaw puzzle, as the original thread shows ...
> 
> ah yes. Open source is self correcting in that regard.
> When someone decides it's important to have vserver syscall
> implemented on parisc, they can demonstrate it works and
> show it's useful.  

yes ;)

> If it's really arch independent, then implementing it 
> should be as easy as picking some random unused __NR_xxx 
> to test with and enabling the kernel config options, right?

well, yeah, that is what I did to add the parisc(64)
vserver support, except that it doesn't have
a kernel config option yet ;)

> BTW, I visited http://www.linux-vserver.org/ and didn't feel
> I understood why it's more useful than say, user mode linux
> (another form of virtualization) or vPARs. 

hmm, for UML you'll need a kernel for each vps,
which eats up a lot of resources, where vserver
even allow you to share the files between vps

regarding vPARs, I didn't know that they work
for Linux yet, can you give some hints on that?

> But I'm no security expert, just an IO/driver hacker.

security is just one aspect of this project ...
IO/driver hacking is fun sometimes ...

best,
Herbert

> grant
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Grant Grundler]

On Fri, Dec 19, 2003 at 04:24:56AM +0100, Herbert Poetzl wrote:
...
> sure not, but gettimeofday for example, will
> return the current time, and this usually does
> not need an architecture specific interface

glibc

> (for sure it will require an arch specific
> implementation ;)

possible a different syscall.
Sounds like we agree.

...
> > to test with and enabling the kernel config options, right?
> 
> well, yeah, that is what I did to add the parisc(64)
> vserver support, except that it doesn't have
> a kernel config option yet ;)

That should be part of the patch to enable vserver.

> > BTW, I visited http://www.linux-vserver.org/ and didn't feel
> > I understood why it's more useful than say, user mode linux
> > (another form of virtualization) or vPARs. 
> 
> hmm, for UML you'll need a kernel for each vps,
> which eats up a lot of resources, where vserver
> even allow you to share the files between vps

Has anyone bothered to quantify how much resource?
In general, systems are memory starved, so this sounds
like a good thing.

> regarding vPARs, I didn't know that they work
> for Linux yet, can you give some hints on that?

Several arches are capable of running the OS via a "monitor"
that abstracts the HW (even emulating IO devices depending on
the implementation).  Thus allows several OS instances to run
at the same time.  It's not too different from UML except that
the monitor is "lighter weight" than a Linux kernel host and
can run different OSs (ie not just linux) at the same time.

Search for "vPARs" on www.hp.com if you want more details
on HPUX vPARs support.

grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Grant Grundler]

On Fri, Dec 19, 2003 at 04:24:56AM +0100, Herbert Poetzl wrote:
...
> sure not, but gettimeofday for example, will
> return the current time, and this usually does
> not need an architecture specific interface

glibc

> (for sure it will require an arch specific
> implementation ;)

possible a different syscall.
Sounds like we agree.

...
> > to test with and enabling the kernel config options, right?
> 
> well, yeah, that is what I did to add the parisc(64)
> vserver support, except that it doesn't have
> a kernel config option yet ;)

That should be part of the patch to enable vserver.

> > BTW, I visited http://www.linux-vserver.org/ and didn't feel
> > I understood why it's more useful than say, user mode linux
> > (another form of virtualization) or vPARs. 
> 
> hmm, for UML you'll need a kernel for each vps,
> which eats up a lot of resources, where vserver
> even allow you to share the files between vps

Has anyone bothered to quantify how much resource?
In general, systems are memory starved, so this sounds
like a good thing.

> regarding vPARs, I didn't know that they work
> for Linux yet, can you give some hints on that?

Several arches are capable of running the OS via a "monitor"
that abstracts the HW (even emulating IO devices depending on
the implementation).  Thus allows several OS instances to run
at the same time.  It's not too different from UML except that
the monitor is "lighter weight" than a Linux kernel host and
can run different OSs (ie not just linux) at the same time.

Search for "vPARs" on www.hp.com if you want more details
on HPUX vPARs support.

grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Fri, Dec 19, 2003 at 09:11:34AM -0700, Grant Grundler wrote:
> On Fri, Dec 19, 2003 at 04:24:56AM +0100, Herbert Poetzl wrote:
> ...
> 
> That should be part of the patch to enable vserver.
> 
> > > BTW, I visited http://www.linux-vserver.org/ and didn't feel
> > > I understood why it's more useful than say, user mode linux
> > > (another form of virtualization) or vPARs. 
> > 
> > hmm, for UML you'll need a kernel for each vps,
> > which eats up a lot of resources, where vserver
> > even allow you to share the files between vps
> 
> Has anyone bothered to quantify how much resource?
> In general, systems are memory starved, so this sounds
> like a good thing.

well, just as a small example, a single CPU
2GHz Pentium machine with 1GB RAM works reasonably
well with 30-40 vservers, each one running sshd, 
apache, php, postfix and mysql ...
 
a dual CPU 1.5GHz machine with 2GB RAM can
provide shelter for about 60-80 vservers, with
good responsiveness ...

a test patch for 2.4.23-pa3 can be found at
http://vserver.13thfloor.at/Stuff/patch-2.4.23-pa3-vs1.22.diff
(tools need some tweaking ...)

> > regarding vPARs, I didn't know that they work
> > for Linux yet, can you give some hints on that?
> 
> Search for "vPARs" on www.hp.com if you want more details
> on HPUX vPARs support.

heard of it for HPUX, and it seems that XEN
is somewhat compareable to that, but that didn't
answer my question: are they available for Linux
or 'just' for HPUX?

TIA,
Herbert

> grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Fri, Dec 19, 2003 at 09:11:34AM -0700, Grant Grundler wrote:
> On Fri, Dec 19, 2003 at 04:24:56AM +0100, Herbert Poetzl wrote:
> ...
> 
> That should be part of the patch to enable vserver.
> 
> > > BTW, I visited http://www.linux-vserver.org/ and didn't feel
> > > I understood why it's more useful than say, user mode linux
> > > (another form of virtualization) or vPARs. 
> > 
> > hmm, for UML you'll need a kernel for each vps,
> > which eats up a lot of resources, where vserver
> > even allow you to share the files between vps
> 
> Has anyone bothered to quantify how much resource?
> In general, systems are memory starved, so this sounds
> like a good thing.

well, just as a small example, a single CPU
2GHz Pentium machine with 1GB RAM works reasonably
well with 30-40 vservers, each one running sshd, 
apache, php, postfix and mysql ...
 
a dual CPU 1.5GHz machine with 2GB RAM can
provide shelter for about 60-80 vservers, with
good responsiveness ...

a test patch for 2.4.23-pa3 can be found at
http://vserver.13thfloor.at/Stuff/patch-2.4.23-pa3-vs1.22.diff
(tools need some tweaking ...)

> > regarding vPARs, I didn't know that they work
> > for Linux yet, can you give some hints on that?
> 
> Search for "vPARs" on www.hp.com if you want more details
> on HPUX vPARs support.

heard of it for HPUX, and it seems that XEN
is somewhat compareable to that, but that didn't
answer my question: are they available for Linux
or 'just' for HPUX?

TIA,
Herbert

> grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Grant Grundler]

On Fri, Dec 19, 2003 at 06:03:51PM +0100, Herbert Poetzl wrote:
> heard of it for HPUX, and it seems that XEN
> is somewhat compareable to that, but that didn't
> answer my question: are they available for Linux
> or 'just' for HPUX?

http://www.hp.com/products1/unix/operating/manageability/partitions/virtual_partitions.html

grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Grant Grundler]

On Fri, Dec 19, 2003 at 06:03:51PM +0100, Herbert Poetzl wrote:
> heard of it for HPUX, and it seems that XEN
> is somewhat compareable to that, but that didn't
> answer my question: are they available for Linux
> or 'just' for HPUX?

http://www.hp.com/products1/unix/operating/manageability/partitions/virtual_partitions.html

grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Fri, Dec 19, 2003 at 06:51:21PM -0700, Grant Grundler wrote:
> On Fri, Dec 19, 2003 at 06:03:51PM +0100, Herbert Poetzl wrote:
> > heard of it for HPUX, and it seems that XEN
> > is somewhat compareable to that, but that didn't
> > answer my question: are they available for Linux
> > or 'just' for HPUX?
> 
> http://www.hp.com/products1/unix/operating/manageability/partitions/virtual_partitions.html

okay, so just for HPUX 11i and
Superdome, rp8400, rp7410, rp7405, rp7400, rp5470, rp5405.

thanks,
Herbert

> grant

Re: [Vserver] Re: [parisc-linux] syscall number for vserver

[Herbert Poetzl]

On Fri, Dec 19, 2003 at 06:51:21PM -0700, Grant Grundler wrote:
> On Fri, Dec 19, 2003 at 06:03:51PM +0100, Herbert Poetzl wrote:
> > heard of it for HPUX, and it seems that XEN
> > is somewhat compareable to that, but that didn't
> > answer my question: are they available for Linux
> > or 'just' for HPUX?
> 
> http://www.hp.com/products1/unix/operating/manageability/partitions/virtual_partitions.html

okay, so just for HPUX 11i and
Superdome, rp8400, rp7410, rp7405, rp7400, rp5470, rp5405.

thanks,
Herbert

> grant