From: Arnd Bergmann <arnd@arndb.de>
To: Nishanth Menon <nm@ti.com>
Cc: linaro-dev@lists.linaro.org,
dri-devel <dri-devel@lists.freedesktop.org>,
Paul Sokolovsky <paul.sokolovsky@linaro.org>
Subject: Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.
Date: Wed, 17 Apr 2013 12:43:49 +0200 [thread overview]
Message-ID: <201304171243.49854.arnd@arndb.de> (raw)
In-Reply-To: <20130416194857.GA3385@kahuna>
On Tuesday 16 April 2013, Nishanth Menon wrote:
> On 12:50-20130416, Arnd Bergmann wrote:
> > On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > > index 8d1e2bb..73a99e4 100644
> > > > --- a/include/uapi/drm/drm.h
> > > > +++ b/include/uapi/drm/drm.h
> > > > @@ -36,7 +36,7 @@
> > > > #ifndef _DRM_H_
> > > > #define _DRM_H_
> > > >
> > > > -#if defined(__linux__)
> > > > +#if defined(__KERNEL__) || defined(__linux__)
> > > >
> > > > #include <linux/types.h>
> > > > #include <asm/ioctl.h>
> >
> > This is still completely bogus, the __KERNEL__ symbol has no significance here.
> > Either make the compiler define __linux__, or remove this #ifdef completely.
> >
> Searching the v.39-rc7 tag, and greping for _linux_ a few interesting
> list pops up. (pruned):
> arch/arc/Makefile:cflags-y += -mA7 -fno-common -pipe -fno-builtin -D__linux__
> arch/h8300/Makefile:KBUILD_CFLAGS += -D__linux__
> arch/hexagon/Makefile:KBUILD_CFLAGS += -ffixed-$(TIR_NAME) -DTHREADINFO_REG=$(TIR_NAME) -D__linux__
> arch/score/Makefile: -D__linux__ -ffunction-sections -ffreestanding
> arch/xtensa/Makefile:KBUILD_CFLAGS += -ffreestanding -D__linux__
> ^^ these architectures seem to bypass the pain entirely by defining
> __linux__
Right, that seems like a reasonable approach when the compilers are actually known
to be compatible.
> arch/mips/include/uapi/asm/sgidefs.h:#ifndef __linux__
On MIPS, they are not. If you are building a Linux kernel with a gcc that
was targetted at another ABI, the system call interface may change, so they
forbid that here.
> drivers/gpu/drm/radeon/radeon_cp.c:#ifdef __linux__
> {snip}
> drivers/scsi/aic7xxx/aic7770.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aic79xx.h:#ifndef __linux__
> {snip}
> drivers/scsi/aic7xxx/aic79xx_core.c:#ifdef __linux__
> {snip}
> drivers/scsi/aic7xxx/aic79xx_pci.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aic7xxx.h:#ifndef __linux__
> drivers/scsi/aic7xxx/aic7xxx.h:#ifndef __linux__
> drivers/scsi/aic7xxx/aic7xxx_93cx6.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aic7xxx_core.c:#ifdef __linux__
> {snip}
> drivers/scsi/aic7xxx/aic7xxx_pci.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm.h:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm_scan.l:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__
> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__
> drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__))
> drivers/staging/ced1401/machine.h:#if (defined(__linux__) || defined(_linux) || defined(__linux)) && !defined(LINUX)
These are all drivers that are shared with another OS, or used
to be. In most of them, we can probably just remove the
#else path, since I don't think they are getting synchronized
any more.
> include/acpi/platform/acenv.h:#if defined(_LINUX) || defined(__linux__)
The acpi header files are maintained outside of Linux and are kept
OS-independent.
> include/linux/coda.h:#if defined(__linux__)
> include/uapi/drm/drm.h:#if defined(__linux__)
> include/uapi/linux/coda.h:#if defined(__linux__)
> include/uapi/linux/fuse.h:#ifdef __linux__
In case of coda, we should not need to care any more, that header just
got broken by the uapi-split for other operating systems.
The drm.h and fuse.h header files are in theory still kept
OS-agnostic and are actively maintained.
> And then we have the following as well..
> fs/ext4/ext4.h:#if defined(__KERNEL__) || defined(__linux__)
This seems to have been copied from the ext2 utils. The ext2/ext3
versions of this file don't have support for other operating systems.
> Trying out a few different prebuilt compilers I had around, I see:
> http://pastebin.com/bTVDLTb1
>
> So, is our approach just to use __linux__ for builds? I am trying to
> understand rationale behind why #include <linux/types.h> #include <asm/ioctl.h>
> would want __linux__ and why __KERNEL__ check is un-wanted.
> Ofcourse, I cant comment about the "One of the BSDs" in else options..
> and why we'd like to keep it around in kernel :)
We might be in a similar situation on ARM that we are in on MIPS. For
instance, there are some compilers that are targetting (old) Android
that have a slightly different ABI, and building a kernel with those
results in a system call ABI that is incompatible with user space built
with a standard compiler. The safest approach is probably to bail
out early if __linux__ is not set, and force anyone that wants to use
a strange compiler to set the macro manually.
Arnd
next prev parent reply other threads:[~2013-04-17 10:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-12 23:28 [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain Nishanth Menon
2013-04-16 3:15 ` Dave Airlie
[not found] ` <1365809306-1323-1-git-send-email-nm-l0cyMroinI0@public.gmane.org>
2013-04-16 9:48 ` Paul Sokolovsky
2013-04-16 10:50 ` Arnd Bergmann
2013-04-16 19:48 ` Nishanth Menon
2013-04-17 10:43 ` Arnd Bergmann [this message]
[not found] ` <201304171243.49854.arnd-r2nGTMty4D4@public.gmane.org>
2013-04-17 11:13 ` Rob Clark
2013-04-17 10:55 ` Jon Medhurst (Tixy)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201304171243.49854.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-dev@lists.linaro.org \
--cc=nm@ti.com \
--cc=paul.sokolovsky@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.