Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1345578
| 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 |
[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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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