This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-ia64-devel] RE: how to put kernel module in xen/ipf

To: <dan.magenheimer@xxxxxx>
Subject: RE: [Xen-ia64-devel] RE: how to put kernel module in xen/ipf
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 23 Jun 2005 20:48:09 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 23 Jun 2005 12:47:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcV3pZGJccAq7TmyRE2ariLatDdWygAS1IkA
Thread-topic: [Xen-ia64-devel] RE: how to put kernel module in xen/ipf
>> 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?


Xen-ia64-devel mailing list