3. We haven¡¯t found a good place to contain these files. So
temporarily put under xen/arch/ia64.
Then do you have any good suggestion for the place? We¡¯d like to hear
that.
I have been keeping a separate tree for paravirtualized xenlinux
and non-VTI work on multiple domains has been going into that tree.
When we have something working and can specify a patch that
uses asm-specific headers to differentiate between common and
arch-dep, we should submit the changes to Keir for the main
xeno-unstable tree. However, per a discussion on xen-devel
a month ago, Chris Wright is working on restructuring the
xeno-unstable.bk/xenlinux tree, so it is probably best to
just maintain the changes separately until the restructuring
is done.
That's reasonable.
It might make sense to have a public VTI-xenlinux tree, but until
the Xen team decides what source code management tool we will
all be using, it is probably not a good idea to create another
bk tree.
We don't need a public VTI-xenlinux tree. We just need a place to distribute
hypercall/evtchn mechanism as a kernel module. Then customer can install that
module on unmodified domain 0 to make Xen eco-system fully working. However
currently the common code in xenlinux is tightly coupled with kernel source,
which is not designed as a module style initially. So we have to make some
duplication there.
In any case, I don't think the changed files belong in
xeno-xxx.bk/xen/arch/ia64 if they are not linked into
the Xen/ia64 hypervisor.
So what about puting it into the driver directory of xenlinux, but not in Kbuild
system of xenlinux, since it's only for unmodified domain?
Thanks,
Kevin
15 messages in com.xensource.lists.xen-ia64-develRE: [Xen-ia64-devel] RE: how to put k...
.Other