Kontribusi kernel pertama saya dicuri

• Ariel Miculas menelusuri masalah debugging multithread gdbserver yang rusak di PowerPC32 dan menemukan bug korupsi memori di kernel Linux, tetapi perbaikan akhirnya masuk sebagai patch terpisah dari maintainer dan ia hanya mendapat kredit Reported-by
• Petunjuknya adalah thread email lama yang membahas gejala yang sama serta commit perubahan posisi thread_struct thread di dalam task_struct, yang berujung pada beberapa thread tetap berada dalam status proses yang salah sehingga gdbserver kehilangan kendali
• Analisis akar masalah menggunakan pahole, ftrace, dan breakpoint perangkat keras berbasis PowerPC DABR, serta mengonfirmasi bahwa buffer overflow di ptrace_put_fpr menimpa field seperti task_struct.__state
• Overflow terjadi karena indeks untuk elemen 32-bit diterapkan ke array 64-bit, sehingga di belakang array fp_state.fpr yang hanya memiliki 32 entri, gdbserver di sisi pengguna dapat menulis hingga 256 byte
• Maintainer PowerPC Michael Ellerman menerapkan perbaikan versinya sendiri, lalu balasan berikutnya berisi permintaan maaf bahwa kontribusi tersebut tidak tercermin dengan layak hanya lewat Reported-by dan patch itu seharusnya dikembangkan bersama

---

Debugging gdbserver yang rusak di PowerPC32

• Sekitar satu setengah tahun lalu, Ariel Miculas meminta waktu di perusahaan lamanya untuk menyelidiki masalah yang menghambat kemampuan debugging dalam sebuah proyek
• Masalahnya adalah gdbserver tidak bisa melakukan debugging aplikasi multithread dengan benar di arsitektur PowerPC32
  • Koneksi gdbserver terputus dan sesi debug tidak lagi bisa dikendalikan
  • Tidak jelas apakah penyebabnya ada di toolchain, gdbserver, kernel Linux, atau patch kernel kustom
• Setelah penyelidikan dan pencarian, ia menemukan thread email yang membahas gejala yang sama
  • Thread ini juga menunjuk ke commit yang memicu masalah
  • Patch tersebut memindahkan definisi thread_struct thread yang semula berada di tengah task_struct ke bagian akhir

Petunjuk yang mengerucut ke korupsi memori pada status thread

• Menurut analisis sebelumnya dari Holger Brunck, gdbserver mengirim SIGSTOP ke kernel untuk setiap thread dan menunggu respons, tetapi dalam kondisi error kernel hanya merespons sebagian sinyal
• Di level rendah, setelah berinteraksi dengan gdbserver beberapa thread masuk ke status proses yang salah, dan gdbserver kemudian kehilangan kendali
• Ariel membaca deskripsi commit terkait PowerPC dan perubahan di sekitar task_struct selama 3–4 hari sambil memeriksa apakah masalahnya sudah terselesaikan di versi kernel yang lebih baru, tetapi tidak menemukan solusi
• Ia mengubah-ubah posisi thread_struct thread untuk memverifikasi kondisi reproduksi, lalu memeriksa layout task_struct dengan pahole
• Ia memakai ftrace untuk melacak kapan thread dari proses yang sedang didebug dijadwalkan
  • Thread yang macet hanya dijadwalkan satu kali, tidak seperti thread lainnya
  • Pengamatan ini membuatnya kembali mempertimbangkan kemungkinan korupsi memori

Akar masalah sebenarnya ditemukan lewat breakpoint perangkat keras

• Ia memastikan bahwa seperti debug registers di x86, PowerPC juga memiliki fungsi serupa melalui register DABR
• Setelah meneliti cara menggunakan breakpoint perangkat keras di Linux, ia mengimplementasikan modul kernel berdasarkan jawaban Stack Overflow
• Dengan modul ini, ia memasang breakpoint perangkat keras pada field task_struct.__state untuk melacak siapa yang menulis nilainya
• Modul kernel kustom itu menampilkan stack trace dari lokasi penulisan ke task_struct.__state, dan salah satu jalur yang mencurigakan mengarah ke buffer overflow di ptrace_put_fpr
• ptrace_put_fpr digunakan dalam API POKEUSER, dan overflow tersebut menimpa field penting di task_struct seperti __state
  • __state menyimpan status proses
  • Kernel juga memakai field ini saat melacak proses yang dihentikan oleh debugger

