On 5/16/07, Anthony Liguori <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- 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
