19.10.2011 17:38, Erich Titl пишет: > Hi Folks > > at 19.10.2011 14:46, Andrew wrote: >> Hi. >> >> 18.10.2011 21:41, KP Kirchdoerfer пишет: >>> On the other hand, I'm currently thinking about the idea to build a "later" >>> branch to testdrive uClibc 0.9.32. I haven't tested the already built >>> packages and images in production, but a first try looks promising (see Trac >>> ticket #36). >> Yes, I also thinking on new '5.0' branch, with fresher kernel, uClibc >> (it seems like 0.9.32 has nptl - so stack protection in gcc can be >> enabled), reworked toolchain (with separated 'host' and 'target' >> binaries and more common way toolchain assembly w/o magic tricks and >> dirty hacks) to make possible cross-compilation for/on other platforms >> and so on. I think I'll have time to start new branch in some weeks when >> I made some changes to buildtool and check them. > Wouldn't you think we should straighten out 4.x before thinking about > 5.x, and I mean no known bugs whatsoever. > > I have no idea how far the acceptance of 4.x went. For myself I have not > dared yet to upgrade our production firewalls to 4. One of the reasons > is that we are running them in a 7x24 environment. Another reason is the > missing seamless upgrade path. > > What do you reckon native threads will buy us, typically there are few > processes running on a firewall. What kernel issues have we identifid > which force us to upgrade and if we have them why not go for a 4.x. > > In my numbering environment a 5 would mean something completely > different, like kernel 3 or support for multiple processor architecture > or a completely revamped build environment. > > my 0.000002 gold grams (can't trust the bloody money anymore) > > Erich > I mean '5.0' because it'll have newer kernel (3.0/3.1/newer - really 3.x kernel versioning doesn't mean great difference from 2.6.x branch)/toolchain (versions and directory structure)/etc; toolchain reorganization should give possibility to build packages for different architectures.
About uClibc - NPTL is required for enabling GCC stack protection; also uClibc 0.9.30.3 conflicts with some packages (asterisk, yate). Upgrading kernel is also enough important - on 2.6.38 and newer versions global lock aka 'big kernel lock' is removed and this should improve performance on SMP systems. And, in any case, opening new branch doesn't mean stopping of work on 4.x branch; 5.x looks like it requires a lot of modifications and IMHO it'll require months of work till beta release (one of 'heavy' steps - full review of makefiles to remove building hacks) - in that time 4.x can be developed - all fixes from userland (version upgrading and so on) can be easily imported in 5.x branch. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
