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

ron minnich
2007-05-18T05:31:20Z

On 5/16/07, Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> What do you think about a socket interface? I'm not sure how discovery
> would work yet, but there are a few PV socket implementations for Xen at
> the moment.

Hi Anthony,

I still feel that "how about a socket interface" is still focused on
the "how to implement", and not "what the interface should be". I also
am not sure the socket system call interface is quite what we want,
although it's a neat idea. It's also not that portable outside the
"everything is a Linux variant" world.

So how about this as an interface design. The communications channels
are visible in our name space at a mountpoint of our choice. Let's
call this mount point, for sake of argument, vmic.

When we mount on vmic, we see one file:
/vmic/clone

When we open and read /vmic/clone, we get a number, let's pretend for
this example we get '0'. The numbers are not important, except to
distinguish connections. Opening the clone file gets us a connection
endpoint. Ls of the directory now shows this:
/vmic/clone
/vmic/0

The "directory", and the "files" in it, are owned by me, mode 700 or
600 or 400 as the file requires. The mode can be changed, of course,
if I wish to allow wider access to the channel. Here, already, we see
some advantage to the use of the file system for this type of
capability.

What is in the directory? Here is one proposal.
/vmic/0/data
/vmic/0/status
/vmic/0/ctl
/vmic/0/local
/vmic/0/remote
What can we do with this?
Data is pretty obvious: we can read it or write it, and that data is
received/sent from the other endpoint. Note that I'm not saying how
the data flows: it can be done in whatever manner is most efficient,
by the kernel, including zero copy. It can be different for many
reasons, but the point is that the interface is basically unchanging.
Of course, it is an error to read or write data until something at the
other end connects to the local end!

What is status? We cat it and it gets us status in some meaningful
text string. E.g.:
cat /vmic/0/status
connected /domain/name

What is local? It's our local name for the resource in this domain
What is remote? It's the name of other endpoint.

What's a name look like? I'm thinking it might look like /domain/name,
but that is just a guess ...

What is ctl? here is where the fun begins. We might do things such as
echo bind somename > /vmic/0/ctl
this names the vmic. We might want to wait for a connection:
echo listen 1> /vmic/0/ctl
We might want to restrict it somehow
echo key somekey > /vmic/0/ctl
echo listendomain domainnumber > /vmic/0/ctl
or we might know there is something out there.
echo connect /domainname/somename > /vmic/0/ctl

Once it is connected, we can move data.

This is similar to your socket idea, but consider that:
o to see active vmics, I use 'ls'
o I don't have to create a new sockaddr address type
o I can control access with chmod
o I am seperating the interface from the implementation
o This is, of course, not really 'files', but in-memory data
structures; this can
(and will) be fast
o No binary data structures.
For different domains, even on the same machine, alignment rules etc. are not
always the same -- I hit this when I ported Plan 9 to Xen, esp. back when Xen
relied so heavily on gcc tricks such as __align__ and packed. Using
character strings
eliminates that problem.

This is, I think, the kind of thing Eric would also like to see, but
he can correct me.
Thanks

ron