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] [day] [month] [year] [list]
Date:	Sat, 1 Dec 2012 15:54:20 +0100
From:	Antonio Quartulli <ordex@...istici.org>
To:	Sven Eckelmann <sven@...fation.org>
Cc:	The list for a Better Approach To Mobile Ad-hoc
	 Networking <b.a.t.m.a.n@...ts.open-mesh.org>,
	netdev@...r.kernel.org
Subject: Re: Re: Re: [B.A.T.M.A.N.] [PATCH 6/7] batman-adv: Allow to use
 rntl_link for device creation/deletion

On Sat, Dec 01, 2012 at 02:39:26PM +0100, Sven Eckelmann wrote:
> On Saturday 01 December 2012 14:28:02 Antonio Quartulli wrote:
> > > 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.

> 
> > 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

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