device properties and change events

device properties and change events

[Keith Pine]

I'm using udev-147 in CentOS 6.3.

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.
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?

Also, is it possible to determine *what* causes a change event to occur?
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.

-Keith

Re: device properties and change events

[Greg KH]

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

RE: device properties and change events

[Keith Pine]

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHcmVnIEtIIFttYWlsdG86Z3Jl
Z2toQGxpbnV4Zm91bmRhdGlvbi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyOCwgMjAx
MyAzOjU5IFBNDQo+IFRvOiBLZWl0aCBQaW5lDQo+IENjOiBsaW51eC1ob3RwbHVnQHZnZXIua2Vy
bmVsLm9yZw0KPiBTdWJqZWN0OiBSZTogZGV2aWNlIHByb3BlcnRpZXMgYW5kIGNoYW5nZSBldmVu
dHMNCg0KLi4uDQoNCj4gSSB0aGluayB0aGF0IGlzIGNvcnJlY3QuICBXaGVuIGEgZGV2aWNlICJj
aGFuZ2VzIiwgYWxsIG9mIGl0J3MNCj4gYXR0cmlidXRlcyBhcmUgdGhyb3duIGF3YXkgYXMgdGhl
eSBvYnZpb3VzbHkgY2hhbmdlZCAodGhlIGtlcm5lbCB0b2xkIHVzDQo+IHNvLikNCg0KT2ssIHRo
YXQgbWFrZXMgc2Vuc2UuDQoNCj4gPiBXaXRoICd1ZGV2YWRtIG1vbml0b3InIEkgY2FuIHNlZSBj
aGFuZ2UgZXZlbnRzIGJlaW5nIHRyaWdnZXJlZCB3aGVuZXZlcg0KPiBteQ0KPiA+IGFwcGxpY2F0
aW9uIGV4aXRzIChmb3IgdGhlIGRldmljZXMgaXQgaGFzIG9wZW5lZCksIGFuZCB3b3VsZCBsaWtl
IHRvDQo+ID4gZGV0ZXJtaW5lIHdoeS4gSSB3YXMgaG9waW5nIHVkZXYgY291bGQgZ2l2ZSBtZSBh
IGhpbnQuDQo+IA0KPiBZb3VyIGtlcm5lbCBkcml2ZXIgc2hvdWxkIHRlbGwgeW91IHdoeSwgd2hh
dCBkcml2ZXIgaXMgaXQ/DQoNClNDU0kgYmxvY2sgZGV2aWNlIChzZCkuIFlvdXIgcXVlc3Rpb25z
IGdvdCBtZSBsb29raW5nIGFnYWluLCBzbyBJIGRpZCBhIHF1aWNrIHRlc3Qgd2hpY2ggc2hvd2Vk
IHRoYXQgdGhlIGFjdCBvZiBjbG9zaW5nIGEgZmlsZSBkZXNjcmlwdG9yIG9wZW5lZCBvbiB0aGUg
YmxvY2sgZGV2aWNlIHdpdGggd3JpdGUgYWNjZXNzIGlzIGVub3VnaCB0byB0cmlnZ2VyIHRoZSBj
aGFuZ2UgZXZlbnQgKHJlYWQtb25seSBhY2Nlc3MgZG9lcyBub3QgY2F1c2UgYSBjaGFuZ2UgZXZl
bnQpLiBJIGxvb2tlZCBhdCBzY3NpIGRlYnVnIGxvZ3MsIGV0Yy4sIGFuZCBmaW5hbGx5IGNoZWNr
ZWQgR29vZ2xlLCB3aGVyZSBJIHdhcyByZW1pbmRlZCBhYm91dCB0aGUgd2F0Y2ggb3B0aW9uLiBT
dXJlIGVub3VnaCwgdGhlIDYwLXBlcnNpc3RlbnQtc3RvcmFnZS5ydWxlcyBmaWxlIGVuYWJsZXMg
d2F0Y2ggZm9yIHNkIGRldmljZXMuIElmIEkgc2V0IG5vd2F0Y2ggaW4gbXkgY3VzdG9tIHVkZXYg
cnVsZXMgdGhlIGNoYW5nZSBldmVudHMgbm8gbG9uZ2VyIHRyaWdnZXI7IG15c3Rlcnkgc29sdmVk
Lg0KDQpJIGd1ZXNzIG5vdyBJIG5lZWQgdG8gY29uc2lkZXIgd2hldGhlciBvciBub3QgSSBldmVu
IHdhbnQgd2F0Y2ggZW5hYmxlZCBmb3IgbXkgYmxvY2sgZGV2aWNlcy4gVGhlcmUncyBubyBmaWxl
c3lzdGVtIGFuZCBteSBhcHBsaWNhdGlvbiB3aWxsIHR5cGljYWxseSBiZSB0aGUgb3duZXIgYW5k
IG9ubHkgdXNlciwgc28gSSdtIG5vdCBzdXJlIHRoZSBvcHRpb24gaXMgdXNlZnVsLiBBcmUgeW91
IGF3YXJlIG9mIGFueSBvdGhlciBraW5kIG9mIGV2ZW50cyB0aGF0IGNvdWxkIGNhdXNlIGEgY2hh
bmdlIGV2ZW50IG9uIGEgYmxvY2sgZGV2aWNlPw0KDQpUaGFua3MsDQpLZWl0aA0K