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