About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 22 Oct 2003 - 21:36:03 BST

On Wed, Oct 22, 2003 at 07:03:53PM +0200, Enrico Scholz wrote:
> jack_at_solucorp.qc.ca (Jacques Gelinas) writes:
> >> 1) set\control
> >> 2) get info
> >> 3) get command version.
> >
> > /proc should be used to do most of that.

nope, sysfs might be used for some parts,
but there are advantages and disadvantages ...

> No, it is a pain for userspace tools to generate the control-commands
> and yet more pain to parse the results: there are lots of syscalls
> (open,read,close) involved (which can fail), buffer-sizes can not be
> determined in ahead, int->string and string->int conversions are
> needed, and the buffer itself must be parsed to get the position of
> the values.
> This /proc-parsing method requires a proc-filesystem also, which
> may be missing in chroots. Within vserver-chroots, /proc-parsing
> can make attacks possible when a /proc directory with malicious
> entries will be generated.
> Syscalls are *much* more agreeably for userspace-tools.

my opinion too, and with the syscall switch, the
syscalls/functions are cheap, so I see no reason
for a procfs set, but we will use proc to display
a human readable/script parseable? version of relevant
values ...

> > In the kernel, we only spit the various commands available and
> > their version and userland tools can parse that. We keep the
> > bload out of the kernel.
> Implementing the parsing of 'set' commands would be much more
> bloat IMO...


Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 22 Oct 2003 - 21:42:10 BST by hypermail 2.1.3