Non-kernel “Platform” APIs (WIP)

Published on 2026-10-03.

Introduction

  • Unicode data
  • Locale data
  • Timezone data

Those three have in common that most libraries and applications will use them, either directly or indirectly.

Problem

Despite such data and queries built upon them being quite fundamental, there is no standard way of how these are distributed and accessed on Linux.

Most Linux distributions have packaged this data, but disturbingly little software actually makes use of these packages.

Instead, there is an uncontrolled mix of code …

  • linking to some dynamic library that provides this functionality,
  • making use of the (UI) framework’s facilities,
  • bundling resources with the library/application itself.

This results in lots of duplicated efforts, and a continuous need to ship maintenance releases that update these resources to avoid stale data.

Wishful thinking

Ideally, …

  • this data would be present on the system once and for everyone to use.

  • it would be as easy as making a syscall to access these resources, without making the caller worry where or how the resources are stored.

  • the data (and functions to query the data) would not be specific to a language, framework or ecosystem, nor create a dependency on any of those.

  • all APIs/ABIs would be specified in a language-independent machine-readable format that allows languages to make calls without implementing half a C compiler.

     ... applications / libraries here ...

+-----------------------------------------------+
|            Idealized Platform API             |
|                                               |
|  io      net      text      locale      time  |
+-----------------------------------------------+
   |        |        |          |          |
   v        v        v          v          v
  +----------+     +---+      +---+      +---+
  | syscalls |     | ? |      | ? |      | ? |
  +----------+     +---+      +---+      +---+
   |        |        |          |          |
   v        v        v          v          v
 +------------+  +-------+  +-------+  +-------+
 |            |  |unicode|  |unicode|  | iana  |
 | Kernel API |  | -data |  | -cldr |  | -tzdb |
 |            |  +-------+  +-------+  +-------+
 +------------+

Technical considerations

  • Extending the vDSO with functions that query unicode/locale/timezone data?
  • Extending the VVAR page (or adding a new VVAR-like page) to map unicode/locale/timezone data into a processes’ own memory?
  • Versioning of the data? How to provide more than one version of the data?