linux-kernel - Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADuzgbqZQ5oMxUh5XhmzqGpVgU+m6L-42TucOhACDviKYpaCMg@mail.gmail.com>
Date:   Sun, 20 Dec 2020 10:25:49 +0100
From:   Romain Dolbeau <romain@...beau.org>
To:     Julian Calaby <julian.calaby@...il.com>
Cc:     Sam Ravnborg <sam@...nborg.org>,
        David S Miller <davem@...emloft.net>,
        sparclinux <sparclinux@...r.kernel.org>,
        Andreas Larsson <andreas@...sler.com>,
        Arnd Bergmann <arnd@...nel.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Denis Efremov <efremov@...ux.com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ira Weiny <ira.weiny@...el.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Mark Rutland <mark.rutland@....com>,
        Mike Rapoport <rppt@...nel.org>,
        Pekka Enberg <penberg@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Will Deacon <will@...nel.org>, Willy Tarreau <w@....eu>,
        LKML <linux-kernel@...r.kernel.org>,
        debian-sparc <debian-sparc@...ts.debian.org>,
        gentoo-sparc@...ts.gentoo.org, info@...lib.org
Subject: Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

Le dim. 20 déc. 2020 à 09:54, Julian Calaby <julian.calaby@...il.com> a écrit :
> If I want to run them, assuming the hardware still works, I need to
> netboot them as I cannot find working, compatible HDDs for them as
> everything has switched to SATA or SAS.

SCSI2SD (<http://www.codesrc.com/mediawiki/index.php/SCSI2SD>)
are a bit expensive, but solve that problem (I own both a V5 and a V6,
both work well in my SPARCstations, tried sun4c and sun4m).
As it takes micro-sd cards, it's quite easy to keep multiple OSes
on hand.

> Then there's the issue of finding a monitor as they're not
> electrically compatible with VGA

Huh? There is Sun's 13W3-to-vga adapters and cables, and many
monitors will sync to Sun's frequency (though not the most recent
LCDs whose analog circuitry is pathetic compared to old-school
CRTs). Some framebuffers will output 1280x1024 (rarer than for
1152x900), and some can be coerced to do almost anything with
some Forth knowledge (see e.g.
<https://github.com/rdolbeau/SunTurboGX>, again blowing my
own horn here sorry...).

> (...) booting one up for fun is simply impractical

An SCSI2SD and either a null-modem serial cable or a
Sun keyboard/13w3 cable/17"LCD combo and you're good to
go. You might need another unix-like box to netboot the system.

> I believe that Gentoo is architecture-neutral enough that it'd work,
> but I believe that you'll have to compile everything - there'll be no
> pre-built anything for sparc32

Trying gentoo is on my todo list... has been for a long time :-(

> and as it's fairly slow hardware by
> today's standards, that's going to take a long time, however you could
> probably use distcc and cross-compilers to speed it up.

Isn't that what Qemu is for ? :-) I've managed to recompile LLVM
and clang in NetBSD 9 for my SS20, one by cross-compiling
(LLVM requires too much memory), the other in QEmu.
Unfortunately, Qemu doesn't yet support mt-tcg (multithreaded
emulation) for sparc so single-core only - still faster than the HW,
mostly because of incomparably faster I/O.

> If there were more people using it or more testing, or more distros
> supporting it - not just (theoretically?) working on it - then I'd be
> fighting to keep it.

I wish I had some arguments for that point... I will just re-mention Qemu,
as it makes testing quite easy and reasonably not-too-slow.

Cordially,

-- 
Romain Dolbeau