Hi,

> The xen 2.0 tools are part of the xen distribution (in xen-2.0/tools) and
> I've made a packages for them:
> ftp://asim.lip6.fr/outgoing/bouyer/xentools20-package.tgz
> I think that to work on this, a xen setup with a NetBSD domain0 kernel is
> needed. For testing purposes, using the netbsd-XENU-INSTALL kernel (in the
same
> ftp directory) as guest OS, with a vbd read-only on the boot disk would be
> enouth. So, from a working NetBSD 2.0 system, you'd just need to install
> grub, the xen.gz from the xen 2.0 binary distribution, and domain0 NetBSD
> kernel (ftp://asim.lip6.fr/outgoing/bouyer/netbsd-XEN0.gz should work on
most
> hardware).

Excellent, good work!

> Now, what's needed on the tools. There are several issues:
> there are lots of patches in the package, some of them are patches to the
> python files. It would be nice if the different behavior between linux and
> NetBSD (mostly paths to some files which are different) could be made
> conditionnal at run-time, so that we can feed these changes back to the
> xen maintainers.

yes, we will take patches to support this.  I think you should make the
changes similar to what I did for the xentools12 package, i.e. use the
return value from uname to lookup paths in a hash.

> A more important problem is the way xen works with block devices. From a
> config entry like:
> disk = [ 'phy:/dev/wd0e,hda,r' ]
> xend will pass the dev_t and size of /dev/wd0e to the domain0 kernel, and
> the dev_t of hda to the guest (so that the guest can choose which
"personality"
> of the vbd driver is will use). I have 2 issues here:
> - the size of /dev/wd0e passed to the kernel is always 0. I guess the
>   xen tool isn't using the appropriate call to find the size (I guess it
>   just uses the result from stat()).

I parsed the output from disklabel to get the size.

> - to get the dev_t of hda, the xen tool will to a stat() on /dev/hda.
>   This means that we can only properly boot a linux guest from a linux
domain0,
>   or a NetBSD guest from a NetBSD domain0 (creating a linux /dev/hda on
the
>   NetBSD domain0 works, but it's not something we want to use in long term
:)
>   I think the xen tools should compute this dev_t from a table giving the
>   proper major for each device type and guest OS, instead of relying on
>   the domain0's filesysem. I think the xen tools already know the
>   guest's OS from the binary kernel being loaded. If not, we can use the
>   "builder=" config variable. For now xen doen't know about
builder=netbsd,
>   but we could clone it from the linux config.

I thought we already had a table of common Linux device names to major/minor
numbers, maybe that's only in xen-unstable.  I think we would also consider
moving away from the Linux major/minor numbers (especially since the IDE
ones are quite random) but it's not been high priority and it would have
some backwards compatibility issues.  I think the xentools12 package also
has a mapping table from NetBSD device names to Linux major/minor numbers.
I'd really like to avoid using the builder= option, we used to have
different builders for Linux and NetBSD and I did most of the cleanup work
to make them use the same builder.  We only have different builders for
Plan9 (a.out image, not elf) and for VMX domains (because the initial state
is very different).

> There may also be issues with how the network stuff works, but I've not
> analysed this yet. I'll come back on this later, when I have a working
> net backend (hopefully before the end of the week).

You probably want to have NetBSD specific scripts to setup bridging or NAT
networking.  I don't really expect those to have much in common with the
Linux ones.

We're thinking about creating a new set of tools.  The key part to the new
toolset is the xcs (xen control switch) daemon, which allows multiple
independent small tools to control xen instead of having a single large
daemon like xend.  At the moment, xcs is only available for xen-unstable,
but it shouldn't be too difficult to backport it to xen-2.0.  With xcs, it
should be easy to have a set of small tools which wrap the functionality
(domain creation, enumeration, destruction, ...) provided by libxc.  libxc
exists for xen-2.0, the main reason for requiring xcs is that there needs to
be some daemon which does the control message demultiplexing.  Maybe this
would be an option worth considering...

    christian