Want to fix bugs in Linux Kernal
 

Hi,
I am new to this forum. I am master student and I have been given assignment in advance OS course to fix two bugs in Linux Kernal. I am window user and have no idea of linux OS and compiling & fixing linux kernal means real pain in the butt. Can anybody give me idea how to see bugs from debain linux and assign them to myself and then downloading source code, compiling and then trying to fix them.
Thanks in advance.

The kernel bug report database is at kernel.org. The same website has the source code available.

The kernelnewbies site has more information about making changes to the kernel.

Since you mentioned Debian, start by installing it on a spare or virtual machine. Once you have done that you can go to the bug tracking page to find a bug you would like to work on. Then the you can install the linux kernel source and start playing with it. Post back here once you have a working installation (or if you have problems installing).

Cheers,

Evo2.

Thanks to both. You have made my day. Try to install and see...

I'm curious about the prerequisites for an "advance OS course". I don't think it makes sense to try to teach such a course to students that only know how to use one OS.

The kernel is Linux, not Debian. You might choose to install Debian as your development and test environment for work on the Linux kernel, but "bugs from debian" would be specific to that distribution and that is not the bug list you want for kernel bugs (neonsignal already gave you the right bug list).

I don't know what is done in Linux kernel development for "assign them to myself", but unless they're crazy, you can't. Among experienced reliable developers, there obviously must be a way to grab ownership of bugs to avoid duplicate effort. But too many beginners think they can fix bugs and really can't to allow beginners to take ownership of bugs. So when you select a bug to fix I don't think you can do much to discourage someone experienced from selecting the same bug after you do and fixing it before you do.

You might want to select an older lower priority bug to get the best chance of fixing it before someone else does.

I'm curious about the prerequisites
U r right John but he is not teaching linux only but giving us concepts. This is just an assignment for a month.

The kernel is Linux, not Debian.
The task was to take Debian Linux source code and fix two bugs. Here i want u people help step by step.

"Debian Linux source code" is ambiguous. It could mean the source code for all of Debian, including various utilities.

As already mentioned, the **kernel** source code is the same regardless of distro.

you, not u
I think we already did----

Go to kernel.org
get the source code
read the bug reports and pick one to work on
read the source code to find where the bug occurs
fix it.

Thanks Pixellany.

U mean that i dont need to install anything. Just download the latest source code and try to fix it.
Ok but if this is the case even then i would need help to compile source code and resolve library issues. I have been told that resolving reference issues while compiling is 50% of the work.
First of all tell me is it c code and which is best tool to work with this source code.

I think you took my comment the opposite of what I meant. I do not think it is wrong to teach OS internals using only Linux as an example. I think it is wrong to teach OS internals at all to students that only know how to use Windows.

Taken literally, I think that would mean fixing bugs in one of the few parts of Debian Linux that is exclusive to Debian Linux. Almost all of Debian Linux, including the kernel, is built from unmodified source code from other projects. Bug fixes occur in those projects, not in Debian itself.

Fixing and testing bug in some utility that is part of Debian (whether exclusive to it or not) would be much easier than fixing and testing a kernel bug.

Even that, in one month starting without Linux experience, is a very aggressive schedule.

I'm sure he didn't mean that.

Compiling and testing any part of Linux without a Linux install would be insanely difficult.

You need to install Linux in a physical or virtual machine before even starting to try to work on any bug in any part of Linux.

Almost all of "Debian Linux" is written in C. The best tool for editing C code is whatever tool you have experience using.

For me, that is Windows Visual Studio. So when I want to work on serious projects in Linux, I

Make a Samba share on the Linux system so my work directory on Linux can be mounted as a drive letter in Windows.

Open a cygwin putty window in Windows so I can issue make commands on the Linux system.

Edit the source code in Visual Studio on Windows and compile/test it in Linux via putty.

I expect you don't know how to set up Samba in Linux nor how to set up cygwin putty in Windows. But if you are a Windows user trying to start working in Linux, you ought to learn such things first (and apparently quickly).

If you want to fix and test anything that is a GUI in Linux, you may also want to set up cygwin xwin so you can use your Windows screen, mouse and keyboard for Linux GUI work.

If you were starting new small projects in Linux, I would suggest using an IDE such as CodeBlocks or KDE. But for making small changes to an existing big project (with existing makefile, etc.) you want to use a text editor that you are already comfortable with.

First of all Sorry for my wrong understanding...

Very helpful and brief suggesions. Thanks very much. I am definitely going to start working on these.

Linux Kernel Project
 

Dear Urfi, I got the same project can you please tell me how you did it when it was assigned to you, any advice?

I guess it's possible Urfi still reads this forum. But I wouldn't bet on it.

Notice the dates on posts. Also notice that you can click on the name of a poster and find their other posts. Urfi had only one other thread:
http://www.linuxquestions.org/questi...studio-804505/
That shows almost three months after the initial question he asked a follow up question that is still within the very beginning of starting to work on the project.

With progress like that, he may not be the person to ask for advice.