Messages in this thread | | | Subject | Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ | From | Alexandre Oliva <> | Date | 30 Nov 2004 21:05:39 -0200 |
| |
On Nov 30, 2004, Linus Torvalds <torvalds@osdl.org> wrote:
> Wrong. They'll _still_ have to maintain duplicates, since they can't rely > ont he end-user to have a recent enough kernel.
No. They just won't have the headers for the newer kernel installed on their system. They stick with the kernel ABI headers provided by a baseline kernel, and that's probably from an older kernel tarball.
> It's just that they can hopefully start _copying_ their dupliates more > easily.
It's still the headers from the kernel, copied or not. From a different, baseline version, maybe.
> At RH you may see only the case where people do a whole-system upgrade.
I personally don't care about the case you perceive as the Red Hat case, because I work on embedded systems development, in a different organization within Red Hat than the people who develop Red Hat Enterprise Linux and Fedora. So yes, in the case that actually benefits me, it's even more of a whole-system thing, since for our group it's *the* kernel, not *a* random kernel version. It's the kernel we port and ship to the customer, and the corresponding kernel<->userland ABI.
That said, I do understand the issues of kernel baseline ABI settings, or at least part of them. I know you don't want to assume the presence of a certain system call just because you're running a kernel that implements it. In fact, I know you don't want to assume the presence of a system call just because it's defined in linux/unistd.h. As long as the userland software keeps this distinction in mind, I don't see why taking the latest kernel<->userland ABI headers, that describe the newest system calls and any corresponding data structures, could hurt anything. In fact, if you don't have the corresponding system call numbers and data structures, you can't possibly take advantage of the new syscalls even if they happen to be available, unless you duplicate the syscall numbers and data structure definitions in your own code, which, from a software engineering standpoint, is bad.
Of course, badly written software can assume the syscalls are present just because their numbers are given, and then people who rely on such bad software lose, but such is the nature of bad software.
-- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |