lkl: Implement lkl_printf and lkl_bug internally

[lrh2000]

(Follow up #587 to remove undefined symbols in lkl.o)

Currently, lkl.o needs the lkl_printf and lkl_bug symbols to work but does not implement the corresponding functions. These helper functions are implemented as part of liblkl in tools/lkl/lib/util.c.

This works, but it requires users of lkl.o to implement lkl_printf manually. However, this does not make much sense, because lkl_printf, by definition, is just a wrapper to host_ops->print.

In fact, lkl_printf can be implemented correctly using the utilities from linux/stdarg.h and linux/sprintf.h, as well as the host operations host_ops->mem_alloc and host_ops->print. See changes in this commit for more details.

Implementing it internally in arch/lkl makes lkl.o more self-contained and easier to use in environments without libc support (since in such environments tool/lkl/lib/util.c may fail to compile due to missing headers like stdio.h and stdarg.h).

[thehajime]

thanks for the patch.

I was wondering if kernel code (i.e., code under arch/lkl) can use printk/panic (or family) instead of lkl_printf/lkl_bug so that we don't have undefined symbols.

[lrh2000]

I was wondering if kernel code (i.e., code under arch/lkl) can use printk/panic (or family) instead of lkl_printf/lkl_bug so that we don't have undefined symbols.

Thanks for your review. I guess sometimes we need to use lkl_printf because we're not in the Linux context (either before lkl_get_cpu or after lkl_put_cpu). I checked the original commit that added lkl_printf/lkl_bug, which states:

lkl: add lkl_printf and lkl_bug

This allows to issue messages and do a controlled crash when we don't run in Linux context.

Or we may be in some state that appears to be corrupted and we don't know if we're in the Linux context:

linux/arch/lkl/kernel/cpu.c

Lines 117 to 119 in b5fa7a2

	if (!cpu.count || !cpu.owner ||
	!lkl_ops->thread_equal(cpu.owner, lkl_ops->thread_self()))
	lkl_bug("%s: unbalanced put\n", __func__);

lkl_bug should be more reliable to use in such scenarios compared to Linux's panic().

[ddiss]

Looks good to me. I'm a little confused by the zpoline test failure, which should(?) have been fixed via b788994

[lrh2000]

I'm a little confused by the zpoline test failure, which should(?) have been fixed via b788994

This commit does not appear to fix the bug, as the issue is still open: #577 (comment)

[tavip]

LGTM, thanks for the patch @lrh2000 !

And you are correct, the purpose of these functions is for cases where we can't use panic or printk because we don't run in Linux context.

[tavip]

Implementing it internally in arch/lkl makes lkl.o more self-contained and easier to use in environments without libc support (since in such environments tool/lkl/lib/util.c may fail to compile due to missing headers like stdio.h and stdarg.h).

Just curios, if you can, could you share more details about the environment? Does it make sense to add support for it in tools/lkl?

[lrh2000]

Just curios, if you can, could you share more details about the environment? Does it make sense to add support for it in tools/lkl?

Thanks for your interest. For the first question, we are trying to play lkl.o with another kernel we're developing (if you're interested, see asterinas/asterinas).

However, the integration with lkl.o is still at a very early stage, and the way LKL interacts with our kernel is still being studied. I have found unexpected undefined symbols in the process, so I am submitting patches to fix the undefined symbols, which will definitely make the integration easier.

Since the way LKL interacts with our kernel is still being determined, I'm afraid I don't have an answer to your second question at this time.

[thehajime]

Thanks for your review. I guess sometimes we need to use lkl_printf because we're not in the Linux context (either before lkl_get_cpu or after lkl_put_cpu). I checked the original commit that added lkl_printf/lkl_bug, which states:

thanks for the info; I wasn't aware of that intention, which is helpful for me.

and thanks for the background information for those PRs. I looked through the asterinas project and also skimmed the paper (apsys) of framekernel. Yes, offering Linux ABI via LKL would be the best if various requirements of yours satisfy.

I have personally ported host_ops for rump hypercall (https://github.com/ukontainer/lkl-linux/blob/rump-hypcall-next/tools/lkl/lib/rump-host.c), which doesn't have libc-like utilities either, as your environment. @tavip and his team had also a port for Windows kernel host_ops, which has similar situation as nolibc environment (I guess).

Having less dependency to lkl.o, as you did, is definitely helpful. If you wish to have more interaction to LKL kernel from your environment, creating a host_ops for your case would be also helpful to cleanly integrate with.

[lrh2000]

@thehajime Thank you for your kind reply and the references you provided.

creating a host_ops for your case would be also helpful to cleanly integrate with.

Yes, that's exactly what I'm trying to do. It seems very promising indeed.