[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