case sensitivity for devicetree node names

I had assumed that devicetree node names were case sensitive. But a recent email thread asserted that they were not, which made me curious.

Quoted 2 lines · Frank Rowand

I had assumed that devicetree node names were case sensitive. But a recent email thread asserted that they were not, which made me curious.

News to me. Got a pointer?

Rob

Why do you use strcasecmp() here?

I had assumed that devicetree node names were case sensitive. But a recent email thread asserted that they were not, which made me curious.

dtc treats node names as case sensitive:

$ cat test_node_case_1.dts

/dts-v1/;

/ {
	node-x {
		prop_a = < 1 >;
	};
};

/ {
	node-X {
		prop_a = < 2 >;
	};
};

$ cat test_node_case_2.dts

/dts-v1/;

/ {
	node-x {
		prop_a = < 1 >;
	};
};

/ {
	node-x {
		prop_a = < 2 >;
	};
};

$ dtc -O dts test_node_case_1.dts
/dts-v1/;

/ {

	node-x {
		prop_a = <0x1>;
	};

	node-X {
		prop_a = <0x2>;
	};
};

$ dtc -O dts test_node_case_2.dts
/dts-v1/;

/ {

	node-x {
		prop_a = <0x2>;
	};
};

But the Linux kernel source code defines of_node_cmp() as:

include/linux/of.h:

  /* Default string compare functions, Allow arch asm/prom.h to override */
  #if !defined(of_compat_cmp)
  #define of_node_cmp(s1, s2) strcasecmp((s1), (s2))

arch/sparc/include/asm/prom.h uses strcmp() instead of strcasecmp().

Examples of using of_node_cmp() to check for a node name can be found, for example, of_find_node_by_name().

Is case insensitivity for node names a bug in the Linux kernel, or desired for some reason?

-Frank

I chased through the history and found a 2.6.0-test5 announcement which noted the patch from you which adds:

  of_find_node_by_path()
  of_find_node_by_name()
  of_find_node_by_type()
  of_find_compatible_node()

(And the patch is commit 394edd852a14 in the git recreation of bitkeeper days, which is found at
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git)

That version of the functions uses a case insensitive compare for devicetree node names.

Do you remember why you chose to not use a case sensitive compare?

Quoted 15 lines · Frank Rowand

I chased through the history and found a 2.6.0-test5 announcement which noted the patch from you which adds:

of_find_node_by_path()
of_find_node_by_name()
of_find_node_by_type()
of_find_compatible_node()

(And the patch is commit 394edd852a14 in the git recreation of bitkeeper days, which is found at
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git)

That version of the functions uses a case insensitive compare for devicetree node names.

Quoted 3 lines

Do you remember why you chose to not use a case sensitive compare?

From memory, there were inconsistency in case on various earlier

machines (notably old macs). I think that's the main reason.

Cheers,
Ben.

Is there a kernel config option (or a small set of config options) that would identify the affected machines?  It would be ok if the option(s) also included some non-affected machines.  That way we could use the case insensitive compare for a small set of machines.

I had assumed that devicetree node names were case sensitive. But a recent email thread asserted that they were not, which made me curious.

dtc treats node names as case sensitive:

$ cat test_node_case_1.dts

/dts-v1/;

/ {
	node-x {
		prop_a = < 1 >;
	};
};

/ {
	node-X {
		prop_a = < 2 >;
	};
};

$ cat test_node_case_2.dts

/dts-v1/;

/ {
	node-x {
		prop_a = < 1 >;
	};
};

/ {
	node-x {
		prop_a = < 2 >;
	};
};

$ dtc -O dts test_node_case_1.dts
/dts-v1/;

/ {

	node-x {
		prop_a = <0x1>;
	};

	node-X {
		prop_a = <0x2>;
	};
};

$ dtc -O dts test_node_case_2.dts
/dts-v1/;

/ {

	node-x {
		prop_a = <0x2>;
	};
};

But the Linux kernel source code defines of_node_cmp() as:

include/linux/of.h:

  /* Default string compare functions, Allow arch asm/prom.h to override */
  #if !defined(of_compat_cmp)
  #define of_node_cmp(s1, s2) strcasecmp((s1), (s2))

arch/sparc/include/asm/prom.h uses strcmp() instead of strcasecmp().

Examples of using of_node_cmp() to check for a node name can be found, for example, of_find_node_by_name().