Penulisan array yang bisa melewati batas hingga 256 byte

• Penyebab overflow adalah indeks yang dirancang untuk menulis ke array elemen 32-bit diterapkan ke array elemen 64-bit
• Indeks yang menunjuk ke FPR berjumlah 64, sehingga rentang akses berdasarkan elemen 64-bit menjadi 64 * 8 = 512 byte
• Padahal array fp_state.fpr yang sebenarnya hanya memiliki 32 entri, jadi memori yang tersedia hanya 32 * 8 = 256 byte
• Akibatnya, pengguna—yakni gdbserver—dapat menulis melewati akhir array hingga 256 byte

Pengajuan upstream dan konflik kredit

• Ariel menilai masalah korupsi memori yang dapat menimpa memori status proses ini berpotensi berdampak pada keamanan, lalu mengirim patch ke [e-mail]
  • Karena mailing list ini bersifat privat, patch yang awalnya ia kirim tidak bisa ditautkan
• Maintainer PowerPC Michael Ellerman menghubunginya secara pribadi dan mengatakan ia akan menangani masalah tersebut
• Ariel mengirim dua patch perbaikan
  • Patch asli yang ia kirim ke mailing list keamanan
  • Versi patch lain yang mencerminkan saran atas pengajuan awalnya
• Patch kedua didasarkan pada kode kernel yang sudah ada untuk mengemulasikan perilaku PowerPC32 di PowerPC64, dan kode itu memang sudah menangani pengindeksan FPR dengan benar
• Michael Ellerman tidak menerima kedua patch itu dan justru membuat perbaikannya sendiri
• Ariel ingin patch miliknya diterima demi pengakuan atas perbaikan masalah ini dan sebagai kredit untuk kontribusi kernel pertamanya, dan ia juga bersedia mengirim versi lanjutan dengan memasukkan umpan balik
• Pada kenyataannya, kredit yang ia terima hanya tag Reported-by, dan Ariel merasa itu tidak adil dibanding usaha yang ia curahkan untuk analisis akar masalah, perbaikan, pengujian, verifikasi, memasukkan masukan internal perusahaan, dan penerapan ke kernel terbaru
  • Dalam dokumentasi Linux, Reported-by adalah tag untuk memberi kredit kepada orang yang menemukan dan melaporkan bug
  • Masalah ini sendiri sebenarnya sudah pernah dilaporkan 6 tahun sebelumnya

Pembaruan dan balasan permintaan maaf

• Pengguna Hacker News menyoroti email dari Michael Ellerman yang berbunyi, “terima kasih atas patch-nya, tetapi saya ingin memperbaikinya dengan cara berbeda. Bisakah Anda menguji patch di bawah ini untuk memastikan bug-nya teratasi?”
• Email ini menunjukkan bahwa Michael Ellerman memilih membuat implementasinya sendiri alih-alih me-review patch Ariel, lalu meminta Ariel menguji patch tersebut
• Ariel menemukan kembali patch asli yang sebelumnya ia kirim ke mailing list keamanan dan meneruskan thread email itu ke linuxppc-dev
• Pembaruan berikutnya mencakup balasan permintaan maaf tentang cara patch tersebut ditangani
  • Di dalamnya ada pernyataan bahwa ia “seharusnya meluangkan lebih banyak waktu untuk mengembangkan patch Anda bersama-sama”
  • Balasan itu juga menyatakan bahwa tag Reported-by tidak cukup mencerminkan kontribusi Ariel

[GN⁺]

Komentar Hacker News

