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:	Sun, 20 Dec 2009 16:44:32 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Alex Chiang <achiang@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 0/12] pci: update pci bridge resources

On Fri, 2009-12-18 at 12:54 -0800, Yinghai Lu wrote:
> this patche set is trying to update pci bridge BAR when that BAR is big enough.
> 
> default it is disabled.
> 
> could use pci=try=2 to enable it.

Thanks for posting this as a nice new series.  It was getting hard to
figure out what went where.

I think you mean "when the BAR is *not* big enough."  And strictly
speaking, I think you're concerned with the bridge *window*, which isn't
actually a bridge BAR.

I don't like the new "pci=try=2" parameter.  Linux should be smart
enough to do the right thing without requiring the user to do something
special.  Using a parameter to enable the new code makes it feel like
"here's some new functionality, but I'm not sure it's safe enough for
everybody to use, so try this parameter if you need it."

The result is that the new code will be rarely used and poorly tested,
yet it remains a burden to all future PCI maintainers, who will have to
understand it and try not to break it.

Can you please put the "-v2"-type comments about your development
history in the [0/n] email?  They are useful while reviewing the
different versions, but they don't need to be in the commit logs.

Also, some of the patches in this series have "-v2" in subject, others
have "-v3", others have nothing.  It's easier to follow development of
the series if the version applies to the series as a whole, not to
individual patches.  The version doesn't need to be on the patch subject
line, because that will go into the commit log, where it won't be
relevant.  Tools like stgit put it where it will be automatically
discarded, e.g., "[PATCH -v2 x/n]"

Bjorn

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