| Message ID | 20190620175648.7969-1-alistair.francis@wdc.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | qemu/riscv32-virt: Fix missing linux-headers patch | expand |
Hello Francis, +Yann in Cc. First of all, my apologies for breaking the build with my change. On Thu, 20 Jun 2019 10:56:48 -0700 Alistair Francis <alistair.francis@wdc.com> wrote: > Commit f9993797959 "configs/qemu_riscv32_virt: update to 5.1 kernel" > broke the qemu/riscv32-virt machine build as the BR2_LINUX_KERNEL_PATCH > mechanism was replaced with the BR2_GLOBAL_PATCH_DIR mechanism when the > patch was applied. This results in the linux-headers not having the > patch applied which causes a glibc build failure. > > Add a symbolic link to ensure the linux patch is applied to linux and > linux-headers. > > Signed-off-by: Alistair Francis <alistair.francis@wdc.com> > --- > board/qemu/riscv32-virt/patches/linux-headers | 1 + > 1 file changed, 1 insertion(+) > create mode 120000 board/qemu/riscv32-virt/patches/linux-headers > > diff --git a/board/qemu/riscv32-virt/patches/linux-headers b/board/qemu/riscv32-virt/patches/linux-headers > new file mode 120000 > index 0000000000..9c52cb36f4 > --- /dev/null > +++ b/board/qemu/riscv32-virt/patches/linux-headers > @@ -0,0 +1 @@ > +linux > \ No newline at end of file I understand the problem, but I am not sure it is the right solution. Indeed, when the option BR2_KERNEL_HEADERS_AS_KERNEL is enabled, we really expect that linux-headers will use the same source code as the kernel, including all patches. The linux-headers.mk is already doing some effort to achieve this, but it does not do it entirely due do BR2_GLOBAL_PATCH_DIR patches. So what I would propose instead is this: diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk index 95432ade83..46f270a0e1 100644 --- a/package/linux-headers/linux-headers.mk +++ b/package/linux-headers/linux-headers.mk @@ -60,7 +60,8 @@ endif # LINUX_HEADERS_CUSTOM_TARBALL # Apply any necessary patches if we are using the headers from a kernel # build. ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y) -LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) +LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) \ + $(wildcard $(addsuffix /linux,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))) # We rely on the generic package infrastructure to download and apply # remote patches (downloaded from ftp, http or https). For local Yann, what do you think of this ? However, Francis & Mark: it is not normal that we can't build a RISC-V 32 toolchain out of the box, as I reported separately. So while this linux-headers/linux patch consistency issue is real, I think we need something better for RISC-V 32. Indeed a user who would build a RISC-V 32 system, but not for Qemu, would not use this defconfig, and would therefore not have this patch. Do you expect this issue to be resolved in the near future on the kernel side ? Best regards, Thomas
On Thu, Jun 20, 2019 at 11:54 AM Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Francis, > > +Yann in Cc. > > First of all, my apologies for breaking the build with my change. No worries. > > On Thu, 20 Jun 2019 10:56:48 -0700 > Alistair Francis <alistair.francis@wdc.com> wrote: > > > Commit f9993797959 "configs/qemu_riscv32_virt: update to 5.1 kernel" > > broke the qemu/riscv32-virt machine build as the BR2_LINUX_KERNEL_PATCH > > mechanism was replaced with the BR2_GLOBAL_PATCH_DIR mechanism when the > > patch was applied. This results in the linux-headers not having the > > patch applied which causes a glibc build failure. > > > > Add a symbolic link to ensure the linux patch is applied to linux and > > linux-headers. > > > > Signed-off-by: Alistair Francis <alistair.francis@wdc.com> > > --- > > board/qemu/riscv32-virt/patches/linux-headers | 1 + > > 1 file changed, 1 insertion(+) > > create mode 120000 board/qemu/riscv32-virt/patches/linux-headers > > > > diff --git a/board/qemu/riscv32-virt/patches/linux-headers b/board/qemu/riscv32-virt/patches/linux-headers > > new file mode 120000 > > index 0000000000..9c52cb36f4 > > --- /dev/null > > +++ b/board/qemu/riscv32-virt/patches/linux-headers > > @@ -0,0 +1 @@ > > +linux > > \ No newline at end of file > > I understand the problem, but I am not sure it is the right solution. > Indeed, when the option BR2_KERNEL_HEADERS_AS_KERNEL is enabled, we > really expect that linux-headers will use the same source code as the > kernel, including all patches. The linux-headers.mk is already doing > some effort to achieve this, but it does not do it entirely due do > BR2_GLOBAL_PATCH_DIR patches. > > So what I would propose instead is this: > > diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk > index 95432ade83..46f270a0e1 100644 > --- a/package/linux-headers/linux-headers.mk > +++ b/package/linux-headers/linux-headers.mk > @@ -60,7 +60,8 @@ endif # LINUX_HEADERS_CUSTOM_TARBALL > # Apply any necessary patches if we are using the headers from a kernel > # build. > ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y) > -LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) > +LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) \ > + $(wildcard $(addsuffix /linux,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))) > > # We rely on the generic package infrastructure to download and apply > # remote patches (downloaded from ftp, http or https). For local This is fine with me, although I haven't tested to make sure it works. > > Yann, what do you think of this ? > > However, Francis & Mark: it is not normal that we can't build a RISC-V > 32 toolchain out of the box, as I reported separately. So while this > linux-headers/linux patch consistency issue is real, I think we need > something better for RISC-V 32. Indeed a user who would build a RISC-V > 32 system, but not for Qemu, would not use this defconfig, and would > therefore not have this patch. Do you expect this issue to be resolved > in the near future on the kernel side ? Ah, now I understand what you mean. Yes this is a bad situation. From my understanding the glibc port for RV32 is basically done, it just needs a little bit of cleaning and then more effort to submit it. In saying that no one is really pushing for it at the moment. I'll take a look to see if I can help get it in. In the meantime we can either apply a patch to Linux, or we should be able to user older kernel headers (I think 5.0 should be fine). Is that a better solution? Alistair > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Thomas, Alistair, Mark, All, On 2019-06-20 20:54 +0200, Thomas Petazzoni spake thusly: > +Yann in Cc. I seem to consistently been dragged into weird corner-cases... ;-) > On Thu, 20 Jun 2019 10:56:48 -0700 > Alistair Francis <alistair.francis@wdc.com> wrote: > > Add a symbolic link to ensure the linux patch is applied to linux and > > linux-headers. [--SNIP--] > I understand the problem, but I am not sure it is the right solution. > Indeed, when the option BR2_KERNEL_HEADERS_AS_KERNEL is enabled, we > really expect that linux-headers will use the same source code as the > kernel, including all patches. The linux-headers.mk is already doing > some effort to achieve this, but it does not do it entirely due do > BR2_GLOBAL_PATCH_DIR patches. Agreed. > So what I would propose instead is this: > > diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk > index 95432ade83..46f270a0e1 100644 > --- a/package/linux-headers/linux-headers.mk > +++ b/package/linux-headers/linux-headers.mk > @@ -60,7 +60,8 @@ endif # LINUX_HEADERS_CUSTOM_TARBALL > # Apply any necessary patches if we are using the headers from a kernel > # build. > ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y) > -LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) > +LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) \ > + $(wildcard $(addsuffix /linux,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))) > > # We rely on the generic package infrastructure to download and apply > # remote patches (downloaded from ftp, http or https). For local > > Yann, what do you think of this ? Acked-by: Yann E. MORIN <yann.morin.1998@free.fr> > However, Francis & Mark: it is not normal that we can't build a RISC-V > 32 toolchain out of the box, as I reported separately. So while this > linux-headers/linux patch consistency issue is real, I think we need > something better for RISC-V 32. Indeed a user who would build a RISC-V > 32 system, but not for Qemu, would not use this defconfig, and would > therefore not have this patch. Do you expect this issue to be resolved > in the near future on the kernel side ? So, upstream is broken. Our response is usually that we patch it, and cary the patch(es) in the package directory (or in a per-version subdirectory thereof). However, for the kernel, it is more complex, because we usually can't know what version the user will end up using (and it is definitely not uncommon that they go with a non upstream kernel), and so we can't have an automatic way to locate that patch. And even if we could, it may or may not apply (e.g. not on older kernels that don't have riscv). So, besides providing a defconfig, like this one for qemu or for a real board, which has the patch we can point users at, I don;t see what we can do. Oh, yes I see: we can wait the kernel to get fixed. ;-) Regards, Yann E. MORIN.
On Thu, Jun 20, 2019 at 1:43 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote: > > Thomas, Alistair, Mark, All, > > On 2019-06-20 20:54 +0200, Thomas Petazzoni spake thusly: > > +Yann in Cc. > > I seem to consistently been dragged into weird corner-cases... ;-) > > > On Thu, 20 Jun 2019 10:56:48 -0700 > > Alistair Francis <alistair.francis@wdc.com> wrote: > > > Add a symbolic link to ensure the linux patch is applied to linux and > > > linux-headers. > [--SNIP--] > > I understand the problem, but I am not sure it is the right solution. > > Indeed, when the option BR2_KERNEL_HEADERS_AS_KERNEL is enabled, we > > really expect that linux-headers will use the same source code as the > > kernel, including all patches. The linux-headers.mk is already doing > > some effort to achieve this, but it does not do it entirely due do > > BR2_GLOBAL_PATCH_DIR patches. > > Agreed. > > > So what I would propose instead is this: > > > > diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk > > index 95432ade83..46f270a0e1 100644 > > --- a/package/linux-headers/linux-headers.mk > > +++ b/package/linux-headers/linux-headers.mk > > @@ -60,7 +60,8 @@ endif # LINUX_HEADERS_CUSTOM_TARBALL > > # Apply any necessary patches if we are using the headers from a kernel > > # build. > > ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y) > > -LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) > > +LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) \ > > + $(wildcard $(addsuffix /linux,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))) > > > > # We rely on the generic package infrastructure to download and apply > > # remote patches (downloaded from ftp, http or https). For local > > > > Yann, what do you think of this ? > > Acked-by: Yann E. MORIN <yann.morin.1998@free.fr> > > > However, Francis & Mark: it is not normal that we can't build a RISC-V > > 32 toolchain out of the box, as I reported separately. So while this > > linux-headers/linux patch consistency issue is real, I think we need > > something better for RISC-V 32. Indeed a user who would build a RISC-V > > 32 system, but not for Qemu, would not use this defconfig, and would > > therefore not have this patch. Do you expect this issue to be resolved > > in the near future on the kernel side ? > > So, upstream is broken. Our response is usually that we patch it, and > cary the patch(es) in the package directory (or in a per-version > subdirectory thereof). > > However, for the kernel, it is more complex, because we usually can't > know what version the user will end up using (and it is definitely not > uncommon that they go with a non upstream kernel), and so we can't have > an automatic way to locate that patch. And even if we could, it may or > may not apply (e.g. not on older kernels that don't have riscv). > > So, besides providing a defconfig, like this one for qemu or for a real > board, which has the patch we can point users at, I don;t see what we > can do. Oh, yes I see: we can wait the kernel to get fixed. ;-) I started looking at fixing glibc, but it seems to be a large task as without __ARCH_WANT_TIME32_SYSCALLS defined in the kernel we need to implement a lot of syscalls in glibc. Alistair > > Regards, > Yann E. MORIN. > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------' On Thu, Jun 20, 2019 at 1:43 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote: > > Thomas, Alistair, Mark, All, > > On 2019-06-20 20:54 +0200, Thomas Petazzoni spake thusly: > > +Yann in Cc. > > I seem to consistently been dragged into weird corner-cases... ;-) > > > On Thu, 20 Jun 2019 10:56:48 -0700 > > Alistair Francis <alistair.francis@wdc.com> wrote: > > > Add a symbolic link to ensure the linux patch is applied to linux and > > > linux-headers. > [--SNIP--] > > I understand the problem, but I am not sure it is the right solution. > > Indeed, when the option BR2_KERNEL_HEADERS_AS_KERNEL is enabled, we > > really expect that linux-headers will use the same source code as the > > kernel, including all patches. The linux-headers.mk is already doing > > some effort to achieve this, but it does not do it entirely due do > > BR2_GLOBAL_PATCH_DIR patches. > > Agreed. > > > So what I would propose instead is this: > > > > diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk > > index 95432ade83..46f270a0e1 100644 > > --- a/package/linux-headers/linux-headers.mk > > +++ b/package/linux-headers/linux-headers.mk > > @@ -60,7 +60,8 @@ endif # LINUX_HEADERS_CUSTOM_TARBALL > > # Apply any necessary patches if we are using the headers from a kernel > > # build. > > ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y) > > -LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) > > +LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) \ > > + $(wildcard $(addsuffix /linux,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))) > > > > # We rely on the generic package infrastructure to download and apply > > # remote patches (downloaded from ftp, http or https). For local > > > > Yann, what do you think of this ? > > Acked-by: Yann E. MORIN <yann.morin.1998@free.fr> > > > However, Francis & Mark: it is not normal that we can't build a RISC-V > > 32 toolchain out of the box, as I reported separately. So while this > > linux-headers/linux patch consistency issue is real, I think we need > > something better for RISC-V 32. Indeed a user who would build a RISC-V > > 32 system, but not for Qemu, would not use this defconfig, and would > > therefore not have this patch. Do you expect this issue to be resolved > > in the near future on the kernel side ? > > So, upstream is broken. Our response is usually that we patch it, and > cary the patch(es) in the package directory (or in a per-version > subdirectory thereof). > > However, for the kernel, it is more complex, because we usually can't > know what version the user will end up using (and it is definitely not > uncommon that they go with a non upstream kernel), and so we can't have > an automatic way to locate that patch. And even if we could, it may or > may not apply (e.g. not on older kernels that don't have riscv). > > So, besides providing a defconfig, like this one for qemu or for a real > board, which has the patch we can point users at, I don;t see what we > can do. Oh, yes I see: we can wait the kernel to get fixed. ;-) > > Regards, > Yann E. MORIN. > > -- > .-----------------.--------------------.------------------.--------------------. > | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | > | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | > | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | > '------------------------------^-------^------------------^--------------------'
On Thu, 20 Jun 2019 22:43:14 +0200 "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > > So what I would propose instead is this: > > > > diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk > > index 95432ade83..46f270a0e1 100644 > > --- a/package/linux-headers/linux-headers.mk > > +++ b/package/linux-headers/linux-headers.mk > > @@ -60,7 +60,8 @@ endif # LINUX_HEADERS_CUSTOM_TARBALL > > # Apply any necessary patches if we are using the headers from a kernel > > # build. > > ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y) > > -LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) > > +LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) \ > > + $(wildcard $(addsuffix /linux,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))) > > > > # We rely on the generic package infrastructure to download and apply > > # remote patches (downloaded from ftp, http or https). For local > > > > Yann, what do you think of this ? > > Acked-by: Yann E. MORIN <yann.morin.1998@free.fr> Thanks. One thing I'm sure of is the order in which patches will be applied between the patches in BR2_GLOBAL_PATCH_DIR and BR2_LINUX_KERNEL_PATCH. We need to make sure that what happens for the linux package happens in the same order for the linux-headers package. Thomas
diff --git a/board/qemu/riscv32-virt/patches/linux-headers b/board/qemu/riscv32-virt/patches/linux-headers new file mode 120000 index 0000000000..9c52cb36f4 --- /dev/null +++ b/board/qemu/riscv32-virt/patches/linux-headers @@ -0,0 +1 @@ +linux \ No newline at end of file
Commit f9993797959 "configs/qemu_riscv32_virt: update to 5.1 kernel" broke the qemu/riscv32-virt machine build as the BR2_LINUX_KERNEL_PATCH mechanism was replaced with the BR2_GLOBAL_PATCH_DIR mechanism when the patch was applied. This results in the linux-headers not having the patch applied which causes a glibc build failure. Add a symbolic link to ensure the linux patch is applied to linux and linux-headers. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> --- board/qemu/riscv32-virt/patches/linux-headers | 1 + 1 file changed, 1 insertion(+) create mode 120000 board/qemu/riscv32-virt/patches/linux-headers