libk  Diff

Differences From Artifact [65938a7892]:

• File libk.md — part of check-in [e794c5edef] at 2019-06-29 09:31:50 on branch trunk — add a bunch of code, port the header mechanism to gpp; add a fuckton of definitions and compatibility header code; notably, add core function kstop and x86.lin.{32,64} impl. update docs accordingly (user: lexi, size: 17654) [annotate] [blame] [check-ins using]

To Artifact [05d8d251c9]:

• File libk.md — part of check-in [85a8c60bd2] at 2019-07-26 21:56:33 on branch trunk — add kmath module stub (user: lexi, size: 18352) [annotate] [blame] [check-ins using]

     8      8   
     9      9   it's also a piece of shit.
    10     10   
    11     11   libc is ancient, and it shows. it contains decades worth of cruft, masses of different interfaces with completely different design, horrible hacks to get around the fundamental shifts in basic computer architecture that have occurred over the past half-century, and vendor-specific extensions that make porting code a nightmare. using it is painful, tedious, error-prone, and unsafe. for various reasons, there are many different implementations of libc, but all of them have that same broken, bloated interface in common. as far as i can tell, there are been no serious attempts to create an actual *alternative* to libc - a new system interface that takes into account the decades of painful lessons we programmers have learned since the heydays of UNIX.
    12     12   
    13     13   hence, libk.
    14     14   
    15         -libk aims to offer a better, safer, and most importantly, less unpleasant foundation for modern code in C or any other language.
           15  +libk aims to offer a better, safer, and most importantly, less unpleasant foundation for modern code in C or any other language. it also aims to be much smaller, simpler, and faster than glibc to build so that there's no arduous bootstrapping process for new architectures.
           16  +
           17  +currently, the only dependency on libc in any form is `arch/typesize.c`, a small binary tool which uses libc IO routines to print type information it calculates; however, this could also be augmented to use POISX IO routines, or even potentially libk IO routines to remove any external dependency at all -- the work would be nontrivial, but fully feasible. further, the file it creates can also _in extremis_ be created by hand. the final compiled libc binaries and headers do not depend on or reference libc in any way; typesize is only a makedepend.
    16     18   
    17     19   ## goals
    18     20   
    19     21   libk's goals are far-reaching, and suggestions are welcome. note however that libk is *not* intended to be a kitchen-sink library like libiberty. it's meant to do one thing, and to it well: to provide an easy- and pleasant-to-use foundation for modern open source projects. below is a list of some of the project's major goals.
    20     22   
    21     23    1. **IO.** libc's basic input/output mechanisms are dreadful, built at entirely the wrong level of abstraction. libk is intended to make many more primitives available to the user, and offer a sliding scale of abstraction so libk is suitable for a wide range of needs.
    22     24    2. **file manipulation.** libc's file manipulation primitives are a relic of a bygone age and in dire need of upgrading.