All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Ivanov <anton.ivanov@cambridgegreys.com>
To: Brendan Higgins <brendanhiggins@google.com>,
	jdike@addtoit.com, richard@nod.at
Cc: davidgow@google.com, linux-um@lists.infradead.org,
	linux-kernel@vger.kernel.org, johannes.berg@intel.com
Subject: Re: [RFC v1 0/2] um: drop broken features to fix allyesconfig
Date: Fri, 6 Dec 2019 07:45:03 +0000	[thread overview]
Message-ID: <dd086a74-402c-5b9a-5a12-15a791f8749f@cambridgegreys.com> (raw)
In-Reply-To: <20191206020153.228283-1-brendanhiggins@google.com>

On 06/12/2019 02:01, Brendan Higgins wrote:
> # TL;DR
> 
> This patchset drops two broken features in an attempt to get
> allyesconfig closer to working for ARCH=um.
> 
> # What am I trying to do?
> 
> This patchset is part of my attempt to get `make ARCH=um allyesconfig`
> to produce a config that will build *and* boot to init, so that I can
> use it as a mechanism to run tests[1].
> 
> # How far away are we from an allyesconfig UML kernel?
> 
> I have identified 33 Kconfigs that are selected by allyesconfig, but
> will either not build on UML, or prevent it from booting. They are:
> 
> CONFIG_STATIC_LINK=y
> CONFIG_UML_NET_PCAP=y
> CONFIG_NET_PTP_CLASSIFY=y
> CONFIG_IP_VS=y
> CONFIG_BRIDGE_EBT_BROUTE=y
> CONFIG_BRIDGE_EBT_T_FILTER=y
> CONFIG_BRIDGE_EBT_T_NAT=y
> CONFIG_MTD_NAND_CADENCE=y
> CONFIG_MTD_NAND_NANDSIM=y
> CONFIG_BLK_DEV_NULL_BLK=y
> CONFIG_BLK_DEV_RAM=y
> CONFIG_SCSI_DEBUG=y
> CONFIG_NET_VENDOR_XILINX=y
> CONFIG_NULL_TTY=y
> CONFIG_PTP_1588_CLOCK=y
> CONFIG_PINCTRL_EQUILIBRIUM=y
> CONFIG_DMABUF_SELFTESTS=y
> CONFIG_COMEDI=y
> CONFIG_XIL_AXIS_FIFO=y
> CONFIG_EXFAT_FS=y
> CONFIG_STM_DUMMY=y
> CONFIG_FSI_MASTER_ASPEED=y
> CONFIG_JFS_FS=y
> CONFIG_UBIFS_FS=y
> CONFIG_CRAMFS=y
> CONFIG_CRYPTO_DEV_SAFEXCEL=y
> CONFIG_CRYPTO_DEV_AMLOGIC_GXL=y
> CONFIG_KCOV=y
> CONFIG_LKDTM=y
> CONFIG_REED_SOLOMON_TEST=y
> CONFIG_TEST_RHASHTABLE=y
> CONFIG_TEST_MEMINIT=y
> CONFIG_NETWORK_PHY_TIMESTAMPING=y
> 
> This patchset attempts to deal with CONFIG_STATIC_LINK=y and
> CONFIG_UML_NET_PCAP=y by just removing them since they are broken and
> appear to have been broken for some time. (I am aware of the taboo of
> dropping configs, but given the amount of time they have been broken, I
> figured that I might be able to get away with it in this case, which is
> easier than trying to actually fix them.)
> 
> I also have a patch out to fix CONFIG_EXFAT_FS=y[2].
> 
> After this I plan on going after
> 
> CONFIG_PINCTRL_EQUILIBRIUM=y
> CONFIG_MTD_NAND_CADENCE=y
> CONFIG_FSI_MASTER_ASPEED=y
> CONFIG_CRYPTO_DEV_SAFEXCEL=y
> CONFIG_XIL_AXIS_FIFO=y
> CONFIG_CRYPTO_DEV_AMLOGIC_GXL=y
> CONFIG_XILINX_AXI_EMAC=y
> 
> the problem with these is that they depend on
> devm_platform_ioremap_resource without explicitly depending on
> CONFIG_HAS_IOMEM=y.
> 
> Also note that I don't think that CONFIG_NULL_TTY=y is actually broken
> on UML; however, console seems to get assigned to the null TTY by
> default when it is enabled, so I added it to the list for the sake of
> completeness.
> 
> The other broken configs require more investigation (I would welcome
> help, if anyone is interested ;-) ).
> 
> # Why won't allyesconfig break again after this series of fixes?
> 
> As I mentioned above, I am using UML for testing the kernel, and I am
> currently working on getting my tests to run on KernelCI. As part of our
> testing procedure for KernelCI, we are planning on building a UML kernel
> using allyesconfig and running our tests on it. Thus, we will find out
> very quickly once someone breaks allyesconfig again once we get this all
> working.
> 
> Brendan Higgins (2):
>    um: drivers: remove support for UML_NET_PCAP
>    uml: remove support for CONFIG_STATIC_LINK
> 
>   arch/um/Kconfig              |  23 +----
>   arch/um/Makefile             |   3 +-
>   arch/um/drivers/Kconfig      |  16 ----
>   arch/um/drivers/Makefile     |  17 +---
>   arch/um/drivers/pcap_kern.c  | 113 ----------------------
>   arch/um/drivers/pcap_user.c  | 137 ---------------------------
>   arch/um/drivers/pcap_user.h  |  21 -----
>   arch/um/kernel/dyn.lds.S     | 170 ----------------------------------
>   arch/um/kernel/uml.lds.S     | 115 -----------------------
>   arch/um/kernel/vmlinux.lds.S | 175 ++++++++++++++++++++++++++++++++++-
>   10 files changed, 174 insertions(+), 616 deletions(-)
>   delete mode 100644 arch/um/drivers/pcap_kern.c
>   delete mode 100644 arch/um/drivers/pcap_user.c
>   delete mode 100644 arch/um/drivers/pcap_user.h
>   delete mode 100644 arch/um/kernel/dyn.lds.S
>   delete mode 100644 arch/um/kernel/uml.lds.S
> 
> Looking forward to hearing people's thoughts!
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=205223
> [2] https://patchwork.kernel.org/patch/11273771/
> 

