On Wed, 2007-04-11 at 18:52 +0200, Patrick McHardy wrote:
> I'm not sure I'm following. I was under the impression that the
> conclusion of yesterdays discussion was that its probably not
> worth using rtnetlink for wireless so it will continue to use
> generic netlink exclusively, but even if tha
Johannes Berg wrote:
> On Wed, 2007-04-11 at 18:15 +0200, Patrick McHardy wrote:
>
>> But you have a valid point, if we want to use
>>this for things like bonding or VLAN that aren't actually address
>>families, we should consider introducing "rtnetlink families" to
>>avoid adding AF_BONDING, AF_8
On Wed, 2007-04-11 at 18:15 +0200, Patrick McHardy wrote:
> No, generic netlink avoids allocating netlink families.
Well, yes, I thought that was pretty much the point. :)
> br_netlink
> uses the same netlink family as the other network configuration stuff
> (NETLINK_ROUTE), but a different rtg
On Tue, 10 Apr 2007 23:16:59 +0200
Johannes Berg <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
>
> > Same way as the current RTM_SETLINK message works, but with creating
> > a new link in advance. It works fine in other subsystems, so I don't
> > see why i
Johannes Berg wrote:
> On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
>
>
>>Same way as the current RTM_SETLINK message works, but with creating
>>a new link in advance. It works fine in other subsystems, so I don't
>>see why it would in this case as well. Some subsystems do it in an
>
On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
> Same way as the current RTM_SETLINK message works, but with creating
> a new link in advance. It works fine in other subsystems, so I don't
> see why it would in this case as well. Some subsystems do it in an
> atomic fashion (network sch
On Tue, Apr 10, 2007 at 02:05:46PM +0200, Patrick McHardy wrote:
> So simply put: if I can implement support for
> "ip wireless add dev wlan0 mode managed essid ... key ..."
> in less than 100 lines and get a working connection afterwards, it
> seems worth it.
ACK
--
John W. Linville
[EMAIL PRO
On Tue, 2007-04-10 at 14:05 +0200, Patrick McHardy wrote:
>
> I know too little about wireless to judge really this. My opinion is
> that if it is possible to add and configure an interface (even if
> only for simple cases) without knowledge about driver internals by
> setting a few parameters, it
Johannes Berg wrote:
> Fair enough. Then the question however remains whether wireless should
> try to do all things it needs in one or try leveraging multiple things
> from other places. Thoughts?
I know too little about wireless to judge really this. My opinion is
that if it is possible to add
On Tue, 2007-04-10 at 13:09 +0200, Patrick McHardy wrote:
> I know :) It was a few month ago when I noticed the new bonding
> sysfs interface when I first thought that we really need this.
:)
> > I don't think wireless can get away without a new tool. So much stuff
> > there. Look at
> > http://
Patrick McHardy wrote:
Maybe not wireless, but bonding, briding, vlan, etun, possibly more.
[if I understand you correctly] I agree. With ethtool, the idea is to
have a single tool that supports multiple hardware platforms -- even to
the point of introducing hardware-specific code into ethto
Johannes Berg wrote:
> On Tue, 2007-04-10 at 12:46 +0200, Patrick McHardy wrote:
>
>
>>The main advantage that we don't get more weird sysfs/proc/ioctl based
>>interfaces
>
>
> Please don't put me into a corner I don't want to be in ;) The new
> wireless stuff was completely designed using netl
On Tue, 2007-04-10 at 12:46 +0200, Patrick McHardy wrote:
> Not totally different, so far I think we should use the same attributes
> as for RTM_SETLINK messages and include the device-specific stuff in
> IFLA_PROTINFO, which is symetric to what the kernel sends in RTM_NETLINK
> messages (see br_n
Johannes Berg wrote:
> On Tue, 2007-04-10 at 11:52 +0200, Patrick McHardy wrote:
>
>
>>Without having thought much about it yet, roughly like this:
>>
>>- driver receives RTM_NEWLINK message (under rtnl)
>>- driver allocates new device
>>- driver initializes device based on content of RTM_NEWLINK
On Tue, 2007-04-10 at 11:52 +0200, Patrick McHardy wrote:
> Without having thought much about it yet, roughly like this:
>
> - driver receives RTM_NEWLINK message (under rtnl)
> - driver allocates new device
> - driver initializes device based on content of RTM_NEWLINK message
> - driver returns
Johannes Berg wrote:
> On Tue, 2007-04-10 at 09:52 +0200, Patrick McHardy wrote:
>
>
>>Shouldn't be a problem either. Creating the device atomically also
>>prevents that anything else is setting them UP before they're fully
>>configured.
>
>
> How would you do it generically then? I'm absolutel
On Tue, 2007-04-10 at 09:52 +0200, Patrick McHardy wrote:
> Shouldn't be a problem either. Creating the device atomically also
> prevents that anything else is setting them UP before they're fully
> configured.
How would you do it generically then? I'm absolutely not opposed to the
idea but for n
Johannes Berg wrote:
> Our virtual devices are always associated with a piece of hardware, and
> we really want them to be associated with that at all times, even when
> not UP. Everything else seems like a huge complication if only because
> then we can't have whoever will be responsible for the d
On Tue, 2007-04-10 at 00:08 -0600, Eric W. Biederman wrote:
> How are you specifying which piece of hardware today? By interface name?
By wiphy index, which is just the hardware identifier we give each
802.11 device present on the system (if it uses cfg80211)
> What function do your virtual dev
Johannes Berg <[EMAIL PROTECTED]> writes:
> Our virtual devices are always associated with a piece of hardware, and
> we really want them to be associated with that at all times, even when
> not UP. Everything else seems like a huge complication if only because
> then we can't have whoever will be
On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
> Same way as the current RTM_SETLINK message works, but with creating
> a new link in advance. It works fine in other subsystems, so I don't
> see why it would in this case as well. Some subsystems do it in an
> atomic fashion (network sch
Johannes Berg wrote:
> On Mon, 2007-04-09 at 22:11 +0200, Patrick McHardy wrote:
>
>
>>Thats why I suggested that we should create one, ideally before adding
>>more sysfs/proc/ioctl/... based interfaces, which we'll have a hard time
>>getting rid of again.
>
>
> But then how would we configure
On Mon, 2007-04-09 at 22:11 +0200, Patrick McHardy wrote:
> Thats why I suggested that we should create one, ideally before adding
> more sysfs/proc/ioctl/... based interfaces, which we'll have a hard time
> getting rid of again.
But then how would we configure initial parameters along with creat
Eric W. Biederman wrote:
> 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
On Mon, 2007-04-09 at 13:35 -0600, Eric W. Biederman wrote:
>
> Nor have I seen a rigorous adherence to all new network configuration
> using netlink. The wireless code doesn't even seem to really try.
You're talking about the wext stuff that was invented ten years ago.
cfg80211/nl80211 which I
Eric W. Biederman wrote:
Nor have I seen a rigorous adherence to all new network configuration
using netlink. The wireless code doesn't even seem to really try.
Not true:
commit 711e2c33ac9221a419a9e28d05dd78a6a9c5fd4d
Author: Jean Tourrilhes <[EMAIL PROTECTED]>
Date: Wed Feb 22 15:10:56 2
David Miller <[EMAIL PROTECTED]> writes:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> 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 interf
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Mon, 09 Apr 2007 11:14:52 -0700
Patrick McHardy wrote:
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.
My pre
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> 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.
>
>
> My preference is for ioctls, procfs, or similar that does not
> requ
From: Patrick McHardy <[EMAIL PROTECTED]>
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
From: Ben Greear <[EMAIL PROTECTED]>
Date: Mon, 09 Apr 2007 11:14:52 -0700
> Patrick McHardy wrote:
>
> > 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.
>
> My prefere
Patrick McHardy wrote:
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.
My preference is for ioctls, procfs, or similar that does not
require extra libraries. Ethtool is an i
Johannes Berg wrote:
> On Fri, 2007-04-06 at 20:51 -0600, Eric W. Biederman wrote:
>
>
>>The only sysfs attributes that were always available that I could find
>>were module parameters. A little odd because we can specify them on
>>the kernel command line, or when loading the module in addition
On Fri, 2007-04-06 at 20:51 -0600, Eric W. Biederman wrote:
> The only sysfs attributes that were always available that I could find
> were module parameters. A little odd because we can specify them on
> the kernel command line, or when loading the module in addition to
> being available at run
Eric W. Biederman wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
I guess that will do, but then if you ever change the strings, any user-space
that is
depending on this will break or have to be modified with additional cruft. It
seems
cleaner to me to have an ioctl or a specific place in /pr
Ben Greear <[EMAIL PROTECTED]> writes:
> I guess that will do, but then if you ever change the strings, any user-space
> that is
> depending on this will break or have to be modified with additional cruft. It
> seems
> cleaner to me to have an ioctl or a specific place in /proc or some other
> vi
Eric W. Biederman wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
Is there any way to tell for certain if an interface is a etun or not? Maybe
a file could be found (or not) in sysfs somewhere?
Link for any decent network driver ethtool -i
I guess that will do, but then if you ever
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> Why not implement a true virtual network rather than simple
> tunnel pairs?
Mostly I don't even need etun. It is a cheap way to make up for
the lack of sufficient physical network adapters on the machine.
If you plug in enough network cards into th
Roland Dreier <[EMAIL PROTECTED]> writes:
> > +/*
> > + * The higher levels take care of making this non-reentrant (it's
> > + * called with bh's disabled).
> > + */
> > +static int etun_xmit(struct sk_buff *skb, struct net_device *tx_dev)
>
> You have this comment, but then...
>
> > + dev-
Ben Greear <[EMAIL PROTECTED]> writes:
> Is there any way to tell for certain if an interface is a etun or not? Maybe
> a file could be found (or not) in sysfs somewhere?
Link for any decent network driver ethtool -i
> Also, how do you find the peer device from user-space? This would be very
Stephen Hemminger wrote:
On Fri, 06 Apr 2007 14:38:50 -0700
Ben Greear <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
Why not implement a true virtual network rather than simple
tunnel pairs?
What would a true virtual network do? You mean with routers and such?
On Fri, 06 Apr 2007 14:38:50 -0700
Ben Greear <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > Why not implement a true virtual network rather than simple
> > tunnel pairs?
> >
> What would a true virtual network do? You mean with routers and such?
Rather than just a pair, you could
Stephen Hemminger wrote:
Why not implement a true virtual network rather than simple
tunnel pairs?
What would a true virtual network do? You mean with routers and such?
I use my redirect device (basically same as etun) to join virtual
routers together,
but all of the virtual routing (and b
Why not implement a true virtual network rather than simple
tunnel pairs?
Details:
> +static struct {
> + const char string[ETH_GSTRING_LEN];
> +} ethtool_stats_keys[ETUN_NUM_STATS] = {
> + { "partner_ifindex" },
> +};
You should use sysfs attributes for this rather than
ethtool.
> +s
Eric W. Biederman wrote:
etun is a simple two headed tunnel driver that at the link layer looks
like ethernet. It's target audience is communicating between network
namespaces but it is general enough it has other valid uses as well.
Ben Greear implemented a similar device called redir-dev, for
> +/*
> + * The higher levels take care of making this non-reentrant (it's
> + * called with bh's disabled).
> + */
> +static int etun_xmit(struct sk_buff *skb, struct net_device *tx_dev)
You have this comment, but then...
> +dev->features = NETIF_F_FRAGLIST
> +
etun is a simple two headed tunnel driver that at the link layer looks
like ethernet. It's target audience is communicating between network
namespaces but it is general enough it has other valid uses as well.
Ben Greear implemented a similar device called redir-dev, for network
emulation.
OpenV
47 matches
Mail list logo
