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
> <[email protected]> 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
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)
> 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.
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B
Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
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
>> <[email protected]> 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
Am 24.06.2015 um 11:19 schrieb Richard Weinberger:
Hi,
> Porting PREEMPT_RT is not that easy.
> Did you ever?
I know.
OTOH, is backporting drivers to ancient kernels (where internal APIs
often are _completely_ different) really easier ? Perhaps it might look
so, if it's just one individual driver - but often it doesn't keep this
way, sooner or later other things pop up.
> So, you rewrite all drivers and the board support from scratch?
Sometimes, if I have to. Because - on my own experience - what SoC
vendors provide usually is pretty unusable, just a quick showcase.
Right now, I'm working on a project w/ some imx53-based board.
What freescale provides here is practically unusable. Really ancient
(last time I checked, it was an old 2.6.x), unsable and insecure
(anybody had a closer look at their "kgsl" patch or their gst-plugin ?)
We'll have to drop the whole idea of using the GPUs, due to lack of
support - the existing driver/libgl is known to be broken and insecure,
no support from fsl whatsoever, we're lacking resources for a full
reverse engineering, and moving to another SoC is out of question
(at least for the forseeable future). So, it ends up in having no
GPU, therefore no GL/GSL, therefore no QtQuick/QML.
Pavel already mentioned the correct way to go: chip vendors should
provide proper (mainline'able) patches, or at least full specs.
And I'll add: those who dont, should simply be boycotted.
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B
Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
Am 24.06.2015 um 11:55 schrieb Enrico Weigelt, metux IT consult:
> Am 24.06.2015 um 11:19 schrieb Richard Weinberger:
>
> Hi,
>
>> Porting PREEMPT_RT is not that easy.
>> Did you ever?
>
> I know.
>
> OTOH, is backporting drivers to ancient kernels (where internal APIs
> often are _completely_ different) really easier ? Perhaps it might look
> so, if it's just one individual driver - but often it doesn't keep this
> way, sooner or later other things pop up.
At the end of the day customers will do what is less costly.
Sometimes backporting a driver is much less effort.
That's why we have the excellent backports project.
>> So, you rewrite all drivers and the board support from scratch?
>
> Sometimes, if I have to. Because - on my own experience - what SoC
> vendors provide usually is pretty unusable, just a quick showcase.
>
> Right now, I'm working on a project w/ some imx53-based board.
> What freescale provides here is practically unusable. Really ancient
> (last time I checked, it was an old 2.6.x), unsable and insecure
> (anybody had a closer look at their "kgsl" patch or their gst-plugin ?)
>
> We'll have to drop the whole idea of using the GPUs, due to lack of
> support - the existing driver/libgl is known to be broken and insecure,
> no support from fsl whatsoever, we're lacking resources for a full
> reverse engineering, and moving to another SoC is out of question
> (at least for the forseeable future). So, it ends up in having no
> GPU, therefore no GL/GSL, therefore no QtQuick/QML.
>
>
> Pavel already mentioned the correct way to go: chip vendors should
> provide proper (mainline'able) patches, or at least full specs.
Sure, in a perfect world. But as of now we have to deal with that.
Thanks,
//richard