Mailing List Archive

While part of the previously sent patch was integrated, things still
don't work as expected. Namely is it now impossible to specify an
INSTALL_PATH that doesn't end int /boot.

Jan

On Thu, Jan 05, 2006 at 06:01:55PM +0100, Jan Beulich wrote:
> While part of the previously sent patch was integrated, things still
> don't work as expected. Namely is it now impossible to specify an
> INSTALL_PATH that doesn't end int /boot.

I think it works as expected:
INSTALL_PATH ending in /boot gets the kernel installed to $INSTALL_PATH and
headers installed to $INSTALL_PATH/../usr
INSTALL_PATH not ending in /boot gets the kernel install to $INSTALL_PATH/boot
and headers installed to $INSTALL_PATH/usr

With your patch, the behaviour in the second case would change such that
the kernel is at $INSTALL_PATH and headers in $INSTALL_PATH/usr, which is
rather odd!?

christian


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

>>> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> 06.01.06 11:48:12
>>>
>On Thu, Jan 05, 2006 at 06:01:55PM +0100, Jan Beulich wrote:
>> While part of the previously sent patch was integrated, things
still
>> don't work as expected. Namely is it now impossible to specify an
>> INSTALL_PATH that doesn't end int /boot.
>
>I think it works as expected:
>INSTALL_PATH ending in /boot gets the kernel installed to
$INSTALL_PATH and
>headers installed to $INSTALL_PATH/../usr
>INSTALL_PATH not ending in /boot gets the kernel install to
$INSTALL_PATH/boot
>and headers installed to $INSTALL_PATH/usr
>
>With your patch, the behaviour in the second case would change such
that
>the kernel is at $INSTALL_PATH and headers in $INSTALL_PATH/usr, which
is
>rather odd!?

No, that's the correct way. Whatever INSTALL_PATH is pointing at
(namely e.g. /), this should be the place where the kernel images get
placed. If the boot loader lives in and looks only at /, then the
current way of installing will make the installed images unusable.

The oddity of how the /usr path is determined is the more questionable
part, I just made it that way (in the original patch) to prevent
removing any functionality. Generally I don't think installing header
files should be done together with the kernel (no other part of the
kernel does anything similar). Hence I'd generally favor removing this
part of the installation altogether.

Even beyond that, for consistency the architecture's install.sh should
be used for installing the kernel, primarily to automate
initrd/initramfs generation. I have such a patch in place all the time
locally, and I had posted that long ago to xen-devel. I would be more
than happy if that could also get integrated...

Jan

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

On Fri, Jan 06, 2006 at 12:12:04PM +0100, Jan Beulich wrote:
> >>> Christian Limpach <Christian.Limpach@cl.cam.ac.uk> 06.01.06 11:48:12
> >>>
> >On Thu, Jan 05, 2006 at 06:01:55PM +0100, Jan Beulich wrote:
> >> While part of the previously sent patch was integrated, things
> still
> >> don't work as expected. Namely is it now impossible to specify an
> >> INSTALL_PATH that doesn't end int /boot.
> >
> >I think it works as expected:
> >INSTALL_PATH ending in /boot gets the kernel installed to
> $INSTALL_PATH and
> >headers installed to $INSTALL_PATH/../usr
> >INSTALL_PATH not ending in /boot gets the kernel install to
> $INSTALL_PATH/boot
> >and headers installed to $INSTALL_PATH/usr
> >
> >With your patch, the behaviour in the second case would change such
> that
> >the kernel is at $INSTALL_PATH and headers in $INSTALL_PATH/usr, which
> is
> >rather odd!?
>
> No, that's the correct way. Whatever INSTALL_PATH is pointing at
> (namely e.g. /), this should be the place where the kernel images get
> placed. If the boot loader lives in and looks only at /, then the
> current way of installing will make the installed images unusable.
>
> The oddity of how the /usr path is determined is the more questionable
> part, I just made it that way (in the original patch) to prevent
> removing any functionality. Generally I don't think installing header
> files should be done together with the kernel (no other part of the
> kernel does anything similar). Hence I'd generally favor removing this
> part of the installation altogether.

