21–25 of 25 posts
So, compared to LibOS, it does not emulate timers etc., but provides host system timers, right? There is no way it will replace LibOS in NS-3 DCE [1] and LibOS will continue to be developed out-of-tree, or is it possible that LKL will be ported to NS-3 as an underlying platform just like it supports POSIX and Windows now? [1] https://www.nsnam.org/overview/projects/direct-code-executio...
1. is the entirety of kernel-networking now available to applications e.g. applications using tcp/udp/sctp/ipsec etc. etc. stacks completely in userland, just need to link with liblkl, and they are all set ?
2. also with dpdk etc. quite a large number of vendors are offering implementation of core networking protocols from l2 all the way up to l7. would this make all of those obsolete ?
Earlier quoted context omitted.
If you use it to write a FUSE filesystem, then yes, because it's using FUSE. If you link (-llkl) directly to your program, then no, since it's all in the same process. But this is not exposing the POSIX API or a host filesystem, so that's possibly not useful, depending on what you're trying to do. I compare lkl to libguestfs in my article here: https://rwmj.wordpress.com/2015/11/07/linux-kernel-library-b...
Ah okay, I think I understand more now. Thanks for the link, I'll check it out! Basically this is a kernel running in userspace, not hooking into the actual kernel running in kernel space?
couple of questions 1. is the entirety of kernel-networking now available to applications e.g. applications using tcp/udp/sctp/ipsec etc. etc. stacks completely in userland, just need to link with liblkl, and they are all set ? 2. also with dpdk etc. quite a large number of vendors are offering implementation of core networking protocols from l2 all the way up to l7. would this make all of those obsolete ?
but network stack is not all about open(2)/close(2): bunch of configuration tools are needed to do the job, which is what we want to have in a future.
2. yes and no.