[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48676a7d-2100-c0d1-4e03-788cb6982fee@oracle.com>
Date: Thu, 24 Aug 2023 17:21:27 -0400
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
x86@...nel.org
Cc: Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
xen-devel@...ts.xenproject.org
Subject: Re: [PATCH] xen: simplify evtchn_do_upcall() call maze
On 8/24/23 11:41 AM, Juergen Gross wrote:
> There are several functions involved for performing the functionality
> of evtchn_do_upcall():
>
> - __xen_evtchn_do_upcall() doing the real work
> - xen_hvm_evtchn_do_upcall() just being a wrapper for
> __xen_evtchn_do_upcall(), exposed for external callers
> - xen_evtchn_do_upcall() calling __xen_evtchn_do_upcall(), too, but
> without any user
>
> Simplify this maze by:
>
> - removing the unused xen_evtchn_do_upcall()
> - removing xen_hvm_evtchn_do_upcall() as the only left caller of
> __xen_evtchn_do_upcall(), while renaming __xen_evtchn_do_upcall() to
> xen_evtchn_do_upcall()
>
> Signed-off-by: Juergen Gross <jgross@...e.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@...cle.com>
Powered by blists - more mailing lists