[oe] [PATCH 1/5] Use common files for AT91SAM9 configuration

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Thu Oct 21 09:53:45 UTC 2010


2010/10/21 Koen Kooi <k.kooi at student.utwente.nl>:
> -----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?

I have no problems with that. We could start a migration process to
achieve that. Guess the machine maintainers should be involved (and if
no maintainer is known, i feel the machine should either get a new
maintainer otherwise we should seriously consider whether we want to
keep the machine).

Then again on the other hand it would be nice to have all machine
specifics in one place (which is an argument for machine.conf), but of
course the distro should be able to override 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.

Agree. I am not saying the distro should blindly follow the machine,
the distro should have the ultimate control of what goes in the
distro, but I feel it is up to the machine maintainer to come with a
set of sensible defaults for that machine (which are applied if the
distro uses the default setting)
>
> This whole situation is a mess because recipes/linux is a mess. It would

Agree!
In a lesser case it also applies for u-boot (where some of the
messiness is hidden in the uboot-git recipe)

> 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 can see some serious issues with that, but that's for another thread
> to discuss.
>
> regards,
>
> Koen

Enjoy, Frans.




More information about the Openembedded-devel mailing list