linux-kernel - Re: [PATCH 2/4] x86: Move instruction decoder data into header

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]

Message-ID: <534D412A.30504@oracle.com>
Date:	Tue, 15 Apr 2014 10:24:42 -0400
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
CC:	vegard.nossum@...cle.com, penberg@...nel.org,
	jamie.iles@...cle.com, hpa@...or.com, mingo@...hat.com,
	tglx@...utronix.de, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] x86: Move instruction decoder data into header

On 04/14/2014 11:10 PM, Masami Hiramatsu wrote:
> (2014/04/15 11:28), Sasha Levin wrote:
>> On 04/14/2014 09:41 PM, Masami Hiramatsu wrote:
>>> (2014/04/15 2:44), Sasha Levin wrote:
>>>>> Right now we generate data for the instruction decoder and place it
>>>>> as a code file which gets #included directly (yuck).
>>>>>
>>>>> Instead, make it a header which will also be usable by other code
>>>>> that wants to use the data in there.
>>> Hmm, making the generated data into a header file may clone
>>> the data table instances for each object file. Since the inat
>>> table is not so small, I think we'd better just export the tables.
>>
>> The tables are defined as static, so the compiler drops them
>> once it detects they are not used.
> 
> No, I meant that if the table is used in the different object files,
> will the copies of the tables be compiled in several different
> instances?

That's true, but there was and after this patchset there will still
be only one user that touches the table. I also doubt that more users
will appear since users of the table should be going through the API
and not touching it directly, so I don't think it should be a concern
at this point.

> And I can't see the part which makes the tables static in this patch...

Right, it sneaked to the next patch in this patchset. I'll pull it
into this one in the next version.

>> I feel it would be easier to let the compiler do it's job rather
>> than do optimizations we don't need to do and which will complicate
>> the code quite a bit.
> 
> I haven't tend to optimize it, but just encapsulate it, to hide from other parts.

We could hide it under #ifdef, but that wouldn't change anything for
the user or for the generated code itself.

Splitting code generation into two different files would complicate
everything IMO.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/