Is case insensitivity for node names a bug in the Linux kernel, or desired for some reason?

Quoted 70 lines · Frank Rowand

I had assumed that devicetree node names were case sensitive. But a recent email thread asserted that they were not, which made me curious.

dtc treats node names as case sensitive:

$ cat test_node_case_1.dts

/dts-v1/;

/ {
	node-x {
		prop_a = < 1 >;
	};
};

/ {
	node-X {
		prop_a = < 2 >;
	};
};

$ cat test_node_case_2.dts

/dts-v1/;

/ {
	node-x {
		prop_a = < 1 >;
	};
};

/ {
	node-x {
		prop_a = < 2 >;
	};
};

$ dtc -O dts test_node_case_1.dts
/dts-v1/;

/ {

	node-x {
		prop_a = <0x1>;
	};

	node-X {
		prop_a = <0x2>;
	};
};

$ dtc -O dts test_node_case_2.dts
/dts-v1/;

/ {

	node-x {
		prop_a = <0x2>;
	};
};

But the Linux kernel source code defines of_node_cmp() as:

include/linux/of.h:

  /* Default string compare functions, Allow arch asm/prom.h to override */
  #if !defined(of_compat_cmp)
  #define of_node_cmp(s1, s2) strcasecmp((s1), (s2))

Quoted 7 lines

arch/sparc/include/asm/prom.h uses strcmp() instead of strcasecmp().

Examples of using of_node_cmp() to check for a node name can be found, for example, of_find_node_by_name().

Is case insensitivity for node names a bug in the Linux kernel, or desired for some reason?

Hmm.. a bit embarrassingly, I've never really thought about this in all the years I've been doing dtc - I also pretty much just assumed it was case-sensitive.

I haven't been able to find something in IEEE 1275 definitively saying one way or the other - it's not exactly easy to search for since "case" gives you hundreds or thousands of irrelevant hits of the form "in the case of blah".

I do recall that there was a semantic difference between vendor prefixes in uppercase (they were supposed to be stock tickers) and those in lowercase (those were freeform). That suggests that property names at least were expected to be case sensitive.

Here's my inclination for how to treat this in dtc for the time being:
1) Leave the bulk of dtc case sensitive, as now
2) Add a new check which will generate an error if there are node names which differ only in case.

Any objections to that plan?

Quoted 79 lines · David Gibson

Quoted 70 lines · Frank Rowand

I had assumed that devicetree node names were case sensitive. But a recent email thread asserted that they were not, which made me curious.

dtc treats node names as case sensitive:

$ cat test_node_case_1.dts

/dts-v1/;

/ {
	node-x {
		prop_a = < 1 >;
	};
};

/ {
	node-X {
		prop_a = < 2 >;
	};
};

$ cat test_node_case_2.dts

/dts-v1/;

/ {
	node-x {
		prop_a = < 1 >;
	};
};

/ {
	node-x {
		prop_a = < 2 >;
	};
};

$ dtc -O dts test_node_case_1.dts
/dts-v1/;

/ {

	node-x {
		prop_a = <0x1>;
	};

	node-X {
		prop_a = <0x2>;
	};
};

$ dtc -O dts test_node_case_2.dts
/dts-v1/;

/ {

	node-x {
		prop_a = <0x2>;
	};
};

But the Linux kernel source code defines of_node_cmp() as:

include/linux/of.h:

  /* Default string compare functions, Allow arch asm/prom.h to override */
  #if !defined(of_compat_cmp)
  #define of_node_cmp(s1, s2) strcasecmp((s1), (s2))

Quoted 7 lines

arch/sparc/include/asm/prom.h uses strcmp() instead of strcasecmp().

Examples of using of_node_cmp() to check for a node name can be found, for example, of_find_node_by_name().

Is case insensitivity for node names a bug in the Linux kernel, or desired for some reason?

Quoted 8 lines

Hmm.. a bit embarrassingly, I've never really thought about this in all the years I've been doing dtc - I also pretty much just assumed it was case-sensitive.

I haven't been able to find something in IEEE 1275 definitively saying one way or the other - it's not exactly easy to search for since "case" gives you hundreds or thousands of irrelevant hits of the form "in the case of blah".

One reference in 1275 that I just happened to notice this morning is in "3.2.1.1 Node names":

