On Thu, Jun 30, 2016 at 5:32 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote:
> On 6/30/2016 4:18 PM, Paul Moore wrote:
>> On Thu, Jun 30, 2016 at 4:59 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote:
>>> On 6/30/2016 3:17 PM, Paul Moore wrote:
>>>> On Thu, Jun 23, 2016 at 3:52 PM, Dan Jurgens <danielj@xxxxxxxxxxxx> wrote:
>>>>> From: Daniel Jurgens <danielj@xxxxxxxxxxxx>
>>>>>
>>>>> Support for Infiniband requires the addition of two new object contexts,
>>>>> one for infiniband PKeys and another IB End Ports. Added handlers to read
>>>>> and write the new ocontext types when reading or writing a binary policy
>>>>> representation.
>>>>>
>>>>> Signed-off-by: Daniel Jurgens <danielj@xxxxxxxxxxxx>
>>>>> Reviewed-by: Eli Cohen <eli@xxxxxxxxxxxx>
>>>>> ---
>>>>> security/selinux/include/security.h | 3 +-
>>>>> security/selinux/ss/policydb.c | 129 +++++++++++++++++++++++++++++++-----
>>>>> security/selinux/ss/policydb.h | 27 +++++---
>>>>> 3 files changed, 135 insertions(+), 24 deletions(-)
...
}
>>>>> + case OCON_IB_END_PORT:
>>>> This is a little bit of bikeshedding, but is there such thing as an IB
>>>> "port" that isn't an *end* "port"? Could we simply use OCON_IB_PORT?
>>> Jason Gunthorpe requested that the name be end_port in the RFC series.
>> His reasoning? Is there a IB port concept that isn't an end port?
> The IB spec defines them as such. I had called them ib_devices previously though so it's possible he would tolerate "port" instead.
Okay, if that is what they are called that's fine with me. Perhaps
just squash the macro to OCON_IB_ENDPORT or similar; all those
underscores are messing with my mental parser.
--
paul moore
security @ redhat
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
