linux-kernel - RE: Old platforms: bring out your dead

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]

Date:   Mon, 11 Jan 2021 09:50:41 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Arnd Bergmann' <arnd@...nel.org>, Willy Tarreau <w@....eu>
CC:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Krzysztof Adamski <krzysztof.adamski@...ia.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Baruch Siach <baruch@...s.co.il>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Daniel Tang <dt.tangr@...il.com>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        "Jamie Iles" <jamie@...ieiles.com>,
        Barry Song <song.bao.hua@...ilicon.com>,
        "Viresh Kumar" <viresh.kumar@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jonas Jensen <jonas.jensen@...il.com>,
        Marc Gonzalez <marc.w.gonzalez@...e.fr>,
        Hartley Sweeten <hsweeten@...ionengravers.com>,
        Lubomir Rintel <lkundrak@...sk>,
        Neil Armstrong <narmstrong@...libre.com>,
        Shawn Guo <shawnguo@...nel.org>, Alex Elder <elder@...aro.org>,
        "Alexander Shiyan" <shc_work@...l.ru>,
        Koen Vandeputte <koen.vandeputte@...ntric.com>,
        Hans Ulli Kroll <ulli.kroll@...glemail.com>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Wei Xu <xuwei5@...ilicon.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Yoshinori Sato <ysato@...rs.osdn.me>,
        Mark Salter <msalter@...hat.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        "Geert Uytterhoeven" <geert+renesas@...der.be>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Subject: RE: Old platforms: bring out your dead

From: Arnd Bergmann
> Sent: 09 January 2021 21:53
> 
> On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau <w@....eu> wrote:
> >
> > On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> > > * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
> > >   indications that 486 have no users either on recent kernels.
> > >   There is still the Vortex86 family of SoCs, and the oldest of those were
> > >   486SX-class, but all the modern ones are 586-class.
> >
> > These also are the last generation of fanless x86 boards with 100% compatible
> > controllers, that some people have probably kept around because these don't
> > age much and have plenty of connectivity. I've used an old one a few times
> > to plug in an old floppy drive, ISA SCSI controllers to access an old tape
> > drive and a few such things. That doesn't mean that it's a good justification
> > not to remove them, what I rather mean is that *if* there is no benefit
> > in dropping them maybe we can keep them. On the other hand, good luck for
> > running a modern OS on these, when 16MB-32MB RAM was about the maximum that
> > was commonly found by then (though if people kept them around that's probably
> > because they were well equipped, like that 64MB 386DX I'm having :-)).
> 
> I think there were 486s with up to 256MB, which would still qualify as barely
> usable for a minimal desktop, or as comfortable for a deeply embedded
> system. The main limit was apparently the cacheable RAM, which is limited
> by the amount of L2 cache -- you needed a rare 1MB of external L2-cache to
> have 256MB of cached RAM, while more common 256KB of cache would
> be good for 64MB. Vortex86SX has no FPU or L2 cache at all, but supports
> 256MB of DDR2.

There are also some newer (well less than 30 year old) cpus that are
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)