Re: Xen1.2 NetBSD port snapshot available and set_gdt patch for Xen1.2

[Rolf Neugebauer <rolf.neugebauer@intel.com>]

On Tue, 2004-02-03 at 08:42, Ian Pratt wrote:
> > I don't think you'd want the whole kernel tree in the Xen tree?
> > You could put the sys/arch/xen files into the Xen tree and also the 5
> > additional files which need changes, but it's not really stable/useable yet.
> > Also, I'm waiting for the OK to commit all this to the NetBSD tree and then
> > it won't make much sense to have it in the Xen tree anymore.
> 
> If you can get the changes into the main stream NetBSD tree that
> would be great. It would would set a useful precedent for
> persuading Linus to do the same in 2.6...

I agree it would be great to get this into the NetBSD tree. Christian,
what is the maintenance model for ports in NetBSD? Are the NetBSD folks
fairly easy to convince (I'm more familiar with the FreeBSD model)? Is
it easy for a maintainer to become a commiter to the CVS etc.? 

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. To
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.

 
> > I think there should be a netbsd config file for the domain creation tools,
> > once I've made the above changes.
> 
> Having the netbsd config file and any extra build tools in the
> Xen tree would seem sensible.
> 
> If it looked like there was a problem getting the kernel mods
> into the netbsd tree we could either put a patch or 'sparse tree'
> in the Xen tree in the meantime.

that's certainly the way to go. However, if I understand Christian
correct, the port is against the -current (i.e. the development tree)
which, if it is similar to the FreeBSD model, may not have
snapshots/version numbers we can base the sparse tree against. 

Christian, do you have an idea how far -current has diverged from
-stable in the parts of the tree which matter? or, i fact how often
relavant files in -current change wrt to your changes/patches.

I'm going to give the 1.2 port a spin later today or tomorrow and let
you know how it works out.

Cheers
Rolf



> Cheers,
> Ian
> 
> 
> -------------------------------------------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
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