Messages in this thread | | | Subject | Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code | From | Tomi Valkeinen <> | Date | Mon, 29 Feb 2016 10:44:59 +0200 |
| |
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
[unhandled content-type:application/pgp-signature] | |