From: Anton Blanchard <[EMAIL PROTECTED]> Date: Fri, 19 Aug 2005 05:08:36 +1000
> Maybe we should instead fire off the blink timer, return immediately > and stop the blink when our timeout has been exceeded. If the user > wanted to clear a blink they could then issue another ethtool call with > a 0 length timeout. Yes, the RTNL is overkill for this case. Actually, ethtool operations are in the scope of the device and need only be atomic within that realm. Furthermore, changes made by ethtool do not impact state that non-ethtool parts of the networking really care about. So therefore it is tempting to make a per-device ethtool semaphore or similar. This would mean that we'd need to carefully audit drivers which use ethtool to make sure there are no driver wide assumptions about atomicity between ethtool and non-ethtool calls. For example, does the driver depend upon a MAC address update not happening at the same time an ethtool PHY config change occurs? Both operations require reprogramming the device. I would really like to disentangle RTNL from spots where it truly isn't needed, but very carefully so... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
