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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 09 Apr 2007 13:35:11 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David Miller <davem@...emloft.net>
Cc:	kaber@...sh.net, akpm@...ux-foundation.org, dim@...nvz.org,
	netdev@...r.kernel.org, johannes@...solutions.net,
	jgarzik@...ox.com, containers@...ts.osdl.org, kuznet@....inr.ac.ru,
	shemminger@...ux-foundation.org, greearb@...delatech.com
Subject: Re: [PATCH] net: Add etun driver

David Miller <davem@...emloft.net> writes:

> From: Patrick McHardy <kaber@...sh.net>
> Date: Mon, 09 Apr 2007 18:58:13 +0200
>
>> It would be nice if someone would finally come up with a generic
>> interface based on netlink (RTM_NEWLINK) instead of adding yet
>> another couple of homegrown interfaces.
>
> I absolutely agree, using these ioctls and sysfs/procfs crap
> is totally insane given that we have a core mechanism for
> network configuration.

The core mechanism for network configuration does not support creating
virtual devices in a extensible reusable way.

In particular the tunnel types supported by iproute2 are hard coded
into the user space tool and into the kernel interface.  The interface
seems to be not the least bit extensible for creating new types of 
non hardware backed network devices.

So I don't see a readily usable mechanism for network configuration in
netlink.  The fact that netlink it uses unreliable packets and an
asynchronous interface just adds to the difficulty in making use of
it.

Nor have I seen a rigorous adherence to all new network configuration
using netlink.  The wireless code doesn't even seem to really try.

So I don't believe anyone has found a good maintainable, unix
compatible configuration mechanism for maintaining anything yet.


Regardless I really don't care what the interface is as long as people
agree and I don't have to rewrite significant portions of user space
to allow people to use it.

Since whatever user space interface we pick we will be stuck with
we might as well review it as closely as we can and figure out what
we can live with.


Just to be contrary I'm tempted to add a sysctl interface.  No one has
even mentioned class of user space interfaces yet.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