On 27.04.2022 04:56, Wei Chen wrote: >> -----Original Message----- >> From: Jan Beulich <jbeul...@suse.com> >> Sent: 2022年4月26日 22:31 >> >> On 26.04.2022 12:37, Wei Chen wrote: >>> On 2022/4/26 16:53, Jan Beulich wrote: >>>> On 18.04.2022 11:07, Wei Chen wrote: >>>>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c >>>>> similarity index 71% >>>>> rename from xen/arch/x86/efi/stub.c >>>>> rename to xen/arch/x86/efi/stub-x86.c >>>>> index 9984932626..2cd5c8d4dc 100644 >>>>> --- a/xen/arch/x86/efi/stub.c >>>>> +++ b/xen/arch/x86/efi/stub-x86.c >>>> >>>> I'm not happy to see a file named *x86*.[ch] under x86/. I think the >>>> x86 file wants to simply include the common one (and the symlinking >>>> be suppressed when a real file already exists). Naming the common >>>> file stub-common.c wouldn't help, as a similar anomaly would result. >>>> >>> >>> How about using stub-arch.c to indicate this stub file only contains >>> the arch specific contents? However, we cannot predict what link files >>> will be created in this directory in the future. If someone needs to >>> create a stub-arch.c link file in the future, can we solve it at that >>> time? Or do you have any suggestions? >> >> I did provide my suggestion. I do not like stub-arch.c any better than >> stub-x86.c or stub-common.c. >> > > With my limited English level, I can only see that you don't like this, but > I can't get what you want clearly from your comments. I can only guess: > For "x86 file wants to simply include the common one": > 1. Did you mean, x86 still keeps it stub.c and includes all its original > contents. The common/efi/stub.c link behavior will be ignored, because > of x86 has a real stub.c? And common/efi/stub.c still can works for > other architectures like Arm whom doesn't have a real stub.c? > But in previous version's discussion, I had said I created a stub.c in > Arm/efi, and copied Arm required functions from x86/efi/stub.c. But > people didn't like it. If my guess is correct, I don't know what is > the essential difference between the two approaches. > 2. Keeps stub.c in x86/efi, and use it to include common/stub.c. > I think this may not be the right understanding, but I can't think > of any other understanding.
2 is what I've been suggesting. Jan
