Re: [PATCH v4 6/7] disas: mips: Add micromips R6 disassembler - infrastructure and 16-bit instructions

[Richard Henderson <richard.henderson@linaro.org>]

On 1/25/20 12:22 AM, Aleksandar Markovic wrote:
> 
> 
> On Saturday, January 25, 2020, Richard Henderson <richard.henderson@linaro.org
> <mailto:richard.henderson@linaro.org>> wrote:
> 
>     On 1/24/20 1:38 PM, Aleksandar Markovic wrote:
>     > On Friday, January 24, 2020, Richard Henderson
>     <richard.henderson@linaro.org <mailto:richard.henderson@linaro.org>
>     > <mailto:richard.henderson@linaro.org
>     <mailto:richard.henderson@linaro.org>>> wrote:
>     >     The thing I'm concerned about here is any future maintenance of this
>     file.  One
>     >     would surely prefer to edit the original decodetree input than this
>     output.
>     >
>     >
>     > Here is the deal: This dissasembler is meant to reflect the
>      documentation of a
>     > particular ISA, and as the documentation largely stays constant (except
>     adding
>     > some insignificant errata), the disassembler will stay virtually constant, we
>     > wouldn't like even to touch it, and we like it this way.
> 
>     No, this is neither right nor proper.
> 
>     To review the code in this form is significantly harder than in its decodetree
>     form.  That is in fact the whole point of the decodetree form: otherwise we'd
>     still be writing these sorts of parsers by hand.
> 
>     While there's no license on this new file (another problem), if as assumed this
>     is GPL 2+, then you are in violation of the GPL.  From section 3:
> 
>       # The source code for a work means the preferred form of
>       # the work for making modifications to it.
> 
>     You cannot with a straight face claim that the generated c is the preferred
>     form for making modifications.
> 
>     Finally, suppose we improve decodetree.py, so that it produces code with which
>     the compiler produces better code, for some metric of better.  We would want
>     this disassembler to benefit as well.
> 
> 
> I think you got some things upside-down. A tool developent and usage should be
> driven by the needs of users of a tool, and not dictated by the author. Users
> should be free to use the tool in any way they seem suitable, including its
> modification.

That's exactly right, provided that by "tool" you mean QEMU and by "users" you
mean everyone downstream of us.

Let me state for the record that I object to this generated file being merged
in this form, for the reasons I stated above.


r~