device: add generic named per-device property

[kib]

Summary

The KPI allows to store arbitrary data within struct device, retrieve it
back by name, and update the value.  The data is automatically destroyed
on the device deletion.  Also, the user can request to clear the named
property from all devices.

My need for this interface is due to IOMMU needing to save some
indicator on device, which must survive the re-creation of the domain
context.

[kib]

https://kib.kiev.ua/git/gitweb.cgi?p=deviant3.git;a=commit;h=e7cbd89e297dfbc5b746df74ada2b7181c41c380 usage example

[misha]

'man osd' won't help?

[kib]

In D46605#1062323, @misha wrote:

'man osd' won't help?

osd was my initial thought when I realized that I need this. But looking closely at interface, and realizing that I need to modify osd.h just to add my new osd type made me much less enthusiastic.

Also, osd would need too much rituals to be used: slots are identified by ints, while I can name them directly by iommu devunit name, etc, the overhead of osd is by order higher both in locking and in memory use. My code also has a way to conveniently destroy properties on either device or consumer destruction.

[kib]

Ping?

I have at least one more use for this: I plan to use the props to report iommu unit serving specific device.

[kib]

Allow NULL destructor.

[imp]

This seems reasonable to my eye.
I'd feel better if there were a man page for it, though.

[kib]

In D46605#1073513, @imp wrote:

This seems reasonable to my eye.
I'd feel better if there were a man page for it, though.

I will write the man page after the KPI sit some time in main, to catch any general public' suggestions.

[imp]

In D46605#1073525, @kib wrote:

In D46605#1073513, @imp wrote:

This seems reasonable to my eye.
I'd feel better if there were a man page for it, though.

I will write the man page after the KPI sit some time in main, to catch any general public' suggestions.

works for me. Thanks!

[emaste]

I will write the man page after the KPI sit some time in main

Most of the interface is obvious (to me), but some interesting points:

• for device_set_prop, If a property with the same name already exists, it is overwritten with the new value. EEXIST is returned in this case.
• the memory pointed to by name passed to device_set_prop must remain static for the lifetime of the property

[kib]

In D46605#1073551, @emaste wrote:

I will write the man page after the KPI sit some time in main

Most of the interface is obvious (to me), but some interesting points:

• for device_set_prop, If a property with the same name already exists, it is overwritten with the new value. EEXIST is returned in this case.

This is intended, of course.

• the memory pointed to by name passed to device_set_prop must remain static for the lifetime of the property

This is also intended. It is in-line with the destructor -based KPI for properties, since I want the owner to 1. be able to flush all owned properties (e.g. on owner detach) 2. to be able to handle device detach. From this PoV, typical consumer would provide the same string pointer to all prop_set() call.

I will note these cases in the hypothetical man page, thanks.