[Buildroot] target/device/Atmel kernel patches

[Buildroot] target/device/Atmel kernel patches

[Peter Korsgaard]

Hi,

We have a bunch of large kernel patches in target/device/Atmel for
fairly old kernel versions:

find -type f|xargs ls -shS|head -n 15
816K ./arch-arm/kernel-patches-2.6.24/linux-2.6.24-at91.patch
764K ./arch-arm/kernel-patches-2.6.20.4/linux-2.6.20.4-atmel.patch
744K ./arch-avr32/kernel-patches-2.6.27.6/linux-2.6.27.6-100-avr32-atmel.1.patch
516K ./arch-avr32/kernel-patches-2.6.23/linux-2.6.23-100-avr32-atmel.2.patch
452K ./arch-avr32/kernel-patches-2.6.22.10/linux-2.6.22.10-100-avr32-atmel.4.patch
448K ./arch-avr32/kernel-patches-2.6.24/linux-2.6.24-100-avr32-git.1.patch
412K ./arch-arm/kernel-patches-2.6.21.1/linux-2.6.21.1-at91.patch
412K ./arch-arm/kernel-patches-2.6.21.5/linux-2.6.21.5-at91.patch
272K ./arch-avr32/kernel-patches-2.6.25.10/linux-2.6.25.10.atmel.2.patch.bz2
136K ./arch-arm/kernel-patches-2.6.25/linux-2.6.25-at91.patch.gz
100K ./arch-arm/kernel-patches-2.6.26/2.6.26-at91.patch.gz
 96K ./arch-arm/kernel-patches-2.6.26-rc3/linux-2.6.26-rc3-at91.patch.gz
 96K ./arch-arm/kernel-patches-2.6.27.7/linux-2.6.27-at91.patch.gz
 84K ./arch-avr32/kernel-patches-2.6.24/linux-2.6.24-500-v4l-avr32-isi.patch.cond

Can I just delete anything older than 2.6.27?

-- 
Bye, Peter Korsgaard

[Buildroot] target/device/Atmel kernel patches

[Ulf Samuelsson]

m?n 2009-01-26 klockan 22:03 +0100 skrev Peter Korsgaard:
> Hi,
> 
> We have a bunch of large kernel patches in target/device/Atmel for
> fairly old kernel versions:
> 
> find -type f|xargs ls -shS|head -n 15
> 816K ./arch-arm/kernel-patches-2.6.24/linux-2.6.24-at91.patch
> 764K ./arch-arm/kernel-patches-2.6.20.4/linux-2.6.20.4-atmel.patch
> 744K ./arch-avr32/kernel-patches-2.6.27.6/linux-2.6.27.6-100-avr32-atmel.1.patch
> 516K ./arch-avr32/kernel-patches-2.6.23/linux-2.6.23-100-avr32-atmel.2.patch
> 452K ./arch-avr32/kernel-patches-2.6.22.10/linux-2.6.22.10-100-avr32-atmel.4.patch
> 448K ./arch-avr32/kernel-patches-2.6.24/linux-2.6.24-100-avr32-git.1.patch
> 412K ./arch-arm/kernel-patches-2.6.21.1/linux-2.6.21.1-at91.patch
> 412K ./arch-arm/kernel-patches-2.6.21.5/linux-2.6.21.5-at91.patch
> 272K ./arch-avr32/kernel-patches-2.6.25.10/linux-2.6.25.10.atmel.2.patch.bz2
> 136K ./arch-arm/kernel-patches-2.6.25/linux-2.6.25-at91.patch.gz
> 100K ./arch-arm/kernel-patches-2.6.26/2.6.26-at91.patch.gz
>  96K ./arch-arm/kernel-patches-2.6.26-rc3/linux-2.6.26-rc3-at91.patch.gz
>  96K ./arch-arm/kernel-patches-2.6.27.7/linux-2.6.27-at91.patch.gz
>  84K ./arch-avr32/kernel-patches-2.6.24/linux-2.6.24-500-v4l-avr32-isi.patch.cond

