linux-kernel - Re: [PATCH v3 2/2] arm64/sysreg: Convert HFGITR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Apr 2023 16:25:52 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Will Deacon <will@...nel.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Joey Gouly <joey.gouly@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] arm64/sysreg: Convert HFGITR_EL2 to automatic
 generation

On Thu, Apr 06, 2023 at 04:04:57PM +0100, Will Deacon wrote:
> On Thu, Apr 06, 2023 at 04:02:18PM +0100, Mark Brown wrote:
> > On Thu, Apr 06, 2023 at 03:46:54PM +0100, Will Deacon wrote:

> > > Can't we generate this file from the architecture xml? That would hopefully
> > > avoid typos like this and make review less tedious.

> > I agree that this seems like a sensible idea however there has
> > previously been pushback on the idea of providing tooling to do that,
> > and we would want to manually integrate the output of any such tool
> > since there are a number of cases where for legacy or usability reasons
> > we rename or combine fields.  The cases where we use a Fields block to
> > cover identical ELx versions are another issue.

> > I also note that while the XML is viewable on the web AFAICT the only
> > directly downloadable version of the architecture XML available
> > externally is in PDF format which is not entirely helpful for this
> > purpose.

> Sorry, I didn't mean to automate this in the tree, just that you could
> do it locally when you generate the patch (as I suspect this must be
> tedious for you to write out by hand too!). We've had a string of typos
> in the definitions so far, and it would be nice to take steps to avoid
> that for future changes.

Yeah, normally it's not too bad (and it can be useful to make sure
you've actually looked at the entire register definition properly) but I
did just about get annoyed enough to write something locally while doing
this register.  You could certainly get a good chunk of the way there,
especially for simple fields (enums would need manual naming IIRC) - if
it hadn't been for the pushback mentioned above combined with what's on
developer.arm.com I'd probably have got round to doing something
already.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)