• Meski tidak menerima seluruh patch, akan lebih tepat jika memberikan kredit kepada Ariel Miculas
  Isu keamanan ini kemungkinan besar tidak akan diperbaiki siapa pun jika ia tidak menemukannya dan mengirimkan usulan perbaikan
  Jika Michael membaca patch-nya, hanya mengubah sebagian gaya, lalu mengirimkannya atas namanya sendiri, tidak memberi kredit itu tidak etis; sekalipun kodenya buruk, itu tetap sebuah kolaborasi, jadi jika diperlakukan seperti itu orang mungkin tidak ingin bekerja bersama lagi

  • Dulu saya mengira tidak apa-apa mengambil kontribusi orang lain, menulis ulang sepenuhnya di branch saya lalu me-merge-nya, atau menulis ulangnya sebagai commit baru di PR GitHub
    Untuk yang terakhir, setidaknya Co-Authored-By masih tersisa, tetapi setelah seseorang men-dump kode proyek saya ke repositorinya sendiri tanpa riwayat commit lalu menyebutnya “fork”, saya baru sadar bahwa dari sisi kontributor itu pengalaman yang cukup pahit
    Sekalipun kodenya buruk, perbaikan hasil refactoring yang akhirnya di-merge tidak akan ada tanpa kode tersebut, dan ucapan “versi saya lebih baik” bisa terasa cukup meremehkan
    Namun setelah melihat balasan yang menautkan jawaban aktual maintainer, kalimat terakhir itu tidak berlaku
  • Setuju. Maintainer bisa saja mengatakan bahwa karena alasan kualitas, kode yang masuk ke kernel akan ia tulis sendiri, dan itu sendiri bisa dipahami
    Namun dalam kasus ini, penulis lebih dekat sebagai co-author patch tersebut
    Kalau dianalogikan dengan publikasi akademik, ini mirip ketika Anda mengirim preprint kepada seseorang, lalu orang itu menerbitkan makalah tentang topik yang sama tetapi hanya mencantumkan Anda di ucapan terima kasih, bukan sebagai co-author
    Di sini bukan publikasi melainkan pengembangan kernel, tetapi pencantuman penulis tetap penting dalam CV profesional
  • Saya melihat peran maintainer berpengalaman sebagai fasilitator yang membantu semaksimal mungkin agar kontribusi orang lain masuk dengan rapi
    Masukan tentang konsistensi gaya dan struktur memang diperlukan, tetapi maintainer yang baik adalah orang yang mengakui kredit dan membuat pekerjaan mengalir mulus di belakang layar
  • Saat beberapa kali pertama mengirim patch ke kernel Linux, itu bahkan sebelum pengiriman semi-otomatis melalui LKML dimungkinkan, jadi saya menjalankannya sambil berdiskusi dengan maintainer
    Ketika itu Ted Tso puas dengan kebenaran pekerjaan saya lalu memasukkan patch tersebut, dan saya tidak meminta maupun menerima kredit
    Minat saya hanya memperbaiki kernel, bukan meninggalkan nama
    Beberapa tahun kemudian nama saya memang masuk daftar kontributor karena pekerjaan lain, tetapi saya tidak peduli mana pun hasilnya
  • Ia mendapat kredit. Di commit tertulis Reported-by: Ariel Miculas, dan itu tampak akurat