> Can I just delete anything older than 2.6.27?
> 
No, Just because you like to run with the latest kernel,
that view is not shared by everyone else.

The long term plan is to allow downloading the patch, instead
of storing it in the svn.

I believe that there are more important things that needs attention.

If you feel eager to do something right now,
then ?store the patches on the mirror server and make
sure you can to download and apply them
using the current user interface.

BR
Ulf Samuelsson

[Buildroot] target/device/Atmel kernel patches

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 >> Can I just delete anything older than 2.6.27?
 >> 
 Ulf> No, Just because you like to run with the latest kernel,
 Ulf> that view is not shared by everyone else.

Ok, so what patches can be removed? I take it that atleast *SOME* of
those 10 versions can go?

-- 
Bye, Peter Korsgaard

[Buildroot] target/device/Atmel kernel patches

[Ulf Samuelsson]

m?n 2009-01-26 klockan 22:37 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  >> Can I just delete anything older than 2.6.27?
>  >> 
>  Ulf> No, Just because you like to run with the latest kernel,
>  Ulf> that view is not shared by everyone else.
> 
> Ok, so what patches can be removed? I take it that atleast *SOME* of
> those 10 versions can go?
> 

I have customers still working on 2.6.22 ...

I think you need to understand that some people
are planning for 10-15 year lifetime of products.
They do not neccessarily update the kernel very often.
If they do, they are likely to juyst add tweaks to
their kernel instead of upgrading to a new version.

If you implement the patch downloading, there is
very little reason to remove functionality.

BR
Ulf Samuelsson

[Buildroot] target/device/Atmel kernel patches

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi.

 Ulf> No, Just because you like to run with the latest kernel,
 Ulf> that view is not shared by everyone else.
 >> 
 >> Ok, so what patches can be removed? I take it that atleast *SOME* of
 >> those 10 versions can go?

 Ulf> I have customers still working on 2.6.22 ...

Working as in doing active development? Really?

 Ulf> I think you need to understand that some people
 Ulf> are planning for 10-15 year lifetime of products.
 Ulf> They do not neccessarily update the kernel very often.
 Ulf> If they do, they are likely to juyst add tweaks to
 Ulf> their kernel instead of upgrading to a new version.

I work at a company developing display technology for the military
market, so you don't need to tell me about long term support ;)

But the problem is that you are mixing up configuration control of a
project, and development of buildroot. When you do a project you
ofcourse need to get your individual components under configuration
and be able to reproduce your build if you ever need to fix
something. This ALSO includes buildroot version.

Completely next to that is the state of buildroot svn. This has to be
suitable for starting new projects off, so it needs recent versions of
packages with the latest bugfixes included.

For starting a new project, selecting anything else than the 2.6.28
(or even better, the latest 2.6.29-rcX) seems pretty silly to me, but
I'm even stretching it to include 2.6.27 just in case.

So again, what kernel versions in arch-arm can we remove from svn?

 Ulf> If you implement the patch downloading, there is
 Ulf> very little reason to remove functionality.

Ofcourse there is, otherwise the number of configuration combinations
to test would grow astronomically.

-- 
Bye, Peter Korsgaard

[Buildroot] target/device/Atmel kernel patches

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
> Hi.
>
> Ulf> No, Just because you like to run with the latest kernel,
> Ulf> that view is not shared by everyone else.
> >>
> >> Ok, so what patches can be removed? I take it that atleast *SOME* of
> >> those 10 versions can go?
>
> Ulf> I have customers still working on 2.6.22 ...
>
> Working as in doing active development? Really?

Yes,
I have about 250 ARM9 customers, and I would say
that it normally takes 18-24 months from the decision to goahead
to the first release of a product.
This is for people switching to Linux from another platform.

