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? Also, do we really need nano? Maybe it'll be better to use busybox's vi (it has just some kb size)?
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. 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 > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
