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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
