All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	netdev@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	"Maciej W. Rozycki" <macro@orcam.me.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Doug Berger <opendmb@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Sam Creasey <sammy@sammy.net>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Finn Thain <fthain@telegraphics.com.au>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Andrew Lunn <andrew@lunn.ch>, Alexei Starovoitov <ast@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Andrii Nakryiko <andriin@fb.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	linux-kernel@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com
Subject: Re: [RFC 00/13] [net-next] drivers/net/Space.c cleanup
Date: Tue, 18 May 2021 09:04:17 +1000 (AEST)	[thread overview]
Message-ID: <dbbc513f-94cf-7bfe-9a14-46dc45b496a3@nippy.intranet> (raw)
In-Reply-To: <20210517143805.GQ258772@windriver.com>

On Mon, 17 May 2021, Paul Gortmaker wrote:

> Leaving the more popular cards was a concession to making progress vs. 
> having the whole cleanup blocked by individuals who haven't yet realized 
> that using ancient hardware is best done (only done?) with ancient 
> kernels.
> 

By extension, using ancient kernels is best done with ancient userland. 
And now the time has come to remove all the 'compat' nonsense.

Oh, wait, all of that old software seems to be riddled with bugs and 
vulnerabilities.

And who would have thought that all those developers writing new code for 
emulators and their users were holding up "progress"?

> Maybe things are better now; people are putting more consideration to
> the future of the kernel, rather than clinging to times long past?

If you've been doing engineering for a while you'll start to notice a 
pattern: old designs that work get reused. That's partly why the latest 
silicon contains ancient logic blocks.

When that changes, perhaps we can talk about "progress"...

      parent reply	other threads:[~2021-05-17 23:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15 22:13 [RFC 00/13] [net-next] drivers/net/Space.c cleanup Arnd Bergmann
2021-05-15 22:13 ` [RFC 01/13] [net-next] bcmgenet: remove call to netdev_boot_setup_check Arnd Bergmann
2021-05-16  0:04   ` Florian Fainelli
2021-05-15 22:13 ` [RFC 02/13] [net-next] natsemi: sonic: stop calling netdev_boot_setup_check Arnd Bergmann
2021-05-15 22:13 ` [RFC 03/13] [net-next] appletalk: ltpc: remove static probing Arnd Bergmann
2021-05-15 22:13 ` [RFC 04/13] [net-next] 3c509: stop calling netdev_boot_setup_check Arnd Bergmann
2021-05-15 22:13 ` [RFC 05/13] [net-next] cs89x0: rework driver configuration Arnd Bergmann
2021-05-15 22:13 ` [RFC 06/13] [net-next] m68k: remove legacy probing Arnd Bergmann
2021-05-17  8:10   ` Geert Uytterhoeven
2021-05-15 22:13 ` [RFC 07/13] [net-next] move netdev_boot_setup into Space.c Arnd Bergmann
2021-05-15 22:13 ` [RFC 08/13] [net-next] make legacy ISA probe optional Arnd Bergmann
2021-05-15 22:13 ` [RFC 09/13] [net-next] wan: remove stale Kconfig entries Arnd Bergmann
2021-05-15 22:13 ` [RFC 10/13] [net-next] wan: remove sbni/granch driver Arnd Bergmann
2021-05-15 22:13 ` [RFC 11/13] [net-next] wan: hostess_sv11: use module_init/module_exit helpers Arnd Bergmann
2021-05-15 22:13 ` [RFC 12/13] [net-next] ethernet: isa: convert to module_init/module_exit Arnd Bergmann
2021-05-15 22:13 ` [RFC 13/13] [net-next] 8390: xsurf100: avoid including lib8390.c Arnd Bergmann
2021-05-16  4:24   ` Finn Thain
2021-05-16  9:04     ` Geert Uytterhoeven
2021-05-16  9:39       ` Arnd Bergmann
2021-05-16  0:06 ` [RFC 00/13] [net-next] drivers/net/Space.c cleanup Maciej W. Rozycki
2021-05-16  9:27   ` Arnd Bergmann
2021-05-17 14:38 ` Paul Gortmaker
2021-05-17 15:40   ` Maciej W. Rozycki
2021-05-17 15:49   ` Arnd Bergmann
2021-05-17 23:04   ` Finn Thain [this message]

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=dbbc513f-94cf-7bfe-9a14-46dc45b496a3@nippy.intranet \
    --to=fthain@telegraphics.com.au \
    --cc=andrew@lunn.ch \
    --cc=andriin@fb.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=ast@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    --cc=netdev@vger.kernel.org \
    --cc=opendmb@gmail.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=sammy@sammy.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.