[Buildroot] avr32 patches vs. x86 breakage

[Buildroot] avr32 patches vs. x86 breakage

[Nigel Kukard]

Hi Guys,

Will this proposal to fix the problem work ...

- Make a dir under arch-avr32, for gcc-x.y.z

- Add a make file to set something like
BOARD_EXTRA_PATCH_PATH=target/device/arch-avr32  this will be set if the
board is AVR32 based 

- In GCC / binutils/ uclibc and where ever else avr32 patches are
applied, we can tst if BOARD_EXTRA_PATCH_PATH is available. If it is to
add those patches into the patch set being applied. This should be
simplistic as we know the version for instance GCC_VERSION, we'd just
have to test the path exists and do something like    \*.patch
$(MORE_PATCHES)  , where we set a few lines up.  MORE_PATCHES=
$(BOARD_EXTRA_PATCH_PATH)/gcc-$(GCC_VERSION)


I think this is a good fix to only apply board specific patches if we
need them ... and by simply creating a dir off the board name dir with
the package name in it for each package we muck with.

Good/bad idea? or any combination of idea above.

-N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://busybox.net/lists/buildroot/attachments/20080321/586f4f2b/attachment-0001.pgp 

[Buildroot] avr32 patches vs. x86 breakage

[Peter Korsgaard]

>>>>> "Nigel" == Nigel Kukard <nkukard@lbsd.net> writes:

Hi,

 Nigel> Hi Guys,
 Nigel> Will this proposal to fix the problem work ...

 Nigel> - Make a dir under arch-avr32, for gcc-x.y.z

 Nigel> - Add a make file to set something like
 Nigel> BOARD_EXTRA_PATCH_PATH=target/device/arch-avr32  this will be set if the
 Nigel> board is AVR32 based 

 Nigel> - In GCC / binutils/ uclibc and where ever else avr32 patches are
 Nigel> applied, we can tst if BOARD_EXTRA_PATCH_PATH is available. If it is to
 Nigel> add those patches into the patch set being applied. This should be
 Nigel> simplistic as we know the version for instance GCC_VERSION, we'd just
 Nigel> have to test the path exists and do something like    \*.patch
 Nigel> $(MORE_PATCHES)  , where we set a few lines up.  MORE_PATCHES=
 Nigel> $(BOARD_EXTRA_PATCH_PATH)/gcc-$(GCC_VERSION)

As discussed on IRC, I think its cleaner if everything related to a
package is located under the package/<package>/ dir.

The real problem is that apparent quality issues of some of the arch
specific patches.

If possible, I would prefer if all archs would use the same sources
(so apply the same patches for all archs) as the patches then get a
lot more testing - E.G. you might otherwise not notice if a patch for
some obscure arch no longer applies because you bumped the version of
a package.

But that doesn't seem realistic with the current patches, so I instead
suggest we split up patches in generic and arch specific. The generic
ones gets applied to all archs, and only the arch specific ones for
the selected arch.

The easiest setup is probably to use the naming convention:

 - package-version-*.patch for generic stuff
 - arch-package-version-*.patch for arch specific stuff

What do you think?

-- 
Bye, Peter Korsgaard

[Buildroot] avr32 patches vs. x86 breakage

[Peter Korsgaard]

>>>>> "Nigel" == Nigel Kukard <nkukard@lbsd.net> writes:

Hi,

 Nigel> The other problem is getting some patches to get fixed when a problem is
 Nigel> found ... not all of us are familiar with every single arch or even
 Nigel> assembly in some cases, let alone arch specific assembly.

 Nigel> I think a split would be a good idea, also maybe make it
 Nigel> easier to debug issues.

Or atleast only let the people using that particular arch worry about
it ;)


 >> - package-version-*.patch for generic stuff
 >> - arch-package-version-*.patch for arch specific stuff
 >> 
 >> What do you think?

 Nigel> What about patch order? and patch order when there is generic stuff and
 Nigel> arch specific?

My (possibly too simplistic) view on things is to first apply the
generic patches, and then the arch specific ones.

-- 
Bye, Peter Korsgaard

[Buildroot] avr32 patches vs. x86 breakage

[Nigel Kukard]

Hi,

>  >> - package-version-*.patch for generic stuff
>  >> - arch-package-version-*.patch for arch specific stuff
>  >> 
>  >> What do you think?
> 
>  Nigel> What about patch order? and patch order when there is generic stuff and
>  Nigel> arch specific?
> 
> My (possibly too simplistic) view on things is to first apply the
> generic patches, and then the arch specific ones.

