From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH v2 0/6] batctl: Add vid support and hardif settings
Date: Tue, 09 Jul 2019 17:36:36 +0200 [thread overview]
Message-ID: <2853563.THXLFkejgW@prime> (raw)
In-Reply-To: <20190623130709.24751-1-sven@narfation.org>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
Hi,
overall I think this is a good idea. Please see below:
On Sunday, June 23, 2019 3:07:03 PM CEST Sven Eckelmann wrote:
> Hi,
>
> I've asked a quite while back for some ideas regarding the support for hard
> interface settings in batctl [1]. The current consensus seems to be that
> a more iw-like interface is prefered.
>
> vlan settings
> =============
>
> The requirement to have a VLAN master device on top of the batadv mesh
> interface is artificially limiting the capabilities of batctl. Not all
> master devices in linux which register a VLAN are from type "vlan" and are
> only registering a single VLAN.
>
> For example VLAN aware bridges can create multiple VLANs. These require
> that the VLAN is identified using the VID and not the vlan device.
>
> It is now possible to specify the vlan using:
>
> $ batctl vlan bat0.8 ap_isolation enable
> $ batctl meshif bat0 vid 8 ap_isolation enable
>
>
> hardif settings
> ===============
>
> The infrastructure for the new vlan/vid prefix of commands can now be used
> to introduce another prefix: "hardif".
>
> B.A.T.M.A.N. V introduced two additional settings which are hard (slave)
> interface specific. These can can finally be implemented in batctl. This
> will allow to change/read these settings when sysfs support is not enabled
> in the kernel.
>
> $ batctl hardif eth0 throughput_override 15mbit
> $ batctl hardif eth0 elp_interval
>
>
> Changes
> =======
>
> v2
> --
>
> * replaced (while still being compatible) -m option with "meshif"/"dev"
> prefix * added alternative "slave" for "hardif" prefix
I'd drop those alternative names "slave" and "dev". If we want to change the
naming, we have to do it everywhere. If we don't change the naming, then I
would say we shouldn't even advertise an alternative naming to not confuse
users and keep everything consistent. And if don't advertise, there is no good
reason to parse it and bloat the code.
That's my take, at least. :)
In general, I really like the tree like structure in favor of an unituitive
option parsing.
Cheers,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2019-07-09 15:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-23 13:07 [PATCH v2 0/6] batctl: Add vid support and hardif settings Sven Eckelmann
2019-06-23 13:07 ` [PATCH v2 1/6] batctl: Make vlan setting explicit Sven Eckelmann
2019-06-23 13:07 ` [PATCH v2 2/6] batctl: Integrate hardif setting framework Sven Eckelmann
2019-06-23 13:07 ` [PATCH v2 3/6] batctl: Add elp_interval setting command Sven Eckelmann
2019-06-23 13:07 ` [PATCH v2 4/6] batctl: Add throughput_override " Sven Eckelmann
2019-06-23 13:07 ` [PATCH v2 5/6] batctl: Replace '-m meshif' option with selector prefix Sven Eckelmann
2019-06-23 13:07 ` [PATCH v2 6/6] batctl: Allow to omit explicit prefix name Sven Eckelmann
2019-07-09 15:36 ` Simon Wunderlich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2853563.THXLFkejgW@prime \
--to=sw@simonwunderlich.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox