[systemd-devel] udev rules environment variable

[Kay Sievers]

On Tue, Dec 17, 2013 at 11:58 AM, Hannes Reinecke <hare at suse.de> wrote:
> On 12/17/2013 11:52 AM, Kay Sievers wrote:
>> On Tue, Dec 17, 2013 at 8:56 AM, Hannes Reinecke <hare at suse.de> wrote:
>>> On 12/17/2013 08:52 AM, Robert Milasan wrote:
>>>> Hello,
>>>>   got a small question about creating a rule, like this:
>>>>
>>>> ACTION=="add", ...., ENV{test_device}="1"
>>>>
>>>> ACTION=="remove, ...., ENV{test_device}=="1",
>>>> RUN+="/path/to/some/script"
>>>>
>>>> Does udev save test_device variable someplace and then it can be used
>>>> later on, when have ACTION=="remove" ?
>>
>>> Typically not.
>>
>> There is a standard REMOVE_CMD in 95-udev-late.rules to use for this
>>
>> All variables are stored in the database and are contained in the
>> "remove" event, without the need to be added or queried. Sysfs though
>> is not available, all of it is gone at "remove".

> So 'remove' contains the environment variables set from the 'add' event?

Yes.

> What about the 'change' event?

No.

> I would have thought the same rule applies to this one, but
> experience shows that 'change' events have to generate the same
> environment variables as the 'add' event.
> Otherwise unexpected results happen ...
>
> So why are the environment variables / db entries not merged
> into the 'change' environment?

First of all, the logic at "remove" is older than "change" events even
existed in the kernel. :)

But it actually makes some sense that way. "Remove" is the death of
the device the last event in this life-cycle, so we can add everything
we know and it will not cause any harm or will leak. Also there is no
other data accessible anymore, sysfs is gone, so we need something to
match against.

"Change" on the other hand would leak the old state into the new
device representation and things like symlinks would never be removed
unless the variable is explicitly unset. Also sysfs is there as it was
at "add", we can (and should) just do the same stuff again.

There is IMPORT{db} for "change" events to explicitly carry specific
variables forward from the old device to the new one during "change",
by default all is gone.

Kay