linux-kernel - Re: [PATCH 1/2] dt-bindings: pci: convert faraday,ftpci100 to yaml

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:   Fri, 7 May 2021 12:51:39 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Corentin Labbe <clabbe@...libre.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        Hans Ulli Kroll <ulli.kroll@...glemail.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: pci: convert faraday,ftpci100 to yaml

On Thu, May 6, 2021 at 10:34 PM Bjorn Helgaas <helgaas@...nel.org> wrote:

> I think it's nicer when content changes are in a separate patch from
> format conversion patches.  Otherwise it's really hard to see the
> content changes in the patch.
>
> Maybe a preliminary patch could fix whatever is actually broken?
>
> Rob suggested a bunch of things that could be dropped.  Maybe those
> could be removed in a second preliminary patch before the conversion?
> Or maybe the removals are only possible *because* of the conversion?
> I'm not a yaml expert.

A bit of taste is involved. The old .txt bindings are for processing
by human brain power. Those lack regular syntax and strictness
because brains are designed for evolved natural languages.

The YAML on the other hand is a chomsky type-3 strict regular
language and the .yaml file (and includes) defines this strict regular
grammar and as such admits less mistakes. The upside is that
it enforces some order.

In the process of moving to YAML we often discover a slew of
mistakes and the initiative often comes with the ambition to add
or modernize something.

In this case I wouldn't care with stepwise fixing because the
platform is modernized by a handful of people who all know
what is going on, so there is noone to confuse other than the
subsystem maintainer and the result will end up in the same
kernel release anyway.

Yours,
Linus Walleij