Re: [PATCH 05/16] drm: update todo.rst

From: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 05/16] drm: update todo.rst
Date: Wed, 22 Mar 2017 15:31:00 -0300	[thread overview]
Message-ID: <877f3h2mfv.fsf@dilma.collabora.co.uk> (raw)
In-Reply-To: <20170322083617.13361-6-daniel.vetter@ffwll.ch> (Daniel Vetter's message of "Wed, 22 Mar 2017 09:36:06 +0100")

Daniel Vetter <daniel.vetter@ffwll.ch> writes:

> Just drive-by, but we have gsoc running so better to update it now.
>
> Great news is that two entries can be removed because essentially all
> done.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  Documentation/gpu/todo.rst | 51 ++++------------------------------------------
>  1 file changed, 4 insertions(+), 47 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 9ecd2ebb8dd8..7dc6de07a3bc 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -16,7 +16,7 @@ De-midlayer drivers
>  With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required
>  to have a ``drm_bus`` structure set up. Drivers can directly set up the
>  ``drm_device`` structure instead of relying on bus methods in ``drm_usb.c``
> -and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` /
> +and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
>  ``->unload`` callbacks and open-code the load/unload sequence properly, using
>  the new two-stage ``drm_device`` setup/teardown.
>  
> @@ -151,7 +151,7 @@ fine-grained per-buffer object and per-context
> lockings scheme. Currently the
>  following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and
>  ``udl``.
>  
> -Contact: Daniel Vetter
> +Contact: Daniel Vetter, respective driver maintainers
>  
>  Switch to drm_connector_list_iter for any connector_list walking
>  ----------------------------------------------------------------
> @@ -193,6 +193,8 @@ plan is to switch to per-file driver API headers, which will also structure
>  the kerneldoc better. This should also allow more fine-grained ``#include``
>  directives.
>  
> +In the end no .c file should need to include ``drmP.h`` anymore.
> +
>  Contact: Daniel Vetter
>  
>  Add missing kerneldoc for exported functions
> @@ -208,31 +210,6 @@ See https://dri.freedesktop.org/docs/drm/ for what's there already.
>  
>  Contact: Daniel Vetter
>  
> -Hide legacy cruft better
> -------------------------
> -
> -Way back DRM supported only drivers which shadow-attached to PCI devices with
> -userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge
> -of the entire device, you can spot them with the DRIVER_MODESET flag.
> -
> -Unfortunately there's still large piles of legacy code around which needs to
> -be hidden so that driver writers don't accidentally end up using it. And to
> -prevent security issues in those legacy IOCTLs from being exploited on modern
> -drivers. This has multiple possible subtasks:
> -
> -* Make sure legacy IOCTLs can't be used on modern drivers.
> -* Extract support code for legacy features into a ``drm-legacy.ko`` kernel
> -  module and compile it only when one of the legacy drivers is enabled.

I've been interested in taking up the work to split drm-legacy.ko from
drm.ko.  The plan is to make it an optional module that legacy drivers
depend on, in a way that you don't need to recompile drm.ko to use it.

I think the issue with the current CONFIG_DRM_VM, for instance, which
hid some of the code for legacy drivers is the downside of requiring
recompilation of drm.ko before using a legacy driver.

Anyway, if you agree with this change, can you keep this entry until
that is done?

-- 
Gabriel Krisman Bertazi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel