Removing glibc librtkaio support in Fedora Rawhide.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,
  and providing a system change notification about the library removal for
  F24.
        
  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 we will add a symlink.

Cheers,
Carlos.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux