On Thu, Apr 03, 2008 at 12:19:32PM +0300, Shachar Shemesh wrote: >> My point is that the kernel (or glibc, or any other major piece of >> system software) usually has subtle dependencies on other pieces of >> system software.
> My point is that "user space backwards compatibility" is meaningless > if there is no, well, user space backwards compatibility. Relying on > the insides of file systems in motion (such as sysfs was at the > early versions of 2.6) is sort of acceptable, but I really would > have preferred it if Documentation/filesystems/proc.txt would say > something along the lines of "the interface is guaranteed to have > the field name, a bunch of white spaces, a number and a unit (which > can be kB, mB or gB only)". In other words, if the docs gave all I > needed to write a user space program that, if didn't actually work > under all conditions, at least could tell when it doesn't have > enough info to work, for all future versions. Otherwise, it seems to > me, that the "stable userspace" pledge is just a facade. You are mixing two different things. The system call interface is stable and syscalls are never removed, only added. A 10-year-old binary should - in theory - run on 2.6.25-rc8. The kernel, however, employs a number of userspace helpers such as mount(8). The interface between those helpers and the kernel (e.g., format of /proc files) does change occasionally. The kernel developers however do understand that just because an interface exists for the use of a limited subset of helpers does *not* mean nothing else will use it (i.e., something else will use it), and take extra care to only change the interface when absolutely necessary. Cheers, Muli ================================================================= 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]
