[Buildroot] svn commit: trunk/buildroot/target/device/Atmel/arch-avr32: kernel-patches-2.6.27.6

[Buildroot] svn commit: trunk/buildroot/target/device/Atmel/arch-avr32: kernel-patches-2.6.27.6

[ulf at uclibc.org]

Author: ulf
Date: 2008-12-20 22:19:38 +0000 (Sat, 20 Dec 2008)
New Revision: 24469

Log:
Add 2.6.27.7 patches for AVR32

Added:
   trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/
   trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/linux-2.6.27.6-100-avr32-atmel.1.patch
   trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/linux-2.6.27.6-200-avr32-remove.note.gnu.build-id-section.patch
   trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/linux-2.6.27.6-201-avr32-atmel_mpopfb-disable-debug.patch
   trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/linux-2.6.27.6-202-avr32-atmel_mpopfb-add-signal-to-disable-line-caching.patch
   trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/linux-2.6.27.6-203-avr32-fix-arch-header-byteorder.patch
   trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/linux-2.6.27.6-204-avr32-ap700x-fix-det_pin-for-nand-flash.patch

Modified:
   trunk/buildroot/target/device/Atmel/arch-avr32/Config.in.linux.patches


Changeset:

Sorry, the patch is too large to include (27029 lines).
Please use ViewCVS to see it!

http://uclibc.org/cgi-bin/viewcvs.cgi?view=rev&root=svn&rev=24469

[Buildroot] svn commit: trunk/buildroot/target/device/Atmel/arch-avr32: kernel-patches-2.6.27.6

[Peter Korsgaard]

>>>>> "ulf" == ulf  <ulf@uclibc.org> writes:

 ulf> Author: ulf
 ulf> Date: 2008-12-20 22:19:38 +0000 (Sat, 20 Dec 2008)
 ulf> New Revision: 24469

 ulf> Log:
 ulf> Add 2.6.27.7 patches for AVR32

 ulf> Added:
 ulf>    trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/

2.6.27.6 or 2.6.27.7? Don't they apply to 2.6.27.10?

Do we really need another ~800kb of avr specific patches? What about
the older patches, can they go away?

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit:trunk/buildroot/target/device/Atmel/arch-avr32:kernel-patches-2.6.27.6

[Ulf Samuelsson]

Subject: Re: [Buildroot] svn
commit:trunk/buildroot/target/device/Atmel/arch-avr32:kernel-patches-2.6.27.6


>>>>>> "ulf" == ulf  <ulf@uclibc.org> writes:
>
> ulf> Author: ulf
> ulf> Date: 2008-12-20 22:19:38 +0000 (Sat, 20 Dec 2008)
> ulf> New Revision: 24469
>
> ulf> Log:
> ulf> Add 2.6.27.7 patches for AVR32
>
> ulf> Added:
> ulf>
> trunk/buildroot/target/device/Atmel/arch-avr32/kernel-patches-2.6.27.6/
>
> 2.6.27.6 or 2.6.27.7? Don't they apply to 2.6.27.10?
>
> Do we really need another ~800kb of avr specific patches? What about
> the older patches, can they go away?
>

The way it works now the patches are for a specific major/minor combination
but you select which kernel you want to use, and then you select which
patchset.
You can apply 2.6.27.6 on top of 2.6.27.10 if you want to,
but the name indicates which kernel it was intended for, and the
further away you go in terms of major/minor revisions
the higher the risk that the patch will not apply.

When I get time, I will implement downloading the patchset
instead of storing it in the svn.
Then the size will go down.

Best Regards
Ulf Samuelsson

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

[Buildroot] svn commit:trunk/buildroot/target/device/Atmel/arch-avr32:kernel-patches-2.6.27.6

[Peter Korsgaard]

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

Hi,

 Ulf> The way it works now the patches are for a specific major/minor
 Ulf> combination but you select which kernel you want to use, and
 Ulf> then you select which patchset.  You can apply 2.6.27.6 on top
 Ulf> of 2.6.27.10 if you want to, but the name indicates which kernel
 Ulf> it was intended for, and the further away you go in terms of
 Ulf> major/minor revisions the higher the risk that the patch will
 Ulf> not apply.

But why are you checking in something that is already obsolete? Why
not base on 2.6.27.10 right away?

 Ulf> When I get time, I will implement downloading the patchset
 Ulf> instead of storing it in the svn.
 Ulf> Then the size will go down.

And what about the older patches, can they go away?

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit:trunk/buildroot/target/device/Atmel/arch-avr32:kernel-patches-2.6.27.6

[Ulf Samuelsson]

l?r 2009-01-03 klockan 08:58 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
>  Ulf> The way it works now the patches are for a specific major/minor
>  Ulf> combination but you select which kernel you want to use, and
>  Ulf> then you select which patchset.  You can apply 2.6.27.6 on top
>  Ulf> of 2.6.27.10 if you want to, but the name indicates which kernel
>  Ulf> it was intended for, and the further away you go in terms of
>  Ulf> major/minor revisions the higher the risk that the patch will
>  Ulf> not apply.
> 
> But why are you checking in something that is already obsolete? Why
> not base on 2.6.27.10 right away?

For Linux, I generally try to check in what I can find
on some key sites. These patches have been tested against
2.6.27.6 and while they may work on other versions
like 2.6.27.10 then it is up to the user
to test that out.

If the user does not like the patch, then it is easy
to deselect adding that patch.
It is also possible for the user to make a new patch
and use this instead of the one provided by the svn.

>  Ulf> When I get time, I will implement downloading the patchset
>  Ulf> instead of storing it in the svn.
>  Ulf> Then the size will go down.
> 
> And what about the older patches, can they go away?
> 

As I said in an earlier email, the long term plan
is to download the patches when needed, but 
time is limited and there are other things
that I think have higher priority.

The benefit of this is mainly diskspace and svn download time.
I measured svn download time and it was 25 seconds 
for a total of 39.5 MB.
The Atmel directory is 8,1MB or ~20% so this costs 5 seconds extra.
Admittedly I have a fast line (100 MBps + Fiber) at home, but 
any such thing will save ~ 1-2 seconds of download time, that's it.
At $100/500 GB the cost of hard disk space is $0.2/GB
or 0.8 cents for the complete svn and maybe 0.2 cents for the 
each target/device/Atmel directory. 
I.E: There is not a lot of gain.
?
Removing the config information to accomplish smaller svn 
footprint does not give any noticeable return IMHO.

It does speed up the time to start processing the make rules,
but it can't be much. On my ?P4-3.6GHz it takes about 3 seconds
to parse *all* the rules to determine what to do, and start
processing the first rule.
Removing "old" stuff cannot give any big return.

?I sympatize with the goal of keeping svn size down,
but I do not like the idea of only keeping the last
few kernels around.

As an example of higher priority items:
Doing the same for u-boot will allow us to get rid
of the AT91 specific u-boot directory.

I also today noted a mess regarding alsa
alsa-lib does not build due to lack of python-2.5 libraries.
python is 2.4.5 and upgrading to 2.5 or 3.0 fails
in configure due to no patches for cross-compiling.

BR
Ulf