Re: [GIT PULL] omap changes for v2.6.39 merge window

[Thomas Gleixner]

On Wed, 30 Mar 2011, Tony Lindgren wrote:

> * Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> [110330 15:35]:
> > On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
> > > * Thomas Gleixner <tglx@xxxxxxxxxxxxx> [110330 14:07]:
> > > > 
> > > > So one person will be not enough, that needs to be a whole team of
> > > > experienced people in the very near future to deal with the massive
> > > > tsunami of crap which is targeted at mainline. If we fail to set that
> > > > up, then we run into a very ugly maintainability issue in no time.
> > > 
> > > One thing that will help here and distribute the load is to move
> > > more things under drivers/ as then we have more maintainers looking
> > > at the code.
> > 
> > In many cases, the ARM SoC vendors will want their people producing the
> > code, so although moving things to drivers might be a good thing to do,
> > it won't really increase the number of people involved.  Plus the move
> > to the drivers subtree would be a problem for devices with tight ties
> > to the board or SoC.
> > 
> > There is work on pushing towards common code, but there is a lot of code
> > and this will take time and a lot of work.
> 
> I agree on the common code part, then even drivers with tight
> ties to board or SoC become just generic drivers that are easy
> to review.

You wish. There is an already existing problem that the identical IP
cores of peripheral crap are reused accross architectures. And of
course because it is a different architecture we have two different
drivers with different issues.

See: http://marc.info/?l=linux-kernel&m=130041568128164

We already fail to detect this on the driver level, so please answer
the question I asked before: How do you spread the load and scale with
the amount of shite which is coming in?

The above example is probably not the only one in tree and we will see
lots of unnoticed instances of drivers dealing with minimal different
versions of the same IP crappola in the near future simply because the
vendors claim that their stuff is unique and only works with their
particular instance of hackery unless we have enough capable people to
look over this. Whether it's in arch/ or drivers/ it does not
matter. We are simply not prepared to the amount of crap coming in.

Thanks,

	tglx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/