Skip to contentSkip to conversation

kj-devel.pl - new changes

KJ [email protected] 2 participants 2 messages Feb 10, 2005 Kernel janitors

lore
Share & tools
lore
#0 lore raw

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.

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#1 lore raw
Quoted 3 lines · On Thu, Feb 10, 2005 at 07:27:12PM +0000, [email protected] wrote:

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?

Go wild, I've no intention of touching it again 8-)

Dave

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors