Comment # 26 on bug 1051465 from Thomas Blume

(In reply to Franck Bui from comment #25)
> (In reply to Thomas Blume from comment #24)
> > 
> > KERNEL=="nvme*", ENV{DEVTYPE}=="disk", IMPORT{program}="/bin/sh -c
> > 'ID_SERIAL=$env{ID_SERIAL}; echo ID_SERIAL_TRUNCATED=${ID_SERIAL:0:16}'"
> > 
> > leaves ID_SERIAL_TRUNCATED empty:
> > 
> > because ID_SERIAL is not present in the shell environment.
> 
> Well that was an example which was supposed to show that string mangling
> could be inlined in the rule file.

Upstream seems to prefer less string mangling in the rules and to favour using
shell scripts instead (see comment#22).
I would follow them in this case.

> ID_SERIAL or whatever that needs to be used, is supposed to be retrieved
> from sysfs by using the "$attr{xxx}" syntax.

Yes, that's what the rule is doing.

> Please note that we should make sure to not pollute the environment that is
> already setup by the upstream rules. Therefore setting ID_SERIAL or ID_MODEL
> in 61-xxx is not a good idea.

Agreed, but can we be sure that the upstream rules always run before the compat
rules?
I see it as a kind of security measure to also set ID_SERIAL in the compat
rules. Since it takes the data from sysfs (just like the upstream rules do), we
shouldn't overwrite something with wrong values.
But that way we can be sure that the compat rules work, even if the upstream
rules fail or are executed later.
Does that make sense?