On Sat, 2021-02-06 at 22:28 +0100, Ludovic Courtès wrote: > Maxime Devos skribis: > > I just remembered this subtlety: during bootup, the activation code is > evaluated by the Guile that’s in the initrd, which is a > statically-linked Guile, and thus we can’t use ‘dynamic-link’ & co. in > there. :-/ I remember trying to use make-forkexec-constructor/container from activation code, which didn't work, due to some uses of dynamic-func ... I see two possible options to take: * extend gnu/packages/patches/guile-linux-syscalls.patch with, say, a "%extra-function-pointers" procedure returning a vector (or alist, or something else) of pointers to the relevant C functions. This allows us to write the FFI code mostly in Scheme, and only write C code for obtaining function pointer. * extend gnu/packages/patches/guile-linux-syscalls.patch with additional bindings, or write a patch extending guile itself with fchownat and other *at support. This (second) patch should be submitted upstream, but can be kept in gnu/packages/patches until support for *at functionality makes it upstream. The first option is the path I would find the most convenient myself (though I'll probably write C code for parsing struct stat, as its layout apparently varies much with kernel (Linux / Hurd) and architecture), but the latter seems the way to go to prevent duplicate effort upstream later on. My C is a little rusty, but I'll have a try at the latter. Maxime.