Skip to contentSkip to conversation

Need to get some very basic things sorted out

KJ Dinolinux 5 participants 6 messages Sep 28, 2005 Kernel janitors

lore
Share & tools
lore

Dinolinux

author
#0 lore raw

Hey!

If you noted my last message and thougt that it was very noob, don't count on any more advancement here. ;-)

The thing is that I need help to get started. I'm in the process of learning C and I need to know how the kernel patching and distribution works.

1 - I've looked into the kernel-janitor TODO list and I don't exactly understand lines like this:
/Audit return codes (and handle failure correctly) for: /(What does this mean???)/
- request_region() /(This one was tricky)/
/Where do I have to look for the code? Do I have to go to the _entire_ kernel tree?

2 - How do I start writing patches? This doesn't tell me much:
/Before attacking any of these, we suggest sending a few patches in advance to see if you are doing something wrong, or if someone else is already doing same work.
Read related threads in the mailing list archive.
/Which patches? Where do I find a TODO list of patches that need to be done? The lkml mailing list don't say me much.

I hope this wasn't _too_ noob :-)

Dinolinux

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

#1 lore raw

Gentle People,

I'm newly registered member to the list and wanted to ask a question, if someone has time.

Is anyone aware of any outstanding bug reports regarding Slab Corruption in slab.c?

My most sincere thanks for your time,

[email protected]
Lou Bangert

/Lou:-)

-----Original Message-----
From: Dinolinux <[email protected]>
To: [email protected]
Sent: Wed, 28 Sep 2005 17:14:22 +0200
Subject: [KJ] Need to get some very basic things sorted out

Hey!

If you noted my last message and thougt that it was very noob, don't count on any more advancement here. ;-)

The thing is that I need help to get started. I'm in the process of learning C and I need to know how the kernel patching and distribution works.

1 - I've looked into the kernel-janitor TODO list and I don't exactly understand lines like this:
/Audit return codes (and handle failure correctly) for: /(What does this mean???)/
- request_region() /(This one was tricky)/
/Where do I have to look for the code? Do I have to go to the _entire_ kernel tree?

2 - How do I start writing patches? This doesn't tell me much:
/Before attacking any of these, we suggest sending a few patches in advance to see if you are doing something wrong, or if someone else is already doing same work.
Read related threads in the mailing list archive.
/Which patches? Where do I find a TODO list of patches that need to be done? The lkml mailing list don't say me much.

I hope this wasn't _too_ noob :-)

Dinolinux

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

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

#2 lore raw
In reply to Dinolinux
Quoted 8 lines · Dinolinux

The thing is that I need help to get started. I'm in the process of learning C and I need to know how the kernel patching and distribution works.

1 - I've looked into the kernel-janitor TODO list and I don't exactly understand lines like this:
/Audit return codes (and handle failure correctly) for: /(What does this mean???)/

Consider example:

	buf = kmalloc(256, GFP_KERNEL);
	buf[0] = 'L';

See the prolem? kmalloc() can return NULL, which means "Not enough memory". This buggy code doesn't check for NULL.

	buf = kmalloc(256, GFP_KERNEL);
	if (!buf)
		return -ENOMEM;
	buf[0] = 'L';

This sane code checks return value of kmalloc() and propagate proper error. Note, note, note: undoing all previous allocations if one fails is mandatory. See code around existing kmalloc()s to see how it's usually done.

Quoted 2 lines

- request_region() /(This one was tricky)/
/Where do I have to look for the code?

grep for request_region. -C option of grep is very handy in such cases.

Quoted 1 line

Do I have to go to the _entire_ kernel tree?

It would be nice if each and every request_region() call is checked for return value. Much patience is required for this.

Quoted 1 line

2 - How do I start writing patches?

less Documentation/SubmittingPatches (section 1 and the rest of
course)

Quoted 7 lines

