On Tue, Feb 26, 2008 at 08:24:53AM -0500, Daniel Veillard wrote: > On Tue, Feb 26, 2008 at 12:52:32PM +0000, Daniel P. Berrange wrote: > > On Tue, Feb 26, 2008 at 09:39:49AM +0000, Richard W.M. Jones wrote: > > > > > > Yes, this all looks good. > > > > > > Another advantage of doing this is that we can be sure that the > > > capabilities XML generated by each driver will have the same schema. > > > > Yes indeed - this is a very good benefit, particularly as we extend the > > capabilities with more data like NUMA / migration / etc. At some point > > I think it'd be interesting to do a similar refactoring for domains. So > > we could have an internal virDomainDefPtr to store the definitions and > > a generic XML formatter / XML parser shared by all drivers. > > Yes I think that has been on the back of everybody's mind since > the beginning, but we were not confident enough in the set of properties > doing it internally would be good, then at some point we may even expose > it in the API, but there is no hurry. Yes, if we keep the structs internal we can still change it at will. At worst we'd get compile errors for the drivers which could be trivially fixed. > On the other hand cleaning up the domain code mess (incredible how simple > things become complex as the code is extended) with new internal structures > and APIs in the same way would be a really great thing. But that should > probably wait a little bit I feel we are too close to the next release for > this, Absolutely - i wasn't suggesting that we do it right now - there's plenty of other things to worry about first :-) The existing qemud_conf.h file contains a reasonable starting point for internal VM API, but would need a fair bit more work to be generic enough for the container based drivers. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list