Hi Dave and Juan,
I''d like to get started on the path to integrating the fedora-xen-ia64
work into fedora. There are a number of pieces that I''ll be trying to
pull together over the next few days. The biggest/hardest piece is
the kernel rpm.
I''ve split the changes into two parts:
1. generic fixes and enablement
2. ia64 xen integration
This mail contains the first part. For the second part, I''d like to
request that Juan updates his patch to the most recent xen-unstable
first. Then I''ll work on making it build on ia64 and send back
whatever changes are necessary, including the ia64-xen[0U] configs.
Once the kernel rpm is working, it should be a relatively simple
matter to make the remainder of modifications to "turn on" xen-ia64.
Sound reasonable?
Regards,
Aron
--
This patch makes the following changes to the kernel specfile:
- abstract xenlinux build using xen_flags, xen_target and
xen_image instead of assuming x86 behavior
- add xen_* overrides to %ifarch ia64, won''t be used until
buildxen is flipped on for ia64
- run the xen-mkbuildtree-pre hook following applying the xen
patch. This touches a couple files on ia64 but doesn''t
interfere with any patching down the line. (I and others have
been submitting patches to xen-ia64-devel and xen-devel to
further reduce its function, but it should be harmless as-is.)
- update numerous hardcoded references to /boot to use
%{image_install_path} instead. But make an exception for the
xenU kernels which never need to be available for system
boot.
- build the hypervisor with %{?_smp_mflags} (it works fine)
Signed-off-by: Aron Griffis <aron@hp.com>
--- kernel-2.6.spec.orig 2006-06-01 19:12:59.000000000 -0400
+++ kernel-2.6.spec 2006-06-02 11:18:33.000000000 -0400
@@ -32,6 +32,9 @@
%define xen_version 20060524
%define make_target bzImage
%define kernel_image x86
+%define xen_flags verbose=y debug=y crash_debug=y
+%define xen_target vmlinuz
+%define xen_image vmlinuz
%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
@@ -127,11 +130,15 @@
%endif
%ifarch ia64
-%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-ia64.config
+%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-ia64*.config
%define image_install_path boot/efi/EFI/redhat
%define signmodules 1
%define make_target compressed
%define kernel_image vmlinux.gz
+# ia64 doesn''t building with debug=y at the moment
+%define xen_flags verbose=y crash_debug=y
+%define xen_target compressed
+%define xen_image vmlinux.gz
%endif
#
@@ -834,6 +841,15 @@
# Delete the rest of the backup files, they just confuse the build later
find -name "*.p.xen" | xargs rm -f
+# Run the xen-mkbuildtree-pre hook, if it exists for this architecture.
+# Hopefully this is kept clean (or non-existent) so that patches
aren''t confused
+# further down the line. Presently it''s used only for ia64, and only
for files
+# that we aren''t interested in patching.
+if [[ -f "arch/%{_arch}/xen-mkbuildtree-pre" ]]; then
+ chmod +x arch/%{_arch}/xen-mkbuildtree-pre
+ arch/%{_arch}/xen-mkbuildtree-pre
+fi
+
#
# Xen includes a patch which moves the vsyscall fixmap into a user-space VA,
# freeing user-space from reliance on an absolute fixmap area and so allowing
@@ -1157,7 +1173,13 @@
mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
- cp $KernelImage $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer
+ if [[ "$Flavour" == *xenU* ]]; then
+ # xenU kernels should always install to /boot
+ # because they''re never needed for system boot
+ cp $KernelImage $RPM_BUILD_ROOT/boot/vmlinuz-$KernelVer
+ else
+ cp $KernelImage $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer
+ fi
if [ -f arch/$Arch/boot/zImage.stub ]; then
cp arch/$Arch/boot/zImage.stub
$RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
fi
@@ -1293,15 +1315,15 @@
%if %{includexen}
%if %{buildxen}
cd xen
- mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
+ mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot
%if %{buildxenPAE}
- make debug=y verbose=y crash_debug=y pae=y
- install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}-PAE
+ make %{xen_flags} pae=y
+ install -m 644 xen.gz
$RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}-PAE
install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}-PAE
make clean
%endif
- make debug=y verbose=y crash_debug=y
- install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}
+ make %{?_smp_mflags} %{xen_flags}
+ install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}
install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}
cd ..
%endif
@@ -1310,31 +1332,31 @@
cd linux-%{kversion}.%{_target_cpu}
%if %{buildup}
-BuildKernel %make_target %kernel_image
+BuildKernel %{make_target} %{kernel_image}
%endif
%if %{buildpae}
-BuildKernel %make_target %kernel_image PAE
+BuildKernel %{make_target} %{kernel_image} PAE
%endif
%if %{buildsmp}
-BuildKernel %make_target %kernel_image smp
+BuildKernel %{make_target} %{kernel_image} smp
%endif
%if %{includexen}
%if %{buildxenPAE}
-BuildKernel vmlinuz vmlinuz xen0-PAE
-BuildKernel vmlinuz vmlinuz xenU-PAE
+BuildKernel %{xen_target} %{xen_image} xen0-PAE
+BuildKernel %{xen_target} %{xen_image} xenU-PAE
%endif
%if %{buildxen}
-BuildKernel vmlinuz vmlinuz xen0
-BuildKernel vmlinuz vmlinuz xenU
+BuildKernel %{xen_target} %{xen_image} xen0
+BuildKernel %{xen_target} %{xen_image} xenU
%endif
%endif
%if %{buildkdump}
-BuildKernel %make_target %kernel_image kdump
+BuildKernel %{make_target} %{kernel_image} kdump
%endif
###
@@ -1443,7 +1465,7 @@
%post xen0
[ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen0
-/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL} %{KVERREL}xen0
+/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL} %{KVERREL}xen0
[ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
%post xen0-devel
@@ -1469,7 +1491,7 @@
%post xen0-PAE
[ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen0-PAE
-/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
+/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
[ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
%post xen0-PAE-devel
@@ -1611,7 +1633,7 @@
/%{image_install_path}/vmlinuz-%{KVERREL}xen0
/boot/System.map-%{KVERREL}xen0
/boot/config-%{KVERREL}xen0
-/boot/xen.gz-%{KVERREL}
+/%{image_install_path}/xen.gz-%{KVERREL}
/boot/xen-syms-%{KVERREL}
%dir /lib/modules/%{KVERREL}xen0
/lib/modules/%{KVERREL}xen0/kernel
@@ -1628,7 +1650,7 @@
%files xenU
%defattr(-,root,root)
-/%{image_install_path}/vmlinuz-%{KVERREL}xenU
+/boot/vmlinuz-%{KVERREL}xenU
/boot/System.map-%{KVERREL}xenU
/boot/config-%{KVERREL}xenU
%dir /lib/modules/%{KVERREL}xenU
@@ -1651,7 +1673,7 @@
/%{image_install_path}/vmlinuz-%{KVERREL}xen0-PAE
/boot/System.map-%{KVERREL}xen0-PAE
/boot/config-%{KVERREL}xen0-PAE
-/boot/xen.gz-%{KVERREL}-PAE
+/%{image_install_path}/xen.gz-%{KVERREL}-PAE
/boot/xen-syms-%{KVERREL}-PAE
%dir /lib/modules/%{KVERREL}xen0-PAE
/lib/modules/%{KVERREL}xen0-PAE/kernel
@@ -1668,7 +1690,7 @@
%files xenU-PAE
%defattr(-,root,root)
-/%{image_install_path}/vmlinuz-%{KVERREL}xenU-PAE
+/boot/vmlinuz-%{KVERREL}xenU-PAE
/boot/System.map-%{KVERREL}xenU-PAE
/boot/config-%{KVERREL}xenU-PAE
%dir /lib/modules/%{KVERREL}xenU-PAE
On Fri, 2006-06-02 at 11:32 -0400, Aron Griffis wrote:> - update numerous hardcoded references to /boot to use > %{image_install_path} instead. But make an exception for the > xenU kernels which never need to be available for system > boot.For consistency with native, I''d prefer the kernels for xenU to also end up in %{image_install_path}. Jeremy
On Fri, 2006-06-02 at 11:32 -0400, Aron Griffis wrote:> Hi Dave and Juan,Hi Aron> -- > This patch makes the following changes to the kernel specfile: > > - abstract xenlinux build using xen_flags, xen_target and > xen_image instead of assuming x86 behavior > > - add xen_* overrides to %ifarch ia64, won''t be used until > buildxen is flipped on for ia64 > > - run the xen-mkbuildtree-pre hook following applying the xen > patch. This touches a couple files on ia64 but doesn''t > interfere with any patching down the line. (I and others have > been submitting patches to xen-ia64-devel and xen-devel to > further reduce its function, but it should be harmless as-is.)I think that this one is not acceptable :( We compile from the same source on _all_ architectures. If the source changes from architecture to architecture, we are broken :( Notice also that I do my compile testing as something like:i cd tree for arch in $CONFIGS; do make O=../$ARCH all done Or somesuch. What is on that patch, anyways.> - update numerous hardcoded references to /boot to usetu > %{image_install_path} instead. But make an exception for the > xenU kernels which never need to be available for system > boot.Uh, oh. If everything happens as I hope, after this weekend, xenU kernel is history. xen0 & xenU kernels are going to be the same kernel :p You need another solution here. I haven''t studied the ia64 efi thing to be able to suggest anything, sorry.> - build the hypervisor with %{?_smp_mflags} (it works fine)> %if %{buildup} > -BuildKernel %make_target %kernel_image > +BuildKernel %{make_target} %{kernel_image} > %endifAny reason why you do this changes? in space separated cases, it shouldn''t be needed the use of {} Hope that this helps. Later, Juan.
Jeremy Katz wrote: [Fri Jun 02 2006, 11:48:39AM EDT]> On Fri, 2006-06-02 at 11:32 -0400, Aron Griffis wrote: > > - update numerous hardcoded references to /boot to use > > %{image_install_path} instead. But make an exception for the > > xenU kernels which never need to be available for system > > boot. > > For consistency with native, I''d prefer the kernels for xenU to also end > up in %{image_install_path}.Ok, it doesn''t make a huge difference to me. I was just trying to spare the efi partition, but it''s not a big deal. Aron
Juan Quintela wrote: [Fri Jun 02 2006, 12:14:25PM EDT]> > - run the xen-mkbuildtree-pre hook following applying the xen > > patch. This touches a couple files on ia64 but doesn''t > > interfere with any patching down the line. (I and others have > > been submitting patches to xen-ia64-devel and xen-devel to > > further reduce its function, but it should be harmless as-is.) > > I think that this one is not acceptable :( > We compile from the same source on _all_ architectures. If the source > changes from architecture to architecture, we are broken :( > > Notice also that I do my compile testing as something like:i > > cd tree > for arch in $CONFIGS; do > make O=../$ARCH all > doneOk, we can make this work, no problem :-) Here is the current xen-mkbuildtree-pre in xen-unstable: http://xenbits.xensource.com/xen-unstable.hg?f=a2d784a51f25;file=linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-pre Instead of running it only on ia64, we can run it on all architectures. Since the recent patches, the last remaining files created by that script are: include/asm-ia64/xen/asm-xsi-offsets.h drivers/xen/core/xenia64_init.c Neither of those affect any architecture other than ia64. I''m hoping to move the second one to a better home next week. The first one is less trivial since it''s auto-generated in the hypervisor build.> > - update numerous hardcoded references to /boot to usetu > > %{image_install_path} instead. But make an exception for the > > xenU kernels which never need to be available for system > > boot. > > Uh, oh. If everything happens as I hope, after this weekend, xenU > kernel is history. xen0 & xenU kernels are going to be the same > kernel :p You need another solution here. I haven''t studied the ia64 > efi thing to be able to suggest anything, sorry.No problem. I''m very happy to switch to a unified xen kernel.> > - build the hypervisor with %{?_smp_mflags} (it works fine) > > > > %if %{buildup} > > -BuildKernel %make_target %kernel_image > > +BuildKernel %{make_target} %{kernel_image} > > %endif > > Any reason why you do this changes? in space separated cases, it > shouldn''t be needed the use of {}Nope, it just seemed more consistent with, for example, the %if conditional preceding it :-) Aron
On Fri, 2006-06-02 at 12:37 -0400, Aron Griffis wrote: Hi I am going to integrate the _non_ problematic changes right now :)> Ok, we can make this work, no problem :-) > > Here is the current xen-mkbuildtree-pre in xen-unstable: > http://xenbits.xensource.com/xen-unstable.hg?f=a2d784a51f25;file=linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-pre > > Instead of running it only on ia64, we can run it on all > architectures. Since the recent patches, the last remaining files > created by that script are: > > include/asm-ia64/xen/asm-xsi-offsets.h > drivers/xen/core/xenia64_init.cNoooooooooooo, the sparse tree braindamage again :( xen-sparse tree is already brain-damaged enough for now, I think that addind this kind of "improvements" will make it completelly uncromprensible. If you already have a different repository, why don''t you _just_ put that files into the right place in the 1st place? I will very much preffer to add another patch that this copy of files :p /me is just confused> Nope, it just seemed more consistent with, for example, the %if > conditional preceding it :-)Taking a look at integrating your changes. Thanks, Juan.
Here is an updated patch based on Juan''s and Jeremy''s
comments.
--
This patch makes the following changes to the kernel specfile:
- abstract xenlinux build using xen_flags, xen_target and
xen_image instead of assuming x86 behavior
- add xen_* overrides to %ifarch ia64, won''t be used until
buildxen is flipped on for ia64
- run the ia64 xen-mkbuildtree-pre hook following applying the xen
patch, on all architectures for consistency.
- update numerous hardcoded references to /boot to use
%{image_install_path} instead. No exception for xenU kernels.
- build the hypervisor with %{?_smp_mflags} (it works fine)
Signed-off-by: Aron Griffis <aron@hp.com>
--- kernel-2.6.spec.orig 2006-06-01 19:12:59.000000000 -0400
+++ kernel-2.6.spec 2006-06-02 13:05:34.000000000 -0400
@@ -32,6 +32,9 @@
%define xen_version 20060524
%define make_target bzImage
%define kernel_image x86
+%define xen_flags verbose=y debug=y crash_debug=y
+%define xen_target vmlinuz
+%define xen_image vmlinuz
%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}
@@ -127,11 +130,15 @@
%endif
%ifarch ia64
-%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-ia64.config
+%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{kversion}-ia64*.config
%define image_install_path boot/efi/EFI/redhat
%define signmodules 1
%define make_target compressed
%define kernel_image vmlinux.gz
+# ia64 doesn''t building with debug=y at the moment
+%define xen_flags verbose=y crash_debug=y
+%define xen_target compressed
+%define xen_image vmlinux.gz
%endif
#
@@ -834,6 +841,11 @@
# Delete the rest of the backup files, they just confuse the build later
find -name "*.p.xen" | xargs rm -f
+# Run the ia64 xen-mkbuildtree-pre hook, which creates these symlinks:
+# include/asm-ia64/xen/asm-xsi-offsets.h
+# drivers/xen/core/xenia64_init.c
+arch/ia64/xen-mkbuildtree-pre
+
#
# Xen includes a patch which moves the vsyscall fixmap into a user-space VA,
# freeing user-space from reliance on an absolute fixmap area and so allowing
@@ -1293,15 +1305,15 @@
%if %{includexen}
%if %{buildxen}
cd xen
- mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
+ mkdir -p $RPM_BUILD_ROOT/%{image_install_path} $RPM_BUILD_ROOT/boot
%if %{buildxenPAE}
- make debug=y verbose=y crash_debug=y pae=y
- install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}-PAE
+ make %{xen_flags} pae=y
+ install -m 644 xen.gz
$RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}-PAE
install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}-PAE
make clean
%endif
- make debug=y verbose=y crash_debug=y
- install -m 644 xen.gz $RPM_BUILD_ROOT/boot/xen.gz-%{KVERREL}
+ make %{?_smp_mflags} %{xen_flags}
+ install -m 644 xen.gz $RPM_BUILD_ROOT/%{image_install_path}/xen.gz-%{KVERREL}
install -m 755 xen-syms $RPM_BUILD_ROOT/boot/xen-syms-%{KVERREL}
cd ..
%endif
@@ -1323,13 +1335,13 @@
%if %{includexen}
%if %{buildxenPAE}
-BuildKernel vmlinuz vmlinuz xen0-PAE
-BuildKernel vmlinuz vmlinuz xenU-PAE
+BuildKernel %xen_target %xen_image xen0-PAE
+BuildKernel %xen_target %xen_image xenU-PAE
%endif
%if %{buildxen}
-BuildKernel vmlinuz vmlinuz xen0
-BuildKernel vmlinuz vmlinuz xenU
+BuildKernel %xen_target %xen_image xen0
+BuildKernel %xen_target %xen_image xenU
%endif
%endif
@@ -1443,7 +1455,7 @@
%post xen0
[ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen0
-/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL} %{KVERREL}xen0
+/sbin/new-kernel-pkg --package kernel-xen0 --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL} %{KVERREL}xen0
[ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
%post xen0-devel
@@ -1469,7 +1481,7 @@
%post xen0-PAE
[ ! -x /usr/sbin/module_upgrade ] || /usr/sbin/module_upgrade
%{rpmversion}-%{release}-xen0-PAE
-/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install
--multiboot=/boot/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
+/sbin/new-kernel-pkg --package kernel-xen0-PAE --mkinitrd --depmod --install
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}-PAE %{KVERREL}xen0-PAE
[ ! -x /sbin/ldconfig ] || /sbin/ldconfig -X
%post xen0-PAE-devel
@@ -1611,7 +1623,7 @@
/%{image_install_path}/vmlinuz-%{KVERREL}xen0
/boot/System.map-%{KVERREL}xen0
/boot/config-%{KVERREL}xen0
-/boot/xen.gz-%{KVERREL}
+/%{image_install_path}/xen.gz-%{KVERREL}
/boot/xen-syms-%{KVERREL}
%dir /lib/modules/%{KVERREL}xen0
/lib/modules/%{KVERREL}xen0/kernel
@@ -1651,7 +1663,7 @@
/%{image_install_path}/vmlinuz-%{KVERREL}xen0-PAE
/boot/System.map-%{KVERREL}xen0-PAE
/boot/config-%{KVERREL}xen0-PAE
-/boot/xen.gz-%{KVERREL}-PAE
+/%{image_install_path}/xen.gz-%{KVERREL}-PAE
/boot/xen-syms-%{KVERREL}-PAE
%dir /lib/modules/%{KVERREL}xen0-PAE
/lib/modules/%{KVERREL}xen0-PAE/kernel
Hello All, The stupid question ... When i boot in DOMU i have : Fedora Core release 3 kernel xen.2.6.16-xen on an i686 same with other version Fedora if i verify mu kernel with uname -a , i have Xen. If anybody can tell me Why ? Thanks Eric
Juan Quintela wrote: [Fri Jun 02 2006, 12:53:02PM EDT]> > Here is the current xen-mkbuildtree-pre in xen-unstable: > > http://xenbits.xensource.com/xen-unstable.hg?f=a2d784a51f25;file=linux-2.6-xen-sparse/arch/ia64/xen-mkbuildtree-pre > > > > Instead of running it only on ia64, we can run it on all > > architectures. Since the recent patches, the last remaining files > > created by that script are: > > > > include/asm-ia64/xen/asm-xsi-offsets.h > > drivers/xen/core/xenia64_init.c > > Noooooooooooo, the sparse tree braindamage again :( > > xen-sparse tree is already brain-damaged enough for now, I think > that addind this kind of "improvements" will make it completelly > uncromprensible.I agree that it''s an ugly hack. But please consider two things: 1. If you look at the revision history for xen-mkbuildtree-pre (at the link I posted above) you''ll see that it''s down from 12 files to 2 in the past month. We''re working hard on getting rid of it completely. 2. The two files that are left have zero chance of confusing your patching process. One is regenerated on every build (asm-xsi-offsets.h). The other is planning to be moved soon.> If you already have a different repository, why don''t you _just_ put > that files into the right place in the 1st place?Now I''m the one that''s confused! :-( I don''t have a different repository. I have a temporary xen-ia64-unstable tree ported to 2.6.17-rc5-git6 (at the moment) so I could generate linux-2.6-xen.patch. The repository I have personally is only for the purpose of prototyping this effort. At this point I''m working on going from prototyping to integration, which means that instead of using my temporary tree, we''ll use the xen-unstable tree that you have already ported. xen-unstable and xen-ia64-unstable were synced just a couple days ago so it should work well on ia64. Thanks for looking at the changes. I''ll work on eradicating xen-mkbuildtree-pre, but it will probably take a few days at least. Aron
On Fri, 2006-06-02 at 16:54 -0400, Aron Griffis wrote: Hi> I agree that it''s an ugly hack. But please consider two things: > > 1. If you look at the revision history for xen-mkbuildtree-pre (at the > link I posted above) you''ll see that it''s down from 12 files to > 2 in the past month. We''re working hard on getting rid of it > completely.That is one steep in the right direction :)> 2. The two files that are left have zero chance of confusing your > patching process. One is regenerated on every build > (asm-xsi-offsets.h). The other is planning to be moved soon.It is my understanding that you generate this file during the hypervisor building, right. Just now, we are not generating file from the hypervisor, but we could generate it.> > If you already have a different repository, why don''t you _just_ put > > that files into the right place in the 1st place? >> Now I''m the one that''s confused! :-(Sorry, to confuse you.> I don''t have a different repository. I have a temporary > xen-ia64-unstable tree ported to 2.6.17-rc5-git6 (at the moment) so > I could generate linux-2.6-xen.patch. The repository I have > personally is only for the purpose of prototyping this effort.ok, s/repository/tree/, or s/repository/local repository/. You are already patching the xen-unstable tree. Your patch contains several changes. Why don''t you add just two files instead of a script that generates two links to two files that you also included in your patch? I am losing anything? Or could you, instead of generate the script that links the files, just include the files in the right place?> At this point I''m working on going from prototyping to integration, > which means that instead of using my temporary tree, we''ll use the > xen-unstable tree that you have already ported. xen-unstable and > xen-ia64-unstable were synced just a couple days ago so it should work > well on ia64.Actually we use linux-2.6-xen instead of xen-unstable because it is a _real_ tree, and make everything _so_ much nicer :) What I don''t understand is: a- all your changes are on xen-unstable, then they should also be on linux-2.6-xen, and you should do nothing, everything should be fine. b- some of your patches are not on xen-unstable, and you need to send me a patch. If you have to send me a patch to put on top of my linux-xen patch, then you can also include that two missing files instead of one sript that generates a link to them? I am missing anything? _> Thanks for looking at the changes. I''ll work on eradicating > xen-mkbuildtree-pre, but it will probably take a few days at least.A few days is not a problem at all :) Later, Juan.