dperezde / little-penguin

https://bitbucket.org/dperezde/eudyptula
GNU General Public License v2.0
1 stars 0 forks source link

T04 #2

Closed dperezde closed 9 years ago

dperezde commented 9 years ago

Wonderful job in making it this far. I hope you have been having fun. Oh, you're getting bored, just booting and installing kernels? Well, time for some pedantic things to make you feel that those kernel builds are actually fun!

Part of the job of being a kernel developer is recognizing the proper Linux kernel coding style. The full description of this coding style can be found in the kernel itself, in the Documentation/CodingStyle file. I'd recommend going and reading that right now. It's pretty simple stuff, and something that you are going to need to know and understand. There is also a tool in the kernel source tree in the scripts/ directory called checkpatch.pl that can be used to test for adhering to the coding style rules, as kernel programmers are lazy and prefer to let scripts do their work for them...

Why a coding standard at all? Because of your brain (yes, yours, not mine, remember, I'm just some dumb shell scripts). Once your brain learns the patterns, the information contained really starts to sink in better. So it's important that everyone follow the same standard so that the patterns become consistent. In other words, you want to make it really easy for other people to find the bugs in your code, and not be confused and distracted by the fact that you happen to prefer 5 spaces instead of tabs for indentation. Of course you would never prefer such a thing, I'd never accuse you of that, it was just an example, please forgive my impertinence!

Anyway, the tasks for this round all deal with the Linux kernel coding style. Attached to this message are is one kernel module that does not follow the proper Linux kernel coding style rules. Fix this file up, AND fix up the final submission you did for Task 01, and send them back to me as attachments in your response email.

Yes, the logic in attached second module is crazy, and probably wrong, but don't focus on that, just look at the patterns here, and fix up the coding style, do not remove lines of code.

Oh, and before you think "Ah, but I got the coding style right for Task 01, I already know this stuff!", remember that so far only 10 people, out of over 4000, have gotten the coding style exactly right for their Task 01 module. Yes, you could be one of those people, but the odds are not in your favor. You should look at it again just to be sure.

So again, attach 2 files, this one fixed up, and your Task 01 submission. Don't use base64 either, the scripts will instantly reject it, you don't want to get on their bad side.

dperezde commented 9 years ago

After reading Documentation/CodingStyle, we used these tools from the scripts directory:

checkpatch.pl -f cleanpatch cleanfile

I have also modified my .vimrc to limit line width to 80 characterers: set tw=80 :set formatoptions+=t

To limit line width on files previously written I used the vim built-in gq utility: https://robots.thoughtbot.com/wrap-existing-text-at-80-characters-in-vim

I have also added the following plugin to my .vim/plugins/ folder: https://github.com/bhilburn/kernel-coding-style

dperezde commented 9 years ago

Little commented:

Why did you change the logging level?

dperezde commented 9 years ago

After Little asking to revert the logging to what the default printk has, I had to do a bit of research. In order to get the default logging level for the system you have to cat /proc/sys/kernel/printk 4 4 1 7

from http://tuxthink.blogspot.com.es/2012/07/printk-and-console-log-level.html we get:

The first number in the output is the console log level, the second is the default log level, third is the minimum log level and fourth is the maximum log level.

4 = KERN_WARNING

dperezde commented 9 years ago

printk is default leveled to DEBUG, so all printk messages (both in t01 and t04 code) are changed to pr_debug and voila!!!