From: Philipp Rudo <prudo@redhat.com>
To: Baoquan He <bhe@redhat.com>
Cc: Youling Tang <tangyouling@loongson.cn>,
Simon Horman <horms@kernel.org>,
kexec@lists.infradead.org
Subject: Re: [PATCH 1/2] kexec: Default __NR_kexec_file_load is set to undefined
Date: Fri, 3 Mar 2023 12:03:19 +0100 [thread overview]
Message-ID: <20230303120319.67307b61@rotkaeppchen> (raw)
In-Reply-To: <Y/4CaolPP0U4h6bB@MiWiFi-R3L-srv>
Hi Baoquan,
On Tue, 28 Feb 2023 21:32:26 +0800
Baoquan He <bhe@redhat.com> wrote:
> Hi Philipp,
>
> On 02/27/23 at 04:19pm, Philipp Rudo wrote:
> ......
> > > diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
> > > index be6ccd5..ea77936 100644
> > > --- a/kexec/kexec-syscall.h
> > > +++ b/kexec/kexec-syscall.h
> > > @@ -59,9 +59,7 @@
> > > #endif
> > > #endif /*ifndef __NR_kexec_load*/
> > >
> > > -#ifdef __arm__
> > > #undef __NR_kexec_file_load
> > > -#endif
> > >
> > > #ifndef __NR_kexec_file_load
> >
> > I don't think this will work as intended.
> >
> > On the top of the file sys/syscall.h gets included. In there
> > architectures that support kexec_file_load define __NR_kexec_file_load.
> > This also means that if an architecture doesn't support kexec_file_load
> > __NR_kexec_file_load shouldn't be defined in the first place. Thus I
> > suggest that you find out why sys/syscall.h defines
> > __NR_kexec_file_load for LoongArch even when the system call is not
> > supported and fix it there.
>
> Checking whether LoongArch has defined __NR_kexec_file_load sounds a
> good suggestion. Wondering why we still need add __NR_kexec_file_load
> definition in kexec-tools. E.g below s390 kexec_file support you added.
> <sys/syscall.h> sometime won't be found or __NR_kexec_file_load could be
> not defined yet?
>
> commit d4a948c268272cf37c71be820fb02bf40e56292b
> Author: Philipp Rudo <prudo@linux.ibm.com>
> Date: Wed May 16 14:27:18 2018 +0200
>
> kexec/s390: Add support for kexec_file_load
>
To be honest I don't remember why I have added it back then. Most
likely I simply copied what others have done before.
The benefit in having the extra definition I see is that you don't need
to rebuild glibc when you implement the syscall and don't use the
generic unistd.h. But that is something only few people should ever
encounter.
Thanks
Philipp
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2023-03-03 11:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 9:51 [PATCH 1/2] kexec: Default __NR_kexec_file_load is set to undefined Youling Tang
2023-02-24 9:51 ` [PATCH 2/2] LoongArch: kdump: Set up kernel image segment Youling Tang
2023-02-27 15:19 ` [PATCH 1/2] kexec: Default __NR_kexec_file_load is set to undefined Philipp Rudo
2023-02-28 13:32 ` Baoquan He
2023-03-03 11:03 ` Philipp Rudo [this message]
2023-03-07 3:28 ` Baoquan He
[not found] ` <eb34b2b5-3965-27f1-2fe5-bb4fda4ef16b@loongson.cn>
2023-03-03 10:54 ` Philipp Rudo
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=20230303120319.67307b61@rotkaeppchen \
--to=prudo@redhat.com \
--cc=bhe@redhat.com \
--cc=horms@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=tangyouling@loongson.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox