[KJ] kj-devel.pl

* [KJ] kj-devel.pl - new changes
@ 2005-02-10 19:27 vicente.feito
  2005-02-10 22:37 ` Dave Jones
  0 siblings, 1 reply; 2+ messages in thread
From: vicente.feito @ 2005-02-10 19:27 UTC (permalink / raw)
  To: kernel-janitors

[-- Attachment #1.1: Type: text/plain, Size: 3164 bytes --]

Hi, well, I've added some new features to the script.
First, I've fixed the line number problems, although there are some highline 
numbers that may seem not quite correct, but I'm going to rewrite the 
check_unlock() function if Dave don't mind me doing it, Dave? Anyway, except 
in some special cases the number lines are OK.

Now the script is presented with three options, --includes --nospinlocks 
--nomodules, the --includes allows to check the include files inside the 
source code, both types of include files, locals #include "foo.h" and 
referred to the /lib/modules/`uname -r`/build/include tree (the default it's 
not to process include files) , --nospinlocks allows to avoid the check on 
spin_* functions, I've added this so if someone wants to avoid the checks for 
whatever reason, they can, at least until I rewrite this, of course the 
default it's to check for spinlocks. The --nomodules option came to mind 
cause Randy pointed that not all files are supposed to be modules, so I've 
added this option that by now it only restricts the module_init mechanism and 
the MODULE_AUTHOR/MODULE_DESC, etc, parts, I expect to add some more 'only 
per modules' checks in the days coming, that's why this option comes handy.

The foo comment was changed as Randy suggested, completely right, and now it's 
different the way in which the script handles files, so, there's no problem 
with line numbers stacking between files.

Randy, the comments should be skipped, I've tried with string.c and it didn't 
show me any comments, care to check with this one instead? I'm only checking 
for this kind of comments /* ... */ and multiple lines 
/* bar    /*      /*
 * foo  or    foo  or even   foo */
*/     */
but I'm not checking C++ style comments, like, //, which I'm going to add soon 
cause apparently there's a lot of people that use that style, shouldn't that 
be in the CodingStyles?
I've fixed the problem with return ERR(-EBUSY); and that kind of return codes, 
now you can return anything as long as it's not return ESOMETHING, or return 
<tab>EFOO; or whatever that may be similar.

You may see some code like this:
Unmatched ) in regex; marked by <-- HERE in m/spin_unlock.*) <-- HERE 
  inside ipc_lock_by_ptr(/ at /home/rddunlap/scripts/kj-devel-vic2.pl 
line 61

This code comes from the fact that there are several similar calls to 
spinlocks, but sometimes it's not a call, it's a declaration, and instead of 
having a spinlock_t inside the ( ), being a declaration, it has a datatype 
inside, and perl has two problems with this, if it has a data type, it's not 
a function call but a declaration, so It would not match anything related 
(like an unlock function, because it's not a call), and the second problem, 
if it's a declaration, we found not only types in it, but also more ()) ())
( and that makes the regex engine mad!, so, that's gonna dissapear as soon as 
I rewrite the spinlock checking code, again, if Dave allows me to.

I'm not using diff's because the code is small, and I would have to diff from 
the original devel.pl in the kerneljanitors page. Tell me if it's easier this 
way, or the other way, thank you.

Vicente.

[-- Attachment #1.2: Type: text/html, Size: 3611 bytes --]

[-- Attachment #2: kj-devel.pl --]
[-- Type: application/x-perl, Size: 9890 bytes --]

[-- Attachment #3: Type: text/plain, Size: 167 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply	[flat|nested] 2+ messages in thread