linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@linux-m68k.org>
To: Guenter Roeck <linux@roeck-us.net>,
	Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Richard Kuo <rkuo@codeaurora.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>,
	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: Sat, 24 Feb 2018 09:49:40 +1000	[thread overview]
Message-ID: <7da72881-2c19-9e6d-0a70-7767cab19437@linux-m68k.org> (raw)
In-Reply-To: <20180223171019.GA1125@roeck-us.net>

On 24/02/18 03:10, Guenter Roeck wrote:
> On Fri, Feb 23, 2018 at 03:43:16PM +0000, Alan Cox wrote:
>>> Regarding the older architectures I mentioned (m32r, frv, mn10300),
>>> the situation is a bit different as they don't have the problems with
>>> build testing but they do have problems with using less of the
>>> standard interfaces (syscall, timer, gpio, rtc, ...), so they do add
>>> more to the maintenance burden without the nostalgia value of
>>> some of the even older architectures (parisc, alpha, m68k, ia64)
>>> that people maintain mainly for fun.
>>
>> IMHO the magic word is 'maintain'. If someone is actively maintaining it
>> then I don't think we should care too much, if not then while the code
>> may be buildable on current systems does anyone honestly think it works
>> properly if used in anger ?
>>
> 
> FWIW, alpha and m68k are known boot with qemu (even though m68k
> generates a warning traceback with the mainline kernel).

At the very least I build every defconfig for every rc and release
kernel for m68k. I also run a ColdFire build through qemu (non-MMU)
and also run it and an MMU build on real hardware. So they are
always checked and by far mostly work - and when they don't I fix
it ASAP.

I am pretty sure Geert does similar for the traditional 68k targets.
NXP still sell ColdFire parts, so for the moment it is not dead
in terms of available silicon.

(*) I know linux-4.16-rc1 and rc2 issue a warning on boot of a
non-MMU m68k/coldfire build due to the addition of a warning by
Christoph in 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") but I haven't had a chance to track what the
exact problem is there.

Regards
Greg

  parent reply	other threads:[~2018-02-23 23:49 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
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 [this message]
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
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=7da72881-2c19-9e6d-0a70-7767cab19437@linux-m68k.org \
    --to=gerg@linux-m68k.org \
    --cc=arnd@arndb.de \
    --cc=dhowells@redhat.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --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=rkuo@codeaurora.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).