> >> I was going to add it on to the end of the clean up set, but > >> if you want to do it, go ahead. Nobody seems to have objected to > >> removing the _OLD stuff, which I view as a good thing. > > My thinking here is that any ifenslave old enough (two years > or more) to still be using the OLD ioctl values is unlikely to work > with the current kernel driver, and if somebody did try it, it's > better to have the call fail outright than perform weird and > mysterious rituals in kernel memory. I have trouble envisioning an > scenario where a user would be using the latest 2.4.23 kernel, but an > ifenslave from, what, 2.2.15? 2.4.5? or so. I was specifically told by David Miller that we are not to break binary compatibility within a 2.4 release. Such things had to wait until 2.5 or later. We can not require a user to upgrade their ifenslave within a 2.4 series kernel just to keep using the same functionality they were using in 2.4.1. Obviously we can require them to upgrade in order to keep using new functionality. So the _OLD stuff needs to stay in the 2.4 kernel. If this was brought up in an earlier thread, then I just missed it. Chad - : 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