yea, generic first I think aswell.

few more thoughts...

these would be in for instance  toolchain/gcc/



1.
version/*.patch  - generic
version/arch/*.patch  -  arch specific


2.
version/*.patch
arch-version/*.patch


3.
version-*.patch
arch-version-*.patch


-N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://busybox.net/lists/buildroot/attachments/20080321/9ad75c06/attachment.pgp 

[Buildroot] avr32 patches vs. x86 breakage

[Bernhard Fischer]

On Fri, Mar 21, 2008 at 08:45:42AM +0100, Peter Korsgaard wrote:
>>>>>> "Nigel" == Nigel Kukard <nkukard@lbsd.net> writes:
>
>Hi,
>
> Nigel> Hi Guys,
> Nigel> Will this proposal to fix the problem work ...
>
> Nigel> - Make a dir under arch-avr32, for gcc-x.y.z
>
> Nigel> - Add a make file to set something like
> Nigel> BOARD_EXTRA_PATCH_PATH=target/device/arch-avr32  this will be set if the
> Nigel> board is AVR32 based 
>
> Nigel> - In GCC / binutils/ uclibc and where ever else avr32 patches are
> Nigel> applied, we can tst if BOARD_EXTRA_PATCH_PATH is available. If it is to
> Nigel> add those patches into the patch set being applied. This should be
> Nigel> simplistic as we know the version for instance GCC_VERSION, we'd just
> Nigel> have to test the path exists and do something like    \*.patch
> Nigel> $(MORE_PATCHES)  , where we set a few lines up.  MORE_PATCHES=
> Nigel> $(BOARD_EXTRA_PATCH_PATH)/gcc-$(GCC_VERSION)
>
>As discussed on IRC, I think its cleaner if everything related to a
>package is located under the package/<package>/ dir.
>
>The real problem is that apparent quality issues of some of the arch
>specific patches.

They should fix their arch and you should not add kludge to work around
such bugs, imo.

[Buildroot] avr32 patches vs. x86 breakage

[Nigel Kukard]

Hi Bernhard,

> >The real problem is that apparent quality issues of some of the arch
> >specific patches.
> 
> They should fix their arch and you should not add kludge to work around
> such bugs, imo.

In an ideal situation yes .... but buildroot is an opensource project
with no time constraints imposed on its contributors.

If I contributed a patch to add an arch to GCC, and it broke 2 months
down the line when people began to use it, are you just going to remove
it out of buildroot until it gets fixed? What happens if it broke
support for everything except its own arch?  What happens if there were
thousands of users of it, more than any other arch?

In this case its the AVR32 support which breaks x86 .... I'm sure there
are more users of AVR32 than x86. 1) its impractical to remove AVR32
support until its fixed, we don't know how long it will take  2) its
senseless to drop support for x86 because an AVR32 patch breaks it.

People new to buildroot trying it out don't want to scrape through years
of mailing lists to try find these few mails about everything building
fine on x86, then WHAM BAM .... corruption in the weirdest ways in the
generated images. It puts people off and they get the first impression
that buildroot doesn't work ... something I've seen happen ALOT!

Only alternative I can see is adding kludge to work around horribly
broken patches until someone fixes them or no one bitches and they are
removed like 6-12 months later. This way everything works out of the
box.

The proposed kludge isn't too bad either, its merely splitting the
patches up into different dirs. I am willing to spin a set of patches to
implement these changes.

-N


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://busybox.net/lists/buildroot/attachments/20080321/4bc080ca/attachment.pgp 

[Buildroot] avr32 patches vs. x86 breakage

[Peter Korsgaard]

>>>>> "Nigel" == Nigel Kukard <nkukard@lbsd.net> writes:

Hi,

 >> They should fix their arch and you should not add kludge to work around
 >> such bugs, imo.

 Nigel> In an ideal situation yes .... but buildroot is an opensource
 Nigel> project with no time constraints imposed on its contributors.

But that doesn't mean that contributors don't care.

 Nigel> If I contributed a patch to add an arch to GCC, and it broke 2
 Nigel> months down the line when people began to use it, are you just
 Nigel> going to remove it out of buildroot until it gets fixed? What
 Nigel> happens if it broke support for everything except its own
 Nigel> arch?  What happens if there were thousands of users of it,
 Nigel> more than any other arch?

If you would not be ready to support your work and no one else would
step up to do it (or if I could/would myself) - Then yes. No one gains
by stuff just sitting in the tree bitrotting.

 Nigel> In this case its the AVR32 support which breaks x86 .... I'm sure there
 Nigel> are more users of AVR32 than x86. 1) its impractical to remove AVR32
 Nigel> support until its fixed, we don't know how long it will take  2) its
 Nigel> senseless to drop support for x86 because an AVR32 patch breaks it.

 Nigel> People new to buildroot trying it out don't want to scrape
 Nigel> through years of mailing lists to try find these few mails
 Nigel> about everything building fine on x86, then WHAM BAM
 Nigel> .... corruption in the weirdest ways in the generated
 Nigel> images. It puts people off and they get the first impression
 Nigel> that buildroot doesn't work ... something I've seen happen
 Nigel> ALOT!

True. Keeping a metadist like buildroot working for all archs and
combinations of packages is HARD.

 Nigel> Only alternative I can see is adding kludge to work around
 Nigel> horribly broken patches until someone fixes them or no one
 Nigel> bitches and they are removed like 6-12 months later. This way
 Nigel> everything works out of the box.

The problem is that noone would ever fix the real issues behind those
kludges.

 Nigel> The proposed kludge isn't too bad either, its merely splitting
 Nigel> the patches up into different dirs. I am willing to spin a set
 Nigel> of patches to implement these changes.

Ok, I would like to hear from John first if he's going to fix the
atmel patch.

-- 
Bye, Peter Korsgaard

[Buildroot] avr32 patches vs. x86 breakage

[Ulf Samuelsson]

> Hi,
> 
> >> They should fix their arch and you should not add kludge to work around
> >> such bugs, imo.
> 
> Nigel> In an ideal situation yes .... but buildroot is an opensource
> Nigel> project with no time constraints imposed on its contributors.
> 
> But that doesn't mean that contributors don't care.
> 
> Nigel> If I contributed a patch to add an arch to GCC, and it broke 2
> Nigel> months down the line when people began to use it, are you just
> Nigel> going to remove it out of buildroot until it gets fixed? What
> Nigel> happens if it broke support for everything except its own
> Nigel> arch?  What happens if there were thousands of users of it,
> Nigel> more than any other arch?
> 
> If you would not be ready to support your work and no one else would
> step up to do it (or if I could/would myself) - Then yes. No one gains
> by stuff just sitting in the tree bitrotting.
> 
> Nigel> In this case its the AVR32 support which breaks x86 .... I'm sure there
> Nigel> are more users of AVR32 than x86. 1) its impractical to remove AVR32
> Nigel> support until its fixed, we don't know how long it will take  2) its
> Nigel> senseless to drop support for x86 because an AVR32 patch breaks it.


The AVR32 is supported in two ways today.
1) Through downloading the prepatched source
2) Through normal methods with patches in the toolchain/gcc/gcc-x.y.z

I doubt that we need both.
It is VERY practical to remove the AVR32 support from the toolchain directory.


Best Regards
Ulf Samuelsson

[Buildroot] avr32 patches vs. x86 breakage

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

Sigh, resending with stripped CC list to make mailman happy ..

>>>>> "Bernhard" == Bernhard Fischer <rep.dot.nop@gmail.com> writes:
 >>> The real problem is that apparent quality issues of some of the arch
 >>> specific patches.

 Bernhard> They should fix their arch and you should not add kludge to
 Bernhard> work around such bugs, imo.

 Peter> Sure. That's the real solution ofcause.

 Peter> John, are you going to fix the 900-avr32-atmel.1.3.2.patch soonish?
 Peter> Otherwise I'll remove it.

 Peter> -- 
 Peter> Bye, Peter Korsgaard

-- 
Bye, Peter Korsgaard

[Buildroot] avr32 patches vs. x86 breakage

[John Voltz]

I agree with Bernhard, the AVR32 arch gcc patches seriously need fixed.
There are quite a few problems caused by gcc on the AVR32 as well. It works
pretty well for the most part, but there were problems back with gcc
4.1.2causing the kernel to oops while reading ext2 and ext3
filesystems, and now
gcc 4.2.1 breaks blackbox, and I've never been able to get webkit to work
reliably. gcc 4.2.1 also broke almost all of the open file dialogs in the
applications too. I'm blaming it all on the gcc patches.

Have there been other issues with buildroot in the past when adding other
arches? I'm actually glad all of this happened because it shines a light on
the quality issues in the AVR32 patches. Thanks to Nigel and Peter. I would
have never discovered this on my own. Sorry for giving you guys the
headaches though!

John Voltz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080321/b9b4eabc/attachment.htm 

[Buildroot] avr32 patches vs. x86 breakage

[Bernhard Fischer]

On Fri, Mar 21, 2008 at 07:36:00AM -0400, John Voltz wrote:
>I agree with Bernhard, the AVR32 arch gcc patches seriously need fixed.
>There are quite a few problems caused by gcc on the AVR32 as well. It works
>pretty well for the most part, but there were problems back with gcc
>4.1.2causing the kernel to oops while reading ext2 and ext3
>filesystems, and now
>gcc 4.2.1 breaks blackbox, and I've never been able to get webkit to work
>reliably. gcc 4.2.1 also broke almost all of the open file dialogs in the
>applications too. I'm blaming it all on the gcc patches.
>
>Have there been other issues with buildroot in the past when adding other
>arches? I'm actually glad all of this happened because it shines a light on

buildroot is not ment to be a patch-sink.
The _proper_ thing to do is to add your arch to the upstream packages.

Likewise, if you have to patch a package (for buildroot), then please take
it upon you to fix the issues _upstream_. Everything else is just a
maintenance-nightmare and does the opposite of what OSS is ment to
achieve in the long-run.


>the quality issues in the AVR32 patches. Thanks to Nigel and Peter. I would
>have never discovered this on my own. Sorry for giving you guys the
>headaches though!
>
>John Voltz

[Buildroot] avr32 patches vs. x86 breakage

[John Voltz]

>
>
> buildroot is not ment to be a patch-sink.
> The _proper_ thing to do is to add your arch to the upstream packages.
>

This is absolutely true. The reason the gcc patches haven't gone upstream is
because Atmel's legal department hasn't filed the copyright paperwork with
the FSF yet. And obviously we should all be glad that they haven't, because
the breakage would be widespread. I've asked the Atmel developers about the
status of upstream patches and it goes something like this:

gcc (and binutils?), waiting on legal documents for FSF

uClibc, in svn, will appear on 0.9.30 release.

Linux kernel, all upstream (in -mm, I think) except for some peripherals
that are still under testing.


John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080321/3251f89f/attachment.htm 

[Buildroot] avr32 patches vs. x86 breakage

[Ulf Samuelsson]

>>>>>> "Nigel" == Nigel Kukard <nkukard@lbsd.net> writes:
> 
> Hi,
> 
> Nigel> Hi Guys,
> Nigel> Will this proposal to fix the problem work ...
> 
> Nigel> - Make a dir under arch-avr32, for gcc-x.y.z
> 
> Nigel> - Add a make file to set something like
> Nigel> BOARD_EXTRA_PATCH_PATH=target/device/arch-avr32  this will be set if the
> Nigel> board is AVR32 based 
> 

Why not use the external source for the AVR32.
I think that adding the AVR32 arch specific patches to the toolchain
was a bad idea in the first place. Adds several megabytes to the download
every time you download.
The external source adds download once, and even if you have a slow
connection, I bet that you can access those files through a fast
connection once, and then keep it.


> Nigel> - In GCC / binutils/ uclibc and where ever else avr32 patches are
> Nigel> applied, we can tst if BOARD_EXTRA_PATCH_PATH is available. If it is to
> Nigel> add those patches into the patch set being applied. This should be
> Nigel> simplistic as we know the version for instance GCC_VERSION, we'd just
> Nigel> have to test the path exists and do something like    \*.patch
> Nigel> $(MORE_PATCHES)  , where we set a few lines up.  MORE_PATCHES=
> Nigel> $(BOARD_EXTRA_PATCH_PATH)/gcc-$(GCC_VERSION)
> 
> As discussed on IRC, I think its cleaner if everything related to a
> package is located under the package/<package>/ dir.
> 

I agree.


> The real problem is that apparent quality issues of some of the arch
> specific patches.
> 
> If possible, I would prefer if all archs would use the same sources
> (so apply the same patches for all archs) as the patches then get a
> lot more testing - E.G. you might otherwise not notice if a patch for
> some obscure arch no longer applies because you bumped the version of
> a package.
> 
> But that doesn't seem realistic with the current patches, so I instead
> suggest we split up patches in generic and arch specific. The generic
> ones gets applied to all archs, and only the arch specific ones for
> the selected arch.
> 
> The easiest setup is probably to use the naming convention:
> 
> - package-version-*.patch for generic stuff
> - arch-package-version-*.patch for arch specific stuff

No, because today the patches are applied to "*.patch" in some cases.
I believe that there is already a precedent to use "package-*.patch.$(ARCH)"

> 
> What do you think?
> 
> -- 
> Bye, Peter Korsgaard
> _______________________________________________


Best Regards
Ulf Samuelsson