People working on multiple products, with previous experience
of Linux on AT91 will have shorter time for new products.

The first release of the product does not mean it enters mainteance mode.
There is further active developement after the first release to add feature.

At one point in development, there is a decision to freeze kernel version
and any errors found will be handled by patching that kernel version,
sometimes backpatching from newer kernels.

Once that point is reached, then it becomes a very serious decision
to move to a new kernel.

One of our key customer is working on a major release
using the 2.4.x kernel version they selected in 2004.

Your approach, will automatically disqualify the use of Buildroot
for any customers following normal behaviour.

I have met two customers using buildroot this week,
and they point out that the only use they find for buildroot
is as a way to get the latest patches/build recipes, and they cannot
do anything useful with buildroot itself due to its higly volatile nature.
They need stability, and they do not want to make their own decisions.

>
> Ulf> I think you need to understand that some people
> Ulf> are planning for 10-15 year lifetime of products.
> Ulf> They do not neccessarily update the kernel very often.
> Ulf> If they do, they are likely to juyst add tweaks to
> Ulf> their kernel instead of upgrading to a new version.
>
> I work at a company developing display technology for the military
> market, so you don't need to tell me about long term support ;)
>
> But the problem is that you are mixing up configuration control of a
> project, and development of buildroot. When you do a project you
> ofcourse need to get your individual components under configuration
> and be able to reproduce your build if you ever need to fix
> something. This ALSO includes buildroot version.
>
> Completely next to that is the state of buildroot svn. This has to be
> suitable for starting new projects off, so it needs recent versions of
> packages with the latest bugfixes included.
>
> For starting a new project, selecting anything else than the 2.6.28
> (or even better, the latest 2.6.29-rcX) seems pretty silly to me, but
> I'm even stretching it to include 2.6.27 just in case.

I was told some time ago, that the latest version of Xenomai for ARM only
runs on 2.6.26 kernels.
I do not know if this has changed, but there are drawbacks on beeing too
hasty.

If you continue your thinking, then you will soon delete 2.6.27 and then
2.6.28 etc.
making this something you can use for evalution but nothing more.
The user interface for building linux is clean and simple
and I think that people using old kernels, know how to come around
any difficulty they will stumble upon and can handle that with
custom patches, without the main buildroot team beeing involved.

>
> So again, what kernel versions in arch-arm can we remove from svn?
>

If we want to cover 95% of the cases, we need to keep kernel versions which
are minium 2 years or younger, but 3 years is desirable.

> Ulf> If you implement the patch downloading, there is
> Ulf> very little reason to remove functionality.
>
> Of course there is, otherwise the number of configuration combinations
> to test would grow astronomically.
>

No, because the kernel is orthogonal to the file system,
I see that we need to test kernels when they are are released
and then the kernels should be frozen.

I do not remember anyone complaining about not beeing able
to compile an old kernel, and then the failure was in the build.

If someone complains, then they will be told to upgrade anyway.

> -- 
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


Best Regards
Ulf Samuelsson

[Buildroot] target/device/Atmel kernel patches

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Ulf> The first release of the product does not mean it enters
 Ulf> mainteance mode.  There is further active developement after the
 Ulf> first release to add feature.

To their custom applications I take, rather than the cots rootfs
components of buildroot?

 Ulf> At one point in development, there is a decision to freeze
 Ulf> kernel version and any errors found will be handled by patching
 Ulf> that kernel version, sometimes backpatching from newer kernels.

 Ulf> Once that point is reached, then it becomes a very serious decision
 Ulf> to move to a new kernel.

The same probably goes for buildroot?

 Ulf> One of our key customer is working on a major release
 Ulf> using the 2.4.x kernel version they selected in 2004.

Giggle, as long as I don't have to do it ;)

 Ulf> Your approach, will automatically disqualify the use of Buildroot
 Ulf> for any customers following normal behaviour.

