Re: DT case sensitivity

On 23/08/2018 13:08, Rob Herring wrote:

On Thu, Aug 23, 2018 at 6:48 AM Benjamin Herrenschmidt
[off-list ref] wrote:

quoted

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] wro=

te:

quoted

quoted

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. Leas=

t

quoted

quoted

quoted

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.

I'd hazard to argue that the cost of the string compare will not be a
source of performance problems when compared to doing a linear search
everytime a DT lookup is performed. The search algorithm is far more
problematic.

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.

If case-insensitive-always is chosen, then the kernel should probably
complain at add node time if another matching node name already exists.
That's a relatively easy thing to test.

You are right however that in the FDT world we're case-sensitive now and
if it is relaxed then we're never going back. You could try switching
everyone over to case-sensitive and see if anything falls out in
linux-next for a few cycles. I would not touch the PPC or SPARC
behaviour. I don't think it is worth the risk to make the kernel more
strict when we cannot test the result. Only if everything was changed to
case-insensitive would it make sense to touch PPC and SPARC at the same
time because it reduces the number of platform variations.

If you do change compatible matches to be case sensitive, then you
should be prepared to fix bugs where the driver uses a different case
from the DTS. In which case drivers will need to be modified to accept
the deviant property names.

g.

IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.