On Fri, Apr 20, 2018 at 1:18 AM, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Apr 12, 2018 at 05:44:04AM -0500, Kumar Gala wrote: >> >> > On Apr 11, 2018, at 11:44 PM, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: >> > >> > On Wed, Apr 11, 2018 at 09:26:18AM -0500, Kumar Gala wrote: >> >> >> >>> On Apr 11, 2018, at 12:46 AM, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: >> >>> >> >>> On Tue, Apr 10, 2018 at 11:42:14AM -0500, Kumar Gala wrote: >> >>>> Curious if there is a reason that the alias node name char set is limited to [a-z][0-9] and ‘-‘. >> >>>> >> >>>> I’m guessing some historic reason, so curious as why that limited >> >>>> set. [I really want an emoji in my alias name ;)] >> >>> >> >>> I'm pretty sure that limitation goes all the way back to IEEE1275, >> >>> though I'm not sure of the rationale. Even if the set was widened you >> >>> couldn't really have an emoji since an alias - like all node names - >> >>> is a bag-o'-bytes, not a Unicode string. >> >> >> >> Any reason not to update the spec and allow alias names to be >> >> treated the same as any property name? >> > >> > Well, I don't think they should allow anything more than node names, >> > rather than property names, although I think the two are identical at >> > the moment. The reason is that aliases can appear in paths >> > "alias/foo/bar" so we don't want to expand the set of valid path >> > characters. >> > >> > The only printable character I can immediately see as being a definite >> > problem is '/'. >> > >> > Back in the OF days there might have been more restrictions based on >> > special characters in the Forth environment, to prevent paths with >> > aliases being confused for something else. Not sure. >> >> Matching the char set for node names seems reasonable to me. >> >> >> I was joking about the emoji bit. >> > >> > I thought you probably were :) >> > >> > I would turn the question around a bit, though: do we have a >> > compelling reason to expand the set. Aliases are kind of like >> > identifiers and usually languages work best if identifiers have >> > characters taken from a fairly small set. >> >> Mostly we seem to use ‘_’ in a lot of .dts files and figured I’d >> raise the discussion on the topic. Since we started warning about >> it, wanted to see what direction we might want to take. Really, where? They are a rare exception in dts files in the kernel tree. > Yeah, adding _ seems pretty reasonable to me, despite my general > misgivings about expanding the set. Expanding allowed things in alias > node properties to match property names in general also seems sensible > to me. Expanding what's allowed in dtc *labels* on the other hand > could cause trouble for the lexer, even though they have a somewhat > similar role to aliases. We've discouraged using '_' in node and property names for some time now. I don't think expanding aliases is the right direction. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
