[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [v5][PATCH 03/10] xen:x86: define a new hypercall to get RMRR mappings

>>> On 27.08.14 at 03:37, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/8/26 20:37, Jan Beulich wrote:
>> For example, I had also asked you to adjust your patch titles, yet
> Are you sure? I recheck all e-mails you replied to me but I don't find 
> this comment.


>> they still come in the same bogus form (namely with colons rather
>> than slashes as prefix separators - this ones should e.g. start with
>> "xen/x86:", albeit I personally dislike the xen/ prefix and tend to
>> strip it).
> Anyway, I think you'd like to change all titles as follows:

Along those lines, albeit some of the prefixes continue to be
overly long:

> 1> xen/vtd/rmrr: export acpi_rmrr_units
> 2> xen/vtd/rmrr: introduce acpi_rmrr_unit_entries

In these two, the trailing rmrr is meaningless: rmrr is not really
a sub-component, and the rest of the title already establishes
enough context.

> 3> xen/x86: define a new hypercall to get RMRR mappings

To avoid needless extra rounds, iirc the hypercall was requested
to no longer be RMRR-centric. Hence the title shouldn't be either.

> 4> tools/libxc: introduce hypercall for xc_reserved_device_memory_map
> 5> tools/libxc: check if mmio BAR is out of RMRR mappings

Similarly, this wouldn't be RMRR specific the either.

> 6> hvm_info_table: introduce nr_reserved_device_memory_map

Here the prefix is rather odd: Knowing most of the sub-component
placement throughout the code base quite well, I can't really identify
which sub-component this is about. Please remember that the
primary purpose of these prefixes is to make it easy to identify
roughly which area of the code base a change affects. Hence this
should neither be too fine grained (like you seemed to be picking
e.g. individual header file names as prefixes) nor too coarse grained.

Just take on for yourself the viewing angle a maintainer or potential
reviewer would take: Is this an area I should be looking at or I am
interested in?

> 7> xen/x86: support xc_reserved_device_memory_map in compat case
> 8> tools/firmware/hvmloader: introduce hypercall for
>   xc_reserved_device_memory_map
> 9> tools/firmware/hvmloader: check to reserve RMRR
>   mappings in e820

For these two just "hvmloader:" would seem to provide enough


> 10> xen/vtd: make USB RMRR mapping safe

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.