m (Application) |
|||
| Line 17: | Line 17: | ||
==== Do you plan to continue contributing to the Fedora Project after GSoC? If yes, what sub-project(s) are you interested with? ==== | ==== Do you plan to continue contributing to the Fedora Project after GSoC? If yes, what sub-project(s) are you interested with? ==== | ||
Yes. | Yes. It is not possible to implement the whole project idea mentioned in the DevConf 2015 in 3 months. I will leave out some less important parts which I'll finish after summer. Also I would love to maintain Tinykdump in future. | ||
===Why should we choose you over other applicants?=== | ===Why should we choose you over other applicants?=== | ||
Revision as of 06:02, 24 March 2016
- Your name: Ronit Halder
- FAS Account: Ronit
- Fedora userpage: https://fedoraproject.org/wiki/User:Ronit
- 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. It is not possible to implement the whole project idea mentioned in the DevConf 2015 in 3 months. I will leave out some less important parts which I'll finish after summer. Also 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 am fascinated to learn new algorithms. I have experience in competitive coding(codechef). It is not directly related to open source. But, I think competitive coding problems have improved the way I approach a problem in general. This helps me to analyse different test cases which improved my testing and debugging ability.
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
No, I am very new to open source.
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.
Final deliverable
The tinykdump tool which will dump the crash kernel into usb storage. Implement a linux kernel patch which will enable the tinykdump to allocate memory in run time for the second kernel(capture kernel).