Khem Raj skrev:
On Wed, Oct 20, 2010 at 4:57 PM, Ulf Samuelsson
<[email protected]> wrote:
Khem Raj skrev:
On Mon, Oct 18, 2010 at 4:10 PM, Ulf Samuelsson
<[email protected]> wrote:
Khem Raj skrev:
On Mon, Oct 18, 2010 at 10:10 AM, Ulf Samuelsson
<[email protected]> wrote:
Koen Kooi skrev:
On 18-10-10 15:38, Ulf Samuelsson wrote:
Marcin Juszkiewicz skrev:
Dnia sobota, 16 pazdziernika 2010 o 14:50:02
[email protected]
napisaB(a):
+++ b/conf/machine/include/at91-2.6.30.inc
+++ b/conf/machine/include/at91-2.6.32.inc
Do you plan to duplicate that file with each kernel you will
produce?
Create include/at91-sam9.inc and put it there.
Regards,
This is to allow different kernel versions for different AT91 chips.
This allows both a "stable" version, and a development kernel
to be easily handled.
The file defines (amongst other things) the
* kernel version,
* u-boot version
* at91bootstrap version
so you need one file per version.he
NAK! Machines don't get to decide versions! Please revert that commit
and come up with a better way, e.g. default_preference in the recipes
or
distro include files.
If I look at the machine files, almost all of them provide
a preferred kernel / u-boot. Some also provide version.
we should avoid pinning versions there. Choosing a type is fine.
Why ?
Is it because it affect rebuild time?
It would be good to understand what problems people see with this.
Well we have distro which sets policies including which recipe
versions to be pinned
machine configuration decides on various machine features. There are
different ways to do it
but if we remain consistent in what we do, we can make it more
understandable for others
If you feel strongly that your approach is good I think it should be
decided if this is suitable
for majority of OE distro and machines, If it has technical merits
over existing approaches
people will be interested in it.
We are pinning the version to a specific machine, in the kernel recipe.
If we add a new recipe, then we can, by increasing the priority
force a different kernel to be built.
This will not affect anything else.
If the version is in the machine configuration, then a change of
kernel version could force a total rebuild, or?
I dont think it will force any rebuild or anything. It will just not
be the way other machines
do things. The machine configuration tend to be version agnostic as
per current approach.
Any other problem?
what are the issues that you see in following approaches suggested in
this thread so far ?
1) Many boards do put kernel version in the machine conf file.
The patch was created to collect common stuff in an include file
to make maintenance easier.
2) I cannot assume that all Atmel chips should use the same kernel,
so a single include file will not make it.
3) I want to be able to work with two kernel versions for the same chip.
This is to have one stable kernel, and one development kernel.
The use of the develoment kernel, should not make the stable version
unbuildable.
you want to ship with two kernel or you want to work with two kernel versions?
if you just want to develop then you can have the stable kernel
version as preferred version
and override that in local.conf with yout dev kernel for development
purposes. Once you are
done with it and it is your next stable just add
DEFAULT_PREFERENCE_<machine> = "1" in that recipe
and it should become new default for this machine.
I would like to ship with two kernels.
one "stable" kernel, and another "development" kernel
which is accessible to others to allow shared responsibility
for testing purposes.
Preferably, it should be possible to build both,
without having to rebuild the complete root fs.
for release you can create your own pinned config file and call it
inside distro config you have
and have two distros one for dev and one for stable
If I put the preferred version in the recipe, then I can only work
with one kernel.
If I try to use the preferred version in the recipe, then I
have to have two machine files.
I.E:
at91sam9g45ek
at91sam9g45ek-devel
and I have to support both machines in the recipe.
Once I have come to a point, where the development kernel is
to become the stable version, then I have to edit the recipe
again to make this the official.
I have to remove all references to "sam9g45ek",
then I have to modify the "sam9g45ek-devel" settings to refer to
"sam9g45ek", remove the sam9g45ek.conf and rename the
sam9g45ek-devel.conf to sam9g45ek.conf.
I then have to retest everything!
As I see it, the kernel/u-boot/at91bootstrap hangs together,
and it is easier to maintain a single include file with versions
for this, than to maintain the three recipes.
If I maintain in the recipes, I have to create a lot
of preferred_version_<machine>) in multiple kernel recipes,
and with my method, I include a single file in the machine
configuration.
If I want to change kernel version, I edit a few characters.
4. This points to another weakness.
You can only build a certain machine in one way.
Today, when we specify a MACHINE, we use "$MACHINE.conf"
It would be better, if you could have several machine configuration
files referring to the same MACHINE, and specifying the MACHINE
in the configuration file.
local.conf would then contain
MACHINE_CONFIG = at91sam9g45ek-2.6.30.conf
"at91sam9g45ek-2.6.30.conf" would contain
MACHINE = at91sam9g45ek
This would allow several configuration files referring to the same
machine.
The machine configuration must support selecting separate
* linux ".config"
* uboot configuration
* boot monitor configuration.
why not use existing MACHINE_FEATURES to steer the features you would
like to change in .config files.
Possibly, then machine configuration should support downloading such
stuff from internet.
(I don't expect the mainline OE to contain more than one "stable"
version)
BR
Ulf
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