Patch for pcap: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938962#79


-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

WARNING: multiple messages have this Message-ID (diff)
From: Anton Ivanov <anton.ivanov@cambridgegreys.com>
To: Brendan Higgins <brendanhiggins@google.com>,
	jdike@addtoit.com, richard@nod.at
Cc: johannes.berg@intel.com, linux-um@lists.infradead.org,
	linux-kernel@vger.kernel.org, davidgow@google.com
Subject: Re: [RFC v1 0/2] um: drop broken features to fix allyesconfig
Date: Fri, 6 Dec 2019 07:45:03 +0000	[thread overview]
Message-ID: <dd086a74-402c-5b9a-5a12-15a791f8749f@cambridgegreys.com> (raw)
In-Reply-To: <20191206020153.228283-1-brendanhiggins@google.com>

On 06/12/2019 02:01, Brendan Higgins wrote:
> # TL;DR
> 
> This patchset drops two broken features in an attempt to get
> allyesconfig closer to working for ARCH=um.
> 
> # What am I trying to do?
> 
> This patchset is part of my attempt to get `make ARCH=um allyesconfig`
> to produce a config that will build *and* boot to init, so that I can
> use it as a mechanism to run tests[1].
> 
> # How far away are we from an allyesconfig UML kernel?
> 
> I have identified 33 Kconfigs that are selected by allyesconfig, but
> will either not build on UML, or prevent it from booting. They are:
> 
> CONFIG_STATIC_LINK=y
> CONFIG_UML_NET_PCAP=y
> CONFIG_NET_PTP_CLASSIFY=y
> CONFIG_IP_VS=y
> CONFIG_BRIDGE_EBT_BROUTE=y
> CONFIG_BRIDGE_EBT_T_FILTER=y
> CONFIG_BRIDGE_EBT_T_NAT=y
> CONFIG_MTD_NAND_CADENCE=y
> CONFIG_MTD_NAND_NANDSIM=y
> CONFIG_BLK_DEV_NULL_BLK=y
> CONFIG_BLK_DEV_RAM=y
> CONFIG_SCSI_DEBUG=y
> CONFIG_NET_VENDOR_XILINX=y
> CONFIG_NULL_TTY=y
> CONFIG_PTP_1588_CLOCK=y
> CONFIG_PINCTRL_EQUILIBRIUM=y
> CONFIG_DMABUF_SELFTESTS=y
> CONFIG_COMEDI=y
> CONFIG_XIL_AXIS_FIFO=y
> CONFIG_EXFAT_FS=y
> CONFIG_STM_DUMMY=y
> CONFIG_FSI_MASTER_ASPEED=y
> CONFIG_JFS_FS=y
> CONFIG_UBIFS_FS=y
> CONFIG_CRAMFS=y
> CONFIG_CRYPTO_DEV_SAFEXCEL=y
> CONFIG_CRYPTO_DEV_AMLOGIC_GXL=y
> CONFIG_KCOV=y
> CONFIG_LKDTM=y
> CONFIG_REED_SOLOMON_TEST=y
> CONFIG_TEST_RHASHTABLE=y
> CONFIG_TEST_MEMINIT=y
> CONFIG_NETWORK_PHY_TIMESTAMPING=y
> 
> This patchset attempts to deal with CONFIG_STATIC_LINK=y and
> CONFIG_UML_NET_PCAP=y by just removing them since they are broken and
> appear to have been broken for some time. (I am aware of the taboo of
> dropping configs, but given the amount of time they have been broken, I
> figured that I might be able to get away with it in this case, which is
> easier than trying to actually fix them.)
> 
> I also have a patch out to fix CONFIG_EXFAT_FS=y[2].
> 
> After this I plan on going after
> 
> CONFIG_PINCTRL_EQUILIBRIUM=y
> CONFIG_MTD_NAND_CADENCE=y
> CONFIG_FSI_MASTER_ASPEED=y
> CONFIG_CRYPTO_DEV_SAFEXCEL=y
> CONFIG_XIL_AXIS_FIFO=y
> CONFIG_CRYPTO_DEV_AMLOGIC_GXL=y
> CONFIG_XILINX_AXI_EMAC=y
> 
> the problem with these is that they depend on
> devm_platform_ioremap_resource without explicitly depending on
> CONFIG_HAS_IOMEM=y.
> 
> Also note that I don't think that CONFIG_NULL_TTY=y is actually broken
> on UML; however, console seems to get assigned to the null TTY by
> default when it is enabled, so I added it to the list for the sake of
> completeness.
> 
> The other broken configs require more investigation (I would welcome
> help, if anyone is interested ;-) ).
> 
> # Why won't allyesconfig break again after this series of fixes?
> 
> As I mentioned above, I am using UML for testing the kernel, and I am
> currently working on getting my tests to run on KernelCI. As part of our
> testing procedure for KernelCI, we are planning on building a UML kernel
> using allyesconfig and running our tests on it. Thus, we will find out
> very quickly once someone breaks allyesconfig again once we get this all
> working.
> 
> Brendan Higgins (2):
>    um: drivers: remove support for UML_NET_PCAP
>    uml: remove support for CONFIG_STATIC_LINK
> 
>   arch/um/Kconfig              |  23 +----
>   arch/um/Makefile             |   3 +-
>   arch/um/drivers/Kconfig      |  16 ----
>   arch/um/drivers/Makefile     |  17 +---
>   arch/um/drivers/pcap_kern.c  | 113 ----------------------
>   arch/um/drivers/pcap_user.c  | 137 ---------------------------
>   arch/um/drivers/pcap_user.h  |  21 -----
>   arch/um/kernel/dyn.lds.S     | 170 ----------------------------------
>   arch/um/kernel/uml.lds.S     | 115 -----------------------
>   arch/um/kernel/vmlinux.lds.S | 175 ++++++++++++++++++++++++++++++++++-
>   10 files changed, 174 insertions(+), 616 deletions(-)
>   delete mode 100644 arch/um/drivers/pcap_kern.c
>   delete mode 100644 arch/um/drivers/pcap_user.c
>   delete mode 100644 arch/um/drivers/pcap_user.h
>   delete mode 100644 arch/um/kernel/dyn.lds.S
>   delete mode 100644 arch/um/kernel/uml.lds.S
> 
> Looking forward to hearing people's thoughts!
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=205223
> [2] https://patchwork.kernel.org/patch/11273771/
> 

