From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 120C6C43331 for ; Mon, 11 Jan 2021 14:57:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD53B225AC for ; Mon, 11 Jan 2021 14:57:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388988AbhAKO4v (ORCPT ); Mon, 11 Jan 2021 09:56:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388990AbhAKO4u (ORCPT ); Mon, 11 Jan 2021 09:56:50 -0500 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EF38C0617BF for ; Mon, 11 Jan 2021 06:55:26 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id b9so60201ejy.0 for ; Mon, 11 Jan 2021 06:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fkb+6kHcBYmIX1rA4Q3FeNq39va9LRsa50OKmyScf2g=; b=StzTmugQK+QsKVdCg08VrJTu0InftAnNTeBn1dPFsxCkTHuZnBMqpjVl1j2zpHwIKA kh07HCvlA24asTJhfCOBi+zXMkN/j//P+jqlAF3G9XlwOOklB8kfWHqPXmB4NcCW3qvp 8c+EXmRLkhgt20qosv11KJAZ6tQjoomPnpJmUqQrGTWhpqzQuLJJLtPkwPqGsbykFZEN 56LWdCUy5mExsK2nG0/GGikEooSR70bJpFhBlwl+4hXNBcn+Xl732u9omU7GYbMNZ+od lHAlEnbtMiZOkj06Reg/2m1GX4cGuXUBTKman8nyXquRKYyUEQbZKzMQWERthfTjkqzM jGzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fkb+6kHcBYmIX1rA4Q3FeNq39va9LRsa50OKmyScf2g=; b=rnC8BpJ7DtOraKIbDPBPXkQOD5iXov3OvZxqgH6R8LNMZzDdpS4sTs9IYUbU7Biz9m Heh96V3FnpFa+0fBaa5DgEHYhZIQE7hb5ugqLOivzaRBThpeYcedGisDDeAyjyYi/vX1 PTgDqLCsFPu+Q5r/cHdRsE6FhO9VoLxZdFf4iGzBqdBEZpjIi+CjgL255Env61AfcIxW Qajco+I+XgXryQMT1jSAokBZmKjQ1URuhyJ2I+rdZ+QiTRzBwFLkqBrJB6+/8eq1NqEX ImB3O7u08z5ubWuDQeXKw4+rwcT3QRGZnMy/ktgVMFTBXXqnr5gT5CYU6btRn7+5VDIo pfvw== X-Gm-Message-State: AOAM531eTn6HjKU4pud9xGp8G3/A4dWPxHstRNrAk0NAikA/7eaPHQ6G Q7ESWVnG273R4lhhrc1p3V370lSse2GfaBTWA5k= X-Google-Smtp-Source: ABdhPJw918GbC6QuBafyHDaYJK5elbD1hwsTi1Ed+fYRWxX2QIhf0EjPIimbPBiw3xpG7FeRFh2zgSqqXVAx08t21DY= X-Received: by 2002:a17:906:7c49:: with SMTP id g9mr11454375ejp.185.1610376924969; Mon, 11 Jan 2021 06:55:24 -0800 (PST) MIME-Version: 1.0 References: <20210110214653.GA1693373@ravnborg.org> In-Reply-To: From: chase rayfield Date: Mon, 11 Jan 2021 09:55:13 -0500 Message-ID: Subject: Re: Old platforms: bring out your dead To: John Paul Adrian Glaubitz Cc: Sam Ravnborg , Arnd Bergmann , Linux Kernel Mailing List , linux-m68k , Sparc kernel list , Linux-sh list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz wrote: > > I'm not sure I understand the reasoning for doing this. The SPARC architecture > isn't going to see any new hardware developments in the future after Oracle > let go of most of the SPARC developers. So it's not that we need to make room > for new hardware. > My take is that there *would* be more interest in Sparc sun4m / Sun4d from enthusiasts at the very least if it was possible to actually boot the bloat hog that is Linux these days in a fully usable configuration that probably means some modifications to SILO and Linux required. The problem is as I understand it, SILO only sets up a 16Mb mapping (either due to having to assume 4MB minimum dram stick size or due to mapping limitations not sure, most of these machines have at least 16MB in slot one...these days though that wasn't the case for sun4c), loads Linux into it and says good Luck. This isn't enough for a modern kernel with any hardware support built in. So you might for instance get a kernel to fit but only if you dropped all of networking support etc... I'm guessing the fix for this would be to modify silo to map a larger amount in a way that Linux expects so it can remap it as it likes, or just have SILO map the full memory as Linux would. Anyway that is THE main demotivation for these architectures.... otherwise they have plenty of ram and performance to do basic router/server tasks sans SSL. This has been the status quo for since the last of the 2.6 series of kernels which it was still possible to just barely squeeze a usable kernel out of... If someone wanted to take a few hours and fix this issue, and keep these architectures around I'd be happy to "buy them a round of pizza", though I recognize that many people that work on this already have nice jobs, and just don't have time. Also Sparc would probably be a good project for someone to extend/test Andi Keen's Linux LTO patch set so we could reduce the kernel binary size that way also even if sun4 architectures are dropped, it would still be useful for embedded sparc. Also there is a port of Temlib to the Mister hardware now, 3 cores roughly equivalent to a mid 90s machine, at least 128MB ram is possible ( more if a way to map the ARM system memory also 1GB is available there, it would have higher latency though). It is perfectly viable to build Sparc v7 or v8 32bit binaries in a chroot on a fast machine also, and I would recommend this if you wish to retain sanity rather than attempting cross compiler voodoo, unless that is your thing. Anyways it could be that people that want this get around to fixing SILO eventually and just sit on this last kernel version... *shrugs* Chase