Re: NEWB: How to get started on writing new client?

Andrea Arcangeli wrote:
>> I don't mind the management stuff done in Python, but for performance
>> reasons, I have some C++ code to run.  Is this possible?
> 
> Ok, the bytecode crunching the numbers at 100% cpu load must be
> machine bytecode at this point because of the seccomp restriction. C++
> may also work as long as the statically linked binary object doesn't
> grow too much and as long as the c++ libs don't call into forbidden
> syscalls.

OK.  I think I need a seccomp primer.  Any pointers?  I'm puzzled by the
term "bytecode".  From my reading of the makefiles, buyer clients are
regular x86 (or PPC) machine code, not requiring any run-time
interpretation until a system call is made.  Am I mistaken?  I think the
term bytecode can be unfair to seccomp:  the clients run full speed.

Can seccomp code be multi-threaded?  A corollary question:  if a seller
is selling time on his box, is he selling one core or all the cores
(i.e. can he have multiple simultaneous buyers?)


> ...

> An example of this will be povray. Povray will likely talk through a
> local tcp socket to the buy client. The buy client is the python
> apy.py, while the povray sever will be C. The Povray client is C too
> but under seccomp.
> 
> povray C server ->
>        cpushare buy client python-twisted ->
>        		internet ->
> 			 cpushare sell client python twisted
> 			 	  -> povray client machine bytecode under seccomp

That's very useful.  Thanks.

I think the usefulness of your platform will depend on how capable the
seccomp jail is.  Otherwise, the full OS virtualization approach (ala
EC2) I think will win.

For example, in a previous e-mail, you note that CPUShare doesn't allow
any local storage at this point, but it can be simulated in RAM.  The
easiest-to-use way to do this is to mount a RAM disk.  Can you do that
is a seccomp jail?

It is tempting to think of adding callbacks to the sell client python
script to perform certain operations you can't in the seccomp jail, like
mounting a RAM disk.  However, if you add more than a handful of
callbacks, you're essentially implementing your own OS again.

So, a simple question would be, why not just use pure virtual appliances
on VMWare/VirtualBox/KVM as buyer clients?  Performance is similar.
Security is similar.  If seccomp really is a temporary measure (my first
batch of vPro boxes just arrived), why not use a more convenient
temporary approach?

Nic
-- 
cpushare-discuss_X_at_X_cpushare.com mailing list - http://www.cpushare.com/
To unsubscribe, send mail to cpushare-discuss-unsubscribe_X_at_X_cpushare.com