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: <20080920060059.GA25713@elte.hu>
Date:	Sat, 20 Sep 2008 08:00:59 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	joerg.roedel@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] remove fullflush and nofullflush in IOMMU generic
	option


* FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> wrote:

> This patch against tip/x86/iommu virtually reverts
> 2842e5bf3115193f05dc9dac20f940e7abf44c1a. But just reverting the
> commit breaks AMD IOMMU so this patch also includes some fixes.
> 
> The above commit adds new two options to x86 IOMMU generic kernel boot
> options, fullflush and nofullflush. But such change that affects all
> the IOMMUs needs more discussion (all IOMMU parties need the chance to
> discuss it):
> 
> http://lkml.org/lkml/2008/9/19/106
> 
> For me, adding these boot parameters doesn't make sense.
> 
> All the hardware IOMMUs could use 'fullflush' for lazy IOTLB flushing
> but Calgary doesn't support it. Intel VT-d has the different option
> for it (and we can't rename it). [...]

Well if the new option is desired, you dont have to rename the old 
option - just alias it to the new too and deprecate the old one 
eventually. Boot options are not really ABIs in the traditional sense 
anyway.

But, in general, it's pretty pointless to add boot options for anything 
but debugging - nobody will use them unless there's a _problem_ with the 
default. So the right approach is to not add boot options and to make 
sure that the defaults are sane and intelligent.

So could we work towards removing unnecessary boot options please? _If_ 
we want any strategy switch then that should be runtime anyway - nobody 
sane will reboot a server just to tune it slightly, and no distro will 
litter the boot commandline with hardware dependent tunings either. So 
it's only the default that matters, plus boot parameters for debugging.

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