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:   Wed, 29 Dec 2021 11:03:17 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Dave Young <dyoung@...hat.com>
Cc:     "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        "H . Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        Baoquan He <bhe@...hat.com>, Vivek Goyal <vgoyal@...hat.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        kexec@...ts.infradead.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        devicetree@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        linux-doc@...r.kernel.org, Randy Dunlap <rdunlap@...radead.org>,
        Feng Zhou <zhoufeng.zf@...edance.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Chen Zhou <dingguo.cz@...group.com>,
        John Donnelly <John.p.donnelly@...cle.com>
Subject: Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to
 simplify code

On Wed, Dec 29, 2021 at 03:27:48PM +0800, Dave Young wrote:
> So I think you can unify the parse_crashkernel* in x86 first with just
> one function.  And leave the further improvements to later work. But
> let's see how Boris think about this.

Well, I think this all unnecessary work. Why?

If the goal is to support crashkernel...high,low on arm64, then you
should simply *copy* the functionality on arm64 and be done with it.

Unification is done by looking at code which is duplicated across
architectures and which has been untouched for a while now, i.e., no
new or arch-specific changes are going to it so a unification can be
as simple as trivially switching the architectures to call a generic
function.

What this does is carve out the "generic" parts and then try not to
break existing usage.

Which is a total waste of energy and resources. And it is casting that
functionality in stone so that when x86 wants to change something there,
it should do it in a way not to break arm64. And I fail to see the
advantage of all that. Code sharing ain't it.

So what it should do is simply copy the necessary code to arm64.
Unifications can always be done later, when the dust settles.

IMNSVHO.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