>Complaints about interface churn for filesystems (or anything else, >actually, since an architecture, such as UML, is exposed to nearly the >entire kernel) are imcomprehensible to me. They're easily comprehensible to me. A few years ago, I was maintaining an experimental filesystem drivers and keeping up with the interface changes was a big pain to me. This was 2.4.10 and later and up through about 2.6.10, kernel.org, Red Hat, and Suse. The biggest pain was trying to maintain code that would work in multiple kernel versions, since I had users who wanted to use it with multiple versions. The actual amount of work to adapt to a new version usually wasn't extensive -- a few hours. But the disruption itself was enough to complain about. In the early 2.6 versions, the changes were immense. I think 2.6.1 -> 2.6.3 was a couple of days of design and coding and a few weeks of shaking bugs out. The bulk of the problematic changes were in the virtual memory system (used, as in most filesystem drivers, for cache and mmap). I had a standard to compare against that many Linux developers don't, and it may have enhanced my ability to complain. I was maintaining essentially the same code for AIX. AIX is a whole different world, because people don't have the source code and can't submit code to be distributed and maintained by the AIX developers. Consequently, it has a rock solid binary kernel module interface. There are also far fewer versions of AIX around than of Linux. So I never changed my code for AIX versions unless I wanted to exploit a new feature, and in that case, there was always a convenient facility for making the code work on older AIXes without the feature. I'm not arguing that Linux's philosophy on kernel module interfaces is wrong; I'm just saying it's easy to comprehend why people would complain about it. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
