Messages in this thread |  | | Date | Mon, 30 Jan 2012 15:49:09 +0100 | From | Joerg Roedel <> | Subject | Re: [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
|  |