On Tue, Feb 9, 2016 at 5:32 AM, Corneliu ZUZU <cz...@bitdefender.com> wrote:
> On 2/9/2016 1:55 PM, Jan Beulich wrote: > >> On 09.02.16 at 12:28, <cz...@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 <cz...@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. > I don't really have a strong opinion about this either way, so if the others prefer it staying as it is then there is no point moving it. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