This doesn't tell me much:
/Before attacking any of these, we suggest sending a few patches in advance to see if you are doing something wrong, or if someone else is already doing same work.
Read related threads in the mailing list archive.
/Which patches? Where do I find a TODO list of patches that need to be done?

You're reading one of them -- kernel-janitors TODO list. Things to be done.

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

#3 lore raw
In reply to Dinolinux
Quoted 31 lines · Alexey Dobriyan
Quoted 8 lines · Dinolinux

The thing is that I need help to get started. I'm in the process of learning C and I need to know how the kernel patching and distribution works.

1 - I've looked into the kernel-janitor TODO list and I don't exactly understand lines like this:
/Audit return codes (and handle failure correctly) for: /(What does this mean???)/

Consider example:

	buf = kmalloc(256, GFP_KERNEL);
	buf[0] = 'L';

See the prolem? kmalloc() can return NULL, which means "Not enough memory". This buggy code doesn't check for NULL.

	buf = kmalloc(256, GFP_KERNEL);
	if (!buf)
		return -ENOMEM;
	buf[0] = 'L';

This sane code checks return value of kmalloc() and propagate proper error. Note, note, note: undoing all previous allocations if one fails is mandatory. See code around existing kmalloc()s to see how it's usually done.

Quoted 2 lines

- request_region() /(This one was tricky)/
/Where do I have to look for the code?

Quoted 6 lines

grep for request_region. -C option of grep is very handy in such cases.

Quoted 1 line

Do I have to go to the _entire_ kernel tree?

It would be nice if each and every request_region() call is checked for return value. Much patience is required for this.

Jeff Garzik did a good piece of that work a few days ago. His email also tells what pieces remain to be done.

See
http://marc.theaimsgroup.com/?l=linux-kernel&m=112742405517833&w=2

Signature · 1 line
~Randy

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

#4 lore raw
In reply to Dinolinux

Quoting Alexey Dobriyan <[email protected]>
Sent on Wed, 28 Sep 2005 21:56:14 +0400

Hello,

Quoted 4 lines
	buf = kmalloc(256, GFP_KERNEL);
	if (!buf)
		return -ENOMEM;
	buf[0] = 'L';

*please* correct me if I'm wrong, but I remember reading somewhere a Linus' message stating that one should not use "if (!pointer)" for pointers when it is intended to do "if (pointer == NULL)". in short, what I remember is that one should not assume that NULL == 0, thus the explicit NULL checking.

a quick search revealed these:

	http://lwn.net/Articles/93574/
	http://lwn.net/Articles/93577/

are these still valid? (I presume yes, but...)

Regards.

Signature · 5 lines
Ricardo Nabinger Sanchez
GNU/Linux #140696 [http://counter.li.org]
Slackware Linux + FreeBSD

  Left to themselves, things tend to go from bad to worse.

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

#5 lore raw
In reply to Dinolinux
Quoted 15 lines · Ricardo Nabinger Sanchez

Quoting Alexey Dobriyan <[email protected]>
Sent on Wed, 28 Sep 2005 21:56:14 +0400

Hello,

Quoted 4 lines
	buf = kmalloc(256, GFP_KERNEL);
	if (!buf)
		return -ENOMEM;
	buf[0] = 'L';

*please* correct me if I'm wrong, but I remember reading somewhere a Linus' message stating that one should not use "if (!pointer)" for pointers when it is intended to do "if (pointer == NULL)". in short, what I remember is that one should not assume that NULL == 0, thus the explicit NULL checking.

Quoted 4 lines

a quick search revealed these:

	http://lwn.net/Articles/93574/
	http://lwn.net/Articles/93577/

These say:
don't use 0 for a (null) pointer and
don't use NULL for an integer value.

Quoted 1 line

are these still valid? (I presume yes, but...)

Sure, those are valid, but they aren't the same as the first example above. I don't see anything wrong with what Alexey wrote.

Signature · 1 line
~Randy

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