Re: [Xen-devel] Xen1.2 NetBSD port snapshot available and set_gdtpatch for Xen1.2

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> > It leaves the slight problem on how to deal with the shared files
> > (hypervisor-if.h and friends). If they are not in the main NetBSD tree
> > the port won't compile. If the NetbSD source contains a copy it is more
> > difficult to maintain consistency. I'm more in favour of having a copy
> > in the NetBSD tree as it allows compilation directly from the CVS.
> 
> yes, I've chosen to include the interface header files.  We have
> autobuilders which regularly build all ports and those only work if
> everything is included.

Having the interface headers copied into the guest source tree makes
sense when building completely separately from Xen. For safety we
should add a version number to the interface header files and use that
to check the guest-OS build against the running Xen at guest boot
time. We've avoided this kind of issue up to now since we've only
had Linux fully ported to Xen so building the two together made
sense. 

> > address the consistency issue maybe we should add a version number to
> > hypervisor-if.h and friends and pass that down either as a separate
> > hypercall (i.e., a new domain has to 'register' with Xen) or as part of
> > a infrequently use hypercall (like set_trap_table). we can do the same
> > for the 'device driver' interface.
> 
> Or try to keep the interface changes to a minimum and keep backwards
> compatibility.  I know that's sometimes a pain but I've also found that it
> leads to better interfaces if you have to be careful when adding/changing
> interfaces...

Although some parts are now pretty stable, others are going to be in
flux for a while yet. For example -- the I/O interface is likely to
change somewhat when device drivers are pulled out into isolated
domains. Also new bidirectional console support; the CPU-management
interface (when we add support for SMP guests); ... In general we're
treating the existing interface as a rough prototype and improving it
as we address the weaknesses in each Xen subsystem (e.g., I/O, memory
management, CPU abstraction). This work is still ongoing. However, we
will try harder to minimise the effect on guest OSes now that others
are using the Xen interfaces. :-)

 -- Keir


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel