linux-kernel - Re: [PATCH 7/8] mips: convert to generic builtin command line

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] [day] [month] [year] [list]

Date:   Fri, 12 Oct 2018 21:01:49 +0000
From:   Paul Burton <paul.burton@...s.com>
To:     Maksym Kokhan <maksym.kokhan@...ballogic.com>
CC:     Ralf Baechle <ralf@...ux-mips.org>,
        James Hogan <jhogan@...nel.org>,
        Daniel Walker <dwalker@...o99.com>,
        Daniel Walker <danielwa@...co.com>,
        Andrii Bordunov <aborduno@...co.com>,
        Ruslan Bilovol <rbilovol@...co.com>,
        "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/8] mips: convert to generic builtin command line

Hi Maksym,

On Mon, Oct 08, 2018 at 08:56:25PM +0300, Maksym Kokhan wrote:
> On Thu, Sep 27, 2018 at 9:56 PM Paul Burton <paul.burton@...s.com> wrote:
> > It also doesn't allow for the various Kconfig options which allow us to
> > ignore some of the sources of command line arguments, nor does it honor
> > the ordering that those existing options allow. In practice perhaps we
> > can cut down on some of this configurability anyway, but if we do that
> > it needs to be thought through & the commit message should describe the
> > changes in behaviour.
> 
> Yes, this generic command line implementation lacks some of the
> features, existing in the current mips command line code, and we
> are going to expand functionality of generic command line code to
> correspond it, but it would be easier to initially merge this simple
> implementation and then develop it step by step.

The problem occurs if merging the simple implementation breaks currently
working systems. That is a no-go, and that is what I believe will happen
with the current patchset.

"Knowingly break it now & say we'll fix it later" is not an acceptable
approach.

Thanks,
    Paul