Best practice for compatible strings?

[Mitch Bradley]

As the original instigator of the generic names scheme, I can tell you 
what I had in mind.  That may not be the way things have evolved, but at 
least it's a data point.

The idea is that there are devices for which there are preexisting 
drivers.  Hardware designers often design new hardware that is 
compatible with older hardware so that the old driver can be used.  The 
new hardware often has additional features that can be used with new 
drivers, but at least the device is basically functional with the old 
driver.

The point of a non-specific fallback entry in a compatible property is 
to match an old driver that is known to be present in some important 
extant version of an OS.

In the absence of a preexisting legacy programming model and the 
corresponding old driver, there isn't much point in trying to "invent" a 
non-specific name.  I suppose that, theoretically, it might be possible 
to come up with a least-common-denominator programming model across a 
family of newly-designed devices, but that's not the way it usually 
works in practice, except in the case of a programming model defined by 
a standards committee.  More typically, a particular device gets some 
traction in the market, and then people copy that.

This model of driver evolution is more compelling for operating systems 
with a different development and distribution model than Linux's.  In 
the Linux world, it is hard to point to a specific shipping version and 
say "we must be compatible with that because it is what is already out 
there".

The bottom line:  In my opinion, if there is no preexisting driver that 
you can't change, there is little need for a non-specific name in the 
compatible list.

On 11/17/2011 8:25 AM, Dave Martin wrote:
> Hi Grant,
>
> There seems to be some confusion about how to define and use compatible
> strings in the device tree.  The ePAPR specification doesn't seem to
> spell this out.  If, as is probable, this discussion has happened
> already then feel free to point me to the conclusions.  I don't mean
> to imply that everyone is confused, but I am.
>
> Anyway, my uncertainty boils down to how to know when do define/use more
> specific names, and when to define/use more general names.
>
> [Apologies for verboseness -- as you will see, I was having a hard
> time pinning down what the question is, never mind the answer...]
>
> For example, since the initial Verstaile Express upstream support will
> almost certainly not support all variants from a single machine
> definition, it's unclear whether we should have a "arm,vexpress"
> compatible string at all.  Logically, such a string would be generic
> such that it encompassed not only all versatile express based platforms
> which exist now, but all those which will ever exist in the future.
> Generic strings are attempts to foretell the future, and may turn out to
> be misguided.  However, without this string in device trees, if there
> are eventually hundreds of vexpress based platforms, then the relevant
> board support and drivers in the kernel would have to list all of them
> in their compatible lists.
>
> So, is there a rule for distinguishing between generic compatible
> strings which capture something meaningful (which are probably a good
> idea) and those which do not (i.e., a bad idea).
>
> Finally, is there a convention for what common prefixes should mean?
> It sort of looks like there ought to be, but this can be problematic:
>
> Logically, I might suppose that:
>
>    1) "arm,vexpress" is more general than "arm,vexpress-v2p-ca9".
>    2) "arm,vexpress-v2p-ca9" is not more general than
> "arm,vexpress-v2p-ca5s", nor vice versa.  However, they may have some
> common features which could be possibly described by any common prefix
> of the two strings (such as "arm,vexpress" or "arm,vexpress-v2p" or
> whatever.
>
> However, apart from the vendor prefix convention there does not seem to
> be any formal convention about the anatomy of compatible strings.
> "arm,vexpress-1" might have no connection whatever with "arm,vexpress"
> (except that they come from the same vendor).  Nonetheless, the visual
> similarity may tempt people to believe that there is a deeper
> connection even if there isn't.
>
> (1) causes a particular problem: if an initial attempt to define a
> generic compatible string fails because a future device doesn't fit the
> meaning of the initial generic compatible string, then a new, different
> string is required which does not just append a suffix.  It is desirable
> in such a case to define a _new_ super-generic string to encompass all
> the cases (including the new ones we didn't originally foresee) -- but
> it becomes impossible for that new generic string to be a common prefix
> of all the specific strings it encompasses, so that although the generic
> string can be logically generic, it will not look generic...
>
> Suppose in the future we have some crazy thing like
> "arm,vexpress-v2p-ca25", but it isn't compatible with the original
> definition of "arm,vexpress".  People reading the strings will naturally
> assume compatibility, since the strings look similar.  If we want a new
> super-generic string (we probably do, since we would want to consolidate
> the kernel support), it would have to be something like
> "arm,brand-spanking-new-vexpress", since calling the new string
> "arm,vexpress-*" would give a misleading (reversed) impression of
> compatibility.  But the relationship between that and any of the other
> compatible strings is non-obvious.  The tempting alternative,
> redefinition of "arm,vexpress" to encompass the new platform is
> presumably not an option, because it would mean that new device trees
> would be misinterpreted/mishandled by old kernels and vice versa.
>
> Part of the problem is that in this situation, the actual definition of
> "arm,vexpress" is likely never to be properly clarified -- it is assumed
> initially to be obvious, and an undocumented de facto meaning arises
> from the way this string gets baked into the code.  Because this
> definition may end up distributed around various bits of code and may
> not match what was originally intended, it may be nearly impossible to
> construct a sensible meaning post-hoc which does not conflict with the
> implementation at some or all points in time.
>
> This seems to imply that compatible strings with generic meanings need
> to be very carefully thought out and precisely specified if they are not
> to be useless.  Unfortunately, instinct tends to suggest that those
> levels of care or recision are not needed for generic things, resulting
> in compatible strings which are vague instead of being generic in a
> precise way.
>
> Possibly I've answered my own question here, but I'd be interested
> in your view on it...
>
> Cheers
> ---Dave
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>