backends/tpm/tpm_ioctl.h | 2 +- block/file-posix.c | 9 +++++---- configure | 2 ++ include/qemu/osdep.h | 8 ++++++++ 4 files changed, 16 insertions(+), 5 deletions(-)
Recently, a testsuite for gnumach, the GNU/Hurd microkernel, was developed that uses qemu. Currently qemu cannot be compiled for the GNU/Hurd, as such, this testsuite is available only for GNU/Linux users. This patcheset allows qemu compilation in GNU/Hurd. With this patchset applied, qemu can be compiled without any special configure options. Please review, thanks, Manolo de Medici (4): Include new arbitrary limits if not already defined Avoid conflicting types for 'copy_file_range' Add the GNU/Hurd as a target host Exclude TPM ioctls definitions for the GNU/Hurd backends/tpm/tpm_ioctl.h | 2 +- block/file-posix.c | 9 +++++---- configure | 2 ++ include/qemu/osdep.h | 8 ++++++++ 4 files changed, 16 insertions(+), 5 deletions(-) -- 2.43.0
On Thu, 18 Jan 2024 at 16:02, Manolo de Medici <manolodemedici@gmail.com> wrote: > > Recently, a testsuite for gnumach, the GNU/Hurd microkernel, was developed > that uses qemu. Currently qemu cannot be compiled for the GNU/Hurd, as such, > this testsuite is available only for GNU/Linux users. > > This patcheset allows qemu compilation in GNU/Hurd. With this patchset applied, > qemu can be compiled without any special configure options. > > Please review, thanks, > > Manolo de Medici (4): > Include new arbitrary limits if not already defined > Avoid conflicting types for 'copy_file_range' > Add the GNU/Hurd as a target host > Exclude TPM ioctls definitions for the GNU/Hurd Hi -- something odd seems to have happened with these patchset emails. The cover letter got to the list: https://lore.kernel.org/qemu-devel/CAHP40m=UQ=F1-Vy4-wR18RjqzF9o+8UOjgpUsrTU8QXn=7eAeA@mail.gmail.com/ but it doesn't have any of the patches as followup emails in the thread. Instead they got sent as entirely separate emails, eg here's patch 1: https://lore.kernel.org/qemu-devel/CAHP40mmk4cPk6ZHETfq5BtQxK63A6PiuCKrvv4yyOPBxVTW+OQ@mail.gmail.com/ This means the automated patch tooling thinks none of the patches arrived, eg patchew says "0 patches received": https://lore.kernel.org/qemu-devel/CAHP40mmk4cPk6ZHETfq5BtQxK63A6PiuCKrvv4yyOPBxVTW+OQ@mail.gmail.com/ git format-patch can help in getting this right (it is its "--thread=shallow" style). For this version, I'll send some review comments to the individual patch emails, but it would be nice to get this right on v3. thanks -- PMM
Thank you, I see that there is an issue and I'll take care of fixing it in the future On Mon, Jan 22, 2024 at 5:53 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Thu, 18 Jan 2024 at 16:02, Manolo de Medici <manolodemedici@gmail.com> wrote: > > > > Recently, a testsuite for gnumach, the GNU/Hurd microkernel, was developed > > that uses qemu. Currently qemu cannot be compiled for the GNU/Hurd, as such, > > this testsuite is available only for GNU/Linux users. > > > > This patcheset allows qemu compilation in GNU/Hurd. With this patchset applied, > > qemu can be compiled without any special configure options. > > > > Please review, thanks, > > > > Manolo de Medici (4): > > Include new arbitrary limits if not already defined > > Avoid conflicting types for 'copy_file_range' > > Add the GNU/Hurd as a target host > > Exclude TPM ioctls definitions for the GNU/Hurd > > Hi -- something odd seems to have happened with these patchset > emails. The cover letter got to the list: > https://lore.kernel.org/qemu-devel/CAHP40m=UQ=F1-Vy4-wR18RjqzF9o+8UOjgpUsrTU8QXn=7eAeA@mail.gmail.com/ > > but it doesn't have any of the patches as followup emails > in the thread. Instead they got sent as entirely separate > emails, eg here's patch 1: > https://lore.kernel.org/qemu-devel/CAHP40mmk4cPk6ZHETfq5BtQxK63A6PiuCKrvv4yyOPBxVTW+OQ@mail.gmail.com/ > > This means the automated patch tooling thinks none of the patches > arrived, eg patchew says "0 patches received": > https://lore.kernel.org/qemu-devel/CAHP40mmk4cPk6ZHETfq5BtQxK63A6PiuCKrvv4yyOPBxVTW+OQ@mail.gmail.com/ > > git format-patch can help in getting this right (it is its > "--thread=shallow" style). > > For this version, I'll send some review comments to the > individual patch emails, but it would be nice to get this > right on v3. > > thanks > -- PMM
© 2016 - 2024 Red Hat, Inc.