Why? It obviously didn't disqualify the kernel.

 Ulf> I have met two customers using buildroot this week, and they
 Ulf> point out that the only use they find for buildroot is as a way
 Ulf> to get the latest patches/build recipes, and they cannot do
 Ulf> anything useful with buildroot itself due to its higly volatile
 Ulf> nature.  They need stability, and they do not want to make their
 Ulf> own decisions.

That's why I'm doing releases.

 >> For starting a new project, selecting anything else than the 2.6.28
 >> (or even better, the latest 2.6.29-rcX) seems pretty silly to me, but
 >> I'm even stretching it to include 2.6.27 just in case.

 Ulf> I was told some time ago, that the latest version of Xenomai for
 Ulf> ARM only runs on 2.6.26 kernels.  I do not know if this has
 Ulf> changed, but there are drawbacks on beeing too hasty.

Could be, have never used Xenomai - But that's the "joys" of using out
of tree stuff. It can handly be anyone elses fault than the Xenoami
people.

 Ulf> If you continue your thinking, then you will soon delete 2.6.27 and then
 Ulf> 2.6.28 etc.
 Ulf> making this something you can use for evalution but nothing more.

Again I don't see how this is. I have used buildroot for commercial
products for years, even without releases. It's just a question of
managing it, just like for the Linux kernel and U-Boot and all the
other components.

 Ulf> The user interface for building linux is clean and simple
 Ulf> and I think that people using old kernels, know how to come around
 Ulf> any difficulty they will stumble upon and can handle that with
 Ulf> custom patches, without the main buildroot team beeing involved.

Just like for Linux and all the other open source projects they are
using they have the choice between staying uptodate and get the newest
features/bugfixes or stick to an old version and backport what they
need.

I don't see how buildroot is any different here.

 >> So again, what kernel versions in arch-arm can we remove from svn?
 >> 

 Ulf> If we want to cover 95% of the cases, we need to keep kernel versions which
 Ulf> are minium 2 years or younger, but 3 years is desirable.

That's completely unrealistic with new major upstream releases every 3
months. I think we should rather aim for something like the last 2-3
versions.

 >> Of course there is, otherwise the number of configuration combinations
 >> to test would grow astronomically.
 >> 

 Ulf> No, because the kernel is orthogonal to the file system,
 Ulf> I see that we need to test kernels when they are are released
 Ulf> and then the kernels should be frozen.

Those old and obsolete patches don't belong in buildroot proper (in
fact I don't think we should have ANY feature patches, just bugfixes -
But that's another discussion).

We already have a situation where more than half the size of buildroot
is patches, continuing to grow this is not a workable situation.

If people want to use an old kernel they can maintain it outside of
buildroot or in their local buildroot tree.

I do agree we should make it easier to build u-boot / linux from a
non-mainline svn/git/whatever tree, that's something I will work on
after the release.

-- 
Bye, Peter Korsgaard

[Buildroot] target/device/Atmel kernel patches

[Ulf Samuelsson]

>
> We already have a situation where more than half the size of buildroot
> is patches, continuing to grow this is not a workable situation.
>
I agree with this, but the solution I want to see is that you
only keep the latest patches in the tree,
and as we introduce new kernel versions we
let older patches slip into the mirror server.

I just want them to build as long as possible.
I do not suggest that we spend time on testing od kernels.
Ideally each distribution focus on a single kernel.

> If people want to use an old kernel they can maintain it outside of
> buildroot or in their local buildroot tree.
>

I want to give people the capability to build old kernel
with a new root fs.

If they want to build old kernel with old rootfs,
then they have to handle that on their own.

> I do agree we should make it easier to build u-boot / linux from a
> non-mainline svn/git/whatever tree, that's something I will work on
> after the release.



> -- 
> Bye, Peter Korsgaard
>



Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57 