Each node in the device tree is identified by a node name using the following notation:

driver-name@unit-addres:device-arguments

The driver name field is a sequence of between one and 31 letters, digits, and punctuation characters from the set ",._+-". Uppercase and lowercase characters are distinct.

I am reading "Uppercase and lowercase characters are distinct" to mean that node names are case sensitive.

Quoted 11 lines

I do recall that there was a semantic difference between vendor prefixes in uppercase (they were supposed to be stock tickers) and those in lowercase (those were freeform). That suggests that property names at least were expected to be case sensitive.

Here's my inclination for how to treat this in dtc for the time being:
1) Leave the bulk of dtc case sensitive, as now
2) Add a new check which will generate an error if there are node names which differ only in case.

Any objections to that plan?

I think that the kernel should match the current behavior of dtc.

I agree with "1)".

I don't think that "2)" is required. I think it is a really dumb idea for anyone to create a dts with node names that differ only in case. But I don't think it is the compiler's job to protect people from being dumb. An analogue would be the C language and compilers. The C compiler doesn't error on a program that has variables "foo" and "Foo".

My current thought is to create a Linux kernel RFC patch that

1) changes of_node_cmp() and friends to something like:

   #ifdef CONFIG_OF_CASE_BROKEN
   #define of_node_cmp(s1, s2) strcasecmp((s1), (s2))
   #else
   #define of_node_cmp(s1, s2) strcmp((s1), (s2))
   #endif

2) remove the sparc definition of of_node_cmp() and friends.

3) Change the Kconfig entry for CONFIG_PPC_PMAC to select CONFIG_OF_CASE_BROKEN

Then let the patch sit in the -next tree for two releases to try to shake out any issues. Any other case broken platform could then select or set CONFIG_OF_CASE_BROKEN if the dts and/or code can't be reasonably fixed.

I have a patch series (a few kernel printks and a userspace program to parse the console output) that shows 1) which properties the kernel attempts to access but do not exist in a given device tree and 2) which properties are in a given device tree but the kernel does _not_ attempt to access. I could probably extend that to do the same checks for node names. The patch series is not quite ready for prime-time, but I could make it easily available for anyone who is trying to figure out why my proposed kernel patch breaks a system's boot. Then it becomes a case by case choice of whether to fix the devicetrees or modify the kernel to also check for the incorrect case node.

-Frank

Quoted 1 line · Frank Rowand

On 06/13/16 18:10, David Gibson wrote:

Quoted 9 lines

Quoted 6 lines

Here's my inclination for how to treat this in dtc for the time being:
1) Leave the bulk of dtc case sensitive, as now
2) Add a new check which will generate an error if there are node names which differ only in case.

Any objections to that plan?

I think that the kernel should match the current behavior of dtc.

Quoted 7 lines

I agree with "1)".

I don't think that "2)" is required. I think it is a really dumb idea for anyone to create a dts with node names that differ only in case. But I don't think it is the compiler's job to protect people from being dumb. An analogue would be the C language and compilers. The C compiler doesn't error on a program that has variables "foo" and "Foo".

Hmm.. actually I think protecting you from being dumb is exactly the purpose of compiler warnings. Now that you found that quote from 1275, which is pretty definitive as far as I'm concerned, I'd expect to reduce that error to a warning (by default).

Quoted 2 lines · David Gibson

Quoted 1 line · Frank Rowand

On 06/13/16 18:10, David Gibson wrote:

< snip >

Quoted 17 lines

Quoted 16 lines

Quoted 6 lines

Here's my inclination for how to treat this in dtc for the time being:
1) Leave the bulk of dtc case sensitive, as now
2) Add a new check which will generate an error if there are node names which differ only in case.

Any objections to that plan?

I think that the kernel should match the current behavior of dtc.

I agree with "1)".

I don't think that "2)" is required. I think it is a really dumb idea for anyone to create a dts with node names that differ only in case. But I don't think it is the compiler's job to protect people from being dumb. An analogue would be the C language and compilers. The C compiler doesn't error on a program that has variables "foo" and "Foo".

Quoted 4 lines

Hmm.. actually I think protecting you from being dumb is exactly the purpose of compiler warnings. Now that you found that quote from 1275, which is pretty definitive as far as I'm concerned, I'd expect to reduce that error to a warning (by default).

A warning is ok by me.