Hi, Alex
>On Fri, 2006-07-07 at 14:12 +0900, Akio Takebe wrote:
>> Thank you very much!
>> I reviewed your test tree, and these changes are almost good.
>> I tested dom0/domU booting and INIT work with the test tree
>> and the results are good.
>
>Hi Akio,
>
> "almost" good? Is there something that still needs to be fixed, or
>should I go ahead a push it into xen-ia64-unstable?
>
I'm sorry for my poor English.
That is Japanese expression...
All of these changes are good.
Please push it into xen-ia64-unstable.
>> BTW, I appreciate your work.
>> I'd like to reduce your maintenance work. :-)
>> I learned about the following things by seeing your test tree.
>> We should do the below for reducing your maintenace work, shouldn't we?
>> 1. If we port some features from linux,
>> we add normal file into xen/arch/ia64/linux-xen.
>> 2. Then we modify xen/arch/ia64/linux-xen/README.orig
>> 3. We make the above patch. This is the first patch
>> 4. We add the changes to porting to xen.
>> 5. We make a patch of the chages. This is second patch.
>>
>> And we send the two patch to xen-ia64-devel.
>> We should use linux-2.6.13 for porting to xen.
>> The latest stable linux from www.kernel.org is better than linux-2.6.13.
>>
>> Am I correct?
>
> Yes, this makes things much easier. It gives a known starting point
>with changesets incrementally changing from the base. It also makes
>review on the mailing list much easier. We can typically skip over
>reviewing the details of patches that are only adding files from Linux
>and concentrate on the changes we're making to the files. Isaku did
>this for the P2M/VP patches and I thought it was a good idea.
>
> Linux-2.6.13 is the current Xen/ia64 base and the preferred base for
>pulling in new files. However, if we need features and bug fixes from
>newer versions of Linux, I'll accept those too (try to make note of the
>different base in the README.origin file, see the iosapic.c entry for
>example). At some point we should update the Linux base files in the
>Xen/ia64 tree, but I think we've all been too busy adding new features
>and stabilizing to make that jump.
>
Thank you for your explanation.
We'd like to update the code,
and we'd like to cleanup ifdef at some point, wouldn't we?
If do it, we also do it.
> Sorry for leading you down the path of pulling code out of mca.c into
>a non-linux-xen file. In the end, I think the leverage from the
>upstream file became more obvious and the upcoming MCA work made me
>reluctant to proceed down that path. The #ifdef/#endifs can get ugly
>and tedious, but I think we just need to get more creative in organizing
>the modifications to account for that. Thanks,
I don't care. I also sorry for increasing your maintenance work.
Yes, I also think the upcoming MCA work is more ifdef.
I think maybe better way that a function having many ifdef separate
between changed function and original function.
We're making MCA now, and If we'll have made it,
we'll make the patches with above way.
So we'll reduce your maintenance work. :-)
Best Regards,
Akio Takebe
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home