Messages in this thread | | | Date | Sat, 27 Jul 2013 12:24:24 +0200 | From | "Arend van Spriel" <> | Subject | Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?] |
| |
On 07/27/2013 11:51 AM, Tomasz Figa wrote: > On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote: >> On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote: >>> Long term, final goal is likely to be close to what Russell is saying >> >> Why is this a long term goal? Start today. >> >>> -- nothing should go into the kernel tree unless the binding is in a >>> fully stable state. However, we have a transitional period between now >>> and then, and even when we're at the final state there will be need to >>> have some sort of sandbox for development and test of future bindings. >> >> Why not just set up a git tree right away? >> >>> Dealing with all that, as well as the actual process for locking in >>> bindings, is what needs to be sorted out. >>> >>> I think we're all in agreement that bindings that change over time are >>> nothing but pain, but we're arguing that in circles anyway. >> >> No. >> >> I keep saying, the bindings must be stable ABI, *today*. >> >> You keep saying, maybe later, but until then we will make things up as >> we go along. > > We have currently a lot of broken bindings, because people didn't know how > to define ones and those they defined have not been properly reviewed. Do > you really want such broken ABI in the kernel? > > Sure, there are many existing bindings that can be just made stable and > well they probably are already de facto stable. This is mostly about > subsystem bindings and whatever already has many users, both made them get > more thought when designing and more review before merging. > > Still, a lot of device and platform-specific bindings are simply broken. > Take max8925 backlight driver, that Olof started this whole discussion > with, as an example. We need to sort them out before they can be > stabilized.
That is a nice summary of how we got from null to now and Richard seems to be simply saying: let's stop mucking about and make this a project with a well-defined process of dealing with staging and stable bindings and keep stable bindings stable. Whether it should be within the kernel repo as a separate subsystem or in an entire different repo is a trivial decision, but still a decision that needs to be made.
Apart from stable DT bindings I would love to see a DT compiler that that next to DT syntax detects mistakes in properties used for the selfish reason that I spent hours debugging regulator code, because I typed vmmc_supply iso vmmc-supply. I did not go through all the bindings, but this may require a more formal description so it could be compiled/read in the DT compiler.
Regards, Arend
| |