Patch for pcap: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938962#79


-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


  parent reply	other threads:[~2019-12-06  7:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06  2:01 [RFC v1 0/2] um: drop broken features to fix allyesconfig Brendan Higgins
2019-12-06  2:01 ` Brendan Higgins
2019-12-06  2:01 ` [RFC v1 1/2] um: drivers: remove support for UML_NET_PCAP Brendan Higgins
2019-12-06  2:01   ` Brendan Higgins
2019-12-06  7:23   ` Anton Ivanov
2019-12-06  7:23     ` Anton Ivanov
2019-12-07  0:32     ` Brendan Higgins
2019-12-07  0:32       ` Brendan Higgins
2019-12-07  1:21       ` Brendan Higgins
2019-12-07  1:21         ` Brendan Higgins
2019-12-07  9:14         ` Anton Ivanov
2019-12-07  9:14           ` Anton Ivanov
2019-12-09 23:40           ` Brendan Higgins
2019-12-09 23:40             ` Brendan Higgins
2019-12-10  0:02             ` Richard Weinberger
2019-12-10  0:02               ` Richard Weinberger
2019-12-10  7:14               ` Anton Ivanov
2019-12-10  7:14                 ` Anton Ivanov
2019-12-10 22:40                 ` Brendan Higgins
2019-12-10 22:40                   ` Brendan Higgins
2019-12-10  7:08             ` Anton Ivanov
2019-12-10  7:08               ` Anton Ivanov
2019-12-06  2:01 ` [RFC v1 2/2] uml: remove support for CONFIG_STATIC_LINK Brendan Higgins
2019-12-06  2:01   ` Brendan Higgins
2019-12-06  7:41   ` Anton Ivanov
2019-12-06  7:41     ` Anton Ivanov
2019-12-06 22:49     ` Brendan Higgins
2019-12-06 22:49       ` Brendan Higgins
2019-12-06  7:45 ` Anton Ivanov [this message]
2019-12-06  7:45   ` [RFC v1 0/2] um: drop broken features to fix allyesconfig Anton Ivanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd086a74-402c-5b9a-5a12-15a791f8749f@cambridgegreys.com \
    --to=anton.ivanov@cambridgegreys.com \
    --cc=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=jdike@addtoit.com \
    --cc=johannes.berg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.