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

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