> -----Original Message----- > From: > avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of Joerg Wunsch > Sent: Sunday, June 13, 2010 10:50 PM > To: avr-libc-dev@nongnu.org > 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 _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
