linux-kernel - The future of DT binding maintainership

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 20 Jul 2013 04:46:47 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Wolfram Sang <w.sang@...gutronix.de>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Pawel Moll <pawel.moll@....com>, devicetree@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Cc:	Rob Herring <rob.herring@...xeda.com>,
	Olof Johansson <olof@...om.net>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: The future of DT binding maintainership

A number of us had a face-to-face meeting in Dublin last week to talk
about DT maintainership and the fact that it simply isn't working right
now. Neither Rob nor I can keep up with the load and there are a lot of
poorly designed bindings appearing in the tree.

Device tree binding maintainership needs to be split off to a separate
group, and we've started with a few people willing to help, Pawel Moll,
Mark Rutland, Stephen Warren and Ian Campbell.

(BTW, even though I've already sent a patch adding that group
MAINTAINERS, this is not set in stone. Anyone else wanting to help
maintain should volunteer)

Another thing discussed is that we need to start validating DT schema
with an extension to dtc. Tomasz Figa has volunteered to do this work
and has support from his employer to spend time on it. What I'm hoping
to have is that the DT schema will get checked as part of the dts build
process so that any DT file that doesn't match the documented schema
will get flagged, and that the schema files will be human readable and
will double as documentation.

There is not yet any process for binding maintainership. We talked about
a few ideas, but they really need to be hashed out here on the mailing
list. A couple of the questions:

- How are bindings allowed to be merged? Through subsystem trees, or
  only through the bindings tree?
  - Through the bindings tree is more work but it will provide more
    control.
  - Through subsystem trees means drivers and bindings get merged
    together.
  - If we have a schema tool that reports errors on missing or
    unapproved schema, then spliting the driver from the binding won't
    matter that much.
- Do we need to differentiate between 'staging' and 'stable' bindings?
- What is the schedule for splitting the bindings and .dts files out of
  the kernel?
  - Ian Campbell is maintaining a DT bindings and .dts mirror tree which
    should eventually become the 'master' for merging DT bindings.

g.

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