On Saturday 01 December 2012 14:28:02 Antonio Quartulli wrote:
quoted
Because this is the normal way to create virtual network devices (please
feel free to correct me).
Well, I've seen different iface types using many tools, e.g. vconfig,
tunctl, brctl..
Not that this justifies the fact that we should do the same (imho having a
standard and unified way for creating interfaces would be the best option).
The device creation and enslaving using vconfig, tunctl and brctl can be
replaced using ip.
But, to be honest, I think it should better discuss how to entirely
moving/changing the existent API to a "better one" or to a "new one",
instead of starting to maintain two of them from now on with no plan, don't
you think so?
I leave this discussion to the maintainers of batman-adv. Btw. removing the
old one without a time of coexistence sounds like a bad move. And therefore
maintaining of both interfaces like it is done in other network devices seems
to be necessary.
Kind regards,
Sven
On Sat, Dec 01, 2012 at 02:39:26PM +0100, Sven Eckelmann wrote:
On Saturday 01 December 2012 14:28:02 Antonio Quartulli wrote:
quoted
quoted
Because this is the normal way to create virtual network devices (please
feel free to correct me).
Well, I've seen different iface types using many tools, e.g. vconfig,
tunctl, brctl..
Not that this justifies the fact that we should do the same (imho having a
standard and unified way for creating interfaces would be the best option).
The device creation and enslaving using vconfig, tunctl and brctl can be
replaced using ip.
True.
quoted
But, to be honest, I think it should better discuss how to entirely
moving/changing the existent API to a "better one" or to a "new one",
instead of starting to maintain two of them from now on with no plan, don't
you think so?
I leave this discussion to the maintainers of batman-adv.
I started this discussion here because you are still part of them (even if not
listed in MAINTAINERS).
Btw. removing the
old one without a time of coexistence sounds like a bad move. And therefore
maintaining of both interfaces like it is done in other network devices seems
to be necessary.
Exactly, this is what I wanted to discuss as "a plan".
Anyway, I discussed about this together with the others and it seems
that a proper solution now is to wait before merging this patchset and fix the
current sysfs/rtnl_lock problem first. What do you think?
Adding a new API without fixing the current one doesn't sound like a good move.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara