On 26/02/16 19:21, David Miller wrote:
> From: Tomi Valkeinen
> Date: Fri, 26 Feb 2016 12:58:00 +0200
>
>> While doing this, did you just go forward removing the module support,
>> or did you check if it would be trivial to make the driver build as a
>> module? I wouldn't be surprised if in some
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
From: Tomi Valkeinen
Date: Fri, 26 Feb 2016 12:58:00 +0200
> While doing this, did you just go forward removing the module support,
> or did you check if it would be trivial to make the driver build as a
> module? I wouldn't be surprised if in some cases all that would need to
> be done is change
[Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code] On
26/02/2016 (Fri 12:58) Tomi Valkeinen wrote:
>
>
> On 22/02/16 05:13, Paul Gortmaker wrote:
> > This series of commits is a part of a larger project to ensure
> > people don't reference mo
On 22/02/16 05:13, Paul Gortmaker wrote:
> This series of commits is a part of a larger project to ensure
> people don't reference modular support functions in non-modular
> code. Overall there was roughly 5k lines of dead code in the
> kernel due to this. So far we've fixed several areas, like
This series of commits is a part of a larger project to ensure
people don't reference modular support functions in non-modular
code. Overall there was roughly 5k lines of dead code in the
kernel due to this. So far we've fixed several areas, like tty,
x86, net, ... and we continue to work on othe
6 matches
Mail list logo
