James Carlson wrote: > I don't think I understand that. > > In order to issue the warning message, we would have to detect the > case in which someone is setting a destination address, but should not > be doing so. > > If we know enough about the exact case in which this occurs, why > wouldn't we just return an error and prohibit the action instead of > emitting a warning message? > > The answer has to be that we don't know the difference between the > cases where it happens and it's wrong and those where it's actually > right. If we emit a warning message if the command is used > _properly_, wouldn't that just introduce a new bug? (And likely also > customer calls from people baffled at what's broken ... ?) >
By way of mitigation, the last message was written under the assumption that this issue falls under the category of "not worth the bother and risk." I completely agree that the problem should be fixed rather than ignored, but if the risk is to great to fix it outright, why not issue a warning in the meantime? At the least, it notifies a user (or engineer) that how they make use of pointopoint interfaces may need to be re-thought out. It could also be that I am oversimplifying the problem; it would seem that if IFF_POINTOPOINT is not set on the interface at the time of the SIOCSIFDSTADDR ioctl call, a warning would be issued via cmn_err (the call would still succeed as it does today). I suppose there is also the option of simply categorizing this as a feature and not a bug. -- Yet magic and hierarchy arise from the same source, and this source has a null pointer. Reference the NULL within NULL, it is the gateway to all wizardry. _______________________________________________ networking-discuss mailing list [email protected]
