On Thu, 2007-09-20 at 14:34 +0800, Bryan Wu wrote: > On Thu, 2007-09-20 at 02:08 -0400, Robin Getz wrote: > > On Wed 19 Sep 2007 23:54, Paul Mundt pondered: > > > On Wed, Sep 19, 2007 at 11:42:53PM -0400, Mike Frysinger wrote: > > > > On 9/19/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Sep 20, 2007 at 11:55:25AM +1000, David McCullough wrote: > > > > > > Jivin Robin Getz lays it down ... > > > > > > > On Tue 18 Sep 2007 04:09, Bryan Wu pondered: > > > > > > > > This just adds minimum support for the Blackfin relocations, > > > > > > > > since we don't have enough space in each reloc. The idea > > > > > > > > is to store a value with one relocation so that subsequent > > > > > > > > ones can access it. > > > > > > > > > > > > > > Adding the other appropriate maintainers. for h8, m32r, sh and > > > > > > > v850. > > > > > > > > > > > > Looks fine to me, obviously impacts the existing arches very > > > > > > little. Can't see why it shouldn't get included, > > > > > > > > > > I find it a bit disconcerting that blackfin already depends on this > > > > > in-tree without there being any earlier discussion on making these > > > > > changes. > > > > > > > > not really ... this patch was posted before but was lost in the > > > > shuffle ... and i'm not quite sure what you mean by "depends on" ... > > > > if you want to use the FLAT file format on a Blackfin processor, then > > > > this patch is needed, but that isnt the only file format that works on > > > > the Blackfin port as we also have FDPIC ELF > > > > > > > What I mean by "depends on" is that for what you are attempting to > > > patch, your architecture has an in-tree dependency on something that > > > hasn't > > > been discussed. > > > > "not been discussed" because it was sent to lkml - > > http://lkml.org/lkml/2006/9/22/60 > > - and it got missed/left on the floor during the arch/blackfin inclusion > > (which was huge), not because of any deliberate malicious intent on our > > part > > to mislead or try to get this in now by doing an end around as you are > > implying. > > > > Yes, as Robin pointed out, this patch was sent to LKML at least 3 times > including Bernd's email. This is the 4th round. > http://lkml.org/lkml/2007/5/29/24 > http://lkml.org/lkml/2007/5/28/63 > > I don't wanna to resend it again and again to annoy the receiver and > LKML. But IMO, technically this patch looks fine to binfmt_flat and > other architectures. And the in-tree Blackfin port will fail to be > compiled with this patch if the BINFMT_FLAT is enabled. >
Oops, typo. Correct one: it will fail to be compiled without this patch. > > Our mistake for not poking everyone/resending things sooner/before > > arch/blackfin was included. Bryan will try to make sure that doesn't happen > > again (right Bryan?) - like he is now, by poking/resending things, and > > making > > sure that the appropriate maintainers (like you, if we are changing things > > you maintain) are included. (which is what I think the problem was). > > > > If we can focus on the technical merits of things, rather than how we got > > here - which I agree sucks - was our mistake - we are sorry - we will try > > to > > make sure that it doesn't happen again - I think it would be time/effort > > better spent. > > > > Yes, I will try my best to avoid this happen again. But on the other > hand, several reasons made this mess happen: > a) not very easy found the maintainer information for several domain, > for example this patch should invite binfmt_flat maintainers, arch > maintainers (Thanks Robin to invite them), blackfin port maintainers and > toolchain maintainers. > b) even the maintainers got this patch email, they don't have time to > review or reply. So the patch was ignored by LKML and the sender, sorry > -:))). > c) There is a rule that do __NOT__ send the same patch again and again, > I don't wanna to break this rule. But if there is no feedback about the > patch, we have no choice but resent it or just ignore it. > > I know it is general problem in the LKML patch review. > > Thanks > -Bryan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
