David Woodhouse wrote: > On Mon, 2008-06-16 at 11:49 +0100, Jamie Lokier wrote: > > But here's the thing: do you really want every package have code > > calling every different variation on a system call, at run time, until > > it finds one that works? > > No. That functionality lives in libc, if you want it at all. Sometimes that's ok. But sometimes libc can't do that, because the point of a newer function is it addresses some inadequacy of an old function. If libc does a "compatibility" thing and uses old syscalls on old kernels, sometimes that introduces bugs. E.g. Calls to pread should _not_ be implemented as lseek+read+lseek on old kernels which don't have pread. That leads to race conditions and corruption in some applications. (I think this has really occurred, but I'm unable to find it now). The same applications are fine if pread returns ENOSYS and they know what they need to do with lseek and read. The same is true of the rsync example, with utimes and utime. It's wrong for libc to "emulate" utimes using utime on old kernels: they aren't the same. So the application does it instead: the application has a policy that it's fine with the different functionality when utimes returns ENOSYS. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
