linux-kernel - Re: [PATCH drm-misc-next v2 2/7] drm/gpuvm: rename struct drm_gpuva_manager to struct drm

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] [day] [month] [year] [list]

Message-ID: <149184db-8003-d1d4-4ae0-1401ff1b3359@redhat.com>
Date:   Thu, 7 Sep 2023 10:54:16 +0200
From:   Danilo Krummrich <dakr@...hat.com>
To:     Boris Brezillon <boris.brezillon@...labora.com>
Cc:     matthew.brost@...el.com, thomas.hellstrom@...ux.intel.com,
        sarah.walker@...tec.com, nouveau@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        donald.robson@...tec.com, christian.koenig@....com,
        faith.ekstrand@...labora.com
Subject: Re: [PATCH drm-misc-next v2 2/7] drm/gpuvm: rename struct
 drm_gpuva_manager to struct drm_gpuvm

On 9/7/23 09:56, Boris Brezillon wrote:
> On Wed,  6 Sep 2023 23:47:10 +0200
> Danilo Krummrich <dakr@...hat.com> wrote:
> 
>> Rename struct drm_gpuva_manager to struct drm_gpuvm including
>> corresponding functions. This way the GPUVA manager's structures align
>> very well with the documentation of VM_BIND [1] and VM_BIND locking [2].
>>
>> It also provides a better foundation for the naming of data structures
>> and functions introduced for implementing a common dma-resv per GPU-VM
>> including tracking of external and evicted objects in subsequent
>> patches.
> 
> I'm fine with this rename, but I feel like some bits are missing in
> this patch. I see a few functions taking a drm_gpuvm object and still
> being prefixed with drm_gpuva_ (I'm not talking about functions that
> only manipulate a drm_gpuva object, but those updating the the VM state,
> like the sm_map/unmap helpers), and I think it'd be preferable to
> rename the source files and the Kconfig option too.
> 

I was a bit hesitant to also rename the source files in the first place,
but I think that makes sense.