From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935682Ab3DPOVb (ORCPT ); Tue, 16 Apr 2013 10:21:31 -0400 Received: from mail-lb0-f170.google.com ([209.85.217.170]:35299 "EHLO mail-lb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935534Ab3DPOVa (ORCPT ); Tue, 16 Apr 2013 10:21:30 -0400 MIME-Version: 1.0 X-Originating-IP: [188.6.195.195] In-Reply-To: References: <1366058481-21033-1-git-send-email-ccross@android.com> Date: Tue, 16 Apr 2013 16:21:28 +0200 Message-ID: Subject: Re: [PATCH] fuse: use kernel headers when __KERNEL__ is set From: Miklos Szeredi To: Colin Cross Cc: lkml , Linus Torvalds , "open list:FUSE: FILESYSTEM..." , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 15, 2013 at 11:47 PM, Colin Cross wrote: > On Mon, Apr 15, 2013 at 1:41 PM, Colin Cross wrote: >> Commit 7e98d53086d18c877cb44e9065219335184024de (Synchronize fuse >> header with one used in library) added #ifdef __linux__ around >> defines if it is not set. The kernel build is self-contained and >> can be built on non-Linux toolchains. After the mentioned commit >> builds on non-Linux toolchains will try to include stdint.h and >> fail due to -nostdinc, and then fail with a bunch of undefined >> type errors. >> >> Change the #ifdef to check for __linux__ or __KERNEL__ so that >> it uses the kernel typedefs if __KERNEL__ is set. >> >> Signed-off-by: Colin Cross >> --- >> I think this should go in v3.9, without it bare-metal toolchains >> that don't define __linux__ will fail to compile the kernel, and >> cross-compiles from non-linux hosts will probably also fail. > > Miklos, I see Arve sent an equivalent patch to you a month ago > (https://lkml.org/lkml/2013/3/11/620), and I agree with his response > to your question (checking for __linux__ and __KERNEL__ is better than > just checking for __KERNEL__ if you want this header to be used in > userspace builds on linux targets). And I still disagree. Why should userspace use the linux internal header when there's a perfectly good standard header that it can use? Patch committed and pushed to for-next and for-linus. I'll push to Linus tomorrow. Thanks, Miklos