All examples require a network interface

[mkroening]

This was introduced by @skuenzer in https://github.com/unikraft/catalog/commit/4364d5058cf032094dcbcf9db9ecb215fcec3c3c.

This makes examples such as helloworld-c not run with the command from their README.md:

kraft run --rm --plat qemu --arch x86_64 .

As a workaround, one can publish a nonsensical port to the host:

kraft run --rm --plat qemu --arch x86_64 -p 8080:8080 .

@razvand, what should we do about this? Change all README.mds?

[nderjung]

I agree that the work around with publishing a non-sensical port is, well, nonsensical! :D

It's not clear what the best workaround is right now technically. I'd like to hear input from @skuenzer about whether a fix could be provided from the core and/or altering the KConfig options set such that this mitigation is not necessary.

However, if not I'd like to offer to the discussion that having alternative builds of kernels with the same canonical name but different properties is also possible with tooling via KraftKit. We'd aim to provide some of this transparently such that when users supply certain flags, i.e. -p|--port and -n|--network that we can then select images which have relevant networking subsystems enabled (i.e. CONFIG_LIBUKNETDEV=y).

This is already partially possible (when multiple images of the same canonical name exist) through kraft pkg pull --kconfig CONFIG_LIBUKNETDEV=y. Work would need to be done such that we can provide this feature selecting to kraft run and to transparently set it when -p|--port and -n|--network is set.

[skuenzer]

Seeing it from the core, the option CONFIG_LWIP_FAILNOIFACE makes sense to enable only for applications that rely on networking. Where networking is optional, this KConfig option should be set to n and where no networking is needed, we ideally want to build a Unikernel without networking capabilities and drivers. But because we are speaking here about a generic elfloader image, we are weakening the specialization degree because we need to think a bit more "general purpose".

As (weak) defense: It seems that I did not had on track that we also run non-networking apps with the base image: This is the source of all evil 😄. The option originated for some apps that weren't able to come up properly if networking configuration wasn't finished (e.g., due to DHCP still in progress). However, given we speak about the base image, the option CONFIG_LWIP_WAITIFACE=y should cover everything we need. It will keep the system booting if there is no network device and keeps waiting for DHCP if there are interfaces configured for DHCP.

In fact, we should only set CONFIG_LWIP_FAILNOIFACE=y for applications in the catalog that really rely on network being there.