From: Richard Kuo <rkuo@codeaurora.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-hexagon@vger.kernel.org, Chen Liqin <liqin.linux@gmail.com>,
Lennox Wu <lennox.wu@gmail.com>,
Guan Xuetao <gxt@mprc.pku.edu.cn>,
Guenter Roeck <linux@roeck-us.net>,
Al Viro <viro@zeniv.linux.org.uk>,
James Hogan <jhogan@kernel.org>,
linux-metag@vger.kernel.org, Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>,
openrisc@lists.librecores.org,
David Howells <dhowells@redhat.com>
Subject: Re: Removing architectures without upstream gcc support
Date: Fri, 23 Feb 2018 11:15:43 -0600 [thread overview]
Message-ID: <20180223171543.GA3780@codeaurora.org> (raw)
In-Reply-To: <CAK8P3a3r=3wDtqV5feLUT-hOkE+9yWOLjLVm+nejqdaN7MtMFw@mail.gmail.com>
On Thu, Feb 22, 2018 at 11:43:10PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 22, 2018 at 8:17 PM, Richard Kuo <rkuo@codeaurora.org> wrote:
> > On Thu, Feb 22, 2018 at 04:45:06PM +0100, Arnd Bergmann wrote:
> >> * Hexagon is Qualcomm's DSP architecture. It is being actively used
> >> in all Snapdragon ARM SoCs, but the kernel code appears to be
> >> the result of a failed research project to make a standalone Hexagon
> >> SoC without an ARM core. There is some information about the
> >> project at https://wiki.codeaurora.org/xwiki/bin/Hexagon/ and
> >> https://unix.stackexchange.com/questions/246243/what-is-was-the-qualcomm-hexagon-comet-board
> >> There is a port to gcc-4.5 on the project page, which is evidently
> >> abandoned, but there is an active upstream LLVM port that is
> >> apparently used to build non-Linux programs.
> >> I would consider this one a candidate for removal as well, given that
> >> there were never any machines outside of Qualcomm that used this,
> >> and they are no longer interested themselves.
> >
> > It's difficult for me to speak to the decisions as I can understand
> > your point of view, but maybe I can speak to some of the status.
> >
> > We still use the port internally for kicking the tools around and other
> > research projects. As you noticed we're not doing gcc anymore; we're
> > using LLVM for both kernel and userspace. Yes there have been some
> > caveats but it does work within confines.
> >
> > Time is unfortunately just limited for me to upstream some of my kernel
> > fixes and cleanups, and there are some things that just haven't shown
> > up externally yet.
> >
> > However, as James Hogan mentioned, having it in the tree really has been
> > useful because it gets included in the various upstream changes and
> > fixes, which we appreciate.
> >
> > So hopefully this will help inform the decision a little better.
> >
> > If you have any other questions please let me know.
>
> Thanks for the clarification! Since you are the maintainer and you
> still consider the port useful, I don't see how anyone else would be
> in a position to demand it to be removed, so we should keep it
> around until you want it gone.
>
> I still have a few questions:
>
> - Any idea how we would find out of the status ever changes? E.g. if
> you decide at some point that you don't find the latest Linux useful
> any more for your internal work, would you send a patch for removal?
Yes, we can definitely notify everyone if this happens.
> - How do I build an llvm based toolchain for Hexagon? Do I need patches
> on top of the llvm-6 release branch? Where can I find the corresponding
> binutils-2.30 sources?
The Hexagon LLVM tools available from Qualcomm should have an ABI switch
that's supposed to work for this:
-target hexagon-unknown-linux
Admittedly I haven't tried that one. I'm unsure about the full upstream
status; I'll check on that, but I think the sketchiest component out of
that bunch is currently going to be the linker.
Let me do some checking on all this the next couple of days and get
a better answer.
Thanks,
Richard Kuo
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2018-02-23 17:15 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 15:45 Removing architectures without upstream gcc support Arnd Bergmann
2018-02-22 16:02 ` Christoph Hellwig
2018-02-22 16:19 ` Arnd Bergmann
2018-02-22 17:14 ` Max Filippov
2018-02-22 18:04 ` Christoph Hellwig
2018-02-23 11:37 ` Arnd Bergmann
2018-02-28 8:59 ` Florian Weimer
2018-02-22 16:07 ` Lennox Wu
2018-02-22 16:28 ` James Hogan
2018-02-22 16:34 ` Arnd Bergmann
2018-02-22 19:17 ` Richard Kuo
2018-02-22 22:43 ` Arnd Bergmann
2018-02-23 17:15 ` Richard Kuo [this message]
2018-02-28 2:06 ` Richard Kuo
2018-02-28 8:37 ` Arnd Bergmann
2018-03-03 1:43 ` Richard Kuo
2018-02-22 23:48 ` Guenter Roeck
2018-02-23 10:32 ` Arnd Bergmann
2018-02-23 12:09 ` Andy Shevchenko
2018-02-23 12:20 ` Arnd Bergmann
2018-02-23 14:32 ` Guenter Roeck
2018-02-23 15:43 ` Alan Cox
2018-02-23 17:10 ` Guenter Roeck
2018-02-23 18:19 ` Al Viro
2018-02-23 19:32 ` James Bottomley
2018-02-23 21:34 ` Adam Borowski
2018-02-24 4:04 ` Guenter Roeck
2018-02-24 21:55 ` Guenter Roeck
2018-02-25 19:39 ` [OpenRISC] " Richard Henderson
2018-02-23 23:49 ` Greg Ungerer
2018-02-25 20:28 ` Alan Cox
2018-02-25 22:50 ` Pavel Machek
2018-02-24 0:15 ` Florian Fainelli
2018-02-26 8:26 ` Arnd Bergmann
2018-02-26 22:11 ` Eric W. Biederman
2018-02-25 15:43 ` [OpenRISC] " Philipp Wagner
2018-02-26 8:00 ` Arnd Bergmann
2018-02-26 12:10 ` Philipp Wagner
2018-02-26 15:24 ` whitequark
2018-03-09 14:00 ` Xuetao Guan
-- strict thread matches above, loose matches on Subject: below --
2018-03-09 14:18 Guan Xuetao
2018-03-09 14:33 ` Arnd Bergmann
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=20180223171543.GA3780@codeaurora.org \
--to=rkuo@codeaurora.org \
--cc=arnd@arndb.de \
--cc=dhowells@redhat.com \
--cc=gxt@mprc.pku.edu.cn \
--cc=jhogan@kernel.org \
--cc=jonas@southpole.se \
--cc=lennox.wu@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-metag@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=liqin.linux@gmail.com \
--cc=openrisc@lists.librecores.org \
--cc=shorne@gmail.com \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).