Artem Kachitchkine wrote:
>
>> What I'm talking about is an ARC requirement to *disclose* non-DDI
>> interface consumption by drivers, and to strongly discourage the
>> practice of going outside of the DDI for device drivers. I think
>> that *is* an issue for PSARC at least.
>
> How do you envision to enforce this in practice? Should C-team
> communicate back to PSARC? It used to be mostly one-way, making it
> bounce back and forth is thickening the process, while we're trying to
> thin it, to encourage external contributors.
>
> > (We're talking about interfaces here, not implementation.)
>
> In this particular case, the line is unclear. A minor bugfix can turn
> a DDI compliant driver into a non-compliant one. In my mind it's more
> implementation (think "lint clean") than architecture.
>
> -Artem
As a policy, I'm not sure how *hard and fast* the rule needs to be. I
certainly think that when a case for a new driver goes before ARC, it
should list the APIs it is using. This may mean that driver projects
which were able to skip ARC altogether (although a poor choice, IMO,
self-review should be used instead in such cases, IMO) now need to
expose themselves to ARC. In and of itself, that's not too bad.
And some APIs, like the GLDv3, should probably not cause a case to do
more than self-review, so the cost of effort is minimal in such cases.
Bug fixes that import APIs that the driver didn't have before.... I'm
not so sure about. I'd hope that a fasttrack is not too burdensome.
And again, maybe even some would qualify for self-review.
Certainly the transition in going from DDI compliant to
non-DDI-compliant is not one that I would want to just sweep under the
rug. Better to announce that transition up front, IMO. (And if going
non-DDI compliant is required to fix a bug, my first question would be
"why?")
-- Garrett
