[Top] [All Lists]

Re: [bonding] Add basic support for dynamic configuration of bond interf

To: Jeff Garzik <jgarzik@xxxxxxxxx>
Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Sun, 11 Jan 2004 13:34:16 -0800
Cc: Amir Noam <amir.noam@xxxxxxxxx>, bonding-devel@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, hadi@xxxxxxxxxx
In-reply-to: <>
Organization: Candela Technologies
References: <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
Jeff Garzik wrote:
Amir Noam wrote:

The new SIOCBONDING ioctl handles commands aimed for the bonding module (and not to any specific bonding interface). This is done via an ioctl hook that captures these commands at the socket level (before dev_ioctl()) and passes it to the bonding code. Such commands do not require opening a bonding interface at all, just a valid socket to send the ioctl.

Right. And this last requirement is spurious. The operation is essentially "open a socket unrelated to X, to perform actions on X".

bonding (and it sounds like VLAN too) needs a specific, well-known control point, for controlling module-level data such as the creation and deletion of interfaces.

One such well-known control point would be a /dev node. Jamal's suggestion is also an excellent one: let userspace use netlink to communicate with a well known "address" inside the kernel, which would work as the central (and thus bonding-module-wide) bonding control interface.

I was trying to follow the example of several other network modules (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to handle such deviceless commands.

Do you think that a char device is preferrable, given that other similar modules use a socket ioctl hook?

If vlan/dlci/bridge has similar requirements to described above ("open socket unrelated to X, to perform actions on X") then they need to be fixed up too.

Opening a random socket to use an ioctl(2) to produce some magic behavior is just ugly, and we need to avoid that. Maybe bgreear would be open to updating VLAN's interface to netlink at the same time, for

Actually, I am not a fan of netlink for normal configuration, and would prefer to keep the VLAN control through IOCTL calls. This is mainly because I have not had an easy time of figuring out a simple way to use netlink, while ioctls are very easy to use.

If someone wants to update vlan and vconfig to use netlink, then
maybe we could add that API as well, but definately we should not
remove the IOCTL calls untill at least 2.7.

I would also be open to moving the VLAN ioctls over into the
ethtool ioctl space, but that just exchanges one magic ioctl for


Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc

<Prev in Thread] Current Thread [Next in Thread>