অ্যান্ড্রয়েড কার্নেলকে লেটেস্ট Linux Stable-এ আপগ্রেড করার পদ্ধতি

আমরা অ্যান্ড্রয়েড কার্নেলের ওপর গাইড কভার করেছি, যেমন "How to Build a Custom Kernel" এবং "Best Custom Kernels for Android", কিন্তু আজ আমরা আপনাকে দেখাব কীভাবে আপনার কার্নেলকে লেটেস্ট Linux stable-এ আপস্ট্রিম করবেন।

অনুগ্রহ করে জানুন যে এটি এডভান্সড স্টাফ - আপনি যদি কখনো কার্নেল কম্পাইল করেননি, তবে আপনার উপরের গাইড "How to Build a Custom Kernel" ফলো করা উচিত, এবং এই গাইডে cherry-picking এবং merging commits লেটেস্ট Linux-stable কার্নেল থেকে আপনার অ্যান্ড্রয়েড কার্নেলে কম্পাইল করার আগে জড়িত থাকবে।

আপনার অ্যান্ড্রয়েড কার্নেলকে লেটেস্ট Linux stable-এ আপস্ট্রিম করার অনেক পজিটিভ বেনিফিট আছে, যেমন লেটেস্ট সিকিউরিটি কমিট এবং বাগফিক্সের সাথে আপ-টু-ডেট থাকা - আমরা পরে এই গাইডে কিছু প্রস এবং কন্স ব্যাখ্যা করব।

Linux-Stable কার্নেল কী?

Linux-stable, নামই ইম্পলাই করে, Linux কার্নেলের stable আর্ম। অন্য আর্মটি হচ্ছে "mainline", যা মাস্টার ব্রাঞ্চ। সকল Linux কার্নেল ডেভেলপমেন্ট mainline-এ হয়, এবং সাধারণত এই প্রসেস ফলো করে:

1. Linus Torvalds তার মেইন্টেইনারদের থেকে একসাথে অনেক প্যাচ নেবে দুটি সপ্তাহের জন্য।
2. এই দুটি সপ্তাহের পর, তিনি একটি rc1 রিলিজ করবেন (যেমন 4.14-rc1) কার্নেল।
3. পরবর্তী ৬-৮ সপ্তাহের জন্য প্রতিটি সপ্তাহে, তিনি আরেকটি RC রিলিজ করবেন (যেমন 4.14-rc2, 4.14-rc3, ইত্যাদি) কার্নেল, যেটি শুধু বাগ এবং রিগ্রেশন ফিক্স ধারণ করবে।
4. একবার এটি স্টেবল বলে বিবেচিত হলে, এটি org-এ (যেমন 4.14) ডাউনলোডের জন্য tarball হিসেবে রিলিজ হবে।

LTS কার্নেল কী?

প্রতিবর্ষ, Greg একটি কার্নেল বেছে নেবেন এবং দুই বছর (LTS) বা ছয় বছর (extended LTS) মেইনটেইন করবেন। এগুলো প্রোডাক্টের জন্য ডিজাইন করা যাদের স্টেবিলিটি প্রয়োজন (যেমন অ্যান্ড্রয়েড ফোন বা অন্যান্য IoT ডিভাইস)। প্রসেসটি উপরের মতোই, শুধু এটি দীর্ঘ সময় ধরে চলে। বর্তমানে ছয়টি LTS কার্নেল আছে (যা সবসময় kernel.org releases page-এ দেখা যায়):

• 4.14 (LTS), maintained by Greg Kroah-Hartman
• 4.9 (LTS), maintained by Greg Kroah-Hartman
• 4.4 (eLTS), maintained by Greg Kroah-Hartman
• 4.1(LTS), maintained by Sasha Levin
• 3.16 (LTS), maintained by Ben Hutchings
• 3.2 (LTS), maintained by Ben Hutchings

আমার অ্যান্ড্রয়েড কার্নেলকে Linux Stable-এ আপস্ট্রিম করার বেনিফিট কী?

