[Intel-gfx] [PATCH 05/16] drm: update todo.rst

[Daniel Vetter]

On Wed, Mar 22, 2017 at 03:31:00PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter <daniel.vetter at 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 at 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?

Yeah if you're working on this already I can keep it. But you could keep
working on this also even if there's no todo entry, we're not going to
reject good ideas :-)

I'll resend with only the first sub-task removed, since that is done.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch