Hi again, any thoughts on this topic? Questions, suggestions, criticism? I can make patches to discuss code, but it would rather be handly if I'd be on the same page with everyone here to make something generically useful.
Suikov Pavlo GlobalLogic P +x.xxx.xxx.xxxx M +38.066.667.1296 S psujkov www.globallogic.com <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt On Mon, Jan 25, 2016 at 3:38 PM, Pavlo Suikov <pavlo.sui...@globallogic.com> wrote: > Hi everyone, > > I want to bring domain restart question for a discussion. It originates > from DomD restart, but the solution I am about to offer can be quite > generic. > > Problem is, domain specification currently holds only frontend info, which > is used to generate both frontend and backend entries for a device; that > means that backend xenstore data is handled not by a domain that owns > backends, but by a domain that has frontends linked to these backends. As a > result, reboot of any domain with backends without reboot of the > corresponding frontend domains is impossible. > > This is wrong on many levels, but the main thing is: some domains don't > know something they should (do they have any backends) and some know > something they should not (there are backends for their frontends in > different domains). > > I propose following change: make domain "require" and "provide" interfaces > visible (think CORBA), hold connections between the two in the priveleged > domain (where toolstack is, think controller from the MVC idiom). With this > change domains (except for Dom0 which is a special case) can be rebooted in > any order whatsoever, and frontend/backend link can be adjusted as a static > config or during runtime (e.g. if hardware rendering backend hangs, switch > to software rendering to avoid glitches). However, it requires change in > the libxl internal device representation (device should not be a > frontend/backend pair any more) and config format change, which breaks > backwards compatibility. > > That is, I want domain configuration hold records on both frontends (what > this domain require) and backends (what this domain provides) and libxl to > create corresponding xenstore branches separately. Moreover, I'd like to > have frontend/backend connection information be held in a different config > belonging to Dom0, so that on any domain reboot (or any exceptional > situation like watchdog failure) supervisor (Dom0) can use this information > to initiate a reconnect. > > And, as we talk about libxl refactoring, I'd like to state one point more: > code duplication. Libxl support for a split-driver model consists of an > declarative IDL device specification, xenstore read, xenstore write, config > read, config write, xl args read, JSON read/write and device chain of > responsibility with async device creation. The only thing IDL is used for > is type and JSON read/write code generation, everything else is an > error-prone hand-written duplicated code. > > Why won't we generate as much as we can? That means generation of xenstore > read, xenstore write, config read, config write and xl args read - these > all directly depend on device IDL specification. If we already have > external code generation tool, why not use it to full extent instead of > writing all this serialization/deserialization code manually (and in > different styles - e.g. block device is the only one that uses lexx, and > xl_cmdimpl.c parse_config_data implementations differs from device to > device quite a lot)? > > As a matter of fact, I'd be doing some work in this general direction > because we need DomD restart anyway and libxl boilerplate is kinda messy > (we have ~12 devices and xl/libxl interface patches for them are almost > copy and pasted), but I would like to hear as much criticism and ideas as > possible. It would be nice if we can come out from this discussion with > something potentially upstreamable. > > Suikov Pavlo > GlobalLogic > P +x.xxx.xxx.xxxx M +38.066.667.1296 S psujkov > www.globallogic.com > <http://www.globallogic.com/> > http://www.globallogic.com/email_disclaimer.txt >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
