[LTP] [RFC PATCH 1/1] capability: Introduce capability API
Richard Palethorpe
rpalethorpe@suse.de
Wed Aug 21 13:43:34 CEST 2019
Hello,
Cyril Hrubis <chrubis@suse.cz> writes:
>> +
>> +struct tst_cap_user_header {
>> + uint32_t version;
>> + int pid;
>> +};
>> +
>> +struct tst_cap_user_data {
>> + uint32_t effective;
>> + uint32_t permitted;
>> + uint32_t inheritable;
>> +};
>
> This two should probably go to lapi as well.
Ah, but the naming of the original structures is so bad.
typedef struct __user_cap_header_struct {
...
} __user *cap_user_header_t.
Well not necessarily bad, but against current naming guidelines. I would
rather just use our own definitions and keep them separate from any
fallback definitions for test writers.
>
>> +struct tst_cap {
>> + uint32_t action;
>> + uint32_t id;
>> + char *name;
>> +};
>
> I wonder if we should build a table of capability names for translation
> just as we do errnos and signals instead of storing the name here. But I
> guess that unless we will need a function to translate capabilitities
> into strings on runtime this approach is simpler.
I suppose if we want to print all the current capabilities then we need
this. Which I can imagine would be useful, but I would rather wait until
someone actually needs it.
--
Thank you,
Richard.
More information about the ltp
mailing list