On Apr 28, 2006, at 11:37:03, David Woodhouse wrote:
On Fri, 2006-04-28 at 17:32 +0200, Jan Engelhardt wrote:
Sounds like they want it BSD-style. Do they realize that? New
release, new headers, making it necessary to recompile every app,
because a struct could have changed. That'd seriously impact
compatibility.
Utter crap.
We don't _change_ any of the structs which would be exposed in such
files (i.e. the structs which should be outside the #ifdef
__KERNEL__ at the moment, because that would mean we break
userspace binary compatibility from kernel to kernel.
We absolutely do _NOT_ want to go there. We're talking about
cleaning up the existing mess, not starting a crack habit.
Example: Say the proposed utsname virtualization gets a new clone
flag (CLONE_NEWUTSNAME). Old headers would obviously not include the
CLONE_NEWUTSNAME define. If you want to compile a glibc that uses
CLONE_NEWUTSNAME, you need to build it against a set of the "kabi
headers" from a version of the kernel that includes the feature. The
resulting glibc will _run_ on any kernel; if you call clone
(CLONE_NEWUTSNAME) on an older kernel it would return EINVAL but work
otherwise. A glibc that does *not* use CLONE_NEWUTSNAME would build
an identical binary with older versions and newer versions. This is
_exactly_ the way things work now, except there is no outside llh
project, it's all stored in the kernel tree.
Cheers,
Kyle Moffett
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