যখন গুরুত্বপূর্ণ脆弱তা প্রকাশ/ফিক্স হয়, stable কার্নেলগুলো সেগুলো পাওয়ার প্রথম জন। তাই, আপনার অ্যান্ড্রয়েড কার্নেল আক্রমণ, সিকিউরিটি ফল্ট, এবং সাধারণভাবে বাগের বিরুদ্ধে অনেক সুরক্ষিত থাকবে।

Linux stable এ অনেক ড্রাইভারের ফিক্স আছে যা আমার অ্যান্ড্রয়েড ডিভাইস ব্যবহার করে না, এটি কি অধিকাংশই অপ্রয়োজনীয়?

হ্যাঁ এবং না, নির্ভর করে আপনি কীভাবে "অধিকাংশ" ডিফাইন করেন। Linux কার্নেলে অনেক কোড থাকতে পারে যা অ্যান্ড্রয়েড সিস্টেমে অনইউজড থাকে, কিন্তু এটা গ্যারান্টি দেয় না যে নতুন ভার্সন মার্জ করার সময় সেই ফাইলগুলো থেকে কোনো কনফ্লিক্ট হবে না! বুঝুন যে ভার্চুয়ালি কেউ কার্নেলের প্রতিটি পার্ট বিল্ড করে না, এমনকি সবচেয়ে সাধারণ Linux ডিস্ট্রো যেমন Ubuntu বা Mintও। এটি একদম মানে নয় যে আপনাকে এই ফিক্সগুলো নেওয়া উচিত নয় কারণ এই ফিক্স আছে ড্রাইভারের জন্য যেগুলো আপনি চলাচল করছেন। arm/arm64 এবং ext4 নিই উদাহরণ, যা সবচেয়ে সাধারণ অ্যান্ড্রয়েড আর্কিটেকচার এবং ফাইল সিস্টেম যথাক্রমে। 4.4-এ, 4.4.78 (লেটেস্ট Oreo CAF ট্যাগের ভার্সন) থেকে 4.4.121 (লেটেস্ট আপস্ট্রিম ট্যাগ) পর্যন্ত, এই সিস্টেমগুলো জন্য কমিটের নিচের সংখ্যাগুলো:

nathan@flashbox ~/kernels/linux-stable (master) $ git log --format=%h v4.4.78..v4.4.121 | wc -l2285 nathan@flashbox ~/kernels/linux-stable (master) $ git log --format=%h v4.4.78..v4.4.121 arch/arm | wc -l58 nathan@flashbox ~/kernels/linux-stable (master) $ git log --format=%h v4.4.78..v4.4.121 arch/arm64 | wc -l22 nathan@flashbox ~/kernels/linux-stable (master) $ git log --format=%h v4.4.78..v4.4.121 fs/ext4 | wc -l18

সবচেয়ে টাইম-কনসামিং পার্ট হলো ইনিশিয়াল ব্রিং আপ; একবার আপনি পুরোপুরি আপ-টু-ডেট হলে, একটি নতুন রিলিজ মার্জ করতে কোনো সময় লাগে না, যেটি সাধারণত ১০০ কমিটের বেশি ধারণ করে না। এই প্রসেস যেন বাধ্যতামূলক হওয়া উচিত সেটি আনার বেনিফিটস (আপনার ব্যবহারকারীদের জন্য আরও স্টেবিলিটি এবং बेटার সিকিউরিটি)।

Linux Stable Kernel কে Android Kernel-এ মার্জ করার পদ্ধতি

প্রথমে আপনাকে বের করতে হবে আপনার অ্যান্ড্রয়েড ডিভাইস কী কার্নেল ভার্সন রান করছে।

যেমন তुच্ছ কিনা লাগে, এটি জানা জরুরি যে আপনাকে কোথা থেকে শুরু করতে হবে। আপনার কার্নেল ট্রিতে নিচের কমান্ড রান করুন:

make kernelversion

