[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 for-4.5 1/2] libxl: add support for 'channels'
David Scott writes ("[PATCH v5 for-4.5 1/2] libxl: add support for 'channels'"): > A 'channel': > - is a low-bandwidth private communication channel that resembles > a physical serial port. > - is implemented as a PV console with a well-known string name > which is used to hook the channel to the appropriate software > in the guest (i.e. some kind of guest agent). > - has a backend 'connection' which describes what should happen > to the data. This looks good in principle. I have a couple of easy quibbles: You have forgotten to document that you transport the channel name in xenstore in the subkey `name'. This should be in your `console.txt' patch I think, given that xenstore-paths.markdown refers to that for all the nodes in .../console. And the interaction between consoles in the console part of the domain configuration and the channels listed in the channels part, should be documented. (Even if it's just that consoles always have no name and channels always have one.) I have a harder one: > +int libxl__init_console_from_channel(libxl__gc *gc, > + libxl__device_console *console, > + int dev_num, > + libxl_device_channel *channel) AFAICT this function is used to recreate the domain's channel configuration info for the benefit of libxl's caller (making enquiries) and setting up the qemu arguments. But nowadays, following Wei's save/restore/JSON patches, I think we would expect libxl to retrieve this information from the JSON configuration. That is, the console information should be in the stored JSON config and can be retrieved from there. (There are also unfortunate security implications to reading the backend directory like that - if we have a driver domain, the qemu might get untrustworthy paths.) Wei, am I right ? Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |