Hi all, I am actively developing and maintaining some tools to do automatic network configuration, mostly for laptops. I currently maintain the laptop-net package, a part of Debian, and I am developing a new package in conjunction with Colin Walters, which is a redesign of laptop-net built on top of D-BUS. These programs provide a feature that watches the link-beat status of network devices, and uses that to configure or deconfigure the network as needed. The programs currently use MII support to detect the link beat, but I am extending them to support ethtool as well. As of the 2.4.20pre series, my code stopped working because some of the drivers changed their behavior. (There are a number of drivers that changed; one example is 8139too.c.) These drivers now require netif_running(dev) to be true before they will allow me to probe the link-beat status. Previously, the same drivers worked OK without this constraint. I understand that there are some ioctls that may require the interface to be running, but the evidence seems to indicate that the ioctls I'm interested do not, at least for my purposes. And this is a problem, because I am having trouble figuring out how to do what I need to. There is a simple workaround for the changed drivers, which is to set the IFF_RUNNING flag on the device, do the probe, then restore the flags to their original values. This works most of the time, but it has some problems: (1) not all drivers require this; (2) I have anecdotal reports that this fix breaks the code when used with at least one driver; and (3) it's ugly. So, could you explain to me why this change was made? And, if it was an important change, why didn't _all_ the drivers get the change instead of just a small number of them? I have a feeling that the change is meant to protect something else, and isn't really necessary for the things I'm doing, and if that's true I'd like to ask you to reconsider. Anyway, please reply directly to me as I don't read the list. Chris - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
