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. Frans _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
