Machine and Submachine about meta-sunxi HOT 10 CLOSED

Hi,

In principle, I think it is a very good idea to centralize common code, and avoid code duplication :)

I do not fully understand the proposed SUBMACHINE/MACHINE approach, though; could you perhaps provide an example?

A related approach I have seen used by others, and which I like, is centralizing all common code in an include file, and include that file in the actual machine code files.
See the machine files in http://cgit.openembedded.org/meta-handheld/tree/conf/machine/ for an examples of such a scenario, e.g. http://cgit.openembedded.org/meta-handheld/tree/conf/machine/palmld.conf, which includes a base "palm.conf", which is re-used for all the different palm* versions.

But I think you intend to avoid code duplication in other areas?

Thanks,

Kristof

from meta-sunxi.

hum,
yes it's more or less what i begin to do with the include of sunxi.inc in https://github.com/linux-sunxi/meta-sunxi/blob/master/conf/machine/cubieboard.conf for example.
Maybe submachine is not the right thing finally, and declare as many machine as we have is the best option. Exactly as it's done in the meta-handled layer.
Thanks to point this links:)

from meta-sunxi.

as you said it's more or less like sunxi.inc and meta-handeld is a good example on how to keep it clean, i wouldn't add more complexity with submachines right now.

from meta-sunxi.

One thing that could be good to have is only one defconfig for all boards. For now we have all boards with their own defconfig and they all have differences that shouldn't be (in mele/meleg many things are compiled statically, and in cubieboard2 they are compiled as modules). As it is, it's a pain to build an image to another board as kernel modules are not the same, and so on...

What should be done is having everything that could be different as modules, and use MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-blabla" in each machine config, and build the kernel with the same defconfig for all sunxi boards.

What do you think?

from meta-sunxi.

Yes, making those differences modular, and using module includes in the machine.conf files that need the modules, sounds like a very good idea to me.

But, is it possible to have the same defconfig for all boards? I guess we need at least split between A10/A20, which map on sun4i/sun7i defconfigs available at https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.4/arch/arm/configs?

If possible, I think it would be nice to use the linux-sunxi defconfigs as reference (rather than manually including the file), and providing a means to amend these as necessary (e.g. through a patch file, but there might be more elegant ways?).
We can then even try to submit these patches upstream, to get them included in the linux-sunxi tree - if those amendments are useful to us, they are probably useful for others as well.

from meta-sunxi.

yes sounds good, having a defconfig per cpu architecture (sun4i, sun5i, sun7i) will be better.
Currently we are using a recipe wich is copying the defconfig, we need to change the behaviour to use the arch/arm/config file. You know recipes who does that ?
There is couple of changes that i saw, like adding the spidev module, it's usefull for developping with spi in userspace, and maybe others ?

from meta-sunxi.

i think you can do something like this:

add

KERNEL_DEFCONFIG = "sun7i_defconfig"

in all machine configs (using sun4i... when appropriate), then in kernel recipe:

addtask setup_defconfig before do_configure after do_patch
do_setup_defconfig() {
# copy defconfig
cp ${S}/arch/arm/configs/${KERNEL_DEFCONFIG} ${S}/.config
}

or:

do_configure() {
oe_runmake ${KERNEL_DEFCONFIG}
}

i admit i don't like it very much, i prefer the current approach with per-machine defconfig.
But i know there are pro and cons for both approaches so i'm not strongly against changing it.

from meta-sunxi.

OK, and amending the default defconfig could then happen through patching, right?

Need to try it out, but I think that would work for me.

For additional flexibility, perhaps we should consider extending the code above to check for a local defconfig; if it exists, use it, otherwise, use the default one - to allow people to provide a complete custom defconfig if desired. That would seem to combine the best of both worlds?

from meta-sunxi.

I had a look at other linux recipes at http://layers.openembedded.org/layerindex/branch/master/recipes/?q=linux&page=3, and all of them seem to rely on a local defconfig.

At this point, I am not sure whether trying to standardize on a single (or a few) defconfigs is worth the effort - I have to admit that, in practice, I'd probably be using the local custom defconfig option in any case, to maintain full control.

But, if anyone is willing to try to implement this, I'd be happy to test it, and consider using it.

from meta-sunxi.

I'm closing this, if someone wants to experiment or suggest a solution reopen it or submit a new issue.

from meta-sunxi.