On Fri, Sep 11, 2015 at 9:21 AM, Carlos O'Donell <carlos@xxxxxxxxxx> wrote: > On 09/10/2015 03:42 PM, Adam Miller wrote: >>> It doesn't matter how rare they are, it'll only take a single bundled >>> library handled incorrectly to completely screw a running OS. I don't >>> think this is something that can just be swept under the carpet, it >>> needs to be addressed as a core part of the proposal and currently is >>> not. >>> >> >> I was talking to someone at Red Hat Summit from the GCC/glibc team and >> I was under the impression they (upstream) are working on something >> that handles the symbol tables to allow parallel installed versions of >> libs. No idea how far this is along but it's something that people are >> working towards. > > You spoke to me, and I am responding here to clarify exactly what the > Fedora glibc team trying to do. +1 - Thanks! I remember that we spoke but I didn't want to throw you into the flamewar without warning, but thanks for chiming in! :) (Also, I got one of those ceramic burr grinders and it's awesome. :) ) > > The work being done is to enable an alternate linkage model for Ring-0, > where the implementation and interface of ELF-based shared libraries is > split in two. Linking is carried out against a curated Ring-0 SDK > and ensures if we upgrade say, glibc, and have accidentally added a > new symbol, that no new package can use said symbol until the Ring-0 SDK > package is updated to also have that symbol. Updating the Ring-0 SDK > requires careful review and would likely be frozen after GA. The Ring-0 > SDK contains headers, stub libraries, and more. > > While this idea of an SDK could be extended to all ELF-based shared > libraries in the distribution, it gets much harder outside of Ring-0 > and is more work with less benefit. Keep in mind the goal here is to > provide automation and tooling to measure and control the most important > core part of the OS, that layer upon which the other layers rely. > > The idea itself could allow you to install a brand new glibc on your > system without impacting any builds you do with rpmbuild, mockbuild, > etc. You are isolated from the implementation by the new linkage > model (using curated sysroots). Thus with the brand new glibc, and > because glibs offers backwards compatibility, you could run newer ISV > applications that require newer glibc, without needing a VM. This > ignores several problems like bug-for-bug compatibility, subtle changes > that alter undefined behaviour or unspecified behaviour, and eventually > result in the failure of an application to run against a new glibc. > > However, with the new linkage model it is possible to use it to upgrade, > not not run multiple versions, of shared libraries. > > If you need different versions of shared libraries then you need to use > software collections for those libraries (load isolation via the dynamic > loader), containers (load isolation via namespaces), VMs (load isolation > at the kernel level). > > If you need different versions of the same shared libraries in the same > process then you must use dlmopen for symbol namespace isolation. Note > that at present dlmopen is not functional for this purpose in upstream > glibc master. Ah ok, I either misunderstood or mis-remembered. Thank you for the clarification. -AdamM > > Cheers, > Carlos. > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
