On Wed, Sep 2, 2020 at 5:22 AM Till Maas till@redhat.com wrote:
Hi,
Am Di., 1. Sept. 2020 um 22:04 Uhr schrieb Jarod Wilson jarod@redhat.com:
On Tue, Sep 1, 2020 at 3:43 PM Fernando Fernandez Mancera ferferna@redhat.com wrote:
Hello again!
I am considering all the votes to list shared with you recently as no one proposed new words. Please, send your votes to the mailing list, you have until Friday 8.00 AM UTC :-)
P.S: I am considering the votes already sent, so there is no need to send them again.
I intend to go with either bundle/cable or parent/child for the kernel bonding driver, partially because they're the exact same lengths as master/slave, and make some degree of sense. I'd leave trunk and port off the list of options, because VLAN uses trunk quite a bit, and the bonding 802.3ad code already uses port. Probably leaning towards parent/child, since a bond isn't necessarily a bundle of cables. The bigger issue than actual naming is not breaking anyone's userspace, which unfortunately means quite a bit can NOT be changed. Secondary to that, is not making life hell for -stable kernel tree maintainers trying to backport from a bonding driver with new terminology in use.
I Hope that if we choose parent/child here, the kernel will also it in the future. :-)
Hm. I was not aware of vlan's usage of parent as well... I've got mixed opinions on whether stacked devices should all use similar naming conventions or device-specifc ones. There's also an argument to be made that we'd muddy things with processes, which all have parents and children as well. Not sure how familiar others are with the movie Despicable Me, but the idea of using boss/minion amuses me. Probably too much of a stretch to use Gru instead of boss, but think of the bonding slides you could do, talking about how minions are managed. :)
Now that I've muddied the waters even further... Fwiw, It doesn't look like parent is used at all in either the vlan or vxlan drivers in-kernel.
Note: there's also an open bugzilla for this issue, specific to the bonding driver.
what's the ID?
I believe it's marked as an internal bug, so some folks may not be able to access it, but here it is:
https://bugzilla.redhat.com/show_bug.cgi?id=1857405