ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: ksummit-discuss@lists.linuxfoundation.org
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Alexander Sverdlin <alexander.sverdlin@gmail.com>,
	Lukasz Majewski <lukma@denx.de>,
	Ksummit-discuss@lists.linuxfoundation.org,
	Jonas Jensen <jonas.jensen@gmail.com>
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Deprecation / Removal of old hardware support
Date: Wed, 12 Sep 2018 00:39:34 +0300	[thread overview]
Message-ID: <2400444.QbA1LOmrIy@avalon> (raw)
In-Reply-To: <20180911193308.GA4429@kroah.com>

Hi Greg,

On Tuesday, 11 September 2018 22:33:08 EEST Greg KH wrote:
> On Tue, Sep 11, 2018 at 11:37:25AM +0200, Lukasz Majewski wrote:
> > In the kernel community we pose a lot of attention to security (for
> > example the prompt reaction on meltdown/spectre), but in the same time
> > we tend to forget about the "long lived" devices and force their
> > maintainers to use 2.6.x kernels..... (or even 2.4.x).
> 
> We care, but really, how much can we do here?
> 
> I've been working a lot with the Adroid ecosystem to try to help fix
> their bad habits of "grab a random kernel and ship it and never update
> it" by providing longer lived kernels that they can constantly update
> their devices to.
> 
> But their lifetimes is much shorter compared to yours, and I have no
> insight into what kernels are being used, what configurations you all
> care about, and how long you need/want them updated.
> 
> Working with really old kernels like you have, without hardware
> available to test is a hard task.  If your hardware is in a system like
> kernelci, then you can be sure that any new kernel will work properly
> with your system and then you might not want to have to stay with really
> old kernels that no one can maintain :)
> 
> There's a Linux Foundation project, "CIP" that wants to maintain kernels
> for devices like what you are making for 20+ years.  They are having the
> problems of not knowing exactly what platforms they wish to support, but
> their goal is good, hopefully they eventually nail something down and we
> can work together.  Perhaps you should contact them to try to help solve
> this issue for everyone?

I may be wrong, but I understand Lukasz's comment as the exact opposite: we 
forget about long-lived devices and drop their support while they're still in 
active use, forcing vendors to start using old and unsupported kernels. If a 
large number of ARMv4(T) devices are still being actively deployed and 
maintain, we should treat them as first-class citizens.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2018-09-11 21:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 14:04 Peter Huewe
2018-09-10 15:31 ` Linus Walleij
2018-09-10 21:40   ` Arnd Bergmann
2018-09-10 22:02     ` Guenter Roeck
2018-09-11  8:49       ` Geert Uytterhoeven
2018-09-11 17:27         ` Guenter Roeck
2018-09-11 17:58           ` Geert Uytterhoeven
2018-09-11 18:27             ` Guenter Roeck
2018-09-11 18:37               ` Daniel Vetter
2018-09-11  8:37     ` Linus Walleij
2018-09-11  9:37       ` Lukasz Majewski
2018-09-11 19:33         ` Greg KH
2018-09-11 21:39           ` Laurent Pinchart [this message]
2018-09-11 21:50             ` Thomas Gleixner
2018-09-12  6:40               ` Geert Uytterhoeven
2018-09-12 10:23                 ` Arnd Bergmann
2018-09-12  6:26             ` Greg KH
2018-09-12  6:49               ` Peter Huewe
2018-09-12  7:07                 ` Greg KH
2018-09-11 10:52       ` Mark Brown
2018-09-11 11:22         ` Linus Walleij
     [not found]           ` <TY2PR0101MB2526376DEFC241B754A19A6AE21C0@TY2PR0101MB2526.apcprd01.prod.exchangelabs.com>
2018-09-27 15:25             ` SZ Lin (林上智)
2018-09-28 10:45               ` Thomas Gleixner
2018-09-11 11:53       ` Arnd Bergmann
2018-09-11 21:28         ` Alexander Sverdlin
2018-09-11 21:16       ` Alexander Sverdlin

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=2400444.QbA1LOmrIy@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=alexander.sverdlin@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jonas.jensen@gmail.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=lukma@denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox