RE: [avr-libc-dev] Inclusion of far pointer library (patch#6352)broke avr-libc build

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Sunday, June 13, 2010 10:50 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] Inclusion of far pointer library 
> (patch#6352)broke avr-libc build
> 
> As Jan Waclawek wrote:
> 
> > Maybe a bit more narrative than standard documentation, but I wanted
> > to spawn a discussion first, I did not expect it will be included
> > that soon.
> 
> Jan, we all appreciate your effort and contributions, but please, if
> you want something discussed, start the discussion *here*.  If you
> want to place an additional pointer to the discussion on
> avrfreaks.net, that's fine, but this mailing list is the primary
> medium to discuss things among those who are interested in further
> development of avr-libc.  The list is open to everyone, so any
> avrfreaks.net user who is interested can join if they want, and did
> not yet -- you might be surprised to see how many people are actually
> subscribed to this list, Mailman tells me we've currently got 323
> subscribers.  So it's not that nobody would listen here, even if only
> one...two dozens out of the subscribers are taking part in
> discussions, but that's not different on avrfreaks.net.
> 
> Sorry, the article there has the quality of a "HOWTO" document, but
> it's nothing I'd consider for inclusion into the documentation (see
> below).  I don't have the time to convert it into a documentation
> snippet/article right now.
> 
> The feature will remain undocumented right now (despite the saying "An
> undocumented feature is called a bug"), just so we don't have to back
> it out again.  Btw., the segmented memory regions are certainly
> nothing to include them into default linker scripts, so if someone
> wants to use them, they have to create a custom linker script.  The
> documentation for the feature should thus shortly describe how to
> create a custom linker script.  .progmem_far might go into the default
> linker scripts in a future version I think: it's best if you submitted
> a patch to GNU binutils for this, and file it officially into their
> bugzilla.  That way, the AVR maintainer(s) of binutils have something
> they can refer to within their process.  Sorry there are so many
> places to point you at for submitting bug fixes and enhancements, but
> we've got three major projects (binutils, GCC, avr-libc), and each of
> them has its own process about how patches are being added.  That's
> nothing we could change here.

I have to emphatically agree with Joerg on all of this.

AVR Freaks is not the place to discuss new features, it is this mailing list.

In fact, I would almost suggest that the other progmem.h features, other than 
the additional *_PF function that was submitted, be *removed* until we have a 
chance to discuss the feature, what it requires, pros and cons, and how it fits 
into future planned work.

I wouldn't suggest posting a patch to the binutils folks as they will defer it 
back to us as they won't be able to properly judge whether or not an 
AVR-specific patch such as these linker script additions would be a good thing 
or a bad thing.

Unless there are any immediate objections, I will be preparing a patch to 
remove these additional progmem.h features.

Eric Weddington