26.10.2010 15:01, Erich Titl пишет: > >> compiling test for i686 will add approx 35% more points comparable to >> i386 (using Geode LX); on my Athlon II difference in this test was near >> 25% for i386 and i686 - IMHO good reason to maintain some branches. > Yes, but not complete branches, just the hardware dependent parts. Also > I think the main branch should not depend on all the funny things. > IMHO it'll be good not for only hardware-dependent parts, but also it will be good for all packages that can consume much CPU time. For ex., uClibc and gcc library routines (that are used in almost all packages), busybox (because it can be used as interpreter of complicated scripts - like one in hsh package that generates htb hash tree of classes for specified subnet), maybe - proxy...
> For example, what sense does it make to detect that a certain board has > ISDN hardware if noone ever needs it, all it takes is that there are the > drivers available somewhere. > > Can we make the hardware detection optional? > Hardware detection now just one script and corresponding menu item for it. It consumes no resources at all, but for it's work it requires system with ~64MB RAM (because initramfs can be up to half of available RAM, and it must place all modules from modules.tgz). > >> Possible, in near future it'll be good to add x86_64 branch (for higher >> performance on new hardware - because this distro suitable not only for >> home routers) - but it'll require some work and isn't trivial.Especially >> if it'll be 'true' cross-compilation, on i386 (or other incompatible) >> platform. > Right, automatisms are difficult to realize with a multi platform > environment. > It isn't really so hard to realize cross-build (it will require stage1 gcc compiler + binutils in separate directory compiled for host arch, and stage 3 gcc libs for target arch; also it'll require perl and possible some other binaries that are built for host arch), just current buildtool and other packages aren't targeted for this.So it'll require a lot of work to adapt all to cross-platform building, this work will grab much time, but isn't too hard. >> Also I think that for i686 branch it'll be good to enable PAE - at least >> for NX bit support, which will make LEAF systems less exposed to buffer >> overflow-based remote attacks that oriented on taking shell. > Again, just on hardware that supports it. I _believe_ for example, that > one of our targets is the ALIX board which, at the moment, comes at 256 MB > AFAIK all i686+ CPUs support PAE - so i686 kernel with PAE will not cause troubles on it. >> In any case, anybody who needs support for specific rare hardware, > i486 is _not_ rare, probably more the default on our user base. > > cheers > > Erich > Ok, in my country we have some differ realities - i486-based devices are represented by generic i80486 (and i486 clones by other manufacturers) PCs, and that devices are enough rare (I even don't know who uses 15 years old i486 PCs in my city - except some classes in schools/universities). And as SOHO routers used china MIPS devices like DIR-300. So if you say that i486 are still actual - for easier maintenance (in cost of resulting performance - IMHO near 10-15% performance loss compared to i686 for user-land software) we can compile all user-land software for i486, but kernel (with initrd & modules) we must provide separately for each of supported architectures. ------------------------------------------------------------------------------ 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
