netdev - Re: [PATCH next 4/6] bonding: Allow userspace to set system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 8 Feb 2015 21:44:07 -0800
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	Jay Vosburgh <jay.vosburgh@...onical.com>
Cc:	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Veaceslav Falico <vfalico@...il.com>,
	Nikolay Aleksandrov <nikolay@...hat.com>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH next 4/6] bonding: Allow userspace to set system_priority

On Sat, Feb 7, 2015 at 11:46 PM, Jay Vosburgh
<jay.vosburgh@...onical.com> wrote:
> Mahesh Bandewar <maheshb@...gle.com> wrote:
>
>>On Fri, Feb 6, 2015 at 10:19 PM, Jay Vosburgh
>><jay.vosburgh@...onical.com> wrote:
>>> Andy Gospodarek <gospo@...ulusnetworks.com> wrote:
>>>
>>>>On Fri, Feb 06, 2015 at 04:51:54PM -0800, Mahesh Bandewar wrote:
>>>>> This patch allows user to randomize the system-priority in an ad-system.
>>>>> The allowed range is 1 - 0xFFFF while default value is 0xFFFF. If user
>>>>> does not specify this value, the system defaults to 0xFFFF, which is
>>>>> what it was before this patch.
>>>>>
>>>>> Following example code could set the value -
>>>>>     # modprobe bonding mode=4
>>>>>     # sys_prio=$(( 1 + RANDOM + RANDOM ))
>>>>>     # echo $sys_prio > /sys/class/net/bond0/bonding/ad_actor_system_priority
>>>>
>>>>If I can convince you to change 'ad_actor_system_macaddr' to something
>>>>different can I also convince you to change this to something shorter,
>>>>too?  :)
>>>>
>>>>Maybe 'ad_sys_priority' or something?
>>>
>>>         The name, verbose as it is, is from the 802.1AX standard, and
>>> there's also a "partner_system_priority" (which is not a user-settable
>>> thing, it's a field in the LACPDUs).  My suggestion would therefore be
>>> "ad_actor_sys_prio" for this one, as I think there's some value in
>>> continuity with the names from the standard.
>>>
>>>         The MAC address one in the standard is just "actor_system";
>>> there's a "partner_system" here, too, which is also a field in the
>>> LACPDU.  I'm ok with calling that one just "actor_system," as presumably
>>> anyone changing it will know what it means.
>>>
>>Thank you guys for the suggestions. I didn't like those very long
>>names either but when there is something that already has name
>>similar, I defaulted to being verbose. I will have the name changed to
>>-
>>
>>ad_actor_system_priority            - ad_actor_sys_prio
>>ad_actor_system_mac_address - ad_actor_system
>>ad_actor_user_port_key             - ad_user_portkey
>>
>>Is this reasonable enough?
>
>         Perhaps nitpicking, but I'd call it ad_user_port_key.
>
>         I agree that this one should not have "actor" in it, as this
> particular value is an invention of bonding and isn't directly part of
> the standard.  In bonding, the "user key" (always 0 prior to this
> patch), speed, and duplex are used to generate the actor_admin_port_key
> and actor_oper_port_key.  Those latter two are part of the standard, but
> have no required format.
>

Actually I was thinking of making ad_actor_sysprio instead of making
ad_user_port_key (feels like having more underscores makes it
unnecessary longer). That way all three look similar. So

         ad_actor_sysprio
         ad_actor_system
         ad_user_portkey

All carry the same theme of meaning. Otherwise we could do something like -

         ad_actor_sys_prio
         ad_actor_sys_mac
         ad_user_port_key

Which one seems more logical / reasonable?

>         -J
>
> ---
>         -Jay Vosburgh, jay.vosburgh@...onical.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html