From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755317AbZFRSf7 (ORCPT ); Thu, 18 Jun 2009 14:35:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752857AbZFRSfv (ORCPT ); Thu, 18 Jun 2009 14:35:51 -0400 Received: from sous-sol.org ([216.99.217.87]:49125 "EHLO sequoia.sous-sol.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753402AbZFRSfu (ORCPT ); Thu, 18 Jun 2009 14:35:50 -0400 Date: Thu, 18 Jun 2009 11:34:05 -0700 From: Chris Wright To: "Yu, Fenghua" Cc: "'Chris Wright'" , "'David Woodhouse'" , "'Linus Torvalds'" , "'Stephen Rothwell'" , "'Andrew Morton'" , "'Ingo Molnar'" , "'Christopher Wright'" , "Kay, Allen M" , "'iommu'" , "'lkml'" Subject: Re: [PATCH 1/2] IOMMU Identity Mapping Support: iommu_identity_mapping definition Message-ID: <20090618183405.GC19771@sequoia.sous-sol.org> References: <20090327212321.070229000@intel.com> <20090416001957.GA1527@linux-os.sc.intel.com> <1240135508.3589.75.camel@macbook.infradead.org> <20090513231351.GA22386@linux-os.sc.intel.com> <1242314271.3393.11.camel@macbook.infradead.org> <20090514175944.GA5168@linux-os.sc.intel.com> <20090618180514.GA24082@linux-os.sc.intel.com> <20090618181335.GB19771@sequoia.sous-sol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Yu, Fenghua (fenghua.yu@intel.com) wrote: > >> > >> The first patch defines iommu_identity_mapping varialbe which controls > >the > >> identity mapping code and is 0 by default. > > > >The only real difference between "pt" and "identity" is hardware support. > >We should have a single value we don't have to tell users to do different > >things depending on their hardware (they won't even know what they have) > >to achieve the same result. > > Technically keeping two separate options in base kernel might be clear and easy to understand. A distro might merge them together or have other usage model. This pushes burden to distros and users for no obvious gain. Just like queued invalidation vs. register based invalidation...it's a hardware detail that users don't really care that much about, they just care about user visible functionality. thanks, -chris