[question] How is lklfuse.o linked with liblkl.a?

[petrosagg]

While building this project I noticed the following weird result. When I run strings liblkl.a | grep lkl_sys | sort -u I get the following syscalls:

lkl_sys_access
lkl_syscall
lkl_sys_close
lkl_sys_getdents64
lkl_sys_halt
lkl_sys_mkdir
lkl_sys_mknod
lkl_sys_mount
lkl_sys_nanosleep
lkl_sys_open
lkl_sys_read
lkl_sys_rmdir
lkl_sys_umount
lkl_sys_unlink

However, lklfuce.c refers to a lot of extra lkl_sys_* functions. One example is lkl_sys_chown. I ran find -type f|xargs grep lkl_sys_chown on the whole linux tree that includes my built objects and the only references to this function were in lklfuse.c, lklfuse.o and lklfuse.

How is this linking happening? And why only this specific set of syscalls appears in the output of strings? I couldn't find anything unique about their definition either.

[tavip]

When we compile the kernel object (lkl.o) we make all symbols private (with objcopy -G) except the ones define in LKL_ENTRY_POINTS in arch/lkl/Makefile. This way we can avoid name collisions with applications and other libraries and we can keep the entry points into lkl controlled (we don't want to export any random function due to relatively high changes in the API and the fact that we need a proper context to run the kernel functions anyway).

All lkl_sys_ calls are then redirected to lkl_syscall via the static inline function definitions in arch/lkl/include/uapi/asm/unistd.h (see the LKL_SYSCALL*).

[petrosagg]

Oh, right. That makes sense now. I got confused because liblkl.a includes symbols like lkl_sys_open which from further investigation seem to come from fs.o which is also included in liblkl.a

Thanks for the explanation!

[petrosagg]

Does it make sense to make lkl_sys_* symbols from fs.c etc private as well so that the resulting library doesn't have these symbols exported? I could send a patch for this

[thehajime]

the fact that we need a proper context to run the kernel functions anyway).

if this is only the limitation of exposing random functions, then we may have to think about an alternate path to run in the proper context, though I have no idea at the moment.

I still think that this is an open question: whether what kind of interfaces lkl wants to expose.

if your objective is just avoiding symbol collisions between applications and kernel, there is alternate way to do that. below is the same way what rump kernel does:

libos-nuse/net-next-nuse@751adb6

it is okay to make symbols to be private by objcopy because nobody uses an internal function of Linux kernel right now. but if somebody wants to use such random functions from an application, then exposing those symbols may be helpful. whitebox testing with LKL may benefit such more exposed api, for instance.

[petrosagg]

I still think that this is an open question: whether what kind of interfaces lkl wants to expose.

While it's true that the internal kernel APIs change, that could be something for the application developer to consider when deciding whether or not to use them.

the fact that we need a proper context to run the kernel functions anyway).

Aren't there useful functions that need no context? One example that comes to mind is crypto functions or implementations of various data structures.

if your objective is just avoiding symbol collisions between applications and kernel, there is alternate way to do that. below is the same way what rump kernel does:

namespacing all the symbols and letting the application developer choose what to use sounds like a good idea to me

[tavip]

Aren't there useful functions that need no context? One example that comes to mind is crypto functions or implementations of various data structures.

There already are dedicated userspace libraries for crypto functions and data structures, so I am not sure what purpose would that serve.

For complex tasks such as filesystems manipulation and networking stack usage you need a proper context.

[tavip]

Does it make sense to make lkl_sys_* symbols from fs.c etc private as well so that the resulting library doesn't have these symbols exported? I could send a patch for this

There are no lkl_sys_ symbols exported from fs.c in liblkl.a. You should use nm not strings to see what symbols are exported.

[petrosagg]

There already are dedicated userspace libraries for crypto functions and data structures, so I am not sure what purpose would that serve.

Indeed, using a dedicated crypto userspace library would be the sensible thing to do. But is everything in the kernel available as a userspace library? And even if it is, I don't see how more libraries or more choice for the application developer in general is a bad thing.

For complex tasks such as filesystems manipulation and networking stack usage you need a proper context.

You're right and I don't have a solution for using these functions to manipulate a running kernel.

But those functions can be useful for other uses. I know I had this need some time ago. I had a corrupted bcache disk and I was trying to read bcahce data structures in my application code in order to repair them. But since there was no userspace library for that I was forced to do a lot of manual porting. One particular example was that the in-kernel implementation of crc64 for bcache wasn't the same with other usespace libraries available.

It would have been a great time saver if I could have used the exact same code used by bcache to parse the data structures in my program instead of re-implementing them on my own.

I would expect most filesystem repair utilities to have similar needs.

There are no lkl_sys_ symbols exported from fs.c in liblkl.a. You should use nm not strings to see what symbols are exported.

You're right, thanks for explaining.

Closing this issue as there was no follow up for some time and the underlying issue is tracked in #58.