[Buildroot] target/device/Atmel kernel patches

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 >> We already have a situation where more than half the size of buildroot
 >> is patches, continuing to grow this is not a workable situation.
 >> 
 Ulf> I agree with this, but the solution I want to see is that you
 Ulf> only keep the latest patches in the tree,
 Ulf> and as we introduce new kernel versions we
 Ulf> let older patches slip into the mirror server.

I don't see why we the buildroot project should mirror random obsolete
board patches?

And again, things should get pushed upstream so we only carry patches
for (not-yet-applied-upstream) bugfixes.

 Ulf> I just want them to build as long as possible.

Why can't people just continue to use an old buildroot release or
store their (project specific) board patches outside buildroot?

 >> If people want to use an old kernel they can maintain it outside of
 >> buildroot or in their local buildroot tree.

 Ulf> I want to give people the capability to build old kernel
 Ulf> with a new root fs.

No problem if we make it possible to get the kernel from somewhere
else (for most commercial projects probably a local
cvs/svn/git/whatever repository).

 >> I do agree we should make it easier to build u-boot / linux from a
 >> non-mainline svn/git/whatever tree, that's something I will work on
 >> after the release.

-- 
Bye, Peter Korsgaard

[Buildroot] target/device/Atmel kernel patches

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
> >> We already have a situation where more than half the size of buildroot
> >> is patches, continuing to grow this is not a workable situation.
> >>
> Ulf> I agree with this, but the solution I want to see is that you
> Ulf> only keep the latest patches in the tree,
> Ulf> and as we introduce new kernel versions we
> Ulf> let older patches slip into the mirror server.
>
> I don't see why we the buildroot project should mirror random obsolete
> board patches?
>
> And again, things should get pushed upstream so we only carry patches
> for (not-yet-applied-upstream) bugfixes.
>
> Ulf> I just want them to build as long as possible.
>
> Why can't people just continue to use an old buildroot release or
> store their (project specific) board patches outside buildroot?
>
> >> If people want to use an old kernel they can maintain it outside of
> >> buildroot or in their local buildroot tree.
>
> Ulf> I want to give people the capability to build old kernel
> Ulf> with a new root fs.
>
> No problem if we make it possible to get the kernel from somewhere
> else (for most commercial projects probably a local
> cvs/svn/git/whatever repository).
>

As I see it, you get the base kernel from www.kernel.org
and if you dont want to host kernel patches for AT91,  then
it will be no problem to download them from $(ATMEL_MIRROR).
I just think there are other things in higher need of attention
than removing these patches RIGHT NOW.
I see that moving these patches from svn to a mirror should
be done before the next release of buildroot.

> >> I do agree we should make it easier to build u-boot / linux from a
> >> non-mainline svn/git/whatever tree, that's something I will work on
> >> after the release.
>
> -- 
> Bye, Peter Korsgaard
>

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57 

[Buildroot] target/device/Atmel kernel patches

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> As I see it, you get the base kernel from www.kernel.org

Yes, more or less directly, and that's fine for evaluation boards -
But for real development on specialized hardware that's rarely enough,
hence the need for either:

 - Provide a way to add project specific patches on top

OR

 - Take the kernel from somewhere else (some other
   cvs/svn/git/whatever repo).

I suspect we need to support both.

 Ulf> and if you dont want to host kernel patches for AT91,  then
 Ulf> it will be no problem to download them from $(ATMEL_MIRROR).
 Ulf> I just think there are other things in higher need of attention
 Ulf> than removing these patches RIGHT NOW.
 Ulf> I see that moving these patches from svn to a mirror should
 Ulf> be done before the next release of buildroot.

No, but we're doing a bunch of cleanups now - And as I mentioned before,
the arch-arm directory seems a bit extreme as it is.

I don't think adding a bunch of special case handling to buildroot to
download AT91 patches from somewhere is a better solution. We should
rather generalize the setup so you can handle it outside BR and just
point BR to a repo or a directory full of patches.

-- 
Bye, Peter Korsgaard

[Buildroot] target/device/Atmel kernel patches

