On Tue, 5 May 2009, Alan Jenkins wrote:
On Tue, May 5, 2009 at 2:43 AM, Robby Workman <rworkman@xxxxxxxxxxxxx> wrote:
generate-modprobe.conf | 281
------------------------------------------------
If you look at "git-log generate-modprobe.conf", you see it's had
multiple patches submitted this year. Now, given the history of m-i-t
development, it's possible that the patches were just extremely
delayed and no-one will care if you delete it. But I think you should
CC the patch authors and find out why they cared enough to submit them
:-).
Okay, fair enough, but it's my understanding that all of the backwards
compat stuff for older modutils is being removed, and since part of the
aim of this patchset was to help in that regard, generate-modprobe.conf
had to go. :-) I'm hoping Jon will weigh in on this, but if not, I'll
check with the other authors.
install-with-care | 10 +--
modprobe.devfs | 62 -----------
15 files changed, 409 insertions(+), 841 deletions(-)
Changed backticks to $() command substitution.
Please note the reason for this in the changelog, I can't read your mind.
It's my understanding that the backtick-style command substitution is
more or less deprectated in favor of $()-style in the POSIX standard.
Maybe I've been misinformed, but either way, I'll note that in the
next patchset log.
doc/rmmod.sgml
+ <para><command>rmmod</command> is a trivial program to remove a module
+ from the kernel. Most users will want to use
- </citerefentry> instead, with the <option>-r</option> option.
+ </citerefentry> instead, perhaps with the <option>-r</option> option.
?
If you're looking at using rmmod, you want to remove the module. If
you coose to use modprobe instead, why do you only "perhaps" want to
use -r?
I have no friggin' idea why I added that - this is what happens when
I focus too much on "good english" rather than "good info."
doc/depmod.conf.sgml
- For example, it is possible to override the priority of
- an updated test module called <command>kmp</command> by
- specifying the following command: "override kmp * extra".
- This will ensure that any matching module name installed
- under the <command>extra</command> subdirectory within
- /lib/modules (or other module location) will take priority
- over any likenamed module already provided by the kernel.
+ For example, it is possible to override the priority of an
+ updated test module called <command>kmp</command> by specifying
+ the following command: "override kmp * extra". This will ensure
+ that any matching module name installed under the
+ <command>extra</command> subdirectory within /lib/modules (or
+ other module location) will take priority over any likenamed
+ module already provided by the kernel.
This is a random snippet pasted from the GitHub interface; it's
probably replaced tabs with 8 spaces. This looks like you edited with
4 spaces to the tab, and replaced most existing spaces with tabs, or
something. And changed the word wrapping. And it looks like the
original words are unchanged?
It looks to me like the files are supposed to be 8 spaces to the tab,
just like the C code. I.e. some of them switch randomly between
spaces and tabs, and it seems to look best with 8 spaces to the tab.
So I think you need to try harder to follow the existing convention.
That would make it much easier to review these changes.
Valid point, and I'm *not* arguing, but therein lies part of the problem:
there is no "existing convention" in the files. Some have all spaces and
some have tabs+spaces, and some are mixed randomly, it seems. Either way,
it seems that I need to check on my tab settings.
If you want to faff around with whitespace and word-wrapping, please
do a complete conversion of all files to whatever style you're
advocating, and do it in a _separate_ commit to the actual updates.
I was afraid someone would say that. :-) Believe it or not, I actually
thought about it, but it was only after I was working on the final set
of changes, so I decided to try my luck ;-) Extremely valid point, so
I'll take care of this in upcoming patchesets.
Talking of separate commits, it would be nice to avoid splitting the
commits by file. We can all read multi-file diffs; I don't think you
would have lost anything by e.g. committing all the SGML files at the
same time. That would avoid an ugly history with 8 or so commits with
the same name :-).
Sure; I didn't know the accepted way to handle that.
Thanks for the feedback, Alan - it's much appreciated. I'll get started
on some better patches and try to get them out by this weekend.
-RW
--
To unsubscribe from this list: send the line "unsubscribe linux-modules" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
