This reverts commit 3363179385629c1804ea846f4e72608c2201a81e.
This change is too restrictive. I've been running UML statically linked kernel
with UML_NET_VECTOR networking in a docker "FROM: scratch" container just fine.
As long as we don't reference network peers by hostname and use only IP
addresses, NSS is not needed, so not used. In other words, it is possible to
have statically linked UML and UML_NET_VECTOR (and other networking types) and
use it, although with some restrictions, so let's not disable it.
Additionally, it should be at least theoretically possible to use another libc
(like musl, bionic etc) for static linking. I was able with some hacks to
compile UML against musl, although the executable segfaults for now. But this
option prevents even the research to be done.
Signed-off-by: Ignat Korchagin <[email protected]>
---
arch/um/Kconfig | 8 +-------
arch/um/drivers/Kconfig | 3 ---
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index 96ab7026b037..817a4c838a06 100644
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -62,12 +62,9 @@ config NR_CPUS
source "arch/$(HEADER_ARCH)/um/Kconfig"
-config FORBID_STATIC_LINK
- bool
-
config STATIC_LINK
bool "Force a static link"
- depends on !FORBID_STATIC_LINK
+ default n
help
This option gives you the ability to force a static link of UML.
Normally, UML is linked as a shared binary. This is inconvenient for
@@ -76,9 +73,6 @@ config STATIC_LINK
Additionally, this option enables using higher memory spaces (up to
2.75G) for UML.
- NOTE: This option is incompatible with some networking features which
- depend on features that require being dynamically loaded (like NSS).
-
config LD_SCRIPT_STATIC
bool
default y
diff --git a/arch/um/drivers/Kconfig b/arch/um/drivers/Kconfig
index 9160ead56e33..72d417055782 100644
--- a/arch/um/drivers/Kconfig
+++ b/arch/um/drivers/Kconfig
@@ -234,7 +234,6 @@ config UML_NET_DAEMON
config UML_NET_VECTOR
bool "Vector I/O high performance network devices"
depends on UML_NET
- select FORBID_STATIC_LINK
help
This User-Mode Linux network driver uses multi-message send
and receive functions. The host running the UML guest must have
@@ -246,7 +245,6 @@ config UML_NET_VECTOR
config UML_NET_VDE
bool "VDE transport (obsolete)"
depends on UML_NET
- select FORBID_STATIC_LINK
help
This User-Mode Linux network transport allows one or more running
UMLs on a single host to communicate with each other and also
@@ -294,7 +292,6 @@ config UML_NET_MCAST
config UML_NET_PCAP
bool "pcap transport (obsolete)"
depends on UML_NET
- select FORBID_STATIC_LINK
help
The pcap transport makes a pcap packet stream on the host look
like an ethernet device inside UML. This is useful for making
--
2.20.1
On Wed, Jun 24, 2020 at 2:23 PM Ignat Korchagin <[email protected]> wrote:
>
> This reverts commit 3363179385629c1804ea846f4e72608c2201a81e.
>
> This change is too restrictive. I've been running UML statically linked kernel
> with UML_NET_VECTOR networking in a docker "FROM: scratch" container just fine.
> As long as we don't reference network peers by hostname and use only IP
> addresses, NSS is not needed, so not used. In other words, it is possible to
> have statically linked UML and UML_NET_VECTOR (and other networking types) and
> use it, although with some restrictions, so let's not disable it.
>
> Additionally, it should be at least theoretically possible to use another libc
> (like musl, bionic etc) for static linking. I was able with some hacks to
> compile UML against musl, although the executable segfaults for now. But this
> option prevents even the research to be done.
The reason that we removed support for static linking when these
networking options are enabled is because gcc doesn't support loading
NSS when statically linked, which consequently breaks allyesconfig for
UML under gcc. That is still the case with your revert.
I fully support the goal behind what you are trying to do. However, I
do not want to see this patch accepted unless it is accompanied by an
alternative change that still allows UML to compile under
allyesconfig.
You said that in the current state, researching a solution is
possible? Can you not research a solution with your patch applied to
your own branch?
Cheers
On Tue, Jun 30, 2020 at 11:47 PM Brendan Higgins
<[email protected]> wrote:
>
> On Wed, Jun 24, 2020 at 2:23 PM Ignat Korchagin <[email protected]> wrote:
> >
> > This reverts commit 3363179385629c1804ea846f4e72608c2201a81e.
> >
> > This change is too restrictive. I've been running UML statically linked kernel
> > with UML_NET_VECTOR networking in a docker "FROM: scratch" container just fine.
> > As long as we don't reference network peers by hostname and use only IP
> > addresses, NSS is not needed, so not used. In other words, it is possible to
> > have statically linked UML and UML_NET_VECTOR (and other networking types) and
> > use it, although with some restrictions, so let's not disable it.
> >
> > Additionally, it should be at least theoretically possible to use another libc
> > (like musl, bionic etc) for static linking. I was able with some hacks to
> > compile UML against musl, although the executable segfaults for now. But this
> > option prevents even the research to be done.
>
> The reason that we removed support for static linking when these
> networking options are enabled is because gcc doesn't support loading
> NSS when statically linked, which consequently breaks allyesconfig for
> UML under gcc. That is still the case with your revert.
Yes, sure. But I'm not only "researching", but using UML as a "router"
in one of my dev setups. 3363179385629c1804ea846f4e72608c2201a81e
mentions UML_NET_VECTOR incompatibility (and some other networking
options), which I had enabled and actually my whole dev networking is
based around UML_NET_VECTOR: I have two interfaces - one in raw mode
and one doing ipsec. All this was running in an empty "FROM: scratch"
container and obviously linked statically.
If the static linking breaks some other config options in allyesconfig
- that's another story, but I wanted to point out that config options
mentioned in the commit message worked just fine (if not trying to
resolve hostnames). In other words: if you don't resolve - glibc will
not try to load NSS. glibc-nss is a known problem and I would assume
most people trying to do static linking are aware of this - that is,
if they choose this path they are willing to live with the
consequences. That's why completely disabling the possibility sounds
too restrictive for me.
> I fully support the goal behind what you are trying to do. However, I
> do not want to see this patch accepted unless it is accompanied by an
> alternative change that still allows UML to compile under
> allyesconfig.
If I succeed linking it to musl (or other non-glibc lib), would that be enough?
> You said that in the current state, researching a solution is
> possible? Can you not research a solution with your patch applied to
> your own branch?
As a side note: I tried to revert this patch and statically link 5.7
UML with glibc, but the binary still segfaults on start, so I would
assume it is not related to my previous attempts linking with musl.
Regards,
Ignat
>
> Cheers