kirkwood, one or multiple machines

kirkwood, one or multiple machines

[Frans Meulenbroeks]

Recently I added support for the openrd client board to OE by making a
new machine.
I guessed this was wat was desired since there was a
linux-kirkwood_2.6.31.bb file mentioning sheevaplug and openrd base as
machines.
Also there is a kirkwood.inc file

However after digging a little bit deeper I am not too sure if this is
really desirable.
All three boards are of course based upon the Marvell Kirkwood CPU.
But the kernel as is is fully interchangeable. It uses arcNumber to
identify the board. Which variants are supported can be set (see
arch/arm/mach-kirkwood/Kconfig)
However it is perfectly ok to select multiple variants. This results
in a kernel which supports all these variants.

As a test I successfully ran an openrd client kernel on a sheevaplug.

Then why do we have multiple machines?
the only things I can think of is:
- smaller kernel (but more variants does not drag in that much)
- machine specific patches (but for now these do not exist yet, and a
clearer way then would be to use the machine specific config macros)
- tuned defconfigs (which is the only thing that there is now)

Disadvantage of more machines is that this will grow and grow.
Guess within a short while we'll see a machine definition for QNAP
TS219 probably followed by all kind of plug variants like pogoplug,
toninoplug etc etc.

Btw: wrt the defconfigs: In my opinion the defconfig should be such
that it is usable by all. Board specific things (like e.g. the video
on openrd client) should be build as modules so those who need them
can load them, and those who don't can ignore them.

What is the community thought on this? Did I miss something?

Frans

Re: kirkwood, one or multiple machines

[Florian Boor]

Hi Frans,

Frans Meulenbroeks schrieb:
> Recently I added support for the openrd client board to OE by making a
> new machine.

yep - good job, the OpenRD client is an interesting piece of hardware.

> Then why do we have multiple machines?
> the only things I can think of is:
> - smaller kernel (but more variants does not drag in that much)
> - machine specific patches (but for now these do not exist yet, and a
> clearer way then would be to use the machine specific config macros)
> - tuned defconfigs (which is the only thing that there is now)

These are good reasons to have one machine conf for every machine. Apart from
the fact that it is quite likely that it will cause confusion if you merge
multiple machine configs into one.

> Disadvantage of more machines is that this will grow and grow.
> Guess within a short while we'll see a machine definition for QNAP
> TS219 probably followed by all kind of plug variants like pogoplug,
> toninoplug etc etc.

I do not agree here, a new device configuration file for a new device is
something I can live with pretty well. Even if two devices can live with the
same kernel one config for each makes it much more obvious which ones are
supported in OE and which to look at if you need to change something.
Thanks to include files these configs can be small but I don't see a major
advantage of merging them. Currently this might be possible but you move away
from best results if more specialized Kirkwood devices show up.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en

Re: kirkwood, one or multiple machines

[Frans Meulenbroeks]

2009/10/26 Florian Boor <florian.boor@kernelconcepts.de>:
> Hi Frans,
>
> Frans Meulenbroeks schrieb:
>> Recently I added support for the openrd client board to OE by making a
>> new machine.
>
> yep - good job, the OpenRD client is an interesting piece of hardware.
>
>> Then why do we have multiple machines?
>> the only things I can think of is:
>> - smaller kernel (but more variants does not drag in that much)
>> - machine specific patches (but for now these do not exist yet, and a
>> clearer way then would be to use the machine specific config macros)
>> - tuned defconfigs (which is the only thing that there is now)
>
> These are good reasons to have one machine conf for every machine. Apart from
> the fact that it is quite likely that it will cause confusion if you merge
> multiple machine configs into one.
>
>> Disadvantage of more machines is that this will grow and grow.
>> Guess within a short while we'll see a machine definition for QNAP
>> TS219 probably followed by all kind of plug variants like pogoplug,
>> toninoplug etc etc.
>
> I do not agree here, a new device configuration file for a new device is
> something I can live with pretty well. Even if two devices can live with the
> same kernel one config for each makes it much more obvious which ones are
> supported in OE and which to look at if you need to change something.
> Thanks to include files these configs can be small but I don't see a major
> advantage of merging them. Currently this might be possible but you move away
> from best results if more specialized Kirkwood devices show up.

You have a point here.
The only disadvantage of different defconfigs is that you need to
change them all if there is some lower level change.
E.g. discovered the other day that ubi does not like it if
CONFIG_MTD_NAND_VERIFY_WRITE is set (which it used to be)
(see http://www.linux-mtd.infradead.org/faq/ubi.html#L_subpage_verify_fail)
in that case all defconfigs need to be updated.
THen again if they live nicely in subdirs, not too much of a problem.

Frans