All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: "Enrico Weigelt, metux IT consult" <weigelt@melag.de>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"backports@vger.kernel.org" <backports@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: Uses of Linux backports in the industry
Date: Wed, 24 Jun 2015 11:19:07 +0200	[thread overview]
Message-ID: <558A760B.2030600@nod.at> (raw)
In-Reply-To: <558A73D9.3060703@melag.de>

Am 24.06.2015 um 11:09 schrieb Enrico Weigelt, metux IT consult:
> Am 29.05.2015 um 17:01 schrieb Richard Weinberger:
> 
> Hi,
> 
>> On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult
>> <weigelt@melag.de> wrote:
>>> Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez:
>>> Actually, I really wonder why folks are sticking to ancient kernels on
>>> newer hardware.
>>
>> Enterprise distribution kernels.
> 
> hmm, by "enterprise" you mean distros like RHEL, which even can't get a
> dist-upgrade right ? ;-p

Please send such prepubescent flames to /dev/null.

> In that case, it's the duty of the dist vendor, to port their (often
> horrible) vendor patches. I wouldn't run those distros bare-metal
> anyways, so the need for new kernel features (eg. drivers) wouldn't
> that huge.
> 
>> Or "special" kernels like PREEMPT_RT.
> 
> PREEMPT_RT is pretty close to upstream.
> There're at 4.0.5 right now, and 4.1 is still very fresh.
> 
> If I'd have the need for it (actually was already considering it for our
> project), I'd rather port it to 4.1. (as our BSP already is at 4.1)

Porting PREEMPT_RT is not that easy.
Did you ever?

>> Sometimes the vendor BSP is that horrid that a customer cannot afford
>> to forward port it but wants recent stuff. So you need to backport...
> 
> By "vendor BSP", you perhaps mean certain soc or board manufacturer
> stuff ? Just dont use it, it's usually horrible crap anyways. These
> usually are fire-and-forget showcases, not suited for production use.
> Waste of resources.

So, you rewrite all drivers and the board support from scratch?
Interesting. I'd love to meet your customers they seem to have
a lot of money and time. ;-)

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe backports" in

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: "Enrico Weigelt, metux IT consult" <weigelt@melag.de>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"backports@vger.kernel.org" <backports@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: Uses of Linux backports in the industry
Date: Wed, 24 Jun 2015 11:19:07 +0200	[thread overview]
Message-ID: <558A760B.2030600@nod.at> (raw)
In-Reply-To: <558A73D9.3060703@melag.de>

Am 24.06.2015 um 11:09 schrieb Enrico Weigelt, metux IT consult:
> Am 29.05.2015 um 17:01 schrieb Richard Weinberger:
> 
> Hi,
> 
>> On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult
>> <weigelt@melag.de> wrote:
>>> Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez:
>>> Actually, I really wonder why folks are sticking to ancient kernels on
>>> newer hardware.
>>
>> Enterprise distribution kernels.
> 
> hmm, by "enterprise" you mean distros like RHEL, which even can't get a
> dist-upgrade right ? ;-p

Please send such prepubescent flames to /dev/null.

> In that case, it's the duty of the dist vendor, to port their (often
> horrible) vendor patches. I wouldn't run those distros bare-metal
> anyways, so the need for new kernel features (eg. drivers) wouldn't
> that huge.
> 
>> Or "special" kernels like PREEMPT_RT.
> 
> PREEMPT_RT is pretty close to upstream.
> There're at 4.0.5 right now, and 4.1 is still very fresh.
> 
> If I'd have the need for it (actually was already considering it for our
> project), I'd rather port it to 4.1. (as our BSP already is at 4.1)

Porting PREEMPT_RT is not that easy.
Did you ever?

>> Sometimes the vendor BSP is that horrid that a customer cannot afford
>> to forward port it but wants recent stuff. So you need to backport...
> 
> By "vendor BSP", you perhaps mean certain soc or board manufacturer
> stuff ? Just dont use it, it's usually horrible crap anyways. These
> usually are fire-and-forget showcases, not suited for production use.
> Waste of resources.

So, you rewrite all drivers and the board support from scratch?
Interesting. I'd love to meet your customers they seem to have
a lot of money and time. ;-)

Thanks,
//richard

  reply	other threads:[~2015-06-24  9:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-29  2:54 Uses of Linux backports in the industry Luis R. Rodriguez
2015-05-29  7:00 ` Johannes Berg
2015-05-29  8:08   ` Arend van Spriel
2015-05-29  8:29     ` Julia Lawall
2015-05-29 16:41     ` Arend van Spriel
2015-05-29 16:33   ` Luis R. Rodriguez
2015-05-29 18:47     ` Johannes Berg
2015-05-29 14:53 ` Enrico Weigelt, metux IT consult
2015-05-29 15:01   ` Richard Weinberger
2015-05-29 17:36     ` Theodore Ts'o
2015-05-29 17:51       ` Luis R. Rodriguez
2015-06-23 18:49       ` Pavel Machek
2015-06-23 18:49         ` Pavel Machek
2015-06-24  9:12       ` Enrico Weigelt, metux IT consult
2015-06-24  9:12         ` Enrico Weigelt, metux IT consult
2015-06-24  9:09     ` Enrico Weigelt, metux IT consult
2015-06-24  9:09       ` Enrico Weigelt, metux IT consult
2015-06-24  9:19       ` Richard Weinberger [this message]
2015-06-24  9:19         ` Richard Weinberger
2015-06-24  9:55         ` Enrico Weigelt, metux IT consult
2015-06-24  9:55           ` Enrico Weigelt, metux IT consult
2015-06-24 10:18           ` Richard Weinberger
2015-06-24 10:18             ` Richard Weinberger
2015-06-01 18:50 ` Felix Fietkau
2015-06-01 20:03   ` Julia Lawall
2015-06-24 10:13   ` Enrico Weigelt, metux IT consult
2015-06-24 10:13     ` Enrico Weigelt, metux IT consult
2015-06-02 19:05 ` Szymon Janc

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=558A760B.2030600@nod.at \
    --to=richard@nod.at \
    --cc=backports@vger.kernel.org \
    --cc=julia.lawall@lip6.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    --cc=weigelt@melag.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 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.