[PATCH v1 0/11] drm: move dri1 drivers to drm/dri1/

[Thomas Zimmermann]

Hi Javier

Am 18.07.22 um 11:46 schrieb Javier Martinez Canillas:
> Hello Thomas,
> 
> On 7/18/22 08:56, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 16.07.22 um 20:17 schrieb Sam Ravnborg:
>>> While discussing the way forward for the via driver
>>> Javier came up with the proposal to move all DRI1 drivers
>>> to their own folder.
>>>
>>> The idea is to move the old DRI1 drivers so one do not
>>> accidentally consider them modern drivers.
>>>
>>> This set of patches implements this idea.
>>>
>>> To prepare the move, DRIVER_LEGACY and CONFIG_DRM_LEGACY
>>> are both renamed to *_DRI1. This makes it more obvious
>>> that we are dealing with DRI1 drivers, as we have
>>> a lot of other legacy support.
>>>
>>> The drivers continue to have their own sub-directory
>>> so the driver files are not mixed with the core files
>>> which are copied in the last commit.
>>>
>>> The DRI1 specific part of drm/Kconfig is likewise pulled
>>> out and located in the dri1/ folder.
>>>
>>> Feedback welcome!
>>
>> To be honest, I still don't like this rename. Especially in the case of
>> via, which has a KMS driver coming up. It will now have an include
>> statement that crosses several levels in the directory hierarchy. And
> 
> That could be avoided by moving drivers/gpu/drm/via/via_3d_reg.h and other
> header files to include/drm/via_3d_reg.h for example. Other drivers (i.e:
> i915) do the same for headers that are shared across different subsystems.
>   
>> what about the other DRI1 drivers? If we ever get KMS drivers for those,
>> do we want to move some header files back into their original locations?
> 
> I believe for these we could also move them to include/drm/ if needed.

That pollutes these shared directories at the expense of everyone else. 
If anything, we want to move files out of the shared include paths.

It would make sense to me if we'd have two distinct drivers. But here, 
the new and the old driver is really just one DRM driver with badly 
organized source code.

>   
>> Patches 1 and 2 look reasonable to me. The other driver patches have
>> basically zero upside IMHO.
>>
> 
> I disagree with the zero upside. It may be that the trade offs are not
> worth it but there are upsides of having all DRI1 drivers and core DRI1
> bits in the same place. It makes grep-ing and reading files easier if
> one doesn't care about legacy DRI1 drivers.

The grep-ability is a minor point. It does come up, but is usually 
sorted out easily.

If we want to improve grep output, we should consider applying Sam's 
via_dri1 changes to all DRI1 drivers. So we'd end up with a single 
mga_dri1.c, tdfx_dri1.c, savage_dri1.c and so on. If the core/helper 
code is also in a _dri1-named source file, grep runs can filter out 
those filenames.

> 
> Also, it would ease the removal of this if we ever get rid of them.

We're not going to remove them all at once. And if we'd do, the actual 
work would be in removing the DRI1 code from the DRM core. There's code 
in the core that does runtime tests for DRIVER_LEGACY and is partially 
shared with KMS drivers (mostly in VBLANK handling IIRC).  Removing the 
driver directories is trivial.

>   
>> In the case of moving the core files into dri1/, the resulting Makefile
>> rule looks really ugly. I'd suggest to move all code into a separate
> 
> Maybe this could be sorted by splitting the DRI1 core bits in a separate
> drm_dri1.ko module?

The dri1 core files cannot be in a separate module as they are linked 
with other core stuff. It would result in dependency cycles IIRC.

> 
>> file drm_dri1.c and be done with it.  For something more elaborate,
>> there could by drm_dri1.c and drm_dri1_helper.c, where the latter
>> contains all DRI1 code that is only used by the drivers.
>>
> 
> That would be an improvement but IMO moving them into a different dir
> as Sam did would be preferable. What would be the upside of having it
> in drivers/gpu/drm instead? Just to avoid the Makefile rule to have a
> dri1/ prefix in the included object files ?

Makefile readability is important and our existing ones could be better, 
but that's a minor point.

Putting everything into a single file gets the legacy code out of the 
way, benefits grepping and is faster to build. In the case of a 
core/helper split, it would further align with the overall design of the 
DRM sub-system.

> 
> Regardless of this discussion, I think that at the very least we should
> rename the Kconfig symbols to CONFIG_DRM_DRI1_* even if DRI1 drivers are
> kept in drivers/gpu/drm/ instead of moved to a drivers/gpu/drm/dri1/ dir.
> 

Agreed.

Best regards
Thomas

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220718/2c932180/attachment.sig>