On Wed, Oct 23, 2013 at 03:08:49PM -0600, Jason Gunthorpe wrote: > On Wed, Oct 23, 2013 at 09:58:50PM +0200, Thierry Reding wrote: [...] > > > Also, what happens during development? If you incompatibly change the > > > binding you should change the name, so maybe <version>!marvell,foo is > > > the way to go. > > > > > > v1 of the binding is 1!marvell,foo - version 2 is 2!marvell,foo, etc. > > > > > > When stablized the last bang is kept and the non-bang version is > > > added. The boot warning is supressed once stable no matter the > > > compatible string used in the dt... > > > > Why would we want to go through all that trouble if we define up front > > that the binding is experimental in the first place? Encoding a version > > number in it somehow entails that earlier versions are still supported > > in some way. > > No, certainly not. It just says the binding has changed and every DT > stanza that uses the old version needs to be reviewed and updated. > > > But the whole point of experimental bindings is so that we don't have to > > worry about backwards compatibility. > > The purpose is to not silently throw users/testers under the bus. A > driver that doesn't bind is much better than a driver that blows up in > some crazy, hard to determine way because the DT binding has been > silently incompatibly changed. > > The rule for experimental bindings should be that incompatible changes > to the binding must bump the version number at the same time, clearly > signalling to everyone using that binding that they need to take some > action. I disagree. I think that we should apply the same rule to DT bindings (at least experimental ones) that we apply to code within the Linux kernel. If you change an experimental binding in an incompatible way then it should be your responsibility to update all users of it so that they don't break. In reality I would hope that this isn't much of a problem really. Given the nature of a compatible value there will typically only be a single driver implementing it. Any users of it (DTS files) should be pretty easy to fix up at the same time. That's the same way that platform data used to work, except it had the advantage of the compiler actually pointing out incompatible changes. There has been some discussion about adding validation functionality to DTC, which should make it easy to find DTS files that require updating as well. The above would also indicate that because of their nature, experimental bindings might be better kept within the Linux kernel tree. That would make it easy to keep a good overview of what needs to be updated when a binding changes. It would also make the promotion to stable much more explicit by physically moving the binding document to a different repository. Obviously that comes with its own set of problem that we'll need to find a way to extend the board DTS files that will presumably be kept in the external stable binding repository with experimental content only available in the Linux kernel tree. Thierry
Attachment:
pgpAftezR2HBR.pgp
Description: PGP signature