• Patch maintainer lebih baik

  1. Pada kasus 32-bit, pemeriksaan fpidx < (PT_FPSCR - PT_FPR0) tidak hilang
  2. Pada fungsi put, assignment pengganti *data = child->thread.fp_state.fpscr; yang dipakai saat fpidx di luar rentang tidak hilang
  3. Menghindari makro FPRINDEX yang tidak perlu, yang menyederhana menjadi identitas jika TS_FPRWIDTH bernilai 1
     Pesan commit patch asli mengatakan “di PPC32 boleh diasumsikan bahwa TS_FPRWIDTH adalah 1”, tetapi tetap menyertakan FPRNUMBER, FPRHALF, FPRINDEX
     Hanya karena menemukan ketidakcocokan array yang bisa diperbaiki dengan sederhana, bukan berarti patch yang buggy harus diterima begitu saja
     Namun maintainer seharusnya mengakui bahwa Miculas bukan sekadar melaporkan, melainkan menyelidiki, menemukan akar penyebab, dan bahkan membuat versinya sendiri dari perbaikan sederhana yang hampir sama
     Reported-by tidak tepat untuk menyiratkan bahwa pihak terkait telah menyelidiki secara menyeluruh sampai mengidentifikasi penyebabnya
  • Saya setuju bahwa pekerjaan maintainer lebih baik. Namun ia bisa saja melakukan code review terhadap patch tersebut dan meminta pembaruan
    Untuk kontributor baru, itulah yang lazim dilakukan di proyek, dan itu cara yang benar
    Itu adalah proses mengajari dan membantu orang beradaptasi; jika pekerjaan itu langsung dikerjakan ulang begitu saja, motivasi berkontribusi akan patah dan kesempatan belajar juga hilang
  • Debugging itu sulit, dan kadang sangat sulit. Menulis perbaikan di codebase yang sudah dikenal relatif sepele, terutama jika ada versi yang berjalan dari perbaikan sebelumnya sebagai panduan
    Menulis versi kedua selalu lebih mudah
    Menyebut ini perbaikan sederhana berarti tidak memahami jumlah pekerjaan yang masuk ke perbaikan bug dalam pengembangan perangkat lunak
    Di sini Michael sendiri mengakui bahwa awalnya ia tidak bisa mereproduksinya dan baru kemudian mengonfirmasinya
    Ini menunjukkan dengan jelas besarnya pekerjaan yang OP curahkan untuk debugging dan perbaikan, dan mengambil alih pekerjaan itu tidaklah benar
  • Pernyataan “Hanya karena menemukan ketidakcocokan array yang bisa diperbaiki dengan sederhana, bukan berarti patch yang buggy harus diterima begitu saja” adalah memelintir ucapan orang lain
    Di tulisan asli, ia mengatakan ingin patch-nya diterima, mendapat kredit, menjadi kontributor kernel, dan bersedia mengirim versi lanjutan yang mencerminkan feedback
  • Tidak ada yang mengatakan patch asli harus diterima begitu saja
    Maintainer cukup checkout kode OP, membuat perubahan yang diinginkannya, lalu meluangkan sekitar 2 menit yang diperlukan untuk melakukan commit dengan co-author
    Dengan begitu perbaikan terbaik di-merge dan pekerjaan orang lain juga diakui
    Terutama karena OP secara jelas menyatakan ingin mendapat pengakuan, itu adalah pilihan terbaik
    Namun para maintainer repositori seperti ini tampaknya sering melewatkan tata krama sosial, jadi tidak terlalu mengejutkan
  • Saya telah mengirim banyak patch dan PR ke berbagai open source, dan kebanyakan tujuannya untuk menyelesaikan ketidaknyamanan saya sendiri
    PR sering tidak diterima karena berbagai alasan, tetapi saya tidak ambil pusing
    Saya mengirim PR untuk membuat kode itu tersedia secara publik, dan tidak menghabiskan waktu untuk membuatnya cukup “bagus” agar di-merge
    Saya memberikannya apa adanya; jika seseorang cukup menyukainya, orang itu bisa mengurus prosesnya
    Ada yang di-merge apa adanya, ada yang sedikit diperbaiki pemilik repositori lalu di-merge
    Saya menulis kode open source bukan demi kejayaan atau popularitas, melainkan karena saya menyukainya
    Saya merindukan era 80-an dan 90-an

• Kernel Linux bukanlah imbalan, dan meski saya bersimpati kepada OP, memang benar komunitas lebih memilih solusi yang lebih mudah dipelihara daripada versi yang datang dari OP
  Jadi maintainer masih berada dalam lingkup kewenangannya
  Namun memberi pengakuan kontribusi kepada orang yang ikut memperbaiki itu sangat mudah
  Di Node.js, kami memberi kredit di catatan rilis, dan ketika mengambil sebagian pekerjaan dari PR lalu memodifikasinya, kami berusaha menambahkan Co-Authored-By:
  Setelah lama menjadi maintainer, kredit menjadi kurang penting bagi diri sendiri, sehingga mudah lupa bahwa hal itu sangat penting bagi kontributor baru
  Dalam kasus ini, ketika berbagi kredit penting bagi OP dan memang pantas, kurangnya perhatian lebih besar adalah kerugian bagi OP maupun bagi area Linux tersebut

  • Jika seseorang mencurahkan banyak upaya untuk berkontribusi ke proyek lalu memperbaiki kontribusinya, tetapi pada akhirnya diberi tahu “versi saya lebih baik, jadi pergi saja”, tentu akan marah
    Itu bukan cara proyek yang bergantung pada upaya komunitas dapat bertahan
    Saya kira proyek sebesar dan seterhormat kernel Linux memiliki orang-orang yang bisa menjaga kepentingan terbaik proyek sekaligus menghormati kontributor baru
    Tidak ada yang mengatakan solusi yang bukan terbaik harus diterima hanya karena berasal dari kontributor baru
    Cara yang benar adalah meninjau patch, menjelaskan apa masalahnya dan mengapa, menyarankan bagaimana menulis ulangnya, lalu jika perlu menulis bagian itu bersama sehingga menjadi co-author
    Dengan begitu, akan tercipta aliran kontributor yang tetap tertarik ke depannya
  • Ungkapan “kernel Linux bukanlah imbalan” tampaknya benar dalam arti terburuk jika melihat tulisan ini
  • Ia tampaknya mendapat kredit melalui tag Reported-By

