|To:||Ben Greear <greearb@xxxxxxxxxxxxxxx>|
|Subject:||Re: [bonding] Add basic support for dynamic configuration of bond interfaces|
|From:||Jeff Garzik <jgarzik@xxxxxxxxx>|
|Date:||Sun, 11 Jan 2004 16:59:10 -0500|
|Cc:||Amir Noam <amir.noam@xxxxxxxxx>, bonding-devel@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, hadi@xxxxxxxxxx|
|References:||<E6F7D288B394A64585E67497E5126BA601F991D1@xxxxxxxxxxxxxxxxxxxxxxx> <200401111628.07930.amir.noam@xxxxxxxxx> <4001A667.2020904@xxxxxxxxx> <4001C158.6040103@xxxxxxxxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703|
Ben Greear wrote:
I would also be open to moving the VLAN ioctls over into the ethtool ioctl space, but that just exchanges one magic ioctl for another...
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.
Opening a socket and just ioctl'ing away isn't terribly scalable in the long run, either. Consider all the applications that could legitimately claim they need a SIOCxxx ioctl assignment, just for their little slice of the networking world. Further, consider that all an ioctl is is a message sent to the kernel driver, perhaps sending and/or receiving some data. :)
ioctls are a pain for 32/64-bit emulation layers too. It seems much easier to define a netlink protocol family of some sort and communicate that way.
I'll poke around and see what I can come up with. Jeff
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [bonding] Add basic support for dynamic configuration of bond interfaces, Ben Greear|
|Next by Date:||Re: forcedeth 0.20 eth0: received interrupt report, Carl-Daniel Hailfinger|
|Previous by Thread:||Re: [bonding] Add basic support for dynamic configuration of bond interfaces, Ben Greear|
|Next by Thread:||Re: [bonding] Add basic support for dynamic configuration of bond interfaces, jamal|
|Indexes:||[Date] [Thread] [Top] [All Lists]|