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