I agree, I think we shouldn't install the header files from the linux
kernel build. It would be great if you had a patch which got the headers
installed from the xen-unstable build system...

> Even beyond that, for consistency the architecture's install.sh should
> be used for installing the kernel, primarily to automate
> initrd/initramfs generation. I have such a patch in place all the time
> locally, and I had posted that long ago to xen-devel. I would be more
> than happy if that could also get integrated...

I think this would also be preferable. Please send the patch again.

The only open-issue is how and where to build vmlinuz. My preference
would be to not do it in the boot-xen sub-directory at all but build it
directly from the arch/{i386,x86_64}/Makefiles. It seems insane to me
to type "make vmlinuz" at the top of the tree resulting in the file
being created 3 levels further down in a non-obvious location.

christian


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

>I agree, I think we shouldn't install the header files from the linux
>kernel build. It would be great if you had a patch which got the
headers
>installed from the xen-unstable build system...

I don't; at present I simply don't care about them and (in my private
trees) suppress their installation.

>> Even beyond that, for consistency the architecture's install.sh
should
>> be used for installing the kernel, primarily to automate
>> initrd/initramfs generation. I have such a patch in place all the
time
>> locally, and I had posted that long ago to xen-devel. I would be
more
>> than happy if that could also get integrated...
>
>I think this would also be preferable. Please send the patch again.

Attached (applies cleanly only with the other patches applied before).
I don't have an up-to-date path for the unstable tree at hand.

>The only open-issue is how and where to build vmlinuz. My preference
>would be to not do it in the boot-xen sub-directory at all but build
it
>directly from the arch/{i386,x86_64}/Makefiles. It seems insane to
me
>to type "make vmlinuz" at the top of the tree resulting in the file
>being created 3 levels further down in a non-obvious location.

Again, while I agree that this seems more logical, there are two
arguments against it:
- it is inconsistent with how native i386/x86-64 work
- it pointlessly clutters the tree root with additional files

Jan

On Fri, Jan 06, 2006 at 01:38:54PM +0100, Jan Beulich wrote:
> >> Even beyond that, for consistency the architecture's install.sh
> should
> >> be used for installing the kernel, primarily to automate
> >> initrd/initramfs generation. I have such a patch in place all the
> time
> >> locally, and I had posted that long ago to xen-devel. I would be
> more
> >> than happy if that could also get integrated...
> >
> >I think this would also be preferable. Please send the patch again.
>
> Attached (applies cleanly only with the other patches applied before).
> I don't have an up-to-date path for the unstable tree at hand.

This is not quite what I had in mind -- I was hoping we could move all
of the install code into the script and have a xen one.

So, with the patch below, won't we then be using the regular i386
install.sh if we try installing to /boot (or /)? That seems rather
optimistic...

> >The only open-issue is how and where to build vmlinuz. My preference
> >would be to not do it in the boot-xen sub-directory at all but build
> it
> >directly from the arch/{i386,x86_64}/Makefiles. It seems insane to
> me
> >to type "make vmlinuz" at the top of the tree resulting in the file
> >being created 3 levels further down in a non-obvious location.
>
> Again, while I agree that this seems more logical, there are two
> arguments against it:
> - it is inconsistent with how native i386/x86-64 work

Neither of them build a vmlinuz target/file in the first place, how
can it be inconsistent?

christian


_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge

>This is not quite what I had in mind -- I was hoping we could move all
>of the install code into the script and have a xen one.
>
>So, with the patch below, won't we then be using the regular i386
>install.sh if we try installing to /boot (or /)? That seems rather
>optimistic...

Why? How is the xenolinux kernel different from a native one?

>> Again, while I agree that this seems more logical, there are two
>> arguments against it:
>> - it is inconsistent with how native i386/x86-64 work
>
>Neither of them build a vmlinuz target/file in the first place, how
>can it be inconsistent?

They build a bzImage instead, which is the exact equivalent of
vmlinuz.

Jan

_______________________________________________
Xen-merge mailing list
Xen-merge@lists.xensource.com
http://lists.xensource.com/xen-merge