On Sat, 2010-10-30 at 22:31 +0200, KP Kirchdoerfer wrote:
> Am Samstag, 30. Oktober 2010, 22:01:17 schrieb Andrew:
> > 30.10.2010 22:44, KP Kirchdoerfer пишет:
> > > Am Samstag, 30. Oktober 2010, 19:56:41 schrieb Andrew:
> > >> 30.10.2010 20:37, KP Kirchdoerfer пишет:
> > >>> Am Samstag, 30. Oktober 2010, 19:19:03 schrieb Andrew:
> > >>>> 30.10.2010 19:45, KP Kirchdoerfer пишет:
> > >>>>> What about the kernel??
> > >>>>> kp
> > >>>>
> > >>>> IMHO we need to provide different kernels; one - for legacy i486 or
> > >>>> Geode (or even separate kernels), and one - with SMP, more than 4GB
> > >>>> memory support (at least - for PAE enabling, for NX bit) for PentiumII
> > >>>> or higher.
> > >>>
> > >>> I agree, but IMHO it's a long/middle term goal (beta2 or 3).
> > >>> To get a beta 1 done I think a generic kernel based on the 486
> > >>> processor will be enough for a start (the Bering-uClibc series worked
> > >>> out well, with only one kernel - no objection, if we improve it during
> > >>> the release cycle).
> > >>>
> > >>> I believe the main target for beta1 is to detect remaining bugs and to
> > >>> provide a proof-of-concept (or slightly more - I run Bering-uClibc4
> > >>> for weeks in production).
> > >>>
> > >>> Different kernels are nice-to-have, but IMHO it requires a lot more
> > >>> work, thoughts and testing - and esp. for testing, users who started
> > >>> to use Bering- uClibc4 (with the first beta).
> > >>>
> > >>> kp
> > >>
> > >> It isn't too hard to built some packages for different kernel arch
> > >> without deep config cleaning (just one like current i686 with SMP but
> > >> possible with 64GB RAM support - for PAE and dependent NX bit support,
> > >> and one generic i486 w/o SMP - like your), later we can do clean-up. 1st
> > >> kernel will be very suitable for ISPs (like as own company), and 2nd
> > >> kernel - for small devices like Alix board. I think that enough ISPs
> > >> needed something like this - and some of them tried to develop their own
> > >> distro (for ex., GlobalOS by nuclearcat - which isn't modular, is huge
> > >> comparable to Bering-uClibc, has no documentation except one very tine
> > >> howto page + forum thread, and it's configs are poor).
> > >>
> > >> Also, i686 SMP kernel is tested and looks stable (i use it under enough
> > >> heavy loads - after GCC update to 4.4.5 no troubles noticed), i486 -
> > >> even still not assembled.
> > >
> > > Andrew;
> > >
> > > no doubt that different kernels and esp. a
> > > fully-686-SMP-"whatever"-optimized one are a huge benefit. I also like
> > > the Geode enhancements for the Alix system I use.
> > >
> > > I don't know how easy it'll be to build different kernels (and related
> > > packages) with buildtool yet and how to provide, just never done that
> > > before.
> >
> > IMHO it isn't so hard. It just requires modification of EXTRAVERSION in
> > kernel Makefile + config replacement before building for each arch; +
> > modify modules path for initrd and moddb (make two packages, like for
> > v3.x different versions). I'll try this tomorrow.
>
> Ok, let's see what you'll find out...
>
> > > I also understand that your 686 kernel seems as well tested as the geode
> > > one.
> > >
> > > My main point is that we should start with a kernel for beta1, that
> > > anyone can use, regardless the processor he runs LEAF - the most common
> > > denominator. And to walk from there to more special kernels later.
> > >
> > > That way the user base, who can testdrive beta1 would be as great as
> > > possible. A beta1 that just runs out of the box for a 686 processor
> > > sounds to me to unnecessarily restrict the possible user base.
> > >
> > > kp
> >
> > Providing generic i486 non-SMP version of distro, we'll also reduce
> > users base, especially qualified users like ISP system administrators.
>
> It's no question, that I'd like to support those as well.
> But I do not expect ISP system administrators running a beta1 in production.
> I
> believe they want to testdrive a largely overhauled version in a testbed and
> see if it's bug-free.
>
> If it won't be that hard to produce different kernels, it'll be fine with me.
>
> kp
>
IMHO, if we plan to support multiple kernel variants "soon" (i.e. beta2
or beta3) - and I do think that we should do that - then we should make
the changes to buildtool to enable that "now", i.e. for beta1. Even if
beta1 only ships with a single variant, I would like to have the
framework in place to support multiple variants later, to reduce the
changes to buildtool for future beta releases.
I agree that the changes to support this should be fairly minor:
- An extra directory level for staging/ and build/ (and others?) to
reflect the kernel variants - i486-generic, i686-smp or whatever
"labels" we choose
- A new command-line argument for buildtool.pl and buildpacket.pl to
specify the choice of variant (with a default)
- Some way of patching the kernel .config based on the architecture
"label" specified
- The unpatched .config will be the default architecture
- Perhaps the set of patch files (following a good naming
convention) will define the list of supported architecture variants?
dMb
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
