On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote: > > Of course all this could have been done in C, but it wasn't/hasn't been.. > > You have identified the real issue: poor quality of the ARM board > support process within the kernel. Churn is still churn, whether in DT > or in platform devices, but the DT people promised to end the churn.
Actually my experience in this area was mainly from PPC, and granted it spanned the PPC32/PPC64 merge. > [ I disagree about the "more thought" part. The current discussion, > coming years too late after the introduction of DT to ARM Linux, is > contrary evidence enough. ] The current discussion has little to do with the quality of the bindings, look at the new kirkwood bindings - they have had much more thought put into them than the old board.c stuff they are replacing. > > I can't delay shipping while upstream sorts this out - so I know > > *absolutely* that the DT schema will change. This has been planned for > > and designed into the boot system and won't be a problem. > > > > Why would anyone do embedded any other way? > > Yep, that is the embedded way: ship it! > > We can do better than that. I think you missed the point. There is no way I can possibly ship a product with a DT that is finished. I can't tie my company's product release cycles to the whims of the kernel community. So embedded people are going to ship with unfinished DT and upgrade later. They have to. There is no choice. Stable DT doesn't change anything unless you can create perfect stable bindings for a new SOC instantaneously. This is where I see the whole disconnect in this discussion. General-purpose and embedded are *DIFFERENT* users, and they have different use-cases and different needs. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
