Re: [PATCH 1/7] arm: move arch/arm/hvm.c to arch/arm/hvm/hvm.c

[Corneliu ZUZU <czuzu@bitdefender.com>]

On 2/9/2016 1:55 PM, Jan Beulich wrote:
>>>> On 09.02.16 at 12:28, <czuzu@bitdefender.com> wrote:
>> On 2/9/2016 1:03 PM, Stefano Stabellini wrote:
>>> On Mon, 8 Feb 2016, Corneliu ZUZU wrote:
>>>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
>>>> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
>>> Why are we doing this? These are not header files, their paths don't
>>> necessarily need to be the same and xen/arch/x86/hvm/hvm.c is very
>>> different from xen/arch/arm/hvm.c.
>>>
>>> Please state the reason more clearly.
>>>
>>>
>>>> Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>
>>>> ---
>>>>    xen/arch/arm/Makefile     |  2 +-
>>>>    xen/arch/arm/hvm.c        | 67 -----------------------------------------------
>>>>    xen/arch/arm/hvm/Makefile |  1 +
>>>>    xen/arch/arm/hvm/hvm.c    | 66 ++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>> Because the ARM side hvm.c currently exists solely to add an implementation
>> for
>> do_hvm_op, which on x86 is @ arch/x86/hvm/hvm.c. I presume the ARM hvm.c got
>> its name
>> from the X86 file, so I thought a symmetry between the two was intended from
>> the start.
>> Also, the hvm directory was created to separate hvm-specific code, which is
>> the case w/
>> do_hvm_op on any arch.
> While I'm not an ARM maintainer, this change still strikes me as odd
> (or a change for the change's sake). A directory with just one file
> in it (and - afaict - no current perspective to gain more) is just
> pointless. In fact it's usually the other way around: When a file
> grows (or would grow) too large, a similarly named subdirectory
> gets introduced with the contents "scattered" across multiple files
> in that directory.
>
> Jan

There are already directories w/ just one/a few files in them, even 
small (e.g. common/gcov/gcov.c).
IMHO no harm is done if a file is put in its proper directory even 
before it grows too large.
This way one can find the file more easily, future additions are more 
visibly encouraged to
also be separated in that directory when it makes sense, symmetry 
between arch directories remains
intact (=> easier to compare between code for different arches/find 
equivalent files between them).

But I am not a Xen maintainer, I'm only a contributor so I can only 
suggest :).
If ARM maintainers (e.g. Tamas) feel the same, I will move the file back.

Corneliu.