Re: [PATCH v8 00/23] Introduce the lwIP network stack

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 6816 bytes --]

On Fri, Aug 09, 2024 at 03:19:02PM +0200, Jerome Forissier wrote:
> 
> 
> On 8/8/24 19:24, Tom Rini wrote:
> > On Thu, Aug 08, 2024 at 06:41:02PM +0200, Jerome Forissier wrote:
> >>
> >>
> >> On 8/7/24 22:44, Tom Rini wrote:
> >>> On Wed, Aug 07, 2024 at 07:11:44PM +0200, Jerome Forissier wrote:
> >>>
> >>>> This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip
> >>>> library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP
> >>>> stack [2] [3] as an alternative to the current implementation in net/,
> >>>> selectable with Kconfig, and ultimately keep only lwIP if possible. Some
> >>>> reasons for doing so are:
> >>>> - Make the support of HTTPS in the wget command easier. Javier T. and
> >>>> Raymond M. (CC'd) have some additional lwIP and Mbed TLS patches to do
> >>>> so. With that it becomes possible to fetch and launch a distro installer
> >>>> such as Debian etc. using a secure, authenticated connection directly
> >>>> from the U-Boot shell. Several use cases:
> >>>>   * Authentication: prevent MITM attack (third party replacing the
> >>>> binary with a different one)
> >>>>   * Confidentiality: prevent third parties from grabbing a copy of the
> >>>> image as it is being downloaded
> >>>>   * Allow connection to servers that do not support plain HTTP anymore
> >>>> (this is becoming more and more common on the Internet these days)
> >>>> - Possibly benefit from additional features implemented in lwIP
> >>>> - Less code to maintain in U-Boot
> >>>>
> >>>> Prior to applying this series, the lwIP stack needs to be added as a
> >>>> Git subtree with the following command:
> >>>>
> >>>>  $  git subtree add --squash --prefix lib/lwip/lwip https://git.savannah.gnu.org/git/lwip.git STABLE-2_2_0_RELEASE
> >>>
> >>> For v9, I think it would be good to do a CI run with NET_LWIP default
> >>> and seeing what fails from that too. There's a few problems still
> >>> leading to a lot of failures, in that case. Thanks.
> >>
> >> I pushed my branch to GitHub [1] and there's a failure in the
> >> tools_only_macOS job [2]. Any idea what is going on? I tried twice and
> >> it failed twice :-/
> >> Om my Linux machine, "make tools-only_config tools-only" works
> >> fine.
> >>
> >> [1] https://github.com/u-boot/u-boot/pull/635
> >> [2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=9105&view=results
> > 
> > Alright so from [2] going to the job and then downloading the raw log (it's
> > huge, firefox gets mad for me), scrolling down until it's not the git clone we
> > see:
> > 2024-08-08T14:36:30.0865130Z   HOSTCC  scripts/basic/fixdep
> > 2024-08-08T14:36:30.8641660Z   HOSTCC  scripts/kconfig/conf.o
> > 2024-08-08T14:36:30.9645180Z   LEX     scripts/kconfig/zconf.lex.c
> > 2024-08-08T14:36:31.0545650Z   YACC    scripts/kconfig/zconf.tab.c
> > 2024-08-08T14:36:33.2374910Z   HOSTCC  scripts/kconfig/zconf.tab.o
> > 2024-08-08T14:36:34.9997050Z   HOSTLD  scripts/kconfig/conf
> > 2024-08-08T14:36:36.5552790Z generated_defconfig:7:warning: unexpected data:  # CONFIG_SANDBOX_
> > SDL is not set
> > 2024-08-08T14:36:36.5666380Z generated_defconfig:12:warning: unexpected data:  # CONFIG_BOOTSTD
> > _FULL is not set
> > 2024-08-08T14:36:36.5724560Z generated_defconfig:13:warning: unexpected data:  # CONFIG_BOOTMET
> > H_CROS is not set
> > 2024-08-08T14:36:36.5742720Z generated_defconfig:14:warning: unexpected data:  # CONFIG_BOOTMET
> > H_VBE is not set
> > 2024-08-08T14:36:36.5752700Z generated_defconfig:17:warning: unexpected data:  # CONFIG_CMD_BOO
> > TD is not set
> > 2024-08-08T14:36:36.5772400Z generated_defconfig:18:warning: unexpected data:  # CONFIG_CMD_BOO
> > TM is not set
> > 2024-08-08T14:36:36.5788060Z generated_defconfig:19:warning: unexpected data:  # CONFIG_CMD_BOO
> > TI is not set
> > 2024-08-08T14:36:36.5792360Z generated_defconfig:20:warning: unexpected data:  # CONFIG_CMD_ELF
> >  is not set
> > 2024-08-08T14:36:36.5828400Z generated_defconfig:21:warning: unexpected data:  # CONFIG_CMD_EXTENSION is not set
> > 2024-08-08T14:36:36.5840470Z generated_defconfig:22:warning: unexpected data:  # CONFIG_CMD_DAT
> > E is not set
> > 2024-08-08T14:36:36.5938540Z generated_defconfig:26:warning: unexpected data:  # CONFIG_ACPIGEN
> >  is not set
> > 2024-08-08T14:36:36.5974000Z generated_defconfig:35:warning: unexpected data:  # CONFIG_VIRTIO_MMIO is not set
> > 2024-08-08T14:36:36.5985430Z generated_defconfig:36:warning: unexpected data:  # CONFIG_VIRTIO_PCI is not set
> > 2024-08-08T14:36:36.6045140Z generated_defconfig:37:warning: unexpected data:  # CONFIG_VIRTIO_SANDBOX is not set
> > 2024-08-08T14:36:36.6053060Z generated_defconfig:38:warning: unexpected data:  # CONFIG_GENERATE_ACPI_TABLE is not set
> > 2024-08-08T14:36:36.6068760Z generated_defconfig:39:warning: unexpected data:  # CONFIG_EFI_LOADER is not set
> > 2024-08-08T14:36:36.6088140Z #
> > 2024-08-08T14:36:36.6121560Z # configuration written to .config
> > 2024-08-08T14:36:36.6130190Z #
> > 2024-08-08T14:36:42.5830900Z scripts/kconfig/conf  --syncconfig Kconfig
> > 2024-08-08T14:36:43.9105630Z .config:284:warning: symbol value '' invalid for AVB_BUF_ADDR
> > 2024-08-08T14:36:43.9121120Z .config:285:warning: symbol value '' invalid for AVB_BUF_SIZE
> > 2024-08-08T14:36:43.9142940Z *
> > 2024-08-08T14:36:43.9172380Z * Restart config...
> > 2024-08-08T14:36:43.9257450Z *
> > 2024-08-08T14:36:43.9288610Z *
> > 2024-08-08T14:36:43.9332910Z * Security support
> > 2024-08-08T14:36:43.9366750Z *
> > 2024-08-08T14:36:43.9399770Z Build Android Verified Boot operations (AVB_VERIFY) [Y/n/?] y
> > 2024-08-08T15:35:07.9280210Z ##[error]The Operation will be canceled. The next steps may not contain expected logs.
> > 
> > And indeed, most of that is "normal" if we look at a current build for
> > tools-only on macOS. We're being hit by the fact that the host CC isn't
> > gcc and is llvm and https://github.com/llvm/llvm-project/issues/78778
> > applies, I believe. Now how do we work around this? Hum...
> 
> That's an "interesting" bug...
>  
> > If you go an change "# CONFIG_FOO is not set" to CONFIG_FOO=n in
> > configs/tools-only_defconfig, I assume your build moves on?
> 
> Yep, it does.

OK, good.

> > This is
> > valid syntax and fixing a more generic issue we have on macOS today.
> 
> I am adding a new patch to v9: "configs: use syntax CONFIG_FOO=n in
> tools-only_defconfig". It means one extra step when syncing the
> defconfigs though... It is just a simple sed command but perhaps you
> have a better idea?

This should be fine, there's already a number of configs I have to
un-sync when I do a re-sync.

> Thanks again for testing and for your help,

You're welcome.

Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]