• Dokumentasi kernel mendefinisikan Suggested-by sebagai salah satu konvensi tag
  Tag Suggested-by: menunjukkan bahwa ide patch tersebut diusulkan oleh orang itu, dan menjamin kredit atas ide tersebut
  Disebutkan juga bahwa terutama jika ide itu tidak dipublikasikan di forum publik, tag ini tidak boleh ditambahkan tanpa izin pengusulnya
  Tercantum pula maksudnya bahwa jika pemberi ide diberi kredit dengan sungguh-sungguh, kemungkinan mereka akan membantu lagi di masa mendatang menjadi lebih besar
  Dalam situasi ini, Suggested-by mungkin lebih tepat
  Itu lebih baik menyampaikan makna bahwa ia menemukan solusi untuk masalahnya, tetapi karena belum akrab dengan proyek, sintaks patch yang tepat tidak dipertahankan
  Referensi: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • Saya belum membandingkan patch-patchnya, tetapi menurut komentar di bawah [1], satu-satunya perbedaan antara patch yang diterima dan patch yang diusulkan adalah lokasi perbaikannya
    Perbedaannya hanya satu berada di ifdef di luar if, sedangkan yang lain berada di pernyataan if di dalamnya; itu bukan perbedaan teknis, melainkan perbedaan gaya
    Jika demikian, penulis melakukan jauh lebih banyak daripada sekadar “mengusulkan” ide patch
    Ia men-debug isu dan menulis seluruh patch, lalu patch itu diterima dengan satu perubahan kecil
    1: https://news.ycombinator.com/item?id=37672558
  • Cara itu juga mungkin, tetapi sepertinya lebih cocok untuk kasus yang bukan isu keamanan
    Dalam isu keamanan, kecepatan dan akurasi lebih penting daripada format, dan para maintainer kernel menanganinya dengan benar karena memberi kredit lewat Reported-by
Suggested-by memang sedikit lebih baik, tetapi bukan itu yang diinginkan OP; OP tampaknya menginginkan label “kontributor kernel” berdasarkan patch yang sangat kecil

