***reepca` is now known as reepca
***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<nikita`>janneke: what would porting MesCC to NetBSD require, what are the entry points and modifications for different architectures and kernels? I presume it's less than porting gcc to a new architecture? it's a long shot, but taking notes in advance for what I am doing with Guix as well as potentially something else basing on MesCC <janneke>nikita`: during the reproducible-build summit in marrakesh, we took a few humble steps toward porting mes to freebsd <janneke>so that could be a starting point, to look at those few commits <janneke>i am not really familiar with the BSDs, but i imagine that once you get a simple elf program running, most of the work is filling in the system calls <nikita`>ok, thanks. that's at least something, though FreeBSD is sometimes more linux-leaning in some internals <janneke>ah right, i can imagine that there is some work between the syscall level and the c library <nikita`>my GSoC is about NetBSD libc, so I think that will help once I have some orientation in libc^^ <janneke>i learned a lot from writing mes lib c <nikita`>though I would have rather found a new full-time job <janneke>i figure that having worked on libc's is a marketable skill? <nikita`>probably, and probably also conference paper <nikita`>is there anything below mes (stage0?) which needs added support afterwards, or how did you progress? I can't keep track of everyone's work and the projects around mes are moving fast <janneke>nikita`: yes, there is mescc-tools that needs to learn about netbsd too <janneke>what needs to be done thare is a fraction of what is needed for mes, and most can be re-used or copied <janneke>it was my intention to share mes c library with mescc-tools <janneke>however, mescc-tools uses it's own alphabet (not posix/libc) <janneke>the real difficult bits (the elf headers and connecting the system calls) are easily shared <OriansJ`>nikita`: actually if we move MesCC to leveraging slow-utils (which is mescc-tools written in scheme), the only thing that needs to be done to port MesCC to a new kernel is port its libc (which is mostly just fixing the syscalls). As slow-utils and MesCC will both run on a sufficiently powerful scheme implementation. <OriansJ`>stage0 work is only done if you wish to make that kernel another possible root of trust; then there are only a dozen files one would need to update <OriansJ`>but should you wish to learn the bare metal reality of running programs stage0 is a good place to learn how assemblers, linkers and compilers work at their core. <OriansJ`>kaem provides a brief look into how shells work