linux-kernel - Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR

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: <CAK=WgbZQB+76FuJXK82x09CieDmF23zLQ8KbHbEtjnQsc_4axg@mail.gmail.com>
Date:	Fri, 27 Jan 2012 13:00:02 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Joerg Roedel <joerg.roedel@....com>
Cc:	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	David Woodhouse <dwmw2@...radead.org>,
	David Brown <davidb@...eaurora.org>,
	Tony Lindgren <tony@...mide.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Stuart Yoder <b08248@...il.com>,
	Scott Wood <scottwood@...escale.com>,
	Hiroshi Doyu <hdoyu@...dia.com>
Subject: Re: [PATCH 2/6] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

On Fri, Jan 27, 2012 at 12:26 PM, Joerg Roedel <joerg.roedel@....com> wrote:
> I fell also uncomfortable with the missing type-safety of this
> interface. But the alternative is to have dedicated functions for
> set/get each attribute. Well, it depends on how many attributes we have
> in the end, but given that the PAMU guys already have need for a number
> of hardware specific attributes it is likely that having individual
> functions makes the api too complex in the end.
>
> But probably we can replace the 'void *data' with a 'union
> domain_attr'? This will give us some type-safety.
>

I was thinking that since the geometry concept is actually handled by
the core itself, it could probably have its own dedicated function.

Not sure how many other functions like that we might end up having
eventually, but I personally prefer the dedicated API over a single
multiplexer which is prone to error and (somewhat) harder to
debug/read.

Real vendor-specific attributes do probably justifies an all-catch
attribute API, I agree. Though we should probably try to minimize
them, and where possible, implement them in the core too, for the
benefit of everyone.

Thanks,
Ohad.
--
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/