• Melihat sebagian reaksi di thread ini, saya berharap beberapa orang tertentu tidak mengelola developer junior atau menengah
  Jika di tim ada junior yang antusias, lalu ia membuat PR yang membantu untuk suatu isu tetapi kualitasnya kurang, menegurnya dengan mengatakan “belum cukup bagus”, membuang kodenya, lalu menulis ulang sendiri adalah respons terburuk
  Itu mematahkan semangat, membuang waktu orang itu dan waktu Anda sendiri, membuatnya tidak belajar apa pun, membuatnya tidak bisa memperbaiki diri atau berkontribusi secara berarti lain kali, serta membuatnya enggan meminta bantuan atau berkontribusi secara sukarela
  Sekalipun ia terjun ke area kode yang kompleks, ada cara interaksi yang lebih baik

  • Mengelola dan membimbing junior di perusahaan atau tim berbeda dengan orang acak di internet yang mengirim patch kecil
    Untuk junior di tim, ada ekspektasi bahwa ia akan bertahan untuk sementara, dan lewat wawancara kemampuan dasarnya juga sudah diperiksa sampai taraf tertentu, jadi kita bisa percaya pada potensi pertumbuhannya
    Orang acak di internet tidak punya kewajiban untuk tetap tinggal, dan kebanyakan perbaikan “drive-by” seperti ini memang tidak bertahan
    Kita juga tidak tahu kemampuan sebenarnya orang itu, atau bagaimana ia akan merespons permintaan perbaikan
    Salah satu hal paling membuat frustrasi dari sudut pandang manajemen adalah ketika seseorang memasukkan orang acak ke dalam jalur pelaporan saya dan membuat saya bertanggung jawab atas kinerja orang itu
    Sekarang bayangkan ada seseorang di internet dengan rasa berhak yang besar menghabiskan beberapa hari membuat perbaikan berkualitas rendah, lalu saya harus membimbingnya seperti manajernya; analogi ini tidak masuk akal
    Dulu saya bertanya-tanya mengapa orang begitu ribut soal PR yang tidak diinginkan saat meng-host proyek di GitHub, tetapi sekarang saya mengerti
    Kalau tidak mau berurusan dengan PR acak lalu dituduh sebagai “manajer buruk yang mematahkan semangat dan membuang-buang waktu”, itu adalah rasa berhak yang berlebihan
    Contoh: https://news.ycombinator.com/item?id=25940799
  • Jika seorang junior yang terlalu bersemangat menyelesaikan pekerjaan selama seminggu yang bukan prioritas dan bukan tugasnya, Anda bisa memanggilnya secara terpisah dan berkata, “Ini kita tunda dulu untuk sekarang dan kita lihat lagi nanti. Saat ini X adalah prioritas, jadi kita tidak bisa menghabiskan waktu untuk ini”
    Menjadi profesional juga berarti belajar memisahkan diri sendiri dari hasil kerja, dan memahami bahwa rekan kerja tidak sedang mencoba menghalangi kita dengan rencana jahat
    Semua orang pernah mengalami proyek yang dikerjakan berbulan-bulan dibatalkan, dan pernah menerima komentar keras dalam code review
    Menerima dan belajar dari hal-hal seperti itu adalah bagian dari menjadi profesional
    Tentu saja, orang yang blak-blakan dan kasar juga harus belajar bahwa sikap seperti itu merusak banyak hubungan
    Kita bukan seniman, melainkan profesional
    Jika seorang insinyur sipil junior merancang jembatan dengan cacat struktural dan senior berkata, “Maaf, tapi ini sudah sulit diselamatkan, jadi harus dibuat ulang semuanya,” maka senior itu tidak bermasalah
    Saya tidak ingin mengemudi di atas jembatan rapuh hanya demi menjaga harga diri junior
    Komentar dari orang-orang yang tampaknya tidak punya banyak pengalaman memelihara proyek open source besar terlihat menganggap maintainer luar biasa kejam
    Kalau pernah memelihara proyek open source kecil, menerima PR dari orang acak itu banyak pekerjaannya, dan sering kali memakan waktu lebih banyak daripada mengerjakannya sendiri
    Waktu yang dibutuhkan besar untuk meninjau kode dengan saksama, berkomunikasi dengan kontributor untuk memperbaiki masalah, serta menyesuaikannya dengan kualitas dan konvensi yang diharapkan
    Junior di tempat kerja sudah melewati wawancara, tetapi di sini yang meminta perubahan adalah orang asing acak
    Ketika PR ditolak memang menyedihkan, tetapi saya memahami posisi kedua pihak
    Melihat percakapan maintainer, ia tidak tampak sangat jahat atau tidak sopan
  • Sebaiknya dibaca ulang. Tampaknya hal itu tidak benar-benar terjadi seperti itu, dan setidaknya mungkin merupakan rekonstruksi emosional dari salah satu pihak
  • Sangat mengecewakan, ada banyak komentar keras di thread ini
    Rasanya hampir seperti thread buruk di LKML
    Orang itu secara harfiah melakukan 95% pekerjaan, tetapi dikritik karena ingin jasanya diakui
    Saya benar-benar tidak mengerti kenapa
  • Thread ini terasa seperti penangkal petir yang memperlihatkan buruknya hubungan interpersonal, dan mengingat rentang usia pembaca HN, ini cukup memalukan

• Jika membandingkan kedua patch, terlihat perbedaan yang jelas
  Kontribusi di tulisan yang ditautkan mengubah perilaku kedua cabang if...else, tetapi kontribusi final hanya mengubah jalur di dalam cabang if
  Maintainer pasti punya alasan untuk mengubah kodenya
  Meski begitu, perbaikan aktualnya hampir 100% disalin, jadi sudah semestinya memberi kredit kepada penulis patch asli

  • Patch asli dalam percakapan email di atas juga demikian
    Hasil aslinya tidak memiliki flush_fp_to_thread pada arsitektur PPC32 dan juga tidak memiliki kondisi else
    Patch final memanggil flush_fp_to_thread(child);, lalu menangani berdasarkan ada tidaknya CONFIG_PPC32 di dalam pemeriksaan rentang fpidx, dan jika di luar rentang, menetapkan fpscr
    Jadi ada perbedaan nyata di antara kedua solusi
    Saya tidak bisa mengatakan mana yang benar atau lebih baik, tetapi jelas hasilnya berbeda
  • Sebagai orang yang sudah lama menggunakan C, saya akan berhati-hati jika melihat kode dengan banyak macro kustom
    Itu bisa menunjukkan kurangnya kemahiran dalam C
    Pemeliharaan codebase besar separuhnya adalah memadamkan kebakaran, dan separuhnya lagi adalah menghindari tabrakan nama
  • Saya penulis tulisannya. Sayangnya, patch asli yang saya kirim hanya dikirim ke mailing list keamanan kernel Linux, jadi tidak bisa saya tautkan
    Patch itu cukup berbeda, dan saya menyesal tidak menyimpannya di suatu tempat agar bisa ditunjukkan