[Ulf Samuelsson]

tor 2009-01-29 klockan 17:54 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  Ulf> As I see it, you get the base kernel from www.kernel.org
> 
> Yes, more or less directly, and that's fine for evaluation boards -
> But for real development on specialized hardware that's rarely enough,
> hence the need for either:
> 
>  - Provide a way to add project specific patches on top
> 
> OR
> 
>  - Take the kernel from somewhere else (some other
>    cvs/svn/git/whatever repo).
> 
> I suspect we need to support both.
> 
>  Ulf> and if you dont want to host kernel patches for AT91,  then
>  Ulf> it will be no problem to download them from $(ATMEL_MIRROR).
>  Ulf> I just think there are other things in higher need of attention
>  Ulf> than removing these patches RIGHT NOW.
>  Ulf> I see that moving these patches from svn to a mirror should
>  Ulf> be done before the next release of buildroot.
> 
> No, but we're doing a bunch of cleanups now - And as I mentioned before,
> the arch-arm directory seems a bit extreme as it is.

I much prefer that we avoid doing this under time pressure
and come to an agreememt on how to do a good implementation
after the first release.

> I don't think adding a bunch of special case handling to buildroot to
> download AT91 patches from somewhere is a better solution. We should
> rather generalize the setup so you can handle it outside BR and just
> point BR to a repo or a directory full of patches.
> 

I am for generic solutions, but not at the expense of ease of use.
That is why it needs some pondering, before a solution is selected.

BR
Ulf Samuelsson

[Buildroot] target/device/Atmel kernel patches

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 >> No, but we're doing a bunch of cleanups now - And as I mentioned before,
 >> the arch-arm directory seems a bit extreme as it is.

 Ulf> I much prefer that we avoid doing this under time pressure
 Ulf> and come to an agreememt on how to do a good implementation
 Ulf> after the first release.

Ok, but I guess we can atleast remove the support for 2.6.21.1 (as
there's 2.6.21.5) and 2.6.26-rc3 (as there's 2.6.26) ?

 >> I don't think adding a bunch of special case handling to buildroot to
 >> download AT91 patches from somewhere is a better solution. We should
 >> rather generalize the setup so you can handle it outside BR and just
 >> point BR to a repo or a directory full of patches.
 >> 

 Ulf> I am for generic solutions, but not at the expense of ease of use.
 Ulf> That is why it needs some pondering, before a solution is selected.

I'm not for ease of use over everything else, it also has to be
manageable for the developers - But yes, the easier we can make it to
use at the same time, the better.

-- 
Bye, Peter Korsgaard

[Buildroot] target/device/Atmel kernel patches

[Ulf Samuelsson]

tor 2009-01-29 klockan 20:04 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  >> No, but we're doing a bunch of cleanups now - And as I mentioned before,
>  >> the arch-arm directory seems a bit extreme as it is.
> 
>  Ulf> I much prefer that we avoid doing this under time pressure
>  Ulf> and come to an agreememt on how to do a good implementation
>  Ulf> after the first release.
> 
> Ok, but I guess we can atleast remove the support for 2.6.21.1 (as
> there's 2.6.21.5) and 2.6.26-rc3 (as there's 2.6.26) ?

OK, go ahead, but you need to update the 
arch-at91/Config.in.linux.patches as well.



>  >> I don't think adding a bunch of special case handling to buildroot to
>  >> download AT91 patches from somewhere is a better solution. We should
>  >> rather generalize the setup so you can handle it outside BR and just
>  >> point BR to a repo or a directory full of patches.
>  >> 
> 
>  Ulf> I am for generic solutions, but not at the expense of ease of use.
>  Ulf> That is why it needs some pondering, before a solution is selected.
> 
> I'm not for ease of use over everything else, it also has to be
> manageable for the developers - But yes, the easier we can make it to
> use at the same time, the better.
> 

BR
Ulf Samuelsson