[PATCH] Add device enumeration interface (v3)

[Alex Deucher]

On Thu, May 28, 2015 at 10:22 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi Alex,
>
> On 28 May 2015 at 14:16, Alex Deucher <alexdeucher at gmail.com> wrote:
>> On Thu, May 28, 2015 at 8:44 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 25 May 2015 at 12:18, Zhou, Jammy <Jammy.Zhou at amd.com> wrote:
>>>> Hi Emil,
>>>>
>>>> Do you have chance to have a look at this new version? Thanks!
>>>>
>>> Hi guys sorry for the delay.
>>>
>>> Looking at my original email response it seems that I wasn't clear
>>> enough about my concerns. They can be looked at as independent and/or
>>> grouped up, depending on your liking:
>>>
>>> - Adding a new interface using which it's not obvious how one can
>>> simplify/ease existing related implementations.
>>> As mentioned before, the claiming duplication that already exists is
>>> more complete than this API.
>>>
>>> - No open-source software uses the interface.
>>> Do you have any patches in progress that convert project foo to using
>>> the API? Otherwise is seems like an open-source project catering after
>>> a closed source project needs.
>>
>> It's actually in preparation for upcoming open source releases.
>>
> Ack. Fair enough - the commit message did not mention any open source
> users. The follow-up response mentioned xserver and mesa for which
> this API doesn't seem like a good fit.
>
>>>
>>> - Adding new dependencies.
>>> Previously libpciaccess, now libudev. The former is used only by a
>>> single function in libdrm_intel, while the latter was optional. v3
>>> makes the use of libudev a hard requirement.
>>> Using the library in mesa has caused problems with Steam (and possibly
>>> other binary programs/games) which ships their own version of various
>>> libraries.
>>
>> Can you think of a better method for device enumeration?  Rolling our
>> own seem like a waste of effort.
>>
> Implementation might be uglier (as do other parts of libdrm), but I
> can envision an API that does not require a new dependency, plus it
> works with platform devices. So I'm not sure if it qualifies as better
> or not.
>
>>
>>>
>>> Now that the patch is merged, the last issue has emerged (in a
>>> particular form). Is there any plan to convert an open-source project
>>> to use this API ?
>>
>> The first users actually will be open source they are just not ready
>> for public release just yet.  We are trying to reduce our internal
>> patch queue and get stuff upstream early and thought others might be
>> interested, but if there are concerns we can revert it for now and
>> re-submit it when we are ready to release the relevant code.
>>
> If you can share some pseudo code on what the requirements are/how it
> should be used I can prep an alternative solution. A one that works
> for your usecase and existing ones. In the mean while can we revert
> it, pretty please ?

Sure, go for it.  Jammy or Frank might be able to provide some pseudo
code in the interim.

Alex


>
> Thanks
> Emil