On 30/10/12 18:36, KP Kirchdoerfer wrote:
> Hi Gents;
>
> After some talks about beta alpha and whatever, I'm lost about what
> should happen next :)
>
> I'll try to summarize and want to make a proposal.
>
> Main points discussed are the kernel, the toolchain, uClibc and an image
> beyond X86-32.
>
> I think the uClibc version is fixed - especially since uClibc is
> seldomly updated before a release (don't know why, but this a twice in
> the past :)). Seriously, the current version works for X86 pretty well
> and even compilation of arm-versatile and X86-64 seems to be without
> major pb's. Therefor I don't see an urgent need to wait for a new version.
uClibc currently doesn't support native threads on ARM, maybe this'll be 
fixed in future releases. In any case, uClibc version should be frozen 
in beta, not alpha.
> The toolchain has had a major rework and improvemnts and proved to be
> able to compile for different architectures (plus it's a lot faster to
> build than buildenv) - not to mention that it's more convenient to use.
> It may be necessary to apply fixes, if we move further building images
> for other architectures, but I do not expect, that the general design
> will change.
>
> There has been proposals to update the current 3.2.x kernel. I voted to
> stay with the 3.2 kernel, which is well tested, Andrew voted for a 3.4
> kernel, Yves asked for a more recent one, but also pointed out a few
> weeks, that the 3.4 kernel is also a long-time kernel (until 2014,
> whereas the 3.2 kernel will receive updates until 2015 AFAIK).
We may switch to newer kernel in future or even have multiple kernels.
For non-x86 arch, for ex., there are patches in OpenWRT that are applied 
to 3.2/3.3 kernels, but may be ported to 3.4 with additional work.
> We have no real image for anything beyond X86-32 - that's true. But we
> do have a proof-of-concept.
I think that image for x86_64 isn't a trouble. It seems that it's 
compiled OK.
For embedded platforms things are worse, they requires kernel patching, 
some logic rework (for ex., include overlayfs to mount tmpfs on top of 
r/o root instead of copying all to tmpfs - for memory saving), and a lot 
of experiments.
> My proposal is that we prepare and release alpha version, which means
> that uClibc version and the toolchain are almost done and ready to work
> with. So these will only change, if necessary.
>
> Note: The X86-32 images (i686, i486 and geode), improved compared to the
> 4.x version, and could be considered ready-to-test. So this could  be a
> win for early adopters, and hopefully we'll get somne feedback.
>
> Until beta1 there will be time to
> a) working and test a newer kernel - which should be 3.4 IMHO; it has
> some interesting new features (teaming ethernet devices...) and is also
> an long-time kernel
> b) working on one or more additional images for a different architecture
>
> Yves, git-wise that shall happen in "next" branch?
>
> What's missing IMHO for the alpha version?
> I only see one interesting chapter in the Developer Guide ("using
> buildtool.pl") that needs an update.
> Maybe even a X86-64 version can be build???
>
> What do you think?
>
> kp
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
> _______________________________________________
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct

_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to