--- Rene Herman <[EMAIL PROTECTED]> wrote: > >If we're limited to Linux kernels, this seems to not be the case. Great care >is taken in keeping >this userspace ABI stable -- new system calls are given new numbers. Old >system calls may >disappear (after a long grace period) but even then I don't believe the number >is ever recycled. > > If your discussion is not limited to Linux kernels, then sure, but being > portable at that (sub-libc) level is asking too much. >
I will come to the main issue later but I just wanted to point out that we maintain information at two separate places - mapping between the name and the number in user space and kernel space. Shouldn't this duplication be removed. Now, let's say a vendor has linux_kernel_version_1 that has 300 system calls. The vendor needs to give some extra functionality to its customers and the way chosen is to implement new system call. The new system call number is 301. The customer gets this custom kernel and uses number 301. Next, he downloads another kernel (newer linux kernel version) on his system that has already implemented the system call numbered 301. The customer now runs his program. Even if he compiles it again he has the old header files, so that does not make a difference. Now his program uses number 301 that refers to some other system call and so, we can see system crash, or some very wrong behaviour. Making system calls more portable will ensure that atleast the program gets an indication that something is wrong (error returned from the kernel that this system call name is not matched). Or, if the vendor is actually successful in pushing its system call to the mainline kernel, no one needs to worry about it. Everything will run happily. However, people may say that, implementing custom system calls is not advocated by linux. And I think it is not advocated precisely because of this reason that they are not portable. Regards, Amit __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
