From Fedora Project Wiki
(Application)
(Application)
Line 27: Line 27:
Yes, I have contributed to linux kernel. I have done some bug fixes in staging tree. This is the link to my patches  
Yes, I have contributed to linux kernel. I have done some bug fixes in staging tree. This is the link to my patches  
https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/log/?qt=grep&q=Ronit+Halder
https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/log/?qt=grep&q=Ronit+Halder
==Proposal Description==
===Overview and The Need===
Debugging is the most challenging part of linux kernel programming. Linux kernel behaves very differently depending on the current devices attached and the kernel configuration. This makes  reproduction of some bugs very hard. For example if an unknown bug creates a kernel panic then we have no easy way to find the bug. The only way to get some evidence is to take the crash dump using the kdump tool.
In case of a kernel panic, the kdump tool  boots a new kernel (known as capture kernel) from the crashed kernel using the kexec system call (a kernel to kernel bootloader) and  retrieves the memory of crashed kernel by the /proc/vmcore interface.
The intention of this project is to make a more flexible, reliable and lightweight (with less memory footprint) kernel crash dumping tool that can replace kdump.

Revision as of 13:33, 22 March 2016

  • Email Address: ronit.crj@gmail.com
  • Blog URL: rcodin.github.io
  • Freenode IRC Nick: ronith

Why do you want to work with the Fedora Project?

I am using Fedora for some time. The thing different about fedora is that it keeps the software packages up to date and it's stable. This is main reason for me choosing fedora as a linux distribution. Fedora community consists of experienced redhat employees and volunteers.This community provides opportunity work with and learn from great people. I already felt that by talking to the mentor of the project idea.

Do you have any past involvement with the Fedora project or any other open source project as a contributor?

I don't have any involvement with Fedora Project till now. I contributed to linux kernel. I have done some bug fixes in staging tree.

Did you participate with the past GSoC programs, if so which years, which organizations?

Not yet but I'm looking forward to work with Fedora.

Do you plan to continue contributing to the Fedora Project after GSoC? If yes, what sub-project(s) are you interested with?

Yes. The whole project idea mentioned in the DevConf 2015 is not possible to implement in 3 months. I am leaving some less important part. I will finish them after summer. I would love to maintain Tinykdump in future.

Why should we choose you over other applicants?

  • I am enthusiastic, tenacious and hard working.
  • I have done bug fixes in the mainline kernel and have also completed the eudyptula challenge, theses activities have given me hands-on experience and exposure on the practical nuances and complexities of efficient kernel programming. I have read some of the essential textbooks, Documentation and online resources(mainly lwn.net) on the topics which have made my fundamentals strong. This project needs good amount of linux kernel programming. I have familiarity with the codebase of current kdump tool and dracut.Tinykdump is fundamentally same as fedora's kdump tool and some part of the dracut can be used in Tinykdump. I have done a some college projects in python. I am primarily a C programmer. I think I know enough python to get this project done.
  • I am very interested in this project. I am learning about linux kernel for last 1 year. Now I want to implement something. By this project I can fulfill my dream.
  • I love challenges and that is the reason I choose system programming.

Have you contributed to any other open source organizations or projects? If so, do you have artifacts you can show so we can see your skill set(s)?

Yes, I have contributed to linux kernel. I have done some bug fixes in staging tree. This is the link to my patches https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/log/?qt=grep&q=Ronit+Halder

Proposal Description

Overview and The Need

Debugging is the most challenging part of linux kernel programming. Linux kernel behaves very differently depending on the current devices attached and the kernel configuration. This makes reproduction of some bugs very hard. For example if an unknown bug creates a kernel panic then we have no easy way to find the bug. The only way to get some evidence is to take the crash dump using the kdump tool.

In case of a kernel panic, the kdump tool boots a new kernel (known as capture kernel) from the crashed kernel using the kexec system call (a kernel to kernel bootloader) and retrieves the memory of crashed kernel by the /proc/vmcore interface.

The intention of this project is to make a more flexible, reliable and lightweight (with less memory footprint) kernel crash dumping tool that can replace kdump.