On Wed, Mar 27, 2013 at 04:47:39AM +0000, Keith Pine wrote:
> I'm using udev-147 in CentOS 6.3.
My sympathies :)
> I have two rules that import properties into the udev db. I'll use a
> simplified example.
>
> IMPORT{program}="program1 %k"
> ACTION=="add", IMPORT{program}="program2 %N"
>
> program1 exports MY_FOO, and program2 exports MY_BAR. I've noticed that
> when a change event is triggered, MY_BAR is no longer available in the
> udev database. So it appears change events clear the existing environment.
What is triggering a change event? What type of device? What driver?
> The work done in program2 is relatively expensive so I'd rather only run
> it when the device is first added.
>
> It looks like I can re-import MY_BAR if I use IMPORT{db} in a separate
> rule:
>
> IMPORT{program}="program1 %k"
> ACTION=="add", IMPORT{program}="program2 %N"
> ACTION=="change", IMPORT{db}="MY_BAR"
>
>
> Is this the correct approach? Or is there another way to persist the
> properties that were imported during add, besides re-importing program2?
I think that is correct. When a device "changes", all of it's
attributes are thrown away as they obviously changed (the kernel told us
so.)
> Also, is it possible to determine *what* causes a change event to occur?
What type of device is this?
> With 'udevadm monitor' I can see change events being triggered whenever my
> application exits (for the devices it has opened), and would like to
> determine why. I was hoping udev could give me a hint.
Your kernel driver should tell you why, what driver is it?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
