New guy here, and patch for kj.pl

Hi all.

Here is a patch for kj.pl
It doesn't detect the MOD_{INC,DEC}_USE_COUNT correctly because of a false regexp !

The message is also to be change it says : "Net drivers should call SET_MODULE_OWNER instead of MOD_{INC,DEC}_USE_COUNT" but MOD_{INC,DEC}_USE_COUNT is deprecated for all not only for netdrivers.

I also got a question, If i want to patch something on kernel with help of TODO document, do i have to tell semeone before to not work on same files that someone else or not ?

Mickaël GRIGOUZE	      [email protected]	        ICQ : 42799256
*** \-/ ***  In a World Without Fences Who Needs Gates *** \-/ ***
_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

On Sun, 25 Jan 2004 13:37:47 +0100 JOUANNE Mickael <[email protected]> wrote:

| Hi all.
| 
| Here is a patch for kj.pl
| It doesn't detect the MOD_{INC,DEC}_USE_COUNT correctly because of a
| false regexp !
| 
| The message is also to be change it says : "Net drivers should call
| SET_MODULE_OWNER instead of MOD_{INC,DEC}_USE_COUNT" but
| MOD_{INC,DEC}_USE_COUNT is deprecated for all not only for netdrivers.
| 
| I also got a question, If i want to patch something on kernel with help
| of TODO document, do i have to tell semeone before to not work on same
| files that someone else or not ?

(did anyone reply to your question?)

It's best to let the mailing list know that you plan to tackle something, in case someone else is already working on it.

It's also a good idea to post some changes early so that you get some feedback on them before spending lots of time on it and that time being wasted in the case that it's all wrong/bad.

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

Hi! I'm another new guy here on kj and a few days ago I wrote a little patch to show that I want to tackle the removal of some unnecessary min/max-methods in the kernel.

I didnt get any feedback yet, but I guess since nobody screamed (and I found some more occurences) I'm going to try my best.

Also being new to kernel hacking (and the depth of c-programming) I have a question, which hopefully one of you can help me with:

For example fs/lockd/mon.c has a MAX-function which is used in

#ifndef MAX

# define MAX(a, b)....
#endif

static struct rpc_procinfo nsm_procedures[] = {

[SM_MON] = {
		.p_proc		= SM_MON,
		.p_encode	= (kxdrproc_t) xdr_encode_mon,
		.p_decode	= (kxdrproc_t) xdr_decode_stat_res,
		.p_bufsiz	= MAX(SM_mon_sz, SM_monres_sz) << 2,
	},
[SM_UNMON] = {
		.p_proc		= SM_UNMON,
		.p_encode	= (kxdrproc_t) xdr_encode_unmon,
		.p_decode	= (kxdrproc_t) xdr_decode_stat,
		.p_bufsiz	= MAX(SM_mon_id_sz, SM_unmonres_sz) << 2,
	},
};

but replacing the call of it with max(...) from kernel.h results in following:

CC fs/lockd/mon.o
fs/lockd/mon.c:216: error: braced-group within expression allowed only inside a function
fs/lockd/mon.c:216: error: initializer element is not constant fs/lockd/mon.c:216: error: (near initialization for `nsm_procedures[2].p_bufsiz')
fs/lockd/mon.c:216: error: parse error before ')' token fs/lockd/mon.c:216: error: initializer element is not constant fs/lockd/mon.c:216: error: (near initialization for nsm_procedures[2]') fs/lockd/mon.c:218: error: parse error before '[' token fs/lockd/mon.c:222: error: parse error before "void" fs/lockd/mon.c:179: warning: xdr_encode_unmon' defined but not used fs/lockd/mon.c:199: warning: `xdr_decode_stat' defined but not used make[2]: *** [fs/lockd/mon.o] Error 1
make[1]: *** [fs/lockd] Error 2
make: *** [fs] Error 2

Can anyone help me with that error code?

Thanks in advance
Michael Veeck

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

No screaming is usually good :-)

<snipped some code that uses MAX in struct initializers>

The problem is struct initializers can't be code (max evaluates to some code, while MAX works fine, as the preprocessor does all the work).

In this case that MAX looks like the right thing, except for arguments used twice in #define.

Any better ideas than leaving this as it is now?

Domen

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

On Thu, 05 Feb 2004 22:50:57 +0100 Michael Veeck <[email protected]> wrote:

| 
| 
| Domen Puncer wrote:
| > On Thursday 05 of February 2004 11:20, Michael Veeck wrote:
| > 
| >>Hi! I'm another new guy here on kj and a few days ago I wrote a little
| >>patch to show that I want to tackle the removal of some unnecessary
| >>min/max-methods in the kernel.
| >>
| >>I didnt get any feedback yet, but I guess since nobody screamed (and I
| >>found some more occurences) I'm going to try my best.
| > 
| > 
| > No screaming is usually good :-)
| 
| Good, than I'll try finding some more Min/Max-Unnecessarieness and keep 
| that diffed against the latest kernel until it gets included.
| 
| Is it preferrable to generate indivual patches or (since it isnt really 
| intrusive) to post one big patch?

One patch per source file, unless that is just too tedious, and then try something like one patch file per sub-directory, or one patch file per set of related files.
Not just one large patch, please.

| > <snipped some code that uses MAX in struct initializers>
| > 
| >>Can anyone help me with that error code?
| > 
| > 
| > The problem is struct initializers can't be code (max evaluates to some code, 
| > while MAX works fine, as the preprocessor does all the work).
| > 
| > In this case that MAX looks like the right thing, except for arguments used 
| > twice in #define.
| > 
| > Any better ideas than leaving this as it is now?
| 
| I dont know (yet) if there are more of those min-in-struct-inits, so 
| that we could put one #define in one place and remove the then obsolete 
| ones.

I'm happy that Domen recognized that problem so quickly.

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

Good, than I'll try finding some more Min/Max-Unnecessarieness and keep that diffed against the latest kernel until it gets included.

Is it preferrable to generate indivual patches or (since it isnt really intrusive) to post one big patch?

I dont know (yet) if there are more of those min-in-struct-inits, so that we could put one #define in one place and remove the then obsolete ones.

Regards
Michael

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