मेरा पहला kernel contribution मुझसे छीन लिया गया

 (ariel-miculas.github.io)
2 पॉइंट द्वारा GN⁺ 2023-09-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लेखक PowerPC32 architecture पर चलने वाले gdbserver और multi-threaded application वाले एक प्रोजेक्ट में debugging समस्या से जूझ रहे थे.
  • समस्या यह थी कि gdbserver से कनेक्शन टूट जाता था, जिससे debug session को आगे नियंत्रित नहीं किया जा सकता था.
  • शोध और जांच के बाद, लेखक को एक email thread मिली जो इस समस्या का कारण बने सटीक commit की ओर इशारा करती थी.
  • लेखक ने PowerPC architecture और task_struct के आसपास हुए बदलावों से जुड़ी commit descriptions पढ़ने में 3-4 दिन बिताए और यह समझने की कोशिश की कि क्या यह समस्या बाद के kernel versions में हल हो चुकी है.
  • लेखक ने कई tools और techniques का इस्तेमाल किया, जैसे thread_struct thread को इधर-उधर करना, pahole से task_struct का layout देखना, और ftrace का उपयोग करके यह पता लगाना कि debug किए जा रहे process के threads कब schedule हो रहे हैं.
  • लेखक ने पाया कि यह समस्या memory corruption की हो सकती है, क्योंकि फंसा हुआ thread दूसरे threads के विपरीत केवल एक बार schedule हुआ था.
  • लेखक ने Linux में hardware breakpoints का उपयोग किया और __state field पर hardware breakpoint लगाकर यह पता करने के लिए Linux kernel module बनाया कि उस पर write कौन कर रहा है.
  • लेखक ने पाया कि समस्या ptrace_put_fpr के buffer overflow (जिसका उपयोग POKEUSER API करती है) के कारण थी, जिससे task_struct के महत्वपूर्ण fields, जैसे __state, overwrite हो रहे थे.
  • लेखक ने इस समस्या को ठीक करने के लिए Linux kernel security team (security@kernel.org) को patch भेजा, क्योंकि इससे security issue पैदा हो सकता था.
  • PowerPC maintainer Michael Ellerman ने लेखक का patch स्वीकार करने के बजाय अपने version का fix लागू किया.
  • लेखक को लगा कि उनके काम को ठीक से श्रेय नहीं मिला और उन्हें कम आंका गया; उन्हें केवल Reported-by tag मिला.
  • लेखक का पहला kernel contribution एक निराशाजनक और हतोत्साहित करने वाला अनुभव रहा, जिसमें ऐसे लोगों से बातचीत शामिल थी जो यह महत्वपूर्ण नहीं मानते कि लोगों को उनके काम का उचित श्रेय मिले.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-28
Hacker News राय
  • एक लेख उस स्थिति पर है जहाँ योगदानकर्ता का patch पूरी तरह स्वीकार नहीं किया गया, लेकिन maintainer ने उसी विचार का उपयोग करके security issue को हल किया
  • कुछ टिप्पणियों में कहा गया कि भले ही पूरा patch स्वीकार न किया गया हो, maintainer को योगदानकर्ता को credit देना चाहिए था
  • अन्य टिप्पणियों में कहा गया कि maintainer का patch बेहतर और अधिक efficient था, लेकिन योगदानकर्ता ने समस्या पहचानी और समाधान सुझाया, इसके लिए उसे मान्यता मिलनी चाहिए
  • कुछ टिप्पणियों में कहा गया कि Linux kernel कोई reward नहीं है, और maintainer को सबसे अच्छा समाधान चुनने का अधिकार है, साथ ही योगदानकर्ता को credit देने के महत्व पर भी ज़ोर दिया गया
  • patch idea सुझाने वाले व्यक्ति को credit देने के तरीके के रूप में kernel documentation के "Suggested-by" tag का उल्लेख किया गया
  • कुछ टिप्पणियों में कहा गया कि यह kernel में योगदान देने की सामान्य प्रक्रिया का हिस्सा है, और मुख्य लक्ष्य bug को ठीक करना है, न कि credit पाना
  • कुछ टिप्पणियों में open source projects में अपने योगदान के नज़रअंदाज़ हो जाने या पूरी तरह स्वीकार न किए जाने के अनुभव साझा किए गए, जो आगे योगदान देने की इच्छा को कम कर सकता है
  • कुछ टिप्पणियों में योगदानकर्ता के patch और maintainer के patch की तुलना की गई, अंतर बताए गए और सुझाव दिया गया कि मूल लेखक को credit मिलना चाहिए था
  • चर्चा में यह भी छुआ गया कि junior team members के योगदान को इस तरह संभालना महत्वपूर्ण है जो सीखने और सुधार को प्रोत्साहित करे
  • कुछ टिप्पणियों में नकारात्मक प्रतिक्रिया पर उलझन जताई गई, और कहा गया कि मान्यता महत्वपूर्ण है तथा co-author जोड़ना एक छोटा लेकिन अर्थपूर्ण कदम है
  • चर्चा का समापन diplomacy के महत्व और open source projects में दीर्घकालिक संबंध बनाए रखने पर टिप्पणियों के साथ हुआ