On Wed, Jul 3, 2013 at 1:04 PM, Reshetova, Elena
<elena.reshet...@intel.com> wrote:
>>Things like:
>> ..., XATTR{foo}="foo", XATTR{bar}="bar"
>>would just eat the entire foo key. That is intentional? We usually have lists
>>for that, or we would not allow 2 keys ...
>
> Hm.. Do we want to allow multiple xattr setup on the same node?
I don't know. But we need to sure what we want and document it that way. :)
> I guess this
> can make sense if for example one is to setup the security label and another
> one some other attribute.
> So, I guess then it has to be stored in a list. I will take a look on how it
> is done for other cases.
> Could you please point to the right example on how such case is handled in
> udev (maybe from other permissions or attributes)? Some particular case that I
> should take as an example?
udev_list_entry_add(&event->run_list, ...
and quite a few other examples.
>>If pairs of values that belong to each other are allocated, we better check
>>if we run into allocation problems. Udev ignores that in some places and goes
>>ahead as the value would not have been set at all. But with pairs, we should
>>not end up with inconsistent pairs which have only the name or the value set.
>>The:
>> if ((xattr_name) && (xattr_label))
>>should then just become:
>> if (xattr_name)
>
> OK, and then I guess I would need to check during parcing that they are both
> set correctly and unset the other one, if one is missing, right?
Yeah, it's pretty simple: just always leave a clean state, or give up
where the error happens. Do leave invalid/partial data around and try
to cope with it later.
Kay
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
