Message-ID: <49DA4E6E.5060600@nothome.org>
Date: Mon, 06 Apr 2009 14:48:14 -0400
From: Nathan Angelacos <nangel@nothome.org>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
Precedence: list
MIME-Version: 1.0
To: Natanael Copa <natanael.copa@gmail.com>
CC: Alpine-devel <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] xen support in default kernel
References: <1239028357.26439.24.camel@nc>
In-Reply-To: <1239028357.26439.24.camel@nc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Natanael Copa wrote:
> The default kernel (named linux-grsec in 1.9.x) have paravirt enabled. A
> user here asked for xen support too which is not there currently.
> 
> The problem is that this requires that kernel is compiled for i586. We
> currently do 486.
> 
> IIRC there was some newer cpus (found in TU-40?) that basicly is a
> faster 486 CPU.

Looks like the TU-40 is a 586 chip.  The Ebox-2300SX was a custom "486" 
chip, but was basically unusable anyway - they got rid of it and moved 
to a 586 chipset
> 
> So, the question is, should we say that i596 is required for default
> kernel, and support xen paravirtualization by default? Or should we make
> a separate xenlinux kernel, with full xen support (live migration etc).
> 

i586 should be sufficiently ancient, IMHO.  Looks like even the AMD 
Geode processors on PC Engine's Alix boards will work with i586.


> I tend to think that the default kernel should work with as much as
> possible, but have some optimized kernel flavors for different needs.
> For example linux-grsec for the real lowend without highmem, smp and
> largblock deveices.
> 
> The drawback with many kernels is that it takes some extra time to
> compile things. For example dahdi-linux driver and iscsi dirvers will be
> need to be recompiled for each kernel flavor. This should ideally be
> fully automated, but it is not right now.
> 

Just wonder if "custom kernel" means "you compile it yourself"  - this 
might be a place for more volunteers to step forward and maintain the 
custom kernels, if they desire.







---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---