[PATCH] Revert "drm/xe/devcoredump: Add ASCII85 dump helper function"

[Lucas De Marchi]

On Fri, Dec 13, 2024 at 03:24:59PM +0000, Jose Souza wrote:
>On Fri, 2024-12-13 at 07:10 -0800, José Roberto de Souza wrote:
>> On Fri, 2024-12-13 at 08:38 -0600, Lucas De Marchi wrote:
>> > On Fri, Dec 13, 2024 at 09:12:52AM -0500, Rodrigo Vivi wrote:
>> > > We do not break userspace.
>>
>> There is other patch that also breaks Mesa parser:
>>
>> drm/xe/devcoredump: Improve section headings and add tile info
>>
>> > >
>> > > This reverts commit ec1455ce7e35a31289d2dbc1070b980538698921.
>> >
>> > But we have users calling this function.... the revert is not so simple.
>> > I think we need to revert the functionality rather than reverting all
>> > the patches, otherwise it will cause a lot of headaches.
>> >
>> > I propose we go with:
>> >
>> > a) drop the \n that broke mesa and merge that with cc stable.
>> >
>> > b) move back the entry to the previous section that broke mesa and cc
>> >     stable.
>> >
>> >     José, would it be ok to merge a patch in mesa and port that
>> >     to mesa stable that simply looks at 2 possible sections? Or even
>> >     drop the section checks... ?
>
>But if Xe KMD is reverting the patch that changed the hwctx section why would Mesa need to also parse the new(future to be reverted) section?

first is to undo the damage, with 0 changes in mesa. We do that first and
*then* we agree on what's possible to do to accomodate the 2 parsers we
have.

If we can get something in mesa to work that is backward compatible (i.e. the
changed parser is able to parse both before and after the kernel change),
then it could be considered to a mesa stable and the kernel side
changed.

Lucas De Marchi

>I could CC the Mesa stable but it would not be picked to all Mesa versions with the devcoredump parser.
>
>
>> >
>> > c) settle on one of the possible solutions for \n that were presented in
>> >     this discussion.  I think the sanest one is that a space in the end of a
>> >     line printing ascii85 would signify a continuation marker.  But merging
>> >     (a) means we have time to discuss and adjust if needed.
>> >
>> > After the dust settles we may think of a better way to evolve the
>> > devcoredump format so it doesn't cause breakages in future updates.
>> >
>> > Lucas De Marchi
>>
>