linux-kernel - Re: [RFC][PATCH 2/2] disable boot interrupts on Intel X58 and 55x0

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]

Date:	Sat, 5 Sep 2009 18:18:52 +0200
From:	Olaf Dabrunz <Olaf.Dabrunz@....net>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Stefan Assmann <sassmann@...hat.com>, linux-kernel@...r.kernel.org,
	jcm@...hat.com, sdietrich@...ell.com, linux-acpi@...r.kernel.org,
	andi@...stfloor.org, hpa@...or.com, mingo@...e.hu,
	Olaf.Dabrunz@....net, ktokunag@...hat.com, tglx@...utronix.de,
	lenb@...nel.org
Subject: Re: [RFC][PATCH 2/2] disable boot interrupts on Intel X58 and 55x0

On 05-Sep-09, Daniel Walker wrote:
> On Sat, 2009-09-05 at 11:07 +0200, Stefan Assmann wrote:
> > On 04.09.2009 19:06, Daniel Walker wrote:
> > > On Fri, 2009-09-04 at 12:55 -0400, Stefan Assmann wrote:
> > >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_QPI_TBG15,  quirk_disable_intel_tylersburg_boot_interrupt);
> > >> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL,  PCI_DEVICE_ID_INTEL_QPI_TBG15,  quirk_disable_intel_tylersburg_boot_interrupt);
> > > 
> > > 
> > > These lines are wildly long .. Could you reduce these down to a max of
> > > 80 characters..
> > 
> > Hi Daniel,
> > 
> > you're right about the lines being to long, however if you take a peek
> > at drivers/pci/quirks.c you'll see that all the quirks are done this
> > way. :)
> 
> I looked, the whole thing is a mess .. Really all these lines need to be
> cleaned up.. It doesn't help to have you add more to it tho. Especially
> the tab's or spaces between the commas, I can say I understand why that
> is.. If there is a good reason why it's like that I'm all ears..

It makes adding/deleting/modifying the entries easier, with one-line
editor operations. And if all data for one ID-to-quirk relationship is
on one line, with tabs to make for nice columns, I can more easily see
which device is linked to which quirk. That is why I usually prefer one
line per entry. And the entries in quirks.c are long, but not too long
for that IMHO.

I agree that the 80 columns restriction is a good thing in almost all
cases, as it limits the amount of information that is put on a single
line, and it limits the number of indentation levels within a function.

But in this case I think we are better off with one line per entry, even
if the line becomes longer than 80 characters. The information on one
line is not that much (one macro with 3 parameters), only the
identifiers try to be readable and discernible and therefore become
long.

So this will only be a problem for terminals that are limited to 80
rows, and I do not think that anyone is that restricted nowadays.

Regards,

-- 
Olaf Dabrunz (Olaf.Dabrunz <at> gmx.net)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/