[Rant] Atmel developers: Please submit code upstream

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
Correa
Correa's picture
Level: Hangaround
Joined: Tue. Aug 8, 2006
Posts: 175 View posts
Location: Brazil
#1
Posted by Correa: Mon. Apr 6, 2009 - 09:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I work with upstream buildroot when I have the time to, from where atmel feels free to pull changes from, which is perfectly ok and desireable. We also try to support AVR32 in the upstream project, but the high number of patches makes it dificult.

Not mentioning the gcc soup opera, I found today that openssl is in similar situation.

The openssl patch is unclean, it touches way more files than just necessary to add des-avr32.S and aes-avr32.S as suggested by it's naming. This makes the patch not to apply cleanly anymore.

It could be solved by submiting your changes upstream. You should not try to maintain everything on your own when you can offset some development to the upstream projects.

In the current Atmel's buildroot, you are using version g in the patch while there is a version k that fixes several important security issues.

There is not even a mention of "AVR32" in any of the openssl mailing lists [1]. Which suggests no one has even attempted to submit it upstream, even after having this patch for so long.

The only reason I'm wasting my time on this is to try to make this platform support the best possible, I'm sure your goals are the same as well. You guys have made a great job so far, but failing to take this last step makes your work outdated in very short amount of time.

[1] http://www.openssl.org/support/

PS: A copy of this post is going to support.atmel.no in an attempt to reach Atmel developers. Users, you can show your support replying.

Kind Regards,
Thiago A. Correa

Tags:

AVR Microcontrollers, AVR UC3
Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Tue. Apr 7, 2009 - 02:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correa wrote:
I work with upstream buildroot when I have the time to, from where atmel feels free to pull changes from, which is perfectly ok and desireable. We also try to support AVR32 in the upstream project, but the high number of patches makes it dificult.
Last I heard upstream buildroot didn't want AVR32 cruft until avr32 gcc support was upstream. See below
Quote:
Not mentioning the gcc soup opera,
This hasn't been handled brilliantly - Atmel are trying to get the stuff upstream but the rules of GCC contribution require copyright assignment statements from anyone who wrote avr32 gcc support. Rather than getting the sigs as they went they're still running around now and trying to get them all.
Quote:
I found today that openssl is in similar situation.
I wasn't aware of this one but it's a good point, it should be cleaned, rebased and sent upstream. But all this comes down to people hours; sometimes things like that just slip :-)

-S.

Blag: http://www.niasdigital.com/blag

Top
jsiei97
jsiei97's picture
Level: Hangaround
Joined: Tue. Mar 20, 2007
Posts: 209 View posts
Location: Sweden
Posted by jsiei97: Tue. Apr 7, 2009 - 04:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:

But all this comes down to people hours; sometimes things like that just slip :-)

-S.

When I read this I become a little bit sad,
the reason to send things upstream is to avoid work in the future. If you don't, you keep patching things forever,
you keep patching more and more and more....

If this is post is true and Atmel has not sent anything upstream somebody needs to do something,
it must be in Atmels best interest that the gap is as small as it possibly can especially since this type of work is not very glamorous, it is important to do it right so it don't pile up and smother this really great project!

BR
Johan

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Tue. Apr 7, 2009 - 10:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jsiei97 wrote:
When I read this I become a little bit sad,
the reason to send things upstream is to avoid work in the future. If you don't, you keep patching things forever,
you keep patching more and more and more....
Well yeah, but how many of us have stayed up nights hacking at something, madly getting it working and ended up with a pile of patches (or worse, modified code with no clean diff generated). Then the next morning you wake up and start madly working on the next thing. Ideally you'd be able to have a cup of coffee and distribute the patches upstream right then and there, but it ain't always the case!

As an example in this last week I've been getting Arora to run on the EZLCD+101 board. In that process I've just checked my patch queues and I've generated 3 patches against the kernel, 1 against uClibc, 1 against Qt/webkit and 1 against Arora. They'll be going upstream next week because I know I've got some time off but hells, if I didn't have that break then I'm ashamed to say there's a chance that they would just get buried. As I say, some times things just slip.

