Hello; Am Montag, 13. Januar 2014, 22:07:22 schrieb Andrew: > Hi. > I think that we should rename ARM_EDITOR var to some more generic name, > because we should be targetted not only for ARM arch (for ex., MIPS). > Maybe, PLATFORM_EDITOR?
Fine with me. > Also, do we really need nano? Maybe it'll be better to use busybox's vi > (it has just some kb size)? I've done that before, but I wanted a usable editor :) But your're right, using busybox vi will save memory and on the rpi I can easily replace it with the editor of my choice. Will add the work for busybox-vi once we'll have a working toolchain again. > Also, we have a lot of small packages (root, etc, config) - maybe it'll > be good to merge them into one package, or even to merge them into > initrd (which will be good for platforms with soldered 4-8 MB flash and > 32-64M RAM, like SOHO routers - for them, it's a good solution to have > big initrd which is mounted as root through unionfs, and all other stuff > is unpacked to tmpfs through unionfs, to save valuable memory). > > ifeq/ifdef are also used into platform makefile includes. Sounds worth testing. kp > 13.01.2014 21:02, KP Kirchdörfer пишет: > > Hi; > > > > Rebased git branch master and now build the toochains (which will take > > hours including testing, but I'm now in the mid of x86 and so far it > > looks good) > > > > I've had a patch for etc on non-arm platforms as well waiting to be > > pushed, > > but I've learned that ifdef/else/endif are possible in our buildtool.mk > > files - which is good to know. > > I've also struggled with git doing a rebase with unmerged commits (hints > > how to deal with it in the docs are welcome, as usual), but at last I've > > managed it somehow. > > > > Am Dienstag, 7. Januar 2014, 21:48:35 schrieb Andrew: > >> 07.01.2014 19:28, KP Kirchdörfer пишет: > >>> Hi Andrew; > >>> > >>> Am Montag, 6. Januar 2014, 19:44:35 schrieb Andrew: > >>>> Hi all. > >>>> > >>>> At least I've got an idea how to easily maintain different targets with > >>>> different kernels, and how to simplify config/patches/etc storing with > >>>> minimum modifications of logic. > >>> > >>> Nice coincidence - I've worked towards a unified kernel for rpi, while > >>> you'll try to manage diffenrent kernel for the architectures :) > >>> > >>> But I do see, the benefits. > >>> > >>> And like you, I've started to use the make/toolchain/*mk files to tweak > >>> different settings for architectures myself. Looks like those files > >>> becomes more important - they are not as "static" as they have been. > >>> > >>> Needs to be clarified in the docs/wiki. > >> > >> Unified kernel is good (esp. 3.10 branch - which has some features like > >> removed route cache, which can add additional performance on powerful > >> routers), but in any case we can in future use different kernels for > >> different archs - and usage of different kernels now is easier. > > > > Some reminders for us: > > > > We do need to have a review of the 3.10 kernel configs, to gain the the > > benefits of the upgraded kernel > > > > The changes how to add a hardware architecture variant should be updated/ > > supplemented for 5.1 (kernel stuff went to > > make/toolchain/[kernel-architecture] > > > > see > > http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_ > > 5.x_-_Developer_Guide_-_Adding_a_Hardware_Architecture_Variant > > > > Either Andrew does himself, or some notes given here, anyone incl myself > > can try to explain what's needed. > > > > It is also my understanding that the linux-headers are now seperated from > > the actual kernel, but I'm not shure how, when we have to take care to > > update them and what has to be done to do. Is that even correct? > > > >> Also now we can use different basic kernel configs for different archs > >> to minimize patches. > > > > Sounds good! And great job! > > > >>>> I've moved kernel version into make/toolchain/<target>.mk, and added > >>>> __TOOLCHAIN__, __KVER__ and __KBRANCH__ macro handlind to source > >>>> filename and dir into buildtool.cfg <File> section. So, specifying > >>>> different kernel versions into make/toolchain/<target>.mk we can > >>>> maintain targets with different kernels. Also this eliminates userland > >>>> dependency from kernel (except some packages with kernel modules). > >>>> > >>>> Also I think that it'll be good to add <MultiFile> macro item to > >>>> specify > >>>> a lot of files in single record (for ex., for kernel sub-arch patches), > >>>> but it seems that it'll require more significant changes into buildenv. > >>>> > >>>> It seems like all is working; I'll try to rebuild tree. > >>> > >>> And did it work? > >> > >> Yes. > >> > >>> How far are we away from rebuilding kernel and userland without touching > >>> the toolchain? This would save a lot time testing stuff. > >>> > >>> kp > >> > >> Now it can be rebuilt separately. Just for simplier usage, we should add > >> separate cleanup for toolchain, kernel and userland. Or even move > >> toolchain to separate buildtool target... > > > > A simplification of building/testing changes is heavily welcome. > > I ran into a lot of packaging failures because of not rebuilding in the > > past, and seperating the toolchain from the kernel and userland will save > > a lot of time... > > > > > > kp > > > _______________________________________________ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
