(Application) |
|||
| Line 38: | Line 38: | ||
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. | 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. | ||
===Any relevant experience you have=== | ===Any relevant experience you have=== | ||
I have familiarity with the code base of linux kernel, kdump tool and dracut. | |||
===How do you intend to implement your proposal=== | ===How do you intend to implement your proposal=== | ||
Revision as of 04:53, 25 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
Questions to answer
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 idea page 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 linux kernel programming which have made my fundamentals strong. This project needs good amount of linux kernel programming knowledge. Also I have familiarity with the codebase of current kdump tool and dracut.Tinykdump is fundamentally similar to fedora's kdump tool also some part of dracut can be used in Tinykdump.
- 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 has helped me learn how to analyse different test cases and has 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, except the linux kernel, I haven't contributed to any other project. Essentially I'm 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.
Any relevant experience you have
I have familiarity with the code base of linux kernel, kdump tool and dracut.
How do you intend to implement your proposal
A rough timeline for your progress
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).
Any other details you feel we should consider
I am in touch with the mentor with last 1 month. I have removed some part of the original idea proposed in idea page by consulting with my mentor as I think the whole idea can't be implemented in 3 months. I will finish the leftover part after 3 months.