Moreover many of the upstream lists are subscribers-only and the act of finding the right submission point, subscribing to the list, confirming that subscription, finding the patch submission procedure (S-O-B etc), modifying my mailbox scripts to alert me to any replies (I can't scan ~1000 emails a day across all my subscriptions so my scripts triage for me), responding to replies, keeping track of which lists I don't need to be on anymore etc etc.. It all takes immediate time, time I don't always have!

So yes, the openSSL stuff should have gone upstream. Period. But I can see how it might not have.

-S.

Blag: http://www.niasdigital.com/blag

Top
Correa
Correa's picture
Level: Hangaround
Joined: Tue. Aug 8, 2006
Posts: 175 View posts
Location: Brazil
Posted by Correa: Wed. Apr 8, 2009 - 04:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

squidgit wrote:
Last I heard upstream buildroot didn't want AVR32 cruft until avr32 gcc support was upstream. See below

Actually, there was no problem with AVR32 per se, not even the monstruous patches actually. It was already in the repository anyway. And although the project doesn't want to be a repository of endless patches, it does ask that patches get submitted, it was there and it was working

The upstream buildroot is supporting AVR32 to the best it can. People from other platforms does their best not to break things here and myself and a couple of other AVR32 users try to keep things updated and working. For the toolchain, it changed from patches to a prepatched gcc download with controversy (I was against, but it was pushed anyway).

Regardless of that, it supports AVR32 quite well, and I use it for the NGW all the time.

Quote:
This hasn't been handled brilliantly - Atmel are trying to get the stuff upstream but the rules of GCC contribution require copyright assignment statements from anyone who wrote avr32 gcc support. Rather than getting the sigs as they went they're still running around now and trying to get them all.

True, but AVR32 is a bit older than 2 years now, and for at least a full year we have been hearing of them trying to submit.

We are lucky we got u-boot patches merged a long time ago, the ARM guys still have to live with a branched u-boot.

As I said earilier, if this isn't done, their work, as good as it is, becames obsolete really fast and will likely consume ppl/hours again, and again.

I can understand the rush to get things done because there is a pile of other stuff to do, but it doesn't take that long to file an entry into the bug tracker with a patch. And it can save you a couple of hours later. Not to mention that this greatly improves the custommer experience.

There are people like you and me who are willing to help maintaining the code into the upstream projects. They need to take advantage of that, so they can have more time to push those great new features to market :)

Btw, the gcc thing again: If you enable Qt with xmlpatterns (which requires -exceptions) you won't be able to compile, because you get an internal compiler error every 1 or 2 cpp files. Submitting upstream helps getting bugs fixed and perhaps we wouldn't have this issue.

Top
squidgit
squidgit's picture
Level: Raving Lunatic
Joined: Sun. Sep 14, 2003
Posts: 4228 View posts
Location: Queanbeyan, Australia
Posted by squidgit: Wed. Apr 8, 2009 - 05:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correa wrote:
We are lucky we got u-boot patches merged a long time ago, the ARM guys still have to live with a branched u-boot.
Yeah uboot and kernel support is first class for avr32. Probably not a coincidence that both of those things are maintained by the same guy. Top work Haavard, we looove you ;-)
Quote:
Btw, the gcc thing again: If you enable Qt with xmlpatterns (which requires -exceptions) you won't be able to compile, because you get an internal compiler error every 1 or 2 cpp files. Submitting upstream helps getting bugs fixed and perhaps we wouldn't have this issue.
Right, there are a few places you can hit internal compiler errors still, and a few notable omissions (like having relaxable jumps, not just relaxable calls) and upstream eyes would be fantastic. Certainly I wish that the Atmellians could just ruddy well get the sigs and/or rewrite the code written by any vanished parties.

-S.

Blag: http://www.niasdigital.com/blag

Top