এটি আপনার যে ভার্সনে আছেন সেটি রিটার্ন করবে। প্রথম দুটি নম্বর ব্রাঞ্চ বের করার জন্য ব্যবহৃত হবে (যেমন linux-4.4.y যেকোনো 4.4 কার্নেলের জন্য) এবং শেষ নম্বর ব্যবহার হবে কোন ভার্সন থেকে মার্জ শুরু করতে হবে বের করার জন্য (যেমন আপনি 4.4.21-এ থাকলে, আপনি 4.4.22 পরবর্তীতে মার্জ করবেন)।

kernel.org থেকে লেটেস্ট কার্নেল সোর্স গ্র্যাব করুন

kernel.org লেটেস্ট কার্নেল সোর্স হাউস করে linux-stable রেপোজিটরিতে। সেই পেজের নিচে তিনটি fetch লিংক থাকবে। আমার অভিজ্ঞতাতে, গুগলের মিরর টেন্ড করে সবচেয়ে ফাস্ট, কিন্তু আপনার রেজাল্ট ভিন্ন হতে পারে। নিচের কমান্ডগুলো চালান:

git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

সিদ্ধান্ত নিন আপনি পুরো কার্নেল মার্জ করতে চান না cherry-pick করতে চেন কমিটগুলো

পরবর্তীতে, আপনাকে বেছে নিতে হবে আপনি কমিটগুলো মার্জ করতে চান না cherry-pick করতে চান। এখানে প্রতিটির প্রস এবং কন্স এবং কখন আপনি কী করতে চান।

NOTE: আপনার কার্নেল সোর্স যদি tarball ফরম্যাটে থাকে, তবে আপনার অধিক الأرجল cherry-pick করতে হবে, অন্যথায় আপনি হাজার হাজার ফাইল কনফ্লিক্ট পাবেন কারণ git ইতিহাস পপুলেট করছে পিউরলি আপস্ট্রিমের ওপর ভিত্তি করে, না যা OEM বা CAF পরিবর্তন করেছে। শুধু ধাপ ৪-এ যান।

Cherry-picking:

Pros:

• কনফ্লিক্ট রেজলভ করা সহজ কারণ আপনি জানেন ঠিক কোন কনফ্লিক্ট ইস্যু সৃষ্টি করছে।
• রিবেস করা সহজ কারণ প্রতিটি কমিট নিজস্ব আছে।
• বিসেক্ট করা সহজ ইস্যুতে পড়লে

Cons:

• এটি বেশি সময় নেয় কারণ প্রতিটি কমিট আলাদাভাবে পিক করতে হয়।
• थোডা বেশি কঠিন কমিট আপস্ট্রিম থেকে কিনা এক নজরে বুঝতে

Merge

Pros:

• এটি দ্রুত কারণ আপনাকে সব ক্লিন প্যাচ মার্জ হওয়ার জন্য অপেক্ষা করতে হয় না।
• এটি সহজ দেখতে যে কোনো কমিট আপস্ট্রিম থেকে কিনা কারণ আপনি কমিটার হবেন না, আপস্ট্রিম মেইন্টেইনার হবে।

Cons:

• কনফ্লিক্ট রেজলভ করা একটু বেশি কঠিন হতে পারে কারণ আপনাকে লুক আপ করতে হবে কোন কমিট কনফ্লিক্ট সৃষ্টি করছে git log/git blame ব্যবহার করে, এটি আপনাকে সরাসরি বলবে না।
• রিবেসিং কঠিন কারণ আপনি একটি মার্জ রিবেস করতে পারবেন না, এটি আপনাকে সকল কমিট আলাদাভাবে cherry-pick করার অফার করবে। যাইহোক, আপনার আর রিবেস করতে হবে না প্রায়শই, বরং git revert এবং git merge ব্যবহার করুন যেখানে সম্ভব।

আমি রিকমেন্ড করব চেরি-পিক করে যেকোনো প্রব্লেম কনফ্লিক্টเ বের করার জন্য, তারপর মার্জ করা, তারপর প্রব্লেম কমিটগুলো রিভার্ট করা যাতে আপডেট করা সহজ হয় (যেহেতু আপ-টু-ডেট হলে মার্জ কুইক)۔

আপনার সোর্সে কমিটগুলো যোগ করুন, একバーশন একবারে

