Thread (16 messages) flat view 16 messages, 5 authors, 2018-08-24

Re: DT case sensitivity

From: Rob Herring <robh@kernel.org>
Date: 2018-08-23 12:08:43
Also in: linux-devicetree

On Thu, Aug 23, 2018 at 6:48 AM Benjamin Herrenschmidt
[off-list ref] wrote:
On Thu, 2018-08-23 at 06:43 -0500, Rob Herring wrote:
quoted
On Thu, Aug 23, 2018 at 4:02 AM Grant Likely [off-list ref] wrote:
quoted

What problem are you trying to solve?
I'm looking at removing device_node.name and using full_name instead
(which now is only the local node name plus unit-address). This means
replacing of_node_cmp() (and still some strcmp) calls in a lot of
places. I need to use either strncmp or strncasecmp instead.
quoted
I would think making everything
case insensitive would be the direction to go if you do anything. Least
possibility of breaking existing platforms in that scenario.
Really? Even if all the "new" arches are effectively case sensitive?
Anything using dtc and libfdt are (and json-schema certainly will be).
But I frequently say the kernel's job is not DT validation, so you
pass crap in, you get undefined results.
I tend to agree with Grant. Let's put it this way:

What is the drawback of being case insensitive ?
It's a more expensive comparison. I don't think it's a hot path, but
we do do a lot of string compares.

Property names are case sensitive already. It would be nice if
everything was treated the same way.

If we're case sensitive then it is well defined which node we'll match
and which one will be ignored. Otherwise, it is whichever one we
happen to match first.
Do we expect that there exist a case where we will want to distinguish
between nodes that have the same name with a different case ?
If someone has a DT with a node in the wrong case (as defined in the
DT spec or a binding doc) and the kernel accepts it, then it's an ABI.
Yes, as Grant says, validation is the place that should catch it, but
we're not there yet and it's cheap (cheaper in fact) for the kernel to
do.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help