On 5/11/07, Anthony Liguori <[EMAIL PROTECTED]> wrote:
> > cpu% ls /net/ether0
> > /net/ether0/0
> > /net/ether0/1
> > /net/ether0/2
> > /net/ether0/addr
> > /net/ether0/clone
> > /net/ether0/ifstats
> > /net/ether0/stats
> >
>
> This smells a bit like XenStore which I think most will agree was an
> unmitigated disaster.
>
I'd have to disagree with you Anthony. The Plan 9 interfaces are
simple and built into the kernel - they don't have the
multi-layered-stack-python-xmlrpc garbage that made up the Xen
interfaces.
>This sort of thing gets terribly complicated to deal with in the
corner cases.
>Atomic operation of multiple read/write operations is difficult to express.
> Moreover, quite a lot of things are naturally expressed as a state machine
> which
> is not straight forward to do in this sort of model. This may have been all
> figured out in 9P but it's certainly not a simple thing to get right.
>
That's true, but we have been doing it for over 20 years - I think we
have a good model to base stuff on.
> I think a general rule of thumb for a virtualized environment is that
> the closer you stick to the way hardware tends to do things, the less
> likely you are to screw yourself up and the easier it will be for other
> platforms to support your devices. Implementing a full 9P client just
> to get console access in something like mini-os would be unfortunate.
> At least the posted s390 console driver behaves roughly like a uart so
> it's pretty obvious that it will be easy to implement in any OS that
> supports uarts already.
>
If it were just console access, I would agree with you, but its really
about implementing a single solution for all drivers you are accessing
across the interface. A single client versus dozens of different
driver variants. Our existing 9p client for mini-os is ~3000 LOC and
it is a pretty naive port from the p9p code base so it could probably
be reduced even further. It is a very small percentage of our
existing mini-os kernels and gives us console, disk, network, IP
stack, file system, and control interfaces. Of course Linux clients
could just use v9fs with a hypervisor-shared-memory transport which I
haven't merged yet. We'll also be using the same set of interfaces
for the simulator shortly.
Oh yeah, and don't forget the fact that resource access can bridge
seamlessly over any network and the protocol has provisions to be
secured with authentication/encryption/digesting if desired.
Los Alamos will be presenting 9p based control interfaces for KVM at OLS.
-eric
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
