| |||||||||||||
ABI backward-compatibility is the trick...ABI backward-compatibility is the trick...Posted Dec 1, 2010 7:32 UTC (Wed) by steven676 (subscriber, #41893)In reply to: ABI backward-compatibility is the trick... by madscientist Parent article: The kernel and the C library as a single project
> In fact the advantage of moving libc into the kernel is that we would NOT need to be so worried about the ABI between libc and the kernel since they were modified in sync.
Not unless you want to eliminate static linking and make upgrading your kernel a nightmare. (If the ABI the kernel exposes to libc isn't stable, then libc has to be updated with the kernel -- except that the kernel update isn't effective until reboot, while the libc update will be effective for newly launched programs immediately.)
Solaris has this problem, and "solves" it via a horrible hack called "deferred activation patching" -- basically bind mounting the old libraries over the new ones until reboot. (It's also why there's no static linking on Solaris >= 10.)
(Log in to post comments)
ABI backward-compatibility is the trick... Posted Dec 1, 2010 14:13 UTC (Wed) by madscientist (subscriber, #16861) [Link]
This is very true, and I don't actually believe that the kernel devs would use this as an excuse to give up on their current rules regarding userspace-visible changes. It would have all sorts of evil repercussions.
On the other hand, it's pretty darn hard to link many types of programs statically even today.
ABI backward-compatibility is the trick... Posted Dec 3, 2010 19:50 UTC (Fri) by Spudd86 (guest, #51683) [Link]
I don't think anyone was talking about letting the kernel break libc<->kernel ABI, the talk was about making new API available sooner and having new implementations of the (old) ABI in the libc sooner. Statically linked stuff would still use the old KERNEL ABI, and it would still work, but dynamically linked stuff would use then new libc which would use new kernel ABI, hopefully offering improved performance in the process.
Basically API/ABI-wise nothing changes (at least not intentionally), except the speed at which new parts become useable.
|
|||||||||||||