Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <26729c32-cfd6-82e0-b370-a46ca951adea@gmail.com>
References: <CAPM=9tz-HT7ynGrzXwtnaDcj+0MumLBj1Z8VUB+v6W=9P_eaNA@mail.gmail.com>
 <CA+55aFzCfbqEn=VSn8rhcLm9sTqaRTCQ3AgxhZA2xuP-P3QFBA@mail.gmail.com>
 <CAPM=9txQo2yAe1nwUtyYETbGdgjY9GHgmXYYC=1ojyydUb72HQ@mail.gmail.com> <26729c32-cfd6-82e0-b370-a46ca951adea@gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 17 Nov 2017 08:57:53 -0800
Message-ID: <CA+55aFz4ZeXeu_bfiKGLJhqa8Z2zsvL9Xd+oBSYo-gsdLSSGfA@mail.gmail.com>
Subject: Re: [git pull] drm for v4.15
To:     =?UTF-8?Q?Nicolai_H=C3=A4hnle?= <nhaehnle@gmail.com>
Cc:     Dave Airlie <airlied@gmail.com>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Nov 17, 2017 at 4:51 AM, Nicolai H=C3=A4hnle <nhaehnle@gmail.com> w=
rote:
>
> This raises the question of how people feel about putting the source
> database into the kernel (most likely as XML in our case) and
> auto-generating the headers from there instead.

I suspect that at  least in some cases, the "source" database may be a
bit too sensitive. It may have various comments about errata, and may
even be part of the whole hardware build system (ie it might be munged
from verilog/vhdl)

> I've been pondering doing this in Mesa for radeonsi for quite some time n=
ow.

What personally annoys me most about a lot of generated header files
(not all, but a _lot_) is that exactly because they are generated,
they are often inexcusably stupid.

So say that you have a block of status registers, all of which have a
certain base pattern. Every single auto-generated header file I have
ever seen takes the brute-force approach of just enumerating them all
separately as independent things.

Which makes the header file a huge mess of repeated almost-identical
register defines.

But it's not even the _size_ of the header file that then annoys me,
it's that it's not just big, but inflexible. Often, on a source level,
you may actually be in the situation where you get an index to the
thing, and then you do

    switch (index) {
    case X:
        access_using(REGISTERX_DEFINITION);
    case Y:
        access_using(REGISTERY_DEFINITION);
   ...

or similar. When a _smarter_ auto-generated file would actually take
advantage of the language features (whether preprocessor or dynamic),
and actually allow for

    access_using(REGISTER_DEFINITION(index))

instead.

Or - a variation of the above - it's not that the register definitions
for _one_ core have that kind of regularity, but you have it for a
while family of products, and because you autogenerate, you
auto-generate the stupid "repat the exact same thing with different
names" model, and then you have (instead of the index thing) you have
the "chip family" thing that you switch on.

To see the effects of this, I picked something at random from one of
those huge AMD header files.

I swear. It was entirely at random, and the first thing I picked. Do this:

    git grep PCIE_UNCORR_ERR_MASK

and tell me that there isn't any room for making these things smarter.

Btw, not a single of those defines are actually _used_.  Again, that
pattern was entirely randomly picked from the largest header file we
have.

People say "it's a ton of work to do it by hand". They'd be right. I'm
not saying you should do it by hand. But "automation" does not always
need to mean "completely mindlessly stupid" either.

                 Linus

From 1584291155511467858@xxx Fri Nov 17 05:49:44 +0000 2017
X-GM-THRID: 1584194585945726173
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread