Shachar Shemesh <[EMAIL PROTECTED]> writes: > As a side note, I don't know why the "user space interface" does not > include those programs (well, I can understand about ext2 tools, > assuming ext changed format since 2.4, which I don't know whether it > has). I find it extermely unlikely that procfs changed enough to break > ps or top (after all, the relevant part of /proc to make those > programs work exists even on Solaris). I can see why mount will change > interface, but not why backwards compatibility should not be extended > to the mount(2) syscall. The only program on your list that has, in my > view, a legitimate excuse for failing is udev, and as far as I recall, > Redhat 7.2 predates that by enough to make it irrelevant (in fact, > again, as far as I recall, the sysfs filesystem on which udev relies > wasn't in 2.4 at all, so the changes introduced to it over the 2.6 > versions can't make a difference). As, again, as far as I recall, > Redhat 7.2 does not use the (now deprecated or even removed) devfs, it > means that this particular incompatibility should make no difference > to Aviram.
Hi Shachar, You are asking excellent questions, and a generic answer is that compatibility is not limited to interfaces. The semantics of the kernel operation have changed significantly in many respects between 2.4 and 2.6. As a result, even if various userspace tools and utilities are totally "portable" in terms of the user/kernel *interface* you simply cannot expect them to operate correctly with a kernel they have not been written for or tested against. Google will give you better answers than me regarding specific utilities that must be upgraded with the kernel. Just some examples of stuff that may or may not be interesting to you. Module loading is the most obvious thing - the linking is done in the kernel and insmod is trivial compared to what it used to be when it did the linking. On the file system side, the support for "extended attributes", or per-file metadata embedded in the filesystem, has been expanded significantly. These differ for different FS, and include POSIX ACLs, journal commit time tuning, directory indexing for fast search, and - what is relevant to your excellent questions - default mount options. I have not checked, but I would not be surprised that even utilities such as tar would need to be updated to handle such attributes properly. The kernel changes may have been designed in such a way that things like tar will continue to "work" while ignoring the extensions, so that if you tar/untar a directory tree you'll get your data all right but not the attributes - I don't know. New - and essential - filesystems such as sysfs require mount modifications as well. It is possible that write support for NTFS, transparent compression for ISO9660, and other stuff like that does, too. You might argue that if these filesystems are not used the old mount might do, but I am not sure this is the case with sysfs. The format and structure of proc files may change from time to time, and programs that parse them (such as ps or top) may need to adapt. Such a change is not very likely in general, but between 2.4 and 2.6 it may have happened - I don't remember. On the device front, the 2.6 kernel has much more knowledge of the device internals (a necessity driven, in particular, for laptops). Hotplugging is the norm rather than an exception - the kernel no longer differentiates between a device discovered at boot or a device added later. The kernel now is even able to know of devices whose drivers have not been loaded yet. The infrastructure dealing with boring stuff like reference counting, power management, etc., has been unified. This does have implications for userspace - since the kernel operates differently userspace may need to do much less work now and do it differently than before. I know this is not a point-by-point answer to your questions, but I hope this helps convince you that the incompatibility is not as stupid as it looks at the first glance. As to the original topic of this thread, Aviram, I wouldn't dare. Backup the data, wipe the system clean, install something sane instead. If you cannot live without RH7.3, keep it, but stick to 2.4. -- Oleg Goldshmidt | [EMAIL PROTECTED] ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
