Hi,
I have pulled Dave's drm-fixes-staging into today's linux-next and did
not see a KMS-modesetted resolution change in VT (runlevel-3).
After a quick check of my dmesg, I see also my kernel-module for sound
has "unknown parameter".
( Thus, personally I don't think it is a bug from any drm-2.6 tree. )
# dmesg | egrep -i 'unknown|param'
[ 12.431216] radeon: Unknown parameter `modeset'
[ 12.665911] snd_intel8x0m: Unknown parameter `index'
[ 37.311333] radeon: Unknown parameter `modeset'
Any idea what's going on? Stephen, Randy noticed the same like me?
Regards,
- Sedat -
P.S.: Attached are dmesg and kernel dot-config.
On Mon, Feb 14, 2011 at 1:13 PM, Sedat Dilek <[email protected]> wrote:
> Hi,
>
> I have pulled Dave's drm-fixes-staging into today's linux-next and did
> not see a KMS-modesetted resolution change in VT (runlevel-3).
> After a quick check of my dmesg, I see also my kernel-module for sound
> has "unknown parameter".
> ( Thus, personally I don't think it is a bug from any drm-2.6 tree. )
>
> # dmesg | egrep -i 'unknown|param'
> [ 12.431216] radeon: Unknown parameter `modeset'
> [ 12.665911] snd_intel8x0m: Unknown parameter `index'
> [ 37.311333] radeon: Unknown parameter `modeset'
>
> Any idea what's going on? Stephen, Randy noticed the same like me?
>
> Regards,
> - Sedat -
>
> P.S.: Attached are dmesg and kernel dot-config.
>
[ CC Dmitry Torokhov ]
Could that be a possible fix for me [1]?
- Sedat -
[1] https://patchwork.kernel.org/patch/548891/
On Mon, Feb 14, 2011 at 1:24 PM, Sedat Dilek <[email protected]> wrote:
> On Mon, Feb 14, 2011 at 1:13 PM, Sedat Dilek <[email protected]> wrote:
>> Hi,
>>
>> I have pulled Dave's drm-fixes-staging into today's linux-next and did
>> not see a KMS-modesetted resolution change in VT (runlevel-3).
>> After a quick check of my dmesg, I see also my kernel-module for sound
>> has "unknown parameter".
>> ( Thus, personally I don't think it is a bug from any drm-2.6 tree. )
>>
>> # dmesg | egrep -i 'unknown|param'
>> [ 12.431216] radeon: Unknown parameter `modeset'
>> [ 12.665911] snd_intel8x0m: Unknown parameter `index'
>> [ 37.311333] radeon: Unknown parameter `modeset'
>>
>> Any idea what's going on? Stephen, Randy noticed the same like me?
>>
>> Regards,
>> - Sedat -
>>
>> P.S.: Attached are dmesg and kernel dot-config.
>>
>
> [ CC Dmitry Torokhov ]
>
> Could that be a possible fix for me [1]?
>
> - Sedat -
>
> [1] https://patchwork.kernel.org/patch/548891/
>
[ CC Rusty Russell + Removed drm-2.6/dri-devel folks ]
While digging into the problem, I had a closer look into
linux-next/Trees file [1], which list the included GIT/QUILT
trees/patch-queues, line #121 says:
rr quilt http://ozlabs.org/~rusty/kernel/rr-latest/
( Personally, I thought all stuff are pulled from GIT trees, but you
learn more by CSI-ing. )
As a clever guy, I was silently assuming the problem could occur from
any module-related tree (so I checked linux-next GIT repo via "git log
-3 kernel/params.c" which gave me a hint to Dmitry's commit in
quilt/rr, Bingo?).
With this "evidence material" I "tig-ged" into the commits in my local
linux-next GIT repo, which revealed more:
2011-02-14 14:17 Stephen Rothwell Merge branch 'quilt/rr'
2011-02-11 10:37 Rusty Russell module: deal with alignment issues
in built-in module parameters FIX
2011-02-07 16:02 Dmitry Torokhov module: deal with alignment issues
in built-in module parameters
2011-02-01 21:43 Christoph Hellwig virtio_blk: allow re-reading
config space at runtime
2011-02-07 16:02 Dmitry Torokhov module: do not hide
__modver_version_show declaration behind ifdef
2011-02-07 16:02 Dmitry Torokhov module: deal with alignment issues
in built-in module versions
My damn brain can't understand - looking at the series file in [2] -
why the hell the "possible" patch [3] is not included in linux-next?
I did not compare but [3] looks similiar to [4].
I have applied [3] on top my own patch-series and will report later,
if this worked or not.
BUT please, what are the factors for choosing the relevant patches
from quilt/rr?
( For example, the cpumask stuff is awaited by systemd folks. Is this
stuff included? I saw by a very quick look @ git.k.o there is a GIT
repo for that. )
And yeah, slow-ass UserModeSetting suckz here!
/me confused,
- Sedat -
[1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees
[2] http://ozlabs.org/~rusty/kernel/rr-latest/series
[3] http://ozlabs.org/~rusty/kernel/rr-latest/module:deal_with_alignment_issues_in_built_in_parameters.patch
[4] https://patchwork.kernel.org/patch/548891/
On Mon, Feb 14, 2011 at 2:15 PM, Sedat Dilek <[email protected]> wrote:
> On Mon, Feb 14, 2011 at 1:24 PM, Sedat Dilek <[email protected]> wrote:
>> On Mon, Feb 14, 2011 at 1:13 PM, Sedat Dilek <[email protected]> wrote:
>>> Hi,
>>>
>>> I have pulled Dave's drm-fixes-staging into today's linux-next and did
>>> not see a KMS-modesetted resolution change in VT (runlevel-3).
>>> After a quick check of my dmesg, I see also my kernel-module for sound
>>> has "unknown parameter".
>>> ( Thus, personally I don't think it is a bug from any drm-2.6 tree. )
>>>
>>> # dmesg | egrep -i 'unknown|param'
>>> [ 12.431216] radeon: Unknown parameter `modeset'
>>> [ 12.665911] snd_intel8x0m: Unknown parameter `index'
>>> [ 37.311333] radeon: Unknown parameter `modeset'
>>>
>>> Any idea what's going on? Stephen, Randy noticed the same like me?
>>>
>>> Regards,
>>> - Sedat -
>>>
>>> P.S.: Attached are dmesg and kernel dot-config.
>>>
>>
>> [ CC Dmitry Torokhov ]
>>
>> Could that be a possible fix for me [1]?
>>
>> - Sedat -
>>
>> [1] https://patchwork.kernel.org/patch/548891/
>>
>
> [ CC Rusty Russell + Removed drm-2.6/dri-devel folks ]
>
> While digging into the problem, I had a closer look into
> linux-next/Trees file [1], which list the included GIT/QUILT
> trees/patch-queues, line #121 says:
>
> rr quilt http://ozlabs.org/~rusty/kernel/rr-latest/
>
> ( Personally, I thought all stuff are pulled from GIT trees, but you
> learn more by CSI-ing. )
>
> As a clever guy, I was silently assuming the problem could occur from
> any module-related tree (so I checked linux-next GIT repo via "git log
> -3 kernel/params.c" which gave me a hint to Dmitry's commit in
> quilt/rr, Bingo?).
>
> With this "evidence material" I "tig-ged" into the commits in my local
> linux-next GIT repo, which revealed more:
>
> 2011-02-14 14:17 Stephen Rothwell Merge branch 'quilt/rr'
> 2011-02-11 10:37 Rusty Russell module: deal with alignment issues
> in built-in module parameters FIX
> 2011-02-07 16:02 Dmitry Torokhov module: deal with alignment issues
> in built-in module parameters
> 2011-02-01 21:43 Christoph Hellwig virtio_blk: allow re-reading
> config space at runtime
> 2011-02-07 16:02 Dmitry Torokhov module: do not hide
> __modver_version_show declaration behind ifdef
> 2011-02-07 16:02 Dmitry Torokhov module: deal with alignment issues
> in built-in module versions
>
> My damn brain can't understand - looking at the series file in [2] -
> why the hell the "possible" patch [3] is not included in linux-next?
> I did not compare but [3] looks similiar to [4].
> I have applied [3] on top my own patch-series and will report later,
> if this worked or not.
>
> BUT please, what are the factors for choosing the relevant patches
> from quilt/rr?
> ( For example, the cpumask stuff is awaited by systemd folks. Is this
> stuff included? I saw by a very quick look @ git.k.o there is a GIT
> repo for that. )
>
> And yeah, slow-ass UserModeSetting suckz here!
>
> /me confused,
> - Sedat -
>
> [1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees
> [2] http://ozlabs.org/~rusty/kernel/rr-latest/series
> [3] http://ozlabs.org/~rusty/kernel/rr-latest/module:deal_with_alignment_issues_in_built_in_parameters.patch
> [4] https://patchwork.kernel.org/patch/548891/
>
Patch "module-fix-fallout-from-alignment.patch" fixes the issue here.
- Sedat -
# dmesg | egrep -i 'modeset|intel8x'
[ 0.000000] Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.38-rc4-686-iniza
root=UUID=1ceb69a7-ecf4-47e9-a231-b74e0f0a9b62 ro init=/bin/systemd
radeon.modeset=1 lapic 3
[ 10.706947] [drm] radeon kernel modesetting enabled.
[ 10.712685] [drm] initializing kernel modesetting (RV250
0x1002:0x4C66).
[ 13.552040] intel8x0_measure_ac97_clock: measured 55046 usecs (2652
samples)
[ 13.563714] intel8x0: clocking to 48000
On Mon, 14 Feb 2011 11:45:59 pm Sedat Dilek wrote:
> >> Any idea what's going on? Stephen, Randy noticed the same like me?
Dmitry broke module parameters with a "trivial" transform which turned out
not to be.
I wasn't paying enough attention, and let it through.
> My damn brain can't understand - looking at the series file in [2] -
> why the hell the "possible" patch [3] is not included in linux-next?
There are markers in the series file, which indicate what goes into
linux-next.
Cheers,
Rusty.
On Tue, Feb 15, 2011 at 1:00 AM, Rusty Russell <[email protected]> wrote:
> On Mon, 14 Feb 2011 11:45:59 pm Sedat Dilek wrote:
>> >> Any idea what's going on? Stephen, Randy noticed the same like me?
>
> Dmitry broke module parameters with a "trivial" transform which turned out
> not to be.
>
> I wasn't paying enough attention, and let it through.
>
>> My damn brain can't understand - looking at the series file in [2] -
>> why the hell the "possible" patch [3] is not included in linux-next?
>
> There are markers in the series file, which indicate what goes into
> linux-next.
>
> Cheers,
> Rusty.
>
Thanks for the explanations, it makes things seen from the
patch-management side a bit clearer.
( Not sure if the series files was modified in the meantime. )
Here for documentation-purposes-only (partially extracted):
[ http://ozlabs.org/~rusty/kernel/rr-latest/series ]
# NEXT_PATCHES_START
# MM_PATCHES_START
# Trivial compilation fixes.
## for-linus
virtio:virtio-net-add_schedule_check_to_napi_enable_call.patch
## for-linus end
module:deal_with_alignment_issues_in_built_in_versions.patch
module:do_not_hide_modver_version_show_declaration_behind_ifdef.patch
virtio:blk_allow_re_reading_config_space_at_runtime.patch
# MM_PATCHES_END
# NEXT_PATCHES_END
[ / http://ozlabs.org/~rusty/kernel/rr-latest/series ]
So, I looked again into my own askings:
[ QUOTE ]
With this "evidence material" I "tig-ged" into the commits in my local
linux-next GIT repo, which revealed more:
2011-02-14 14:17 Stephen Rothwell Merge branch 'quilt/rr'
*****
2011-02-11 10:37 Rusty Russell module: deal with alignment issues
in built-in module parameters FIX
*****
2011-02-07 16:02 Dmitry Torokhov module: deal with alignment issues
in built-in module parameters
2011-02-01 21:43 Christoph Hellwig virtio_blk: allow re-reading
config space at runtime
2011-02-07 16:02 Dmitry Torokhov module: do not hide
__modver_version_show declaration behind ifdef
2011-02-07 16:02 Dmitry Torokhov module: deal with alignment issues
in built-in module versions
[ /QUOTE ]
Looks to me, the FIXUP patch marked with ***** was not really applied
to linux-next?
Also, this fixup patch is no more in Rusty's series file.
Is that all correct now?
As I confirmed with "module-fix-fallout-from-alignment.patch"
(aka module:deal_with_alignment_issues_in_built_in_parameters.patch)
my world is OK.
- Sedat -
Hi Sedat,
On Tue, 15 Feb 2011 04:34:24 +0100 Sedat Dilek <[email protected]> wrote:
>
> On Tue, Feb 15, 2011 at 1:00 AM, Rusty Russell <[email protected]> wrote:
> > On Mon, 14 Feb 2011 11:45:59 pm Sedat Dilek wrote:
> >> >> Any idea what's going on? Stephen, Randy noticed the same like me?
> >
> > Dmitry broke module parameters with a "trivial" transform which turned out
> > not to be.
> >
> > I wasn't paying enough attention, and let it through.
> >
> >> My damn brain can't understand - looking at the series file in [2] -
> >> why the hell the "possible" patch [3] is not included in linux-next?
> >
> > There are markers in the series file, which indicate what goes into
> > linux-next.
>
> Thanks for the explanations, it makes things seen from the
> patch-management side a bit clearer.
> ( Not sure if the series files was modified in the meantime. )
>
> Here for documentation-purposes-only (partially extracted):
>
> [ http://ozlabs.org/~rusty/kernel/rr-latest/series ]
>
> # NEXT_PATCHES_START
> # MM_PATCHES_START
> # Trivial compilation fixes.
>
>
> ## for-linus
> virtio:virtio-net-add_schedule_check_to_napi_enable_call.patch
> ## for-linus end
> module:deal_with_alignment_issues_in_built_in_versions.patch
> module:do_not_hide_modver_version_show_declaration_behind_ifdef.patch
> virtio:blk_allow_re_reading_config_space_at_runtime.patch
> # MM_PATCHES_END
> # NEXT_PATCHES_END
>
> [ / http://ozlabs.org/~rusty/kernel/rr-latest/series ]
That is how it looks today. Yesterday, the patch
module:deal_with_alignment_issues_in_built_in_parameters.patch
was also included and that is what caused the problem.
> Looks to me, the FIXUP patch marked with ***** was not really applied
> to linux-next?
No, instead the breaking patch (above) was removed from Rusty's
linux-next series today.
> Also, this fixup patch is no more in Rusty's series file.
> Is that all correct now?
Rusty has a new version of the above patch which includes the fix (I
assume) but it is not included in linux-next today.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, Feb 15, 2011 at 4:58 AM, Stephen Rothwell <[email protected]> wrote:
> Hi Sedat,
>
> On Tue, 15 Feb 2011 04:34:24 +0100 Sedat Dilek <[email protected]> wrote:
>>
>> On Tue, Feb 15, 2011 at 1:00 AM, Rusty Russell <[email protected]> wrote:
>> > On Mon, 14 Feb 2011 11:45:59 pm Sedat Dilek wrote:
>> >> >> Any idea what's going on? Stephen, Randy noticed the same like me?
>> >
>> > Dmitry broke module parameters with a "trivial" transform which turned out
>> > not to be.
>> >
>> > I wasn't paying enough attention, and let it through.
>> >
>> >> My damn brain can't understand - looking at the series file in [2] -
>> >> why the hell the "possible" patch [3] is not included in linux-next?
>> >
>> > There are markers in the series file, which indicate what goes into
>> > linux-next.
>>
>> Thanks for the explanations, it makes things seen from the
>> patch-management side a bit clearer.
>> ( Not sure if the series files was modified in the meantime. )
>>
>> Here for documentation-purposes-only (partially extracted):
>>
>> [ http://ozlabs.org/~rusty/kernel/rr-latest/series ]
>>
>> # NEXT_PATCHES_START
>> # MM_PATCHES_START
>> # Trivial compilation fixes.
>>
>>
>> ## for-linus
>> virtio:virtio-net-add_schedule_check_to_napi_enable_call.patch
>> ## for-linus end
>> module:deal_with_alignment_issues_in_built_in_versions.patch
>> module:do_not_hide_modver_version_show_declaration_behind_ifdef.patch
>> virtio:blk_allow_re_reading_config_space_at_runtime.patch
>> # MM_PATCHES_END
>> # NEXT_PATCHES_END
>>
>> [ / http://ozlabs.org/~rusty/kernel/rr-latest/series ]
>
> That is how it looks today. Yesterday, the patch
> module:deal_with_alignment_issues_in_built_in_parameters.patch
> was also included and that is what caused the problem.
>
>> Looks to me, the FIXUP patch marked with ***** was not really applied
>> to linux-next?
>
> No, instead the breaking patch (above) was removed from Rusty's
> linux-next series today.
>
>> Also, this fixup patch is no more in Rusty's series file.
>> Is that all correct now?
>
> Rusty has a new version of the above patch which includes the fix (I
> assume) but it is not included in linux-next today.
>
> --
> Cheers,
> Stephen Rothwell [email protected]
> http://www.canb.auug.org.au/~sfr/
>
Hmm, would be nice to have a clarification or a confirmation after
compilation and kernel-modules are loaded correctly on i386 (amd64)
arch(s).
- Sedat -
On Tue, Feb 15, 2011 at 05:14:24AM +0100, Sedat Dilek wrote:
> On Tue, Feb 15, 2011 at 4:58 AM, Stephen Rothwell <[email protected]> wrote:
> > Hi Sedat,
> >
> > On Tue, 15 Feb 2011 04:34:24 +0100 Sedat Dilek <[email protected]> wrote:
> >>
> >> On Tue, Feb 15, 2011 at 1:00 AM, Rusty Russell <[email protected]> wrote:
> >> > On Mon, 14 Feb 2011 11:45:59 pm Sedat Dilek wrote:
> >> >> >> Any idea what's going on? Stephen, Randy noticed the same like me?
> >> >
> >> > Dmitry broke module parameters with a "trivial" transform which turned out
> >> > not to be.
> >> >
> >> > I wasn't paying enough attention, and let it through.
> >> >
> >> >> My damn brain can't understand - looking at the series file in [2] -
> >> >> why the hell the "possible" patch [3] is not included in linux-next?
> >> >
> >> > There are markers in the series file, which indicate what goes into
> >> > linux-next.
> >>
> >> Thanks for the explanations, it makes things seen from the
> >> patch-management side a bit clearer.
> >> ?( Not sure if the series files was modified in the meantime. )
> >>
> >> Here for documentation-purposes-only (partially extracted):
> >>
> >> [ http://ozlabs.org/~rusty/kernel/rr-latest/series ]
> >>
> >> # NEXT_PATCHES_START
> >> # MM_PATCHES_START
> >> # Trivial compilation fixes.
> >>
> >>
> >> ## for-linus
> >> virtio:virtio-net-add_schedule_check_to_napi_enable_call.patch
> >> ## for-linus end
> >> module:deal_with_alignment_issues_in_built_in_versions.patch
> >> module:do_not_hide_modver_version_show_declaration_behind_ifdef.patch
> >> virtio:blk_allow_re_reading_config_space_at_runtime.patch
> >> # MM_PATCHES_END
> >> # NEXT_PATCHES_END
> >>
> >> [ / http://ozlabs.org/~rusty/kernel/rr-latest/series ]
> >
> > That is how it looks today. ?Yesterday, the patch
> > module:deal_with_alignment_issues_in_built_in_parameters.patch
> > was also included and that is what caused the problem.
> >
> >> Looks to me, the FIXUP patch marked with ***** was not really applied
> >> to linux-next?
> >
> > No, instead the breaking patch (above) was removed from Rusty's
> > linux-next series today.
> >
> >> Also, this fixup patch is no more in Rusty's series file.
> >> Is that all correct now?
> >
> > Rusty has a new version of the above patch which includes the fix (I
> > assume) but it is not included in linux-next today.
> >
> > --
> > Cheers,
> > Stephen Rothwell ? ? ? ? ? ? ? ? ? [email protected]
> > http://www.canb.auug.org.au/~sfr/
> >
>
> Hmm, would be nice to have a clarification or a confirmation after
> compilation and kernel-modules are loaded correctly on i386 (amd64)
> arch(s).
As it was proven that the change was a bit *ahem* involved it is
probably better for the updated patch (even though I am pretty sure it
is good now) to cook a bit more outside of next so Rusty removed it.
Thanks.
--
Dmitry
On Tue, Feb 15, 2011 at 5:36 AM, Dmitry Torokhov
<[email protected]> wrote:
> On Tue, Feb 15, 2011 at 05:14:24AM +0100, Sedat Dilek wrote:
>> On Tue, Feb 15, 2011 at 4:58 AM, Stephen Rothwell <[email protected]> wrote:
>> > Hi Sedat,
>> >
>> > On Tue, 15 Feb 2011 04:34:24 +0100 Sedat Dilek <[email protected]> wrote:
>> >>
>> >> On Tue, Feb 15, 2011 at 1:00 AM, Rusty Russell <[email protected]> wrote:
>> >> > On Mon, 14 Feb 2011 11:45:59 pm Sedat Dilek wrote:
>> >> >> >> Any idea what's going on? Stephen, Randy noticed the same like me?
>> >> >
>> >> > Dmitry broke module parameters with a "trivial" transform which turned out
>> >> > not to be.
>> >> >
>> >> > I wasn't paying enough attention, and let it through.
>> >> >
>> >> >> My damn brain can't understand - looking at the series file in [2] -
>> >> >> why the hell the "possible" patch [3] is not included in linux-next?
>> >> >
>> >> > There are markers in the series file, which indicate what goes into
>> >> > linux-next.
>> >>
>> >> Thanks for the explanations, it makes things seen from the
>> >> patch-management side a bit clearer.
>> >> ( Not sure if the series files was modified in the meantime. )
>> >>
>> >> Here for documentation-purposes-only (partially extracted):
>> >>
>> >> [ http://ozlabs.org/~rusty/kernel/rr-latest/series ]
>> >>
>> >> # NEXT_PATCHES_START
>> >> # MM_PATCHES_START
>> >> # Trivial compilation fixes.
>> >>
>> >>
>> >> ## for-linus
>> >> virtio:virtio-net-add_schedule_check_to_napi_enable_call.patch
>> >> ## for-linus end
>> >> module:deal_with_alignment_issues_in_built_in_versions.patch
>> >> module:do_not_hide_modver_version_show_declaration_behind_ifdef.patch
>> >> virtio:blk_allow_re_reading_config_space_at_runtime.patch
>> >> # MM_PATCHES_END
>> >> # NEXT_PATCHES_END
>> >>
>> >> [ / http://ozlabs.org/~rusty/kernel/rr-latest/series ]
>> >
>> > That is how it looks today. Yesterday, the patch
>> > module:deal_with_alignment_issues_in_built_in_parameters.patch
>> > was also included and that is what caused the problem.
>> >
>> >> Looks to me, the FIXUP patch marked with ***** was not really applied
>> >> to linux-next?
>> >
>> > No, instead the breaking patch (above) was removed from Rusty's
>> > linux-next series today.
>> >
>> >> Also, this fixup patch is no more in Rusty's series file.
>> >> Is that all correct now?
>> >
>> > Rusty has a new version of the above patch which includes the fix (I
>> > assume) but it is not included in linux-next today.
>> >
>> > --
>> > Cheers,
>> > Stephen Rothwell [email protected]
>> > http://www.canb.auug.org.au/~sfr/
>> >
>>
>> Hmm, would be nice to have a clarification or a confirmation after
>> compilation and kernel-modules are loaded correctly on i386 (amd64)
>> arch(s).
>
> As it was proven that the change was a bit *ahem* involved it is
> probably better for the updated patch (even though I am pretty sure it
> is good now) to cook a bit more outside of next so Rusty removed it.
>
> Thanks.
>
> --
> Dmitry
>
Might be better this way.
( And yeah, it looks like "sth" was dropped according to merge.logs. )
- Sedat -
P.S.:
[ merge.log of next-20110215 ]
...
3270 Merging quilt/rr
3271 $ git merge quilt/rr
3272 Merge made by recursive.
3273 drivers/block/virtio_blk.c | 88
+++++++++++++++++++++++++++++++++++++++-----
3274 include/linux/module.h | 15 ++++---
3275 kernel/params.c | 9 +++-
3276 3 files changed, 92 insertions(+), 20 deletions(-)
...
[ merge.log of next-20110214 ]
...
3315 $ git merge quilt/rr
3316 Merge made by recursive.
3317 drivers/block/virtio_blk.c | 88
++++++++++++++++++++++++++++++++++++++-----
3318 include/linux/module.h | 15 ++++---
3319 include/linux/moduleparam.h | 22 ++++++-----
3320 kernel/params.c | 19 ++++++---
3321 4 files changed, 110 insertions(+), 34 deletions(-)
...
- EOT -