Rebuttal by a Linux kernel developer
Posted Sep 23, 2004 22:10 UTC (Thu) by
khim (subscriber, #9252)
In reply to:
Rebuttal by a Linux kernel developer by gregkh
Parent article:
A Sun engineer on Linux
Applications written for Linux 1.0 work just fine on the 2.6 kernel.
Now, this is just plain wrong. Any applications ? No chance in hell: there were quite a few changes in userspace visible API (even if you'll forget about things like procfs and devfs). Take a look on linux/arch/i386/kernel/entry.S :
.long sys_ni_syscall /* old break syscall holder */
.long sys_ni_syscall /* old stty syscall holder */
.long sys_ni_syscall /* old gtty syscall holder */
.long sys_ni_syscall /* old ftime syscall holder */
.long sys_ni_syscall /* old prof syscall holder */
.long sys_ni_syscall /* old lock syscall holder */
.long sys_ni_syscall /* old mpx syscall holder */
.long sys_ni_syscall /* old ulimit syscall holder */
.long sys_ni_syscall /* old profil syscall holder */
.long sys_ni_syscall /* old "idle" system call */
More then 10 syscalls are already history - and it's without counting some syscalls with non-100%-compatible implementation!
Some applications? You do not need any serious compatibility for this: empty shell script works for all known UNIX-like systems - you can even rename it to .bat and run unmodified under Windows !
Yet I do not see this like such a big problem: there are no such a thing as 100% compatibility! And most obsoleted syscalls are really... obsoleted and not used by contemporary programs. And yes, usually old interface is kept around for a long-long time. Yet... just this week all sysadmins got the warning to prepare to throw away perfectly good userspace applications. Why ? Support for that code is too hard, it's obsoleted for a few years, so it's time to stop bothering. You just can not keep old interfaces forever.
It's way better to have no support for "old USB drivers" model (like Linux does) then buggy support for "old USB drivers" (like Windows does) and I'm pretty sure Sun engeeners spend a lot of time trying to support old binary interfaces - work with no real benefits in open-source world, where driver can always be adopted to new API.
(
Log in to post comments)