linux-kernel - Re: [RFC PATCH] drm/print: Add deprecation notes to 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: <CAD=FV=UMkkSrCQHfsUwkc_W8BmG-doH8jmNC1ckrh4w1rYbcxA@mail.gmail.com>
Date:   Fri, 24 Sep 2021 14:59:15 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     dri-devel <dri-devel@...ts.freedesktop.org>
Cc:     Sam Ravnborg <sam@...nborg.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Lyude Paul <lyude@...hat.com>,
        Jani Nikula <jani.nikula@...el.com>,
        Stephen Boyd <swboyd@...omium.org>,
        David Airlie <airlied@...hat.com>,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] drm/print: Add deprecation notes to DRM_...() functions

Hi,

On Tue, Sep 21, 2021 at 8:28 AM Douglas Anderson <dianders@...omium.org> wrote:
>
> It's hard for someone (like me) who's not following closely to know
> what the suggested best practices are for error printing in DRM
> drivers. Add some hints to the header file.
>
> In general, my understanding is that:
> * When possible we should be using a `struct drm_device` for logging
>   and recent patches have tried to make it more possible to access a
>   relevant `struct drm_device` in more places.
> * For most cases when we don't have a `struct drm_device`, we no
>   longer bother with DRM-specific wrappers on the dev_...() functions
>   or pr_...() functions and just encourage drivers to use the normal
>   functions.
> * For debug-level functions where we might want filtering based on a
>   category we'll still have DRM-specific wrappers, but we'll only
>   support passing a `struct drm_device`, not a `struct
>   device`. Presumably most of the cases where we want the filtering
>   are messages that happen while the system is in a normal running
>   state (AKA not during probe time) and we should have a `struct
>   drm_device` then. If we absolutely can't get a `struct drm_device`
>   then these functions begrudgingly accept NULL for the `struct
>   drm_device` and hopefully the awkwardness of having to manually pass
>   NULL will keep people from doing this unless absolutely necessary.
>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---
>
>  include/drm/drm_print.h | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)

Landed in drm-misc-next:

306589856399 drm/print: Add deprecation notes to DRM_...() functions