[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CY4PR1201MB0120A3C58405DD60FF6B4359A10A0@CY4PR1201MB0120.namprd12.prod.outlook.com>
Date: Thu, 16 May 2019 17:44:44 +0000
From: Alexey Brodkin <Alexey.Brodkin@...opsys.com>
To: Vineet Gupta <Vineet.Gupta1@...opsys.com>
CC: "paltsev@...opsys.com" <paltsev@...opsys.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
Subject: RE: [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma access
permission code
Hi Vineet,
> -----Original Message-----
> From: Vineet Gupta <vgupta@...opsys.com>
> Sent: Thursday, May 16, 2019 8:38 PM
> To: Eugeniy Paltsev <paltsev@...opsys.com>
> Cc: paltsev@...opsys.com; linux-kernel@...r.kernel.org; Alexey Brodkin <abrodkin@...opsys.com>; linux-
> snps-arc@...ts.infradead.org
> Subject: Re: [PATCH 4/9] ARC: mm: do_page_fault refactor #3: tidyup vma access permission code
>
> On 5/16/19 10:24 AM, Eugeniy Paltsev wrote:
> >> + unsigned int write = 0, exec = 0, mask;
> > Probably it's better to use 'bool' type for 'write' and 'exec' as we really use them as a boolean
> variables.
>
> Right those are semantics, but the generated code for "bool" is not ideal - given
> it is inherently a "char" it is promoted first to an int with an additional EXTB
> which I really dislike.
> Guess it is more of a style thing.
In that sense maybe think about re-definition of "bool" type to 32-bit one
for entire architecture and get that benefit across the entire source tree?
-Alexey
Powered by blists - more mailing lists