I meant to make this request at the summit but never got around to it: One of the big problems we have is following the rapid development of upstream xen-unstable whilst working on our current base. It''s simply impossible to keep abreast of every change in upstream, especially when the vast majority don''t impact the Solaris case at all. We review changes when we jump to a new base (as we''re doing now for 3.1.2), but this is not ideal for a host of obvious reasons. Would it be feasible to start some kind of change log for things affecting dom0 and domU implementations? That is, such a patch would need to list itself on a wiki page (or something else) before it goes into the main tree as a point of policy. Wherever possible I''d be glad to help out (documenting the change on that page, for example). The kinds of changes that this would apply to include: - any new hypercalls - all changes to domctl/sysctl but *especially* incompatible ones - any behaviour changing domain builder stuff (new ELF feature flags etc.) - all changes to inter-domain protocols - new file formats (core dump, save/restore, etc.) - any new code that thinks there''s text inside /proc ;) - maybe significant reworks such as Dan Berrange''s qemu/text console stuff With documentation, this would also start to form the basis of a better-documented hypervisor API, at least for ''new'' bits. Comments? thanks, john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Not a bad idea, although I will say that domU interfaces are guaranteed to maintain backward compatibility (although this would be easier with detailed interface documentation, of course). And the sysctl/domctl changes should largely be hidden in the low-level libraries and tools. -- Keir On 19/11/07 10:30, "John Levon" <levon@movementarian.org> wrote:> > I meant to make this request at the summit but never got around to it: > > One of the big problems we have is following the rapid development of > upstream xen-unstable whilst working on our current base. It''s simply > impossible to keep abreast of every change in upstream, especially when > the vast majority don''t impact the Solaris case at all. We review > changes when we jump to a new base (as we''re doing now for 3.1.2), but > this is not ideal for a host of obvious reasons. > > Would it be feasible to start some kind of change log for things > affecting dom0 and domU implementations? That is, such a patch would > need to list itself on a wiki page (or something else) before it goes > into the main tree as a point of policy. > > Wherever possible I''d be glad to help out (documenting the > change on that page, for example). > > The kinds of changes that this would apply to include: > > - any new hypercalls > - all changes to domctl/sysctl but *especially* incompatible ones > - any behaviour changing domain builder stuff (new ELF feature flags etc.) > - all changes to inter-domain protocols > - new file formats (core dump, save/restore, etc.) > - any new code that thinks there''s text inside /proc ;) > - maybe significant reworks such as Dan Berrange''s qemu/text console stuff > > With documentation, this would also start to form the basis of a > better-documented hypervisor API, at least for ''new'' bits. > > Comments? > > thanks, > john > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Nov 19, 2007 at 11:56:15AM +0000, Keir Fraser wrote:> Not a bad idea, although I will say that domU interfaces are guaranteed to > maintain backward compatibility (although this would be easier with detailed > interface documentation, of course). And the sysctl/domctl changes should > largely be hidden in the low-level libraries and tools.Backwards compatibility isn''t really the problem (minus the occasional bug). It''s when something new and exciting is added, and we really could make use of it, but don''t even /know/ about it. As for domctl, this unfortunately isn''t true - due to the mlock() differences, we have to have intimate knowledge of the structures inside our kernel driver - one of the reasons that switching Xen versions with Solaris dom0 tends towards the miserable. regards john _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel