linux-kernel - Re: linux-next: manual merge of the xen-tip tree with the tip tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1504183017.2786.36.camel@perches.com>
Date:   Thu, 31 Aug 2017 05:36:57 -0700
From:   Joe Perches <joe@...ches.com>
To:     Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Juergen Gross <jgross@...e.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Xen Devel <Xen-devel@...ts.xensource.com>,
        Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: manual merge of the xen-tip tree with the tip tree

On Thu, 2017-08-31 at 11:16 +0200, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@...utronix.de> wrote:
> Low prio nitpicking, could we please write such table based initializers in a 
> vertically organized, tabular fashion:
> 
> > +	{ debug,			xen_xendebug,				true },
> > +	{ int3,				xen_xenint3,				true },
> > +	{ double_fault,			xen_double_fault,			true },
> > +#ifdef CONFIG_X86_MCE
> > +	{ machine_check,		xen_machine_check,			true },
> > +#endif
> > +	{ nmi,				xen_nmi,				true },
> > +	{ overflow,			xen_overflow,				false },
> > +#ifdef CONFIG_IA32_EMULATION
> > +	{ entry_INT80_compat,		xen_entry_INT80_compat,			false },
> > +#endif
> > +	{ page_fault,			xen_page_fault,				false },
> > +	{ divide_error,			xen_divide_error,			false },
> > +	{ bounds,			xen_bounds,				false },
> > +	{ invalid_op,			xen_invalid_op,				false },
> > +	{ device_not_available,		xen_device_not_available,		false },
> > +	{ coprocessor_segment_overrun,	xen_coprocessor_segment_overrun,	false },
> > +	{ invalid_TSS,			xen_invalid_TSS,			false },
> > +	{ segment_not_present,		xen_segment_not_present,		false },
> > +	{ stack_segment,		xen_stack_segment,			false },
> > +	{ general_protection,		xen_general_protection,			false },
> > +	{ spurious_interrupt_bug,	xen_spurious_interrupt_bug,		false },
> > +	{ coprocessor_error,		xen_coprocessor_error,			false },
> > +	{ alignment_check,		xen_alignment_check,			false },
> > +	{ simd_coprocessor_error,	xen_simd_coprocessor_error,		false },
> > +#ifdef CONFIG_TRACING
> > +	{ trace_page_fault,		xen_trace_page_fault,			false },
> > +#endif
> ,,
> ... as to me such a table is 100 times more readable - YMMV.

Yeah, kinda.

It's a lot of whitespace and eyeball left/right scanning.
And these tables require whitespace updating if a longer
name is ever used.

Given the near 1:1 mapping of <trap> to xen_<trap>
perhaps adding a macro would be nice.

#define xen_trap(trap, ist_ok) \
	{ trap, xen_##trap, ist_ok }

	{ debug,	xen_xendebug,	true },
	{ int3,		xen_xenint3,	true },
#ifdef CONFIG_X86_MCE
	xen_trap(machine_check, true),
#endif
	xen_trap(double_fault, true),
	xen_trap(nmi, true),
	xen_trap(overflow, false),
	...

ymmv. </bikeshedding>