এই প্রসেসের সবচেয়ে গুরুত্বপূর্ণ পার্ট হলো একバーশন একবারের পার্ট। আপনার আপস্ট্রিম সিরিজে একটি প্রব্লেম প্যাচ থাকতে পারে, যা বুটিং-এ প্রব্লেম সৃষ্টি করতে পারে বা সাউন্ড বা চার্জিং এর মত কিছু ভাঙতে পারে (টিপস অ্যান্ড ট্রিকস সেকশনে ব্যাখ্যা করা হয়েছে)। ইনক্রিমেন্টাল ভার্সন চেঞ্জ করা এই কারণেই গুরুত্বপূর্ণ, ৫০ কমিটে একটি ইস্যু খুঁজে বের করা সহজ চেয়ে কিছু ভার্সনের জন্য ২০০০+ কমিটের মধ্যে। আমি শুধু ফুল মার্জ রিকমেন্ড করব একবার আপনি সকল প্রব্লেম কমিট এবং কনফ্লিক্ট রেজলিউশন জানলে।

Cherry-picking

Format:

git cherry-pick <previous_tag>..<next_tag>

Example:

git cherry-pick v3.10.73..v3.10.74

Merge

Format:

git merge <next_tag>

Example:

git merge v3.10.74

আমি রিকমেন্ড করব মার্জ কমিটে কনফ্লিক্ট ট্র্যাক রাখতে # মার্কার রিমুভ করে।

কনফ্লিক্ট রেজলভ করার পদ্ধতি

আমরা প্রতিটি কনফ্লিক্ট রেজলভ করার জন্য স্টেপ-বাই-স্টেপ গাইড দিতে পারি না, কারণ এতে C ল্যাঙ্গুয়েজের ভালো জ্ঞান প্রয়োজন, কিন্তু এখানে কিছু হিন্ট।

আপনি যদি মার্জ করছেন, বের করুন কোন কমিট কনফ্লিক্ট সৃষ্টি করছে। আপনি এটি দুটিভাবে করতে পারেন:

1. git log -p v$(make kernelversion)..<latest_tag> আপনার করেন্ট ভার্সন এবং আপস্ট্রিম থেকে লেটেস্টের মধ্যে চেঞ্জ পাওয়ার জন্য। -p ফ্ল্যাগ প্রতিটি কমিটের করা চেঞ্জ দেবে যাতে আপনি দেখতে পারেন।
2. ফাইলে git blame চালান প্রতিটি কমিটের হ্যাশ পাওয়ার জন্য এরিয়ায়। আপনি তারপর git show --format=fuller চালাতে পারেন দেখতে কমিটার mainline/stable থেকে কিনা, গুগল থেকে, বা CodeAurora থেকে।

• বের করুন আপনার پاس কমিটটি ইতিমধ্যে আছে কিনা। কিছু ভেন্ডর như Google বা CAF আপস্ট্রিমে ক্রিটিক্যাল বাগের জন্য লুক করতে চেষ্টা করে, যেন ডার্টি COW ফিক্স, এবং তাদের ব্যাকপোর্টস আপস্ট্রিমের সাথে কনফ্লিক্ট করতে পারে। আপনি git log --grep="<part_of_commit_message>" চালাতে পারেন এবং দেখতে পারেন কি এটা কিছু রিটার্ন করে। যদি করে, তবে আপনি কমিটটি স্কিপ করতে পারেন (cherry-picking ব্যবহার করে git reset --hard && git cherry-pick --continue) বা কনফ্লিক্টগুলো ইগনোর করতে পারেন (<<<<<<< এবং ====== এবং >>>>>>> এর মধ্যে সবকিছু রিমুভ করে)।
• বের করুন কোনো ব্যাকপোর্ট আছে কিনা যা রেজলিউশন গুলিয়ে দিচ্ছে। Google এবং CAF কিছু প্যাচ ব্যাকপোর্ট করতে পছন্দ করে যা stable করবেনা। Stable প্রায়শই মেইনলাইন কমিটের রেজলিউশন অ্যাডাপ্ট করতে হবে কিছু প্যাচের অভাবে যা Google ব্যাকপোর্ট করতে পছন্দ করে। আপনি মেইনলাইন কমিট দেখতে পারেন git show <hash> চালানোর মাধ্যমে (মেইনলাইন হ্যাশ stable কমিটের কমিট মেসেজে উপলব্ধ থাকবে)। যদি কোনো ব্যাকপোর্ট এটা গুলিয়ে দিচ্ছে, তবে আপনি চেঞ্জগুলো ডিসকার্ড করতে পারেন বা আপনি মেইনলাইন ভার্সন ব্যবহার করতে পারেন (যেটি আপনার সাধারণত করতে হবে)।
• পড়ুন কমিটটি কী করার চেষ্টা করছে এবং দেখুন প্রব্লেমটি ইতিমধ্যে ফিক্সড আছে কিনা। কখনো CAF আপস্ট্রিম থেকে স্বতন্ত্রভাবে একটি বাগ ফিক্স করতে পারে, অর্থাৎ আপনি তাদের ফিক্স ওভাররাইট করতে পারেন আপস্ট্রিমের দিয়ে বা ডিসকার্ড করতে পারেন, উপরের মত।

