linux-kernel - Re: No more new fbdev drivers, please

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 Sep 2015 20:46:18 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	Alex Deucher <alexdeucher@...il.com>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	linux-fbdev <linux-fbdev@...r.kernel.org>,
	Teddy Wang <teddy.wang@...iconmotion.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	DRI Development <dri-devel@...ts.freedesktop.org>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnaud Patard <apatard@...driva.com>,
	Dave Airlie <airlied@...hat.com>,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>
Subject: Re: No more new fbdev drivers, please

Hi David,

On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@...il.com> wrote:
> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
> <geert@...ux-m68k.org> wrote:
>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@...il.com> wrote:
>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>> <geert@...ux-m68k.org> wrote:
>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>> to these existing really simple drivers?
>>>
>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>
>> Thanks for the list!
>>
>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>> several fbdev drivers that have less than 200 LoC.
>> Granted, these really small ones support a single fixed video mode only, but
>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>
>> I'm sure DRM can do better?
>
> Is counting lines really the level of the discussion to go here?

LoC is not the most important. But if the smallest DRM driver needs an order
of magnitude more LoC than the smallest fbdev driver, I start to wonder.

E.g. if I want to write a new simple driver for my new shiny hardware, it
can make a big difference if I have to write (and test/debug) 800 LoC, or
3000 LoC.

> DRM is a big set of helpers, nothing else. If many trivial, small
> drivers share common code, developers are more than welcome to
> contribute them to drm-core and help making drivers less complex.

Good. But from the figures above, I don't think we're at that point yet that
writing a new DRM driver is less/equal amount of work than writing a new
fbdev driver, at least for some classes of hardware. So it may be a bit
premature to put a moratorium on new fbdev drivers.
I may be mistaken, I'm still not sufficiently familiar with the DRM subsystem
as I'd like to be.

> As Daniel mentioned, the connector+encoder+crtc combination is one of
> those simplifications that would make sense if more such drivers are
> added. Furthermore, the not-yet-merged SimpleDRM driver is one example
> how to implement multiple of those dumb-fb drivers with a shared
> code-base.

Thanks, looking forward to SimpleDRM!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/