the future of ethtool

[Jeff Garzik <jeff@garzik.org>]

Thanks for accepting ethtool maintainership.

There are two key unresolved issues with ethtool that are worth noting 
to the next maintainer.  Both of these come from years of user and 
customer complaints.

1) ethtool command line interface.

For 1,001 minor reasons of user taste and expectation, people tend to 
complain about the command line interface.  Due to script usage it is 
set in stone, and has been since before my tenure.  But users 
continually request something more flexible, often, in particular, 
wanting to set multiple settings in one execution, or wanting to apply 
the same setting to multiple interface in one execution.

Obviously one can script this, but, it is probably the #1 user request.

My thought was to create "nictool", a new tool with more flexible 
command line interface, using the same old ethtool ioctls currently in 
use today.  ('nictool' also solves a minor naming complaint from 
wireless and other people, who use ethtool on non-ethernet network 
interfaces)


2) multiple settings and the ethtool kernel interface

Another common complaint is related to multiple settings, and associated 
hardware NIC resets.

Many ethtool driver implementations look like this:

	ethtool_op_do_something()
		stop RX/TX
		apply settings
		perform full NIC reset, consuming much time
		start RX/TX

The problem arises when the user wishes to change multiple hardware 
attributes at the same time.  A user wishing to change 4 attributes 
could wind up with 4 ethtool(1) invocations, with 4 accompanying 
hardware NIC resets.  Time consuming, inefficient, and unnecessary.


Obviously the world has not ended without these changes, but these items 
do cause continued complaints from users, and we're here to be 
responsive to users presumably ;-)

	Jeff