On Wed, Sep 19, 2007 at 11:42:53PM -0400, Mike Frysinger wrote:
quoted text
> On 9/19/07, Paul Mundt <lethal@linux-sh.org> 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. It's more than a bit backwards to push the follow-up bits before
even getting an Ack on the changes you want to make in the common code.

The fact you have other options is great, so at least you haven't shafted
all of your git kernel users, but that's not the point. You should not be
pushing things in to the kernel that have dependencies on API changes
that may or may not be merged, especially when you're breaking the entire
kernel for your platform (and the ability to bisect for those users) in
the process.
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/