Frans Meulenbroeks skrev:
2010/10/22 Ulf Samuelsson <[email protected]>:
Koen Kooi skrev:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 21-10-10 10:43, Frans Meulenbroeks wrote:
PS: my opinion is that machine maintainers generally know better what
kernel works best for their machines than distro owners;
And what's stopping them to put DEFAULT_PREFERENCE_machine and
COMPATIBLE_MACHINE in the kernel recipes?
There is no technical reason for setting it in machine.conf, so why
should we break the orthogonality for that?
PPS: what's next? removing the PREFERRED_PROVIDER_virtual/kernel from
the machine configs because you feel you know better ?
That is actually an option these days since most kernel recipes set
COMPATIBLE_MACHINE correctly :)
But seriously, there are use cases for one distro to use a different
kernel for a given machine for whatever reasons.
This whole situation is a mess because recipes/linux is a mess. It would
be a nice topic for OEDEM to see if we should switch to a poky BSP
model. It would boils down to:
1 bblayer per machine or SOC_FAMILY containing:
* machine.conf
* first and second stage bootloaders
* kernel
I have already come to the conclusion that we could have a single linux.bb
recipe.
This assumes that you define things like KERNEL_VERSION, SOC_FAMILY
etc. outside the recipe and then include files with include filenames
containing approproate ENVIRONMENT variables.
I.E:
include $(KERNEL_VERSION)/kernel_source
include $(SOC_FAMILY)/$(KERNEL_VERSION)/kernel_patch
etc.
Isn't that what kernel.bbclass is about ?
Wrt your example:
instead of
include $(KERNEL_VERSION)/kernel_source
you could say:
at the place where you define kernel_source:
SRC_URI = "..."
Basically what you propose is kind of a template.
Didn't study kernel.bbclass.
A problem with this approach, is that different kernel version
are located in different directories.
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.36-rc8.tar.gz
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.36.tar.bz2
If we want to have a single linux.bb file, then it
seems to be cleaner to have an include file per kernel version which
specifies both the directory and the file name.
$(KERNEL_VERSION)/kernel_source would then contain
SRC_URI =
"http://www.kernel.org/pub/linux/kernel/v2.6/linux-$(KERNEL_VERSION).tar.bz2"
for a stable kernel, and
SRC_URI =
"http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-$(KERNEL_VERSION).tar.bz2"
for a release candidate.
One this file is created for a kernel version, it would require little
or no maintenance.
Similar files in the SOC_FAMILY directory structure would control which
minor patch as well as other architecture specific patches to be added.
Frans
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
