Re: [Xen-devel] [PATCH] build in SATA drivers to the -xen kernel for x86_64

[Sean Dague <japh@xxxxxxxxxx>]

On Wed, Mar 29, 2006 at 07:19:18PM +0100, Keir Fraser wrote:
> 
> On 29 Mar 2006, at 19:07, Sean Dague wrote:
> 
> >This patch adds in the SATA drivers that are supported in the -xen0 
> >kernel.
> >Because the default behavior of xen is to reboot on a dom0 crash (i.e. 
> >not
> >finding root filesystem), and the xen0 kernel supported SATA directly, 
> >a
> >number of people (including myself) got caught by the switch over.
> >
> >Long term, we probably want to modularize more of the kernel, and make
> >initrd building more of the default, however this should ease people's
> >transition from the -xen0 => -xen kernel for testing on x86_64.
> 
> If this is done at all, it should be done for i386 as well. I think 
> it's debatable really -- -xen is supposed to be a modular kernel build. 
> If people want stuff built in they should modify the config or use 
> -xen0.

Well, SATA is significantly more relevant for x86_64, as a very large
percentage of x86_64 systems are SATA based.  I doubt that even 1/2 of the
IDE controllers that are compiled in by default for the x86_64 kernel have
ever existed in an x86_64 system.  If we're shooting for truely modular, we
should start removing the IDE drivers from the -xen kernel.

I would agree that changes here are debateable, however given that xen
default behavior is to reboot on dom0 fail (i.e. no screen log unless on
serial), a large number of users have been tripped up by this process on the
-xen kernels, and will find it hard to debug.  The approach of making the
-xen0 storage drivers also on in the -xen kernel just makes it a bit more
predicable.  (i.e. -xen == -xen0 + lots of other device support).  While it
isn't that today, I think it would make more sense if it was that way.  But
then again, that's just my $0.02. :)

An alternate (or even in addition to any changes to the -xen kernel) would
be to default xen behavior to "noreboot", which would make it a lot clearer
to users *why* their system doesn't come up with Xen on the first try.

        -Sean

-- 
Sean Dague
IBM Linux Technology Center                     email: japh@xxxxxxxxxx
Open Hypervisor Team                           alt: sldague@xxxxxxxxxx

Attachment: pgpsBEws9HwHt.pgp
Description: PGP signature

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