Hi Tao,
On 9/19/19 4:06 AM, Tao Xu wrote:
> There is an extra line in comment of CPUID_8000_0008_EBX_WBNOINVD,
> remove the extra enter and spaces.
>
> Signed-off-by: Tao Xu <tao3...@intel.com>
> ---
> target/i386/cpu.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 5f6e3a029a..71b6193390 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -695,8 +695,7 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
>
> #define CPUID_7_1_EAX_AVX512_BF16 (1U << 5) /* AVX512 BFloat16 Instruction */
>
> -#define CPUID_8000_0008_EBX_WBNOINVD (1U << 9) /* Write back and
> -
> do not invalidate cache */
> +#define CPUID_8000_0008_EBX_WBNOINVD (1U << 9) /* Write back and do not
> invalidate cache */
The QEMU CODING_STYLE [*] recommend a 80 chars per line limit:
Line width
==========
Lines should be 80 characters; try not to make them longer.
Sometimes it is hard to do, especially when dealing with QEMU subsystems
that use long function or symbol names. Even in that case, do not make
lines much longer than 80 characters.
Rationale:
* Some people like to tile their 24" screens with a 6x4 matrix of 80x24
xterms and use vi in all of them. The best way to punish them is to
let them keep doing it.
* Code and especially patches is much more readable if limited to a sane
line length. Eighty is traditional.
* The four-space indentation makes the most common excuse ("But look
at all that white space on the left!") moot.
* It is the QEMU coding style.
[*]
https://git.qemu.org/?p=qemu.git;a=blob;f=CODING_STYLE.rst;h=427699e0e425431ea99d4046e40543bdcc22e9c5;hb=HEAD#l82
Can you repost using correct lenght comments?
> #define CPUID_8000_0008_EBX_IBPB (1U << 12) /* Indirect Branch Prediction
> Barrier */
>
> #define CPUID_XSAVE_XSAVEOPT (1U << 0)
>
