On Friday 20 March 2009, Jon Masters wrote: > > Sure, if there are very strong reasons to break things, fine. But > > whenever possible the kernel has ensured backwards compatibility, > > mostly only _after_ someone "complained". Think of the i386 and > > x86_64 symlinks after the x86 integration, think of the COMPAT_SYSFS > > flags, think of optional support for old /proc files, think > > feature-removal-schedule.txt. > > All of these examples refer to the future. The *future*. Things that > will change, preserving backward compatibility, keeping symlinks around > for those who are used to the old location. *Backward* compatibility. Exactly: making sure that tools in "older" userspace environments (old version of modprobe) continue to work with new kernels (or built in an environment that happens to have the latest and greatest depmod). > But the issue you raised was about *Forward* compatibility. This is > nice but isn't the same. That would be like guaranteeing that all > future kernel features will work with a kernel from 6 months ago, or > that modules will, or other similar stuff. I really don't see the huge difference. IMO you are comparing apples with oranges. I'm really don't think I'm trying to use modules from a 2.4 kernel with a 2.6 kernel here. m-i-t is _not_ an integral part of the kernel. It's just another tool, and one that's used in two different environments: a kernel build environment and a kernel user environment. And the format of the files generated by one and read by the other is the glue that keeps things together. Changing that format should IMO be done with due consideration for relevant use cases, and only if there are very strong arguments to do so. > > So far you seem to be avoiding to give the reasons for the change. > > What would be so wrong with ensuring the compatibility for some > > transition period and avoiding the problem? [...] > Hopefully you see that this is not a regular compatibility issue. What I mainly see is that you seem to be avoiding answering this question and are apparently unwilling to consider to repair the situation. I think my 2 cents are played out by now, so I'll drop things here. Maybe someone else will be willing to take up the batton. At least the issue is somewhat documented now. I'll inform others in Debian that the issue exists and fix things locally for my own use case. Thanks again for your replies. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
