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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACRpkdYaMASWWDTX7hTt+xQnVPA=WTWNFk2eDnTjKoJF=LA7LQ@mail.gmail.com>
Date:   Sun, 10 Jan 2021 22:33:56 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Fabian Vogt <fabian@...ter-vogt.de>
Cc:     Daniel Tang <dt.tangr@...il.com>, Arnd Bergmann <arnd@...nel.org>,
        Baruch Siach <baruch@...s.co.il>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Neil Armstrong <narmstrong@...libre.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Jamie Iles <jamie@...ieiles.com>,
        Krzysztof Adamski <krzysztof.adamski@...ia.com>,
        Alexander Shiyan <shc_work@...l.ru>,
        Michael Ellerman <mpe@...erman.id.au>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Wei Xu <xuwei5@...ilicon.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Alex Elder <elder@...aro.org>,
        Marc Gonzalez <marc.w.gonzalez@...e.fr>,
        Hans Ulli Kroll <ulli.kroll@...glemail.com>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Lubomir Rintel <lkundrak@...sk>,
        Koen Vandeputte <koen.vandeputte@...ntric.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Barry Song <song.bao.hua@...ilicon.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jonas Jensen <jonas.jensen@...il.com>,
        Hartley Sweeten <hsweeten@...ionengravers.com>,
        Mark Salter <msalter@...hat.com>,
        Shawn Guo <shawnguo@...nel.org>
Subject: Re: Old platforms: bring out your dead

On Sun, Jan 10, 2021 at 7:16 PM Fabian Vogt <fabian@...ter-vogt.de> wrote:
> Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <dt.tangr@...il.com> wrote:

> > > * nspire -- added in 2013, no notable changes after 2015
>
> Most of the platform is just the DT sources and some small drivers around it,
> so it's actually fairly low maintenance. So far the migration away from
> panel-simple in 2019
> (https://lore.kernel.org/linux-arm-kernel/20190805085847.25554-1-linus.walleij@linaro.org)
> was the biggest required change so far.

What we're seeing here is actually a port that is:
- Finished
- Has a complete set of working drivers
- Supported
- Just works

I.e. it doesn't see much patches because it is pretty much perfect.

We are so unused to this situation that it can be mistaken for
the device being abandoned.

I think it was Russell who first pointed out that this is actually
the case for a few machines.

> > Would either of you already have a guess for how long it makes
> > sense to update kernels on it?
> >
> > I see that this is one of the more limited platforms with just 32MB
> > of RAM (64MB in case of CX), and kernels only get more bloated over
> > time, so I expect at some point you will be stuck with running old
> > software.
>
> The kernel overhead isn't actually that bad. I just built today's 2ff90100ace8
> and booted it with a busybox-based initrd. free -m reports:
> total used free shared buffers
>    58   12   46      0       0
>
> Relatively speaking, still mostly unused ;-) The stock OS actually uses more!
> With 32MiB, the situation is definitely worse, but still manageable. Should
> that change in the future, dropping just the Classic/CM variants would be a
> possible option, but that still seems far enough away.

64 MB is perfectly fine to run Linux. OpenWrt-type distributions (also
OpenEmbedded/YOCTO) run just fine with that. 32 MB certainly works.
For example this is the Gemini D-Link DNS-313 which is my NAS
and works perfectly on 64MB:

root@...-313:~# free -m
              total        used        free      shared  buff/cache   available
Mem:          56136       21032       28612           0        6492       23812
Swap:        131128        1280      129848

Not even using the fallback swap.

I can add that at the time it is syncing a backup AND playing back
a 1080p movie over SMB. The trick is using ksmbd rather than
Samba. ksmbd is much less memory-intensive.

I like to use this device for NAS since it is good at I/O, stable,
maintained by myself and JustWorks(TM).

Yours,
Linus Walleij