Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752110AbbFAJv2 (ORCPT ); Mon, 1 Jun 2015 05:51:28 -0400 Received: from mail-bn1bon0110.outbound.protection.outlook.com ([157.56.111.110]:41808 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751210AbbFAJvU convert rfc822-to-8bit (ORCPT ); Mon, 1 Jun 2015 05:51:20 -0400 Authentication-Results: spf=none (sender IP is 165.204.84.221) smtp.mailfrom=amd.com; arm.linux.org.uk; dkim=none (message not signed) header.d=none; X-WSS-ID: 0NP9FDD-07-58E-02 X-M-MSG: Message-ID: <556C2B0E.8000001@amd.com> Date: Mon, 1 Jun 2015 11:51:10 +0200 From: =?windows-1252?Q?Christian_K=F6nig?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russell King - ARM Linux CC: Mikko Rapeli , Krzysztof Kozlowski , , , Seung-Woo Kim , , , "Kyungmin Park" , Kukjin Kim , Subject: Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h References: <1433000370-19509-1-git-send-email-mikko.rapeli@iki.fi> <1433000370-19509-6-git-send-email-mikko.rapeli@iki.fi> <20150530164655.GM2067@n2100.arm.linux.org.uk> <556C15BA.7000909@amd.com> <20150601085605.GN2067@n2100.arm.linux.org.uk> <556C2105.2090607@amd.com> <20150601093808.GP2067@n2100.arm.linux.org.uk> In-Reply-To: <20150601093808.GP2067@n2100.arm.linux.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed X-Originating-IP: [10.224.52.127] Content-Transfer-Encoding: 8BIT X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD048;1:D3WQVC1b20wPE35xoi9Riokmn6sGQgMjpa92dN7VSwDHBFUEL+1mTLhk54x8F9wJQd5JtXinNgxsjgHDzrLpqqBC9QpqiFvRxnAKYdh2FUpmncH5L//U6dLzVlyMw2Kkq5RU4ftXi4vLzdQO9EHDezCS+yvQcvtxz0Scf1Ko80rVOUlt0kLAUhLfFJCkF1pKDfStXpaBzFi1NWNPXemNuZiD1AgVVDasHzk4vusMPEJmkwvA8uBScnvX4Bn429aRtJ4ZNTtP5XxOO+lUwsUdQA== X-Forefront-Antispam-Report: CIP:165.204.84.221;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(428002)(199003)(76104003)(24454002)(51704005)(189002)(87936001)(64706001)(65956001)(93886004)(68736005)(77156002)(62966003)(77096005)(64126003)(65806001)(46102003)(106466001)(47776003)(83506001)(80316001)(92566002)(50986999)(50466002)(86362001)(101416001)(33656002)(76176999)(87266999)(54356999)(65816999)(5001860100001)(110136002)(59896002)(105586002)(5001920100001)(5001830100001)(4001350100001)(4001540100001)(189998001)(2950100001)(36756003)(23746002)(97736004)(3940600001);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR02MB1114;H:atltwp01.amd.com;FPR:;SPF:None;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR02MB1114; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(520003)(3002001);SRVR:BY1PR02MB1114;BCL:0;PCL:0;RULEID:;SRVR:BY1PR02MB1114; X-Forefront-PRVS: 05947791E4 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2015 09:51:15.4292 (UTC) X-MS-Exchange-CrossTenant-Id: fde4dada-be84-483f-92cc-e026cbee8e96 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fde4dada-be84-483f-92cc-e026cbee8e96;Ip=[165.204.84.221];Helo=[atltwp01.amd.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR02MB1114 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2143 Lines: 45 On 01.06.2015 11:38, Russell King - ARM Linux wrote: > On Mon, Jun 01, 2015 at 11:08:21AM +0200, Christian K?nig wrote: >> Yeah, completely agree with Linus on the visibility problem and that's >> exactly the reason why we don't include in the kernel header and >> expect userspace to define the ISO types somewhere. >> >> But using the types from "include/linux/types.h" and especially including it >> into the uapi headers doesn't make the situation better, but rather worse. >> >> With this step we not only make the headers depend on another header that >> isn't part of the uapi, but also pollute the user space namespace with __sXX >> and __uXX types which aren't defined anywhere else. > 1) Header files are permitted to pollute userspace with __-defined stuff. > > 2) __[su]XX types are defined as part of the kernel's uapi. > include/uapi/linux/types.h includes asm/types.h, which in userspace > picks up include/uapi/asm-generic/types.h. That picks up > asm-generic/int-ll64.h, which defines these types. > > Moreover, this is done throughout the kernel headers _already_ (as you > would expect for a policy set 10+ years ago). > > Please, I'm not interested in this discussion, so please don't argue > with me - I may agree with your position, but what you think and what > I think are really not relevant here. If you have a problem, take it > up with Linus - I made that clear in my email. > In this case I'm fine with the changes, but I'm still not sure if that's a good idea or not. Sticking to ISO C still sounds better than doing something on our own. And it now looks a bit different than it was in 2004, stdint.h is widely adopted in userspace if I'm not completely mistaken. Anyway you're perfectly right that Linus need to decide and I'm not in the mod to argue with him either (got way to much other things to do as well). Regards, Christian. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/