= Proposed System Wide Change: Removal of librtkaio from glibc = https://fedoraproject.org/wiki/Changes/GLIBC223_librtkaio_removal Change owner(s): * Carlos O'Donell <carlos AT redhat DOT com> Remove librtkaio support from glibc in Fedora 24. == Detailed Description == On July 2003 the rtkaio add-on was added to Fedora in glibc 2.3.2-64. The rtkaio add-on provided a POSIX realtime API interface that used linux kernel Asynchronous IO support (KAIO) to provide high performance AIO for a small subset of files (those using O_DIRECT, and not all file types). Typically the use case was databases or high-speed transactional systems that needed fast AIO. The libraries were installed under /lib64/rtkaio/ e.g. /lib64/rtkaio/librt.so.1 (symlink to /lib64/rtkaio/librtkaio-X.Y.so with SONAME librt.so.1) and could be used by preloading (LD_PRELOAD), dynamic linker lookup path changes (LD_LIBRARY_PATH) or by directly opening the shared library (dlopen). This accelerated access to file was used by customers like Sybase during the development of their database Sybase ASE (now owned by SAP). It has been 12 years since rtkaio was released, and while it has seen some uptake, the only known usage example is Sybase ASE. Sybase now exclusively uses the Linux Kernel Asynchronous I/O Library (libaio) for over 10 years ago and no longer use rtkaio. The libaio project provides a unique API that is tailored to doing very fast AIO. An analysis of Fedora shows no packages using rtkaio. Lastly the rtkaio add-on was never contributed upstream, likely because it never provided full POSIX conformance and worked only with a small subset of the required POSIX realtime features, those supported by KAIO. It is the conclusion of the Fedora glibc team that the maintenance burden of rtkaio is no longer warranted. The glibc team suggest rtkaio be deprecated and removed. Application developers should use libaio if they want high performance KAIO, or use librt if they want portable and flexible AIO. What are the consequences of removing rtkaio? * Application developers using rtkaio will see a performance decrease if they were previously using KAIO on O_DIRECT opened files, but should otherwise see no semantic changes in their applications. * Application developers using LD_PRELOAD will see a warning that the preloaded library is missing, but the application will load the normal librt and continue to operate correctly. * Application developers using LD_LIBRARY_PATH will see no warning, and the application will load the normal librt and continue to operate correctly. * Application developers using dlopen will see a failure from dlopen since the library is missing. This is mitigated by shipping a symlink from the rtkaio library to librt in the official Fedora release. The rtkaio library and the librt library are ABI and API compatible, and therefore interchangeable. As long as we provide one of them we will meet our application compatibility requirements. We will continue to provide the POSIX realtime library (librt) forever. The following plan of action is suggested: * Immediately remove rtkaio from Fedora Rawhide, deprecating the library. See https://bugzilla.redhat.com/show_bug.cgi?id=1227855 No compatibility symlinks are provided for Rawhide. We want to use Rawhide to detect if any applications are actually using rtkaio. Before the F24 branch a compatibility symlink will be added and left in place for a full release after which it will be removed. == Scope == Proposal owners: * Update glibc and remove librtkaio. Other developers: * Aside from Carlos O'Donell <carlos AT redhat DOT com>, Siddhesh Poyarekar <siddhesh AT redhat DOT com>, Torvald Riegel <triegel AT redhat DOT com>, Martin Sebor <msebor AT redhat DOT com>, and Patsy Franklin <pfrankli AT redhat DOT com>, no other developers are required. These developers need to ensure that rawhide is stable and ready for the Fedora 24 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when librtkaio is removed. Release engineering: In general coordination with release engineering is not required. A mass rebuild is not required. Policies and guidelines: The policies and guidelines do not need to be updated. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
