[Top] [All Lists]

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

To: netdev@xxxxxxxxxxx
Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces
From: Jason Lunz <lunz@xxxxxxxxxxxx>
Date: Mon, 12 Jan 2004 00:13:46 +0000 (UTC)
Organization: PBR Streetgang
References: <E6F7D288B394A64585E67497E5126BA601F991D1@xxxxxxxxxxxxxxxxxxxxxxx> <200401111628.07930.amir.noam@xxxxxxxxx> <4001A667.2020904@xxxxxxxxx> <4001C158.6040103@xxxxxxxxxxxxxxx> <4001C72E.8030108@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: slrn/ (Linux)
jgarzik@xxxxxxxxx said:
> The key question is what is the best interface for userland to configure 
> in-kernel information -that is unrelated to a specific interface-. 
> ethtool ioctl space doesn't apply, because that's a per-interface API.

ethtool is just as bad as brctl or any of the others. From (userland)

        static int doit(void)
                struct ifreq ifr;
                int fd;

                /* Setup our control structures. */
                memset(&ifr, 0, sizeof(ifr));
                strcpy(ifr.ifr_name, devname);
                /* Open control socket. */
                fd = socket(AF_INET, SOCK_DGRAM, 0);
                if (fd < 0) {
                        perror("Cannot get control socket");
                        return 70;

                /* now do ioctl() on fd, having nothing to do with
                 * AF_INET nor SOCK_DGRAM */

calling a spade a spade, and all that. I don't see how that's any better
than brctl. The per-interface only comes into it when you copy a dev
name into a struct ifreq, but that doesn't associate the fd with the
interface in any way. You could go ahead and issue another ioctl on the
same fd for a different interface. 


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