• Ini adalah bagian umum dari kontribusi kernel
  Sering kali cara paling ringkas untuk menyampaikan masalah adalah dalam bentuk patch, jadi orang mengirim patch; ekspektasinya seharusnya mereka tidak akan memakai patch itu
  Sepintas saja terpikir, hal seperti ini pernah terjadi pada saya setidaknya tiga kali [1][2][3]
  Sejujurnya saya bahkan tidak pernah terpikir untuk marah, karena tujuan utama saya adalah memperbaiki bug, dan saya senang itu terjadi
  Saran tulus saya untuk OP: sebaiknya hapus tulisan blog ini. Anda akan menyesalinya nanti
  [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • Membuka nama pihak lain dan melemparkannya ke bawah bus benar-benar terlihat buruk
    Saya cukup terkejut melihat nama orang lain itu

• Di proyek open source, hal seperti ini terjadi terus, dan pada akhirnya hanya mematahkan semangat orang untuk berkontribusi lagi
  Tahun lalu saya mengambil isu yang sudah terbuka selama beberapa tahun, membuat PR, memperbaiki kode pengujian, bahkan mengerjakan pekerjaan terpisah untuk memperbaiki masalah build
  Maintainer hanya mengambil PR yang memperbaiki masalah build dan mengabaikan begitu saja isu aslinya
  Tidak ada kemungkinan saya akan meluangkan waktu lagi untuk berkontribusi ke proyek itu

  • Ada orang-orang yang seluruh resume GitHub-nya berisi kontribusi hasil salin-tempel
    Anda membuka PR, lalu mendapat komentar permintaan perubahan
    Beberapa hari kemudian ketika Anda punya waktu untuk memperbaikinya, PR itu sudah ditutup oleh PR lain dari kontributor rutin
    Jika melihat PR itu, kodenya hampir sama dengan kode Anda, hanya satu nama variabel yang berubah, dan langsung disetujui berdasarkan review “teman”
    Kalau melihat profil orang itu, hampir semua kontribusinya adalah menyalin kode orang lain
  • Sebagai maintainer proyek kecil, saya senang ketika orang berkontribusi kode atau pengujian
    Saya berusaha membantu merapikannya agar sesuai dengan bagian lain codebase, dan inilah bagian tersulit
    Karena kebanyakan developer ingin langsung memasukkan perbaikannya, alih-alih mempelajari konvensi proyek terlebih dahulu
    Namun jika kodenya kira-kira sudah benar dan setelah merge saya hanya perlu merapikan sekitar 15 menit serta menambahkan sedikit pengujian, saya akan menerimanya
    Kasus ini juga tampaknya situasi seperti itu, dan maintainer seharusnya melakukan hal tersebut
    Kontributor mendapat kredit, maintainer hanya perlu beberapa menit merapikan secukupnya agar bisa diterima upstream, dan semua orang akan senang
    Pernyataan “versi saya lebih baik” sangat arogan dan tidak profesional, entah memang lebih baik atau tidak
    Jika sebuah isu tidak berhasil diperbaiki selama 6 tahun sejak pertama kali dilaporkan, Anda harus mengakui bahwa tanpa kontribusi orang itu, perbaikan Anda juga tidak akan ada
    Setelah melihat “solusinya”, lalu mengambil perbaikan itu pada dasarnya mendekati pencurian
  • Dari pengalaman saya, yang diinginkan proyek kode adalah laporan bug dan ide perbaikan, bukan harus kode Anda
    Orang-orang menganggapnya personal ketika kode mereka tidak diterima atau ditulis ulang, tetapi mereka melewatkan bahwa menulis kode hanyalah bagian kecil dari menjalankan sebuah proyek
  • Ini masalah umum
    Saya biasanya melihat laporan bug dan merge request untuk menilai bagaimana patch akan diperlakukan
    Pada proyek yang tampaknya tidak menyenangkan untuk dikontribusikan, saya membatalkan banyak perbaikan bug begitu saja, dan kernel Linux tahun 2003 juga salah satu contohnya
    Ada proyek yang memang seperti itu, jadi lebih baik tidak terlibat, dan biasanya hanya buang-buang waktu
    Sekarang, setelah revolusi AI, pelanggaran lisensi open source terjadi secara luas, jadi sejak itu saya tidak pernah mengirim kode open source lagi dan tidak akan melakukannya ke depan

• Saya benar-benar sulit memahami toksisitas di sini
  Ucapan seperti “jangan melakukannya demi pengakuan, star, imbalan, resume, dan semacamnya” terdengar gila
  Apakah orang-orang yang mengatakan itu punya pekerjaan? Kalau punya, agar konsisten mereka seharusnya bekerja sepenuhnya gratis
  Gaji juga merupakan salah satu bentuk pengakuan atas kontribusi
  Secara pribadi, meskipun solusi akhirnya berbeda dari yang diusulkan, jika itu dibangun di atas temuan solusi awal, menambahkan co-author adalah hal yang sangat kecil
  Penulis punya alasan yang sah untuk mengeluhkan hal ini, dan ini bukan pertama maupun terakhir kalinya seseorang merasa kontribusinya tidak diakui

  • Orang-orang bertingkah seolah-olah kita adalah robot kode yang sama sekali tidak menginginkan pengakuan atas pekerjaan yang kita lakukan dengan baik
    Sekalipun patch itu sendiri inferior, upaya debugging-nya sama sekali tidak demikian
  • Ini situasi yang berbeda dari hubungan kerja
    Dalam hubungan kerja, pemberi kerja dan karyawan membuat kesepakatan bahwa pekerjaan dilakukan dengan imbalan kompensasi
    Jika Anda tiba-tiba masuk ke suatu perusahaan tanpa pemberitahuan dan mulai mengerjakan sesuatu yang tidak diminta siapa pun, hampir tidak ada orang yang akan mengklaim bahwa Anda berhak mendapat kompensasi
    Analogi yang lebih tepat untuk apa yang terjadi pada OP adalah yang ini
  • Akan lebih adil jika mengakui penulis asli dan menyajikan dirinya sendiri sebagai editor

• Tanggapan seperti “maaf, tapi versi saya lebih bagus. Kalau kamu ingin menjadi kontributor kernel Linux, ini ada isu yang bisa kamu perbaiki” adalah cara yang sangat ampuh untuk membuat seseorang tidak mau membantu lagi dan bahkan mematahkan semangat orang lain

  • Ungkapan sebenarnya berbeda
    Maintainer mengatakan bahwa ia tidak bisa mereproduksi crash dengan gdbserver, tetapi ada test case yang menunjukkan bug tersebut sehingga ia memeriksa dan menguji perbaikannya, lalu menulis, “terima kasih atas patch-nya, tapi saya ingin memperbaikinya dengan cara berbeda. Bisakah kamu mencoba patch di bawah ini dan memastikan apakah bug-nya sudah diperbaiki?”
    https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
    Ada juga komentar review lain yang tidak disebutkan
    Isinya bahwa ia tidak melihat keuntungan apa pun dari makro khusus untuk PPC32, #ifdef sebaiknya dihindari sebisa mungkin, dan patch Michael lebih mudah dipahami
    https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
  • Maintainer sebenarnya tidak mengatakan hal seperti itu
    OP menaruh kata-kata di mulut pihak lain lalu marah terhadapnya, dan itu bukan strategi yang baik, terutama dalam komunikasi teks
  • Apalagi jika OP sudah menulis bahwa isu ini dilaporkan 6 tahun lalu lalu diabaikan, tindakan maintainer itu cukup buruk
  • Kenyataannya, hal itu sama sekali tidak terjadi seperti itu
    OP membuat percakapannya terlihat seolah-olah tidak sopan, padahal sebenarnya tidak demikian
  • Lagi pula, apa jaminannya bahwa lain kali maintainer tidak akan lagi berkata “versi saya lebih bagus” sambil menunjuk bug lain?