[Pkg-xen-devel] Re: [Pkg-xen-changes] r70 - trunk/xen-3.0/debian

[Ralph Passgang]

Am Mittwoch, 8. März 2006 15:43 schrieb Goswin von Brederlow:
> Ralph Passgang <ralph at debianbase.de> writes:
> > Am Sonntag, 5. März 2006 18:42 schrieb Bastian Blank:
> >> On Sat, Mar 04, 2006 at 07:43:23PM +0100, Ralph Passgang wrote:
> >> > Am Samstag, 4. März 2006 13:45 schrieb Julien Danjou:
> >> > > Bastian, why did you remove this package in your last commit?
> >> >
> >> > I would like to have an explanation for that too. We believe we don't
> >> > need to remove this package (at least now where all problems with
> >> > upgrading from older versions have been fixed) and it helps to have a
> >> > setup that is easy to setup for new users (because they only need to
> >> > run: "apt-get install xen") and even it helps for upgrading a xen2
> >> > setup to xen3.
> >>
> >> I don't see a dependency against a kernel nor a check if it will boot at
> >> all (this is impossible). A valid upgrade procedure have no point where
> >> it can make the system unbootable. The same problem makes it currently
> >> impossible to do automatic kernel upgrades from sarge.
> >
> > I don't get that.
> >
> > providing kernel images is not the job of the pkg-xen group. And besides
> > that. I don't think a depenendcy for a kernel is really what we want. Of
> > course we would like to have kernel images available within the debian
> > archive, so that it's easy for the user to install a kernel, but we also
> > want that the user can compile his own kernel, so we should use a
> > dependency for a kernel at all.
> >
> > Btw. (luckily) the whole debian distribution doesn't depend on a kernel
> > image anywhere! You can install a complete system without a bootloader or
> > a kernel installed. This is often needed for virtualized systems, or do
> > you install a kernel in a domU? :)
> >
> > so why should xen depend on a kernel image? I don't see a reasion for
> > that.
>
> In fact it may not. It has been discussed for the kernel package over
> and over and the conclusion is always the same.
>
> - A depends on a kernel does not work for custom compiled kernels (non
> make-kpkg) - A installed kernel deb does in no way mean the kernel is
> running - The first time one installs xen there won't be a xen kernel
> running but it should still be possible to install the userspace tools.
>
> So you can't even do a check in preinst for a running xen kernel
> without causing anoyance.
>
> Please don't.

100% ack... suggestions/recommendations should be definitly enough.

> >> > Or why do you cross-compile hypervisors?
> >>
> >> There is nothing cross-compiled there.
> >
> > how do you call it, when you compile a amd64 hypervisor on a i386 box?
> >
> >> > If you use a 64bit hypervisor you have to use a 64bit dom0 kernel and
> >> > you have to use 64bit version of xen userspace tools.
> >>
> >> Bah, they really have allignment issues in some struct.
> >
> > I am not a c-guru in any form and I don't care why a 64bit hypervisor is
> > not really controllable with the 32bit version of the userspace tools,
> > but because thats the way it is, we shouldn't provide a 64bit hypervisor
> > for the normal i386 architecture (and at least for me it looks like this
> > is happening now).
>
> Yes you should.
>
> Sarge i386 has 64bit kernels and the plan has always been to have them
> again in the linux-2.6 source package. That would include the new xen
> flavours. There is no reason not to have a 64bit xen kernel with a
> 32bit userspace. For example this allows for systems with more than 4
> GB ram and swap (but only 4GB virtual address space per 32bit
> process). For this to work you need a 64bit hypervisor though because
> xens structure alignmend is screwed up (by the compiler).

The problem is that the normal i386 userspace tools to control xen domains 
doesn't work with a 64bit hypervisor+dom0 kernel. At least that is what I 
read on the xen-ml more than once.

In general you are right... a user can mix 64bit kernel and 32bit userspace 
(besides for example iptables). But as long as this would led to system where 
no domU can be started & controlled it doesn't make any sense to me to even 
provide a 64bit hypervisor on i386 (at the moment).

I am not a c-guru, so I don't know if this is fixable in future versions of 
xen... if it's fixable we should provide a 64bit hypervisor on i386, but at 
the moment it would only confuse people.

but maybe I am getting this wrong... I should check & test that on my own 
amd64 box. But I have only a clean amd64 setup and not a i386 debianversion 
installed at the moment.

hmmm, in future this might get more complicated anyways, because xen will be 
available on more then just i386 & amd64 in future.

> [Note: iptables gets screwed by this as well]
>
> MfG
>         Goswin

MfG? :)) einen ebenso freundlichen gruss zurueck :-p

--Ralph

>
> _______________________________________________
> Pkg-xen-devel mailing list
> Pkg-xen-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-xen-devel