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

[Nicolas Pitre]

On Fri, 1 Apr 2011, Arnd Bergmann wrote:

> On Friday 01 April 2011, Will Deacon wrote:
> 
> > > 1. The core arch code is not a problem (Russell does a great job here)
> > > 2. The platform specific code contains a lot of crap that doesn't belong there
> > >    (not enough reviewers to push back on crap)
> > > 3. The amount of crap in platform specfic files is growing exponentially,
> > >    despite the best efforts of a handful of people to clean it up.
> > > 4. Having one source file per board does not scale any more.
> > > 5. Discoverable hardware would solve this, but is not going to happen
> > >    in practice.
> > > 6. Board firmware would not solve this and is usually not present.
> > > 7. Boot loaders can not be trusted to pass valid information
> > > 8. Device tree blobs can solve a lot of the problems, and nobody has
> > >    come up with a better solution.
> > 
> > Right, so this is directly related to point (5) because in essence FDT
> > is a way to make undiscoverable hardware discoverable by probing the
> > tree. The `it's just data' mantra sums it up nicely.
> 
> Well, except that because of point 7, device trees are still inferior to
> having correct and complete information in hardware.

I helped with the design of a rather simple patch for ARM allowing for:

	cat zImage foobar.dtb > zImage_with_dtb

Then the kernel is smart enough to detect it has a dtb on its tail and 
use it.

In a perfect world the bootloader would be bug free and always up to 
date with the best DT data.  In practice I'm very skeptical this will 
always be the case and painless.  At least the above makes it very 
simple to have a self contained kernel when (not if) need be.

> > > 9. All interesting work is going into a handful of platforms, all of which
> > >    are ARMv7 based.
> > 
> > I think starting out ARMv7-only might make this more manageable but
> > there are still shed loads of pre-v7 chips out there which we should try
> > not to break.
> 
> Yes, see below: the idea is to touch as little of the existing code
> as possible, at least in the first stages.

I don't think this is a realistic approach.  See my previous mail. Once 
you start identifying concrete and well defined areas that needs 
cleaning, it is best to come up with solutions that covers as much 
existing code as possible, validating that the solution is also worth it 
in the process.  The more existing code you may cover with your cleanup, 
the more likely it will fit future hardware as well.


Nicolas
--
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/