Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1345578

Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code

From Tomi Valkeinen <tomi.valkeinen@ti.com>
Newsgroups linux.kernel
Subject Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
Date 2016-02-29 09:50 +0100
Message-ID <r7rGG-Ft-19@gated-at.bofh.it> (permalink)
References <r4Pcu-7KX-3@gated-at.bofh.it> <r6ohS-1Wt-63@gated-at.bofh.it> <r6r62-44C-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On 26/02/16 15:58, Paul Gortmaker wrote:

> A counter point would be that if an old driver has remained non-modular
> for all these years, then clearly there is no demand for adding a new
> modular implementation at this point in time.

True. Then again, I think fbdev drivers are almost always used as
built-in to get the console up and running early. For fbdev I see the
module support mostly as a way to improve the code quality and to
simplify development and testing.

> The main reason is listed as #4 above -- if we keep drivers around that
> reflect a disconnect between Kconfig and code, the same mistake gets
> copied into more and more new drivers as they are created.

Yep, but the same could be said about having drivers without module
support too =).

In any case, I don't accept new fbdev drivers except in special cases,
so fbdev drivers' value as examples is not that much.

> If the argument was to not go in and rewrite core code for legacy
> drivers, I'd agree with that, but that isn't what is happening here.
> In a lot of these type changes, where the only change is to replace
> module_init with device initcall, the object files are identical.

Yes, the patches look simple enough. Ensuring they would work as modules
would be riskier.

> If subsystem maintainers would rather have blanket tristate coversions
> and whatever changes are required to make it compile and modpost, and
> are OK to assume things will just work, then that could be an option...

Nope, I think these are fine. I'll queue them up for 4.6.

 Tomi

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc  code Tomi Valkeinen <tomi.valkeinen@ti.com> - 2016-02-26 12:00 +0100
  Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc  code Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-02-26 15:00 +0100
    Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc  code Tomi Valkeinen <tomi.valkeinen@ti.com> - 2016-02-29 09:50 +0100
  Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular  sparc  code,Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc  code David Miller <davem@davemloft.net> - 2016-02-26 18:30 +0100
    Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc  code,Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc  code Tomi Valkeinen <tomi.valkeinen@ti.com> - 2016-02-29 10:00 +0100

csiph-web