> The interface presented to guest userspace is of a simple char
> device, so it can be used like this:
>
> fd = open("/dev/vcon2", O_RDWR);
> ret = read(fd, buf, 100);
> ret = write(fd, string, strlen(string));
>
> Each port is to be assigned a unique function, for example, the
> first 4 ports may be reserved for libvirt usage, the next 4 for
> generic streaming data and so on. This port-function mapping
> isn't finalised yet.
Unless I am missing something this looks completely bonkers
Every time we have a table of numbers for functionality it ends in
tears. We have to keep tables up to date and managed, we have to
administer the magical number to name space.
Anyway - you don't seem to need a fixed number you can use dynamic
allocation and udev.
There are at least two better ways to do this
- Using sysfs nodes so you have a proper heirarchy of names/functions
- Using a simple file system which provides a heirarchy of nodes whose
enumeration and access is backed by calls to whatever happyvisor you
are using.
it then self enumerates, self populates, doesn't need anyone to keep
updating magic tables of guest code and expands cleanly - yes ?
Alan
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
