Linux DRM

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Linux DRM

Thomas de Grivel-2
I was browsing the DRM code ported from Linux and it's a terrible
mess, is there any ongoing project to clean up that codebase or
rewrite it entirely ?

--
 Thomas de Grivel

Reply | Threaded
Open this post in threaded view
|

Re: Linux DRM

Philip Guenther-2
On Mon, Sep 3, 2018 at 11:46 AM Thomas de Grivel <[hidden email]> wrote:

> I was browsing the DRM code ported from Linux and it's a terrible
> mess, is there any ongoing project to clean up that codebase or
> rewrite it entirely ?
>

No.  OpenBSD doesn't have the resources to reimplement the DRM subsystem or
maintain a non-trivial fork of the Linux version.  We don't want to get
stuck with a code base that doesn't support close-to-current hardware, so
the porting work has concentrated on minimizing the changes necessary to
make the upstream code base work in OpenBSD.

It's clear that the hardware support in the upstream has large
contributions from developers with inside access at the hardware vendors;
without such access it's doubtful that all the hardware bugs^Wlimitations
can be worked around with non-infinite resource.

Improvements in the DRM code itself should be done in the upstream, not
just to minimize OpenBSD costs in this area, but so that all OSes that draw
from that base can benefit.


Philip Guenther
Reply | Threaded
Open this post in threaded view
|

Re: Linux DRM

Thomas de Grivel-2
Le lun. 3 sept. 2018 à 23:33, Philip Guenther <[hidden email]> a écrit :

>
> On Mon, Sep 3, 2018 at 11:46 AM Thomas de Grivel <[hidden email]> wrote:
>>
>> I was browsing the DRM code ported from Linux and it's a terrible
>> mess, is there any ongoing project to clean up that codebase or
>> rewrite it entirely ?
>
>
> No.  OpenBSD doesn't have the resources to reimplement the DRM subsystem or maintain a non-trivial fork of the Linux version.  We don't want to get stuck with a code base that doesn't support close-to-current hardware, so the porting work has concentrated on minimizing the changes necessary to make the upstream code base work in OpenBSD.
>
> It's clear that the hardware support in the upstream has large contributions from developers with inside access at the hardware vendors; without such access it's doubtful that all the hardware bugs^Wlimitations can be worked around with non-infinite resource.
>
> Improvements in the DRM code itself should be done in the upstream, not just to minimize OpenBSD costs in this area, but so that all OSes that draw from that base can benefit.

You probably do not care and actually neither do I but that current
state of graphic hardware support code is crazy in my opinion.
Computer graphic cards have to be the single most successful hardware
in the history of computer hardware or even hardware in general and
yet their drivers are a complete mess. It makes no sense to me. It all
appears like a hideous obscurity-based false sense of security where
you really cannot ensure the minimality of any driver and their
features.

I would not be least surprised to see a few backdoors in that code,
preventing OpenBSD for use for private intellectual property work,
however different the advertisement can be. I sure hope I'm wrong.

--
 Thomas de Grivel
 http://kmx.io/

Reply | Threaded
Open this post in threaded view
|

Re: Linux DRM

Joseph Mayer
Thomas,

On September 4, 2018 10:55 AM, Thomas de Grivel <[hidden email]> wrote:

> Le lun. 3 sept. 2018 à 23:33, Philip Guenther [hidden email] a écrit :
>
> > On Mon, Sep 3, 2018 at 11:46 AM Thomas de Grivel [hidden email] wrote:
> >
> > > I was browsing the DRM code ported from Linux and it's a terrible
> > > mess, is there any ongoing project to clean up that codebase or
> > > rewrite it entirely ?

For the one who has not reviewed the code, can you quantify and
illustrate approximately how bad it is?

> > No. OpenBSD doesn't have the resources to reimplement the DRM subsystem or maintain a non-trivial fork of the Linux version. We don't want to get stuck with a code base that doesn't support close-to-current hardware, so the porting work has concentrated on minimizing the changes necessary to make the upstream code base work in OpenBSD.
> > It's clear that the hardware support in the upstream has large contributions from developers with inside access at the hardware vendors; without such access it's doubtful that all the hardware bugs^Wlimitations can be worked around with non-infinite resource.
> > Improvements in the DRM code itself should be done in the upstream, not just to minimize OpenBSD costs in this area, but so that all OSes that draw from that base can benefit.
>
> You probably do not care and actually neither do I but that current
> state of graphic hardware support code is crazy in my opinion.
> Computer graphic cards have to be the single most successful hardware
> in the history of computer hardware or even hardware in general and
> yet their drivers are a complete mess.

I agree this is unacceptable.

> It makes no sense to me. It all
> appears like a hideous obscurity-based false sense of security where
> you really cannot ensure the minimality of any driver and their
> features.

Common.

I guess any OS would benefit of a clean, open source, audited DRM
stack. This makes sense as a separate code project?

What's the quality of the exported interfaces? Satisfactory for
a higher-quality implementation to use it?

Reply | Threaded
Open this post in threaded view
|

Re: Linux DRM

Chris Cappuccio
Joseph Mayer [[hidden email]] wrote:
>
> For the one who has not reviewed the code, can you quantify and
> illustrate approximately how bad it is?
>

Perhaps he was reading from someone who does know some detail of the code?

https://arcan-fe.com/2018/04/25/towards-secure-system-graphics-arcan-and-openbsd/

Reply | Threaded
Open this post in threaded view
|

Re: Linux DRM

Theo de Raadt-2
In reply to this post by Thomas de Grivel-2
Thomas de Grivel <[hidden email]> wrote:

> Le lun. 3 sept. 2018 à 23:33, Philip Guenther <[hidden email]> a écrit :
> >
> > On Mon, Sep 3, 2018 at 11:46 AM Thomas de Grivel <[hidden email]> wrote:
> >>
> >> I was browsing the DRM code ported from Linux and it's a terrible
> >> mess, is there any ongoing project to clean up that codebase or
> >> rewrite it entirely ?
> >
> >
> > No.  OpenBSD doesn't have the resources to reimplement the DRM subsystem or maintain a non-trivial fork of the Linux version.  We don't want to get stuck with a code base that doesn't support close-to-current hardware, so the porting work has concentrated on minimizing the changes necessary to make the upstream code base work in OpenBSD.
> >
> > It's clear that the hardware support in the upstream has large contributions from developers with inside access at the hardware vendors; without such access it's doubtful that all the hardware bugs^Wlimitations can be worked around with non-infinite resource.
> >
> > Improvements in the DRM code itself should be done in the upstream, not just to minimize OpenBSD costs in this area, but so that all OSes that draw from that base can benefit.
>
> You probably do not care and actually neither do I but that current
> state of graphic hardware support code is crazy in my opinion.
> Computer graphic cards have to be the single most successful hardware
> in the history of computer hardware or even hardware in general and
> yet their drivers are a complete mess. It makes no sense to me. It all
> appears like a hideous obscurity-based false sense of security where
> you really cannot ensure the minimality of any driver and their
> features.
>
> I would not be least surprised to see a few backdoors in that code,
> preventing OpenBSD for use for private intellectual property work,
> however different the advertisement can be. I sure hope I'm wrong.

It's been nearly 2 weeks and you haven't shown your draft reimplimentation yet!