Re: [PATCH/RFC 7/9] Virtual network guest device driver

[Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Eric Van Hensbergen wrote:
> On 5/11/07, Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 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.
>   

My point isn't that 9p is just like XenStore but rather that turning 
this idea into something that is useful and elegant is non-trivial.

> 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.

There's definitely a conversation to have here.  There are going to be a 
lot of small devices that would benefit from a common transport 
mechanism.  Someone mentioned a PV entropy device on LKML.  A 
host=>guest filesystem is another consumer of such an interface.

I'm inclined to think though that the abstraction point should be the 
transport and not the actual protocol.  My concern with standardizing on 
a protocol like 9p would be that one would lose some potential 
optimizations (like passing PFN's directly between guest and host).

>   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.
>   

So is there any reason to even tie 9p to KVM?  Why not just have a 
common PV transport that 9p can use.  For certain things, it may make 
sense (like v9fs).

Regards,

Anthony Liguori

> 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


-------------------------------------------------------------------------
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/