On 16.11.2017 21:57, Dave Airlie wrote:
> On 16 November 2017 at 14:59, Linus Torvalds
> <[email protected]> wrote:
>> On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie <[email protected]> wrote:
>>>
>>> There is some code touched on sound/soc, but I think the sound tree
>>> should have the same commits from the same base,so this may luck different
>>> if you pulled it as I generated my pull request a couple of days ago. Otherwise
>>> the highlights are below.
>>
>> I'm more curious about (and disgusted by) this one:
>>
>> include/dt-bindings/msm/msm-bus-ids.h
>>
>> wtf? It's full of defines that aren't actually used anywhere. Which
>> is just as well, since it doesn't seem to be included from anything
>> either.
>>
>> There's something odd about drm people. You guys like these completely
>> insane generated header files, and you seem to be populating the whole
>> tree with this odd and diseased notion of "generated header files are
>> cool".
>>
>> Is somebody getting paid by line of code?
>
> It would still cost less than transcribing each register and all it's fields by
> hand from pdfs generated from the same place.
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've been pondering doing this in Mesa for radeonsi for quite some time
now. Given that the Mesa header style is different from the kernel
header style, this could help reduce our IP review load going forward,
and would have some other neat benefits as well.
Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
From 1584347654276161190@xxx Fri Nov 17 20:47:46 +0000 2017
X-GM-THRID: 1584194585945726173
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Fri, Nov 17, 2017 at 4:51 AM, Nicolai Hähnle <[email protected]> wrote:
>
> 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 now.
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