One library that I wanted to implement was an interface to Linux system calls. GNAT hides this functionality behind layers-upon-layers of abstractions, so you can't really get access to raw system calls. Additionally, all interfacing with the OS in GNAT is done via C, which is very unreliable foundation compared to Ada. My plan was to start small with the most basic syscalls: openat, close, mmap, and fstat. These should allow users to create files on file system, and read and write memory mapped files.
How is this different from what ave1 is doing? The scope of the library that I have in mind is a bit different. It is supposed to be used independent of runtime to provide functionality that happens to be missing from Ada standard and its GNAT extensions.
Unfortunately, I did not have enough time to polish it before publishing, so instead I will provide you some information on what work I will do in the future, and what I have done already.
What still needs to be done:
Why is it still not publishable, and why did such a trivial thing take so much time? I don't particularly like approach of adding an Machine_Code'Asm snippets into every system call wrapper function, so it took some time to make it generic1: I have functions that stuff each of the system call arguments into register-sized type2 in the correct way before passing them to the system call instruction. I have also ensured that these functions inline into single moves in the assembly. These experiments have eaten up most of my time, so I have no choice now but to make an empty genesis. I expect that further work, when I get back to it, will progress much faster.
curl 'http://bvt-trace.net/vpatches/syscalls_genesis.vpatch' > syscalls_genesis.vpatch curl 'http://bvt-trace.net/vpatches/syscalls_genesis.vpatch.bvt.sig' > syscalls_genesis.vpatch.bvt.sig curl 'http://wot.deedbot.org/6CF3EFF892A7F23E7E798E5EBA6B8C054B962B68.asc' > bvt.asc