Am 27.12.2012 15:24, schrieb Yves Blusseau: > > Le 26 déc. 2012 à 00:01, KP Kirchdoerfer <kap...@users.sourceforge.net> a > écrit : > >> Hi; >> >> sorry for the delay - I started the discussion and then went offline :( >> >> Am 21.12.2012 10:21, schrieb Yves Blusseau: >>> >>> Le 19 déc. 2012 à 17:46, KP Kirchdoerfer <kap...@users.sourceforge.net> a >>> écrit : >>> >>>> Hi Gents; >>>> >>>> I'd like to make a proposal for the timeframe and features of the second >>>> alpha version of 5.0. >>>> >>>> First of all, I think it should still be an alpha version - so neither >>>> the kernel nor the uClibc are fixed. >>>> >>>> Also the major goal for 5.0 to support other cpu architectures misses at >>>> least one image/example. >>>> >>>> We saw over 100 downloads of alpha1 and received no complaints so far, >>>> so I consider for X86_32 even an alpha1 version was not bad. >>>> >>>> Along with usual Package updates and fixes, the new features for the >>>> second alpha could be a X86_64 image and to "enable" zram support at >>>> least, and eventually offering signed packages. >>>> >>>> As far as I'm aware a X86_64 version currently needs >>>> - a patch for vsftpd >>>> - a solution for the uClibc loader (lib/ld-uClibc-0.9.33.2.so vs >>>> lib/ld64-uClibc-0.9.33.2.so >>>> - and images (AFAIR it worked without changes) >>> >>> About the uClibc shared library, i've already start to discuss about this >>> with Andrew. Look at the messages with x86_64 toolchain subject. >>> Actually we are 2 solutions: >>> * Patch the toolchain so the library will always be: /lib/ld-uClibc.so >>> * Add a variable and put the right name for every toolchains >> >> Ouch, I missed that part in the thread, just read the stuff about the >> compilation with gcc. Reread, and my vote goes for option 2. > > Option 2 is: use a variable in every toolchain ?
I thought this pointed to to your proposal about including $(toolchain).files in initrd/buildtool.cfg. Though it does not work yet, and it has a slight drawback, that we need a file which defines the loader for each architecture, even if only the X86_64-bit version is known to require that change, I prefer this option over patching uClibc... > > Andrew was talking also to create symlinks. Haven't read that, and no code yet. In either way, I hope we'll find a good solution, cause that's the only remaing task IMHO for a second alpha version of 5.x. >> >> >>>> >>>> About zram support, I've lost track about it's status. >>>> I know some changes has been made in master (like swap support in the >>>> kernel), others seems to be merged into next branch (like changes to >>>> conf/images/common/leaf.cfg) - don't know what other changes ended in >>>> which repository..., and finally it lacks any documentation how to >>>> enable and to make use of it. >>> >>> The zram support is in the topic branch: buc5-zram-support >>> >>> This branch as been merged in next but not in master. If we decided to >>> integrate it, we only have to merge the topic branch into master. >>> >>> For the configuration there are a new variable: zswap_size that can be >>> defined in leaf.cfg. >>> The values can be: >>> -1 = disabled >>> 0 = auto >>> other = size of sram swap partition >>> >>> Default is -1, but for our images i fixed it to 0 (in >>> conf/image/common/config.cfg) >> >> I'd like to integrate it now - if disabled it won't cause any harm, when >> enabling it, it (hopefully) just works and we'll have the chance to get >> feedback. >> >> If we agree, can you pls merge the topic branch into master? > > Branch buc5-zram-support merged info master. > next branch was reset to master because now it's the same. > Branch buc5-zram-support deleted. thx. >> I'll try to take of the documentation. > > Go ahead :D ok :) kp ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