অন্যথায়, এটি শুধু CAF/Google/OEM অডিশনের ফলাফল হতে পারে, যেস সেস আপনাকে কিছু জিনিস শাফল করতে হবে।

এখানে linux-stable kernel.org রেপোজিটরির একটি মিরর GitHub-এ, যা কমিট লিস্ট এবং ডিফস কনফ্লিক্ট রেজলিউশনের জন্য লুক আপ করা সহজ করতে পারে। আমি কমিট লিস্ট ভিউতে প্রথমে যাওয়া এবং প্রব্লেম কমিট লোকেট করে আরিজিনাল ডিফ দেখার রিকমেন্ড করব আপনার সাথে তুলনা করার জন্য।

Example URL: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

আপনি কমান্ড লাইন দিয়েও করতে পারেন:

git log <current_version>..<version_being_added> <path> git show <hash>

রেজলিউশন সলভ করা সব কন্টেক্সটের ওপর। আপনার যা সবসময় করা উচিত সেটি হলো নিশ্চিত করা আপনার ফাইনাল ডিফ আপস্ট্রিমের সাথে মেলে কিনা নিচের কমান্ডগুলো দুটি আলাদা উইন্ডোতে চালিয়ে:

git diff HEAD git diff v$(make kernelversion)..$(git tag --sort=-taggerdate -l v$(make kernelversion | cut -d . -f 1,2)* | head -n1)

rerere ইনেবল করুন

Git-এ একটি ফিচার আছে rerere (stands for Reuse Recorded Resolution), অর্থাৎ যখন এটি একটি কনফ্লিক্ট ডিটেক্ট করে, এটি রেকর্ড করে কীভাবে আপনি এটাকে রেজলভ করেছেন যাতে আপনি পরে পুনরায় ব্যবহার করতে পারেন। এটি খুব হেল্পফুল উভয় ক্রনিক রিবেসারদের জন্য মার্জিং এবং cherry-picking-এ যেহেতু আপনাকে শুধু git add . && git --continue চালাতে হবে আপস্ট্রিম ব্রিংআপ রিডু করার সময় কারণ কনফ্লিক্ট রেজলভ হবে আপনি আগে যেভাবে করলেন।

এটি আপনার কার্নেল রেপোতে নিচের কমান্ড চালিয়ে ইনেবল করা যায়:

git config rerere.enabled true

git bisect ব্যবহার করে কম্পাইলার বা রানটাইম এরর হলে

যেহেতু আপনি বড় সংখ্যক কমিট যোগ করবেন, আপনার জন্য একটি কম্পাইলার বা রানটাইম এরর ইন্ট্রোডিউস হওয়া খুব সম্ভব। শুধু হার মানবেন না, আপনি git-এর বিল্ট-ইন bisect টুল ব্যবহার করে ইস্যুর রুট কজ খুঁজে বের করতে পারেন! আদর্শভাবে, আপনি প্রতিটি কার্নেল ভার্সন বিল্ড এবং ফ্ল্যাশ করবেন যেহেতু আপনি এড করছেন যাতে bisecting কম সময় নেয় যদি প্রয়োজন হয় কিন্তু আপনি ৫০০০ কমিটও বিসেক্ট করতে পারেন কোনো ইস্যু ছাড়া।

