Subject: Re: [vserver] call method of host in guest os
From: "Michael S. Zick" <mszick@morethan.org>
Date: Mon, 22 Dec 2008 10:13:48 -0600

On Sun December 21 2008, Michael S. Zick wrote:
> On Sun December 21 2008, Michael S. Zick wrote:
> > On Sat December 20 2008, Michael S. Zick wrote:
> > > On Thu December 18 2008, Michael S. Zick wrote:
> > > > 
> > > > You would probably be better off with tipc:
> > > > http://tipc.sourceforge.net
> > > > 
> > > 
> > > Well, I mentioned it, and it is a slow weekend - - -
> > > Besides, haven't done anything with tipc in nearly 3 decades ;)
> > > 
> > > = = = =
> > > 
> > > Hardware: C2Q (Q9300) @ 2.5Ghz (probably typical of a server)
> > > Host: 64bit-Gentoo, 2.6.27.10-vs2.3.0.36.2 + tipc-1.7.6 + tipc_utils-1.1.8
> > > Guest: 32bit-Gentoo-i686
> > > Network: dummy0
> > > 
> > > = = = =
> > > 
> > > The good: The tipc sources do not conflict with the vserver patch.
> > > Just overwrite net/tipc with the project's tarball for .27
> > > (The kernel main-stream isn't even close to current.)
> > > 
> > > The bad: The tipc sources are probably not context aware.
> > > I don't think that really makes a difference in this case, could be wrong.
> > > 
> > 
> > I was wrong - this protocol needs to become context aware for anything
> > other than the simplest of uses.
> > 
> > What you see happening (if you give it a try) is its ability to find the
> > closest node that can satisfy the request - even if it is talking to itself. ;)
> > (Which is by design, it is supposed to work that way unless directed otherwise).
> > It only becomes obvious when you enable remote management - there isn't a "remote".
;)
> > 
> > Will give the main-stream code a few tests - see if it is complete enough
> > to even consider using. (and patching to be multiple-context aware)
> >
> 
> Yup - mainstream code is working - although not the same feature set as the project
code.
> 
> The bad: you can't set a node address per guest (to use the system as it was intended)
> The good(?): any code (host or guest) with access to the kernel socket API can use
it.
> The puzzle: the userland configuration tool is capabilities limited - because it uses
> the netlink access API (mostly) rather than the socket API.
> 
> The ugly: this isn't any "patch" it is a re-write - - -
> The system is built out of a large collection of globals which need to be moved into
> a structure and then have a structure per context - then guests could be "independent"
> computational nodes, exactly like the system was intended to work. (says one of the
intendees).
> 

Intendees???  Intendors???  Probably the second choice. ;)

According to Ericsson -
http://www.ericsson.com/technology/opensource//
The linux driver is the: "de-facto reference implementation" -

In 2.6.27.10 that is one of the 1.6.x versions of the driver.

On the same page, following the link to their project site, you
find (in addition to the 1.6.x stuff) that the project-current
is version 1.7.6 (and some compatibility notes between the versions).
So the main-stream code is clearly subject to change.

In the code is the repeated comment that this is the "single node"
version of the driver (we would need a "multi-node version").

My conclusion - "too soon to start patching the driver".

Will wait and see if the project introduces the multi-node version.
(For my own use, I can just do an artificial, by port-range assignment,
multi-guest system. I.E: fake it).

Mike
> Phooey.
> > Mike
> > 
> > 
> 
> 
> 
>