[PATCH v2] arm64: Add basic JSON register parser

[Marc Zyngier]

On Mon, 06 Jan 2025 15:19:55 +0000,
Mark Brown <broonie at kernel.org> wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Thu, Jan 02, 2025 at 02:43:39PM +0000, Marc Zyngier wrote:
> > We currently populate the sysreg file by hand from the ARM ARM,
> > resulting in a bunch of errors being introduced on a regular basis.
> > While there is an XML dump of the architecture produced on a quarterly
> > basis, the license that comes attached to it excludes any sort of
> > open-source usage.
> 
> ...
> 
> > I completely expect this to quickly rewritten by people who know
> > what they are doing (I don't) and improved as we understand more
> > of the data model.
> 
> Thanks for jumping on this so quickly.

Things you do when you're drunk...

> Reviewed-by: Mark Brown <broonie at kernel.org>
> 
> to the extent I understand jq, and it seems to be doing sensible things
> for the registers I've tried it with.  This is going to be useful for
> getting started and it's helpful to see the feature dependencies.  Like
> you suggest it's a good basis for further development, even if we also
> get some other tools that won't stop this being useful.
> 
> What I was thinking with this stuff was to use something like Python and
> parse the files into data structures in memory before outputting them,

The moment you use a general purpose language, you end-up reinventing
JSON in another way, and I didn't have the courage to do that. Also,
jq feels like an exotic mix of functional programming and Forth,
something toxic enough to be irresistible.

> then we can hopefully use that for things like diffing two architecture
> versions while handling cases where we've intentionally diverged from
> how the architecture describes things. It'd be nice to have something
> that'd go through and check for updates to registers we already have
> mapped and provide an updated sysreg file.  It might however just be
> easier to use something like this and then work with sysreg files using
> text processing tools.

My current plan is somehow different: extract all the trapping
information for each register handled by KVM, and *automatically*
generate tests that check that KVM is doing the right thing. Or rather
convince someone to do that.

Then get rid of all such manually implemented tests from the kernel,
once and for all.

	M.

-- 
Without deviation from the norm, progress is not possible.