git bisect যা করবে সেটি হলো একটি কমিট রেঞ্জ নেওয়া, যেখানে ইস্যু প্রেজেন্ট থেকে যেখানে প্রেজেন্ট ছিল না, এবং তারপর কমিট রেঞ্জ হাফ করতে শুরু করবে, আপনাকে বিল্ড এবং টেস্ট করতে দিয়ে এবং এটকে জানাতে দিয়ে ভালো কিনা। এটি এটি চালিয়ে যাবে যতক্ষণ না প্রব্লেম সৃষ্টি করার কমিটটি বের করে দেয়। সেই পয়েন্টে, আপনি إما এটি ফিক্স করতে পারেন বা রিভার্ট করতে পারেন।

1. বিসেক্ট শুরু করুন: git bisect start
2. কারেন্ট রিভিশনকে bad লেবেল করুন: git bisect bad
3. একটি রিভিশনকে good লেবেল করুন: git bisect good <sha1>
4. নতুন রিভিশনে বিল্ড করুন
5. রেজাল্টের ওপর ভিত্তি করে (ইস্যু প্রেজেন্ট কিনা), git-কে বলুন: git bisect good OR git bisect bad
6. ধাপ ৪-৫ রিপিট করুন যতক্ষণ না প্রব্লেম কমিটটি খুঁজে পাওয়া যায়!
7. প্রব্লেম কমিট রিভার্ট বা ফিক্স করুন।

NOTE: Mergerদের將暂时需要运行 git rebase -i <good_sha> সকল প্যাচ আপনার ব্রাঞ্চে অ্যাপ্লাই করার জন্য প্রপার bisecting-এর জন্য, যেহেতু במקוםে মার্জসহ bisecting করলে প্রায়শই আপস্ট্রিম কমিটসে চেকআউট করে, অর্থাৎ আপনার কোনো অ্যান্ড্রয়েড-স্পেসিফিক কমিট নেই। আমি এর ওপর আরও গভীরে যেতে পারি অনুরোধ করলে কিন্তু আমার মতে, এটি প্রয়োজন। একবার আপনি প্রব্লেম কমিট আইডেন্টিফাই করলে, আপনি এটি রিভার্ট বা রিবেস করতে পারেন মার্জে।

আপস্ট্রিম আপডেট Squash করবেন না

অনেক নতুন ডেভেলপার এই করার চেষ্টা করে কারণ এটি "ক্লিনার" এবং "ম্যানেজ করা সহজ"। এটি কিছু কারণের জন্য ভয়ংকর:

• Authorship হারায় চলে। অন্য ডেভেলপারদের সাথে অন্যাযোগ্য যারা তাদের কাজের জন্য ক্রেডিট হারিয়ে যান।
• Bisecting অসম্ভব। আপনি যদি একটি কমিট সিরিজ squash করেন এবং সেটিতে কিছু ইস্যু থাকে, squash-এ কোনো কমিট ইস্যু সৃষ্টি করেছে কিনা বলা অসম্ভব।
• ফিউচার cherry-picks হার্ডার। আপনি যদি একটি squashed সিরিজের সাথে রিবেস করতে চান, কনফ্লিক্ট কোথা থেকে ফলাফলপূর্ণ হয় বলা কঠিন/অসম্ভব।

Linux Kernel mailing list সাবস্ক্রাইব করুন টাইমলি আপডেটের জন্য

যতক্ষণ একটি আপস্ট্রিম আপডেট থাকে, নোটিফাইড হওয়ার জন্য, linux-kernel-announce list-এ সাবস্ক্রাইব করুন। এটি আপনাকে একটি ইমেইল দেবে هرবার একটি নতুন কার্নেল রিলিজ হলে যাতে আপনি আপডেট এবং পুশ করতে পারেন যত দ্রুত সম্ভব।