linux-kernel - Re: [PATCH 1/8] staging: android: binder: replace explicit size types

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: <5162B72A.4040009@arm.com>
Date:	Mon, 08 Apr 2013 13:25:14 +0100
From:	Serban Constantinescu <Serban.Constantinescu@....com>
To:	Greg KH <gregkh@...uxfoundation.org>,
	Arve Hjønnevåg 
	<arve@...roid.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Android Kernel Team <kernel-team@...roid.com>,
	John Stultz <john.stultz@...aro.org>,
	Dave Butcher <Dave.Butcher@....com>
Subject: Re: [PATCH 1/8] staging: android: binder: replace explicit size types

On 06/04/13 07:00, Greg KH wrote:
> On Fri, Apr 05, 2013 at 04:17:47PM -0700, Arve Hjønnevåg wrote:
>> On Thu, Apr 4, 2013 at 5:32 AM, Serban Constantinescu
>> <serban.constantinescu@....com> wrote:
>>>
>>> Since the binder driver uses both uint32_t and unsigned int any further
>>> kernel changes will be difficult to read. This patch fixes the inconsistent
>>> types usage.
>>>
>>
>> Would it make more sense to only change the types that need to be
>> larger on a 64 bit system?
>
> I agree.  You are also changing the type from explicit to "unexplicit",
> the exact opposite from what I would be expecting to see here.  Why?

I have changed the types used so that they seem consistent throughout 
the driver(uint32_t is used in some of the internal structures and some 
of the function prototypes). Changing these types to kernel explicit 
types would have meant that we would have the same inconsistency for u32 
types.

We can live without this patch and I can take a look at modifying the 
function prototypes, internal structures and kernel/userspace 
interaction to use explicit kernel types it that is preferred.

Thanks for your feedback,
Serban

--
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/