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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
