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

[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.

>> > 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).

[Note: iptables gets screwed by this as well]

MfG
        Goswin