DT case sensitivity

[Grant Likely]

On 23/08/2018 13:08, Rob Herring wrote:
> On Thu, Aug 23, 2018 at 6:48 AM Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
>>
>> On Thu, 2018-08-23 at 06:43 -0500, Rob Herring wrote:
>>> On Thu, Aug 23, 2018 at 4:02 AM Grant Likely <grant.likely at arm.com> wrote:
>>>>
>>>>
>>>> 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.
>>>
>>>> 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.

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 confidential and may also be privileged. If you are not the intended recipient, please 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.