[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1mz1h1guo.fsf@ebiederm.dsl.xmission.com>
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