lkml.org 
[lkml]   [2012]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute
On Sat, Jan 28, 2012 at 10:44:22PM +0200, Ohad Ben-Cohen wrote:
> On Fri, Jan 27, 2012 at 3:03 PM, Joerg Roedel <joerg.roedel@amd.com> wrote:
> > Note that only the read-side is handled by the core. An IOMMU driver may
> > decide to implement a write-side for the geometry which would be not in
> > the core then. Having a dedicated function for the write-side does not
> > make sense because (for now) there is only one upcoming driver requiring
> > this.
>
> I'd still go with a type-safe interface here, but maybe it's only me.

Well, the idea still stands to replace 'void *data' with something like
'union domain_attr *data'. This isn't as type-safe as dedicated
functions, but still better than void*.

> I'm not so sure how would drivers use these "hardware-specific api
> attr extensions" in general.

Depends on the attribute. For the geometry attribute drivers that
allocate a domain should read out the geometry and only use the range
returned for map/unmap (or fail initialization when the domain geometry
is unexpected).

> Is the intention that only hardware-specific drivers will use them ? I
> guess that generic drivers won't be able to use them, because their
> behavior will not be well-defined across all hardware implementations.

Hardware specific attributes are intended, but not limited to hardware
specific drivers. A generic driver that _may_ run on a given hardware
can use a hardware specific attribute too. If it doesn't run on this
hardware it will just get -EINVAL back.

Regards,

Joerg

--
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632



\
 
 \ /
  Last update: 2012-01-30 15:51    [W:0.037 / U:11.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site