কীভাবে আপনার অ্যান্ড্রয়েড কার্নেলকে সর্বশেষ লিনাক্স স্থিতিশীল-এ আপডেট করবেন

আমরা অ্যান্ড্রয়েড কার্নেলগুলির উপর নির্দেশিকাগুলি কভার করেছি, যেমন "কীভাবে একটি কাস্টম কার্নেল তৈরি করতে হয়" এবং "অ্যান্ড্রয়েডের জন্য সেরা কাস্টম কার্নেল", কিন্তু আজ আমরা আপনাকে দেখাব কিভাবে সর্বশেষ লিনাক্স স্থিতিশীলতার বিপরীতে আপনার কার্নেল আপস্ট্রিম করতে হয়।

অনুগ্রহ করে জেনে রাখুন যে এটি উন্নত স্টাফ - আপনি যদি আগে কখনো কার্নেল কম্পাইল না করে থাকেন, তাহলে উপরে লিঙ্ক করা "কিভাবে একটি কাস্টম কার্নেল তৈরি করবেন" নির্দেশিকা অনুসরণ করা উচিত, এবং এই নির্দেশিকাটি আপনার অ্যান্ড্রয়েড কার্নেলের সাথে সর্বশেষ লিনাক্স-স্থির কার্নেল থেকে চেরি-পিকিং এবং মার্জ কমিট অন্তর্ভুক্ত করবে। আপনি এটি কম্পাইল করার আগে।

আপনার অ্যান্ড্রয়েড কার্নেলকে লেটেস্ট লিনাক্স স্টেবলে আপস্ট্রিম করার অনেক ইতিবাচক সুবিধা রয়েছে, যেমন সাম্প্রতিক নিরাপত্তা প্রতিশ্রুতি এবং বাগ ফিক্সের সাথে আপ-টু-ডেট থাকা – আমরা এই নির্দেশিকাতে পরে কিছু সুবিধা এবং অসুবিধা ব্যাখ্যা করব।

লিনাক্স-স্টেবল কার্নেল কি?

লিনাক্স-স্থির হল নাম থেকে বোঝা যায় লিনাক্স কার্নেলের স্থিতিশীল হাত। অন্য বাহুটি "মেইনলাইন" নামে পরিচিত, যা হল মাস্টার শাখা . লিনাক্স কার্নেলের সমস্ত বিকাশ মেইনলাইনে ঘটে এবং সাধারণত এই প্রক্রিয়াটি অনুসরণ করে:

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

LTS কার্নেল কি?

প্রতি বছর, গ্রেগ একটি কার্নেল বাছাই করবে এবং দুই বছর (এলটিএস) বা ছয় বছর (বর্ধিত এলটিএস) জন্য এটি বজায় রাখবে। এগুলি এমন পণ্যগুলির জন্য ডিজাইন করা হয়েছে যেগুলির স্থায়িত্ব প্রয়োজন (যেমন অ্যান্ড্রয়েড ফোন বা অন্যান্য আইওটি ডিভাইস)৷ প্রক্রিয়াটি উপরের মতোই ঠিক একই, এটি কেবল দীর্ঘ সময়ের জন্য ঘটে। বর্তমানে ছয়টি এলটিএস কার্নেল রয়েছে (যা সবসময় kernel.org রিলিজ পৃষ্ঠাতে দেখা যায় ):

• 4.14 (LTS) , রক্ষণাবেক্ষণ করেছেন গ্রেগ ক্রোহ-হার্টম্যান
• 4.9 (LTS) , রক্ষণাবেক্ষণ করেছেন গ্রেগ ক্রোহ-হার্টম্যান
• 4.4 (eLTS) , রক্ষণাবেক্ষণ করেছেন গ্রেগ ক্রোহ-হার্টম্যান
• 4.1(LTS) , সাশা লেভিন দ্বারা রক্ষণাবেক্ষণ করা হয়
• 3.16 (LTS) , বেন হাচিংস দ্বারা রক্ষণাবেক্ষণ করা হয়
• 3.2 (LTS) , বেন হাচিংস দ্বারা রক্ষণাবেক্ষণ করা হয়

লিনাক্স স্টেবলে আমার অ্যান্ড্রয়েড কার্নেল আপস্ট্রিম করার সুবিধা কী?

যখন গুরুত্বপূর্ণ দুর্বলতাগুলি প্রকাশ/স্থির করা হয়, তখন স্থিতিশীল কার্নেলগুলি প্রথমে সেগুলি পায়। এইভাবে, আপনার অ্যান্ড্রয়েড কার্নেল আক্রমণ, নিরাপত্তা ত্রুটি এবং সাধারণভাবে বাগগুলির বিরুদ্ধে অনেক বেশি নিরাপদ হবে৷

লিনাক্স স্ট্যাবলে আমার অ্যান্ড্রয়েড ডিভাইস ব্যবহার করে না এমন অনেকগুলি ড্রাইভারের সমাধান অন্তর্ভুক্ত করে, এটি কি বেশিরভাগই অপ্রয়োজনীয় নয়?

হ্যাঁ এবং না, আপনি কীভাবে "বেশিরভাগ" সংজ্ঞায়িত করেন তার উপর নির্ভর করে। লিনাক্স কার্নেলে অনেকগুলি কোড অন্তর্ভুক্ত থাকতে পারে যা অ্যান্ড্রয়েড সিস্টেমে অব্যবহৃত হয়ে যায়, তবে এটি গ্যারান্টি দেয় না যে নতুন সংস্করণগুলি মার্জ করার সময় সেই ফাইলগুলি থেকে কোনও বিরোধ থাকবে না! ভার্চুয়ালি কেউই বুঝে নিন কার্নেলের প্রতিটি অংশ তৈরি করে, এমনকি উবুন্টু বা মিন্টের মতো সাধারণ লিনাক্স ডিস্ট্রোও নয়। এর মানে এই নয় যে আপনার এই সংশোধনগুলি নেওয়া উচিত নয় কারণ সেখানে আছে৷ আপনি করুন ড্রাইভারগুলির জন্য সংশোধন করুন৷ চালান উদাহরণস্বরূপ 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

সবচেয়ে সময়সাপেক্ষ অংশ হল প্রাথমিকভাবে তুলে ধরা; আপনি একবার আপ টু ডেট হয়ে গেলে, একটি নতুন রিলিজে একত্রিত হতে মোটেও সময় লাগে না, যেটিতে সাধারণত 100 টির বেশি কমিট থাকে না। এটি যে সুবিধাগুলি নিয়ে আসে (আপনার ব্যবহারকারীদের জন্য আরও স্থিতিশীলতা এবং আরও ভাল নিরাপত্তা) তবে এই প্রক্রিয়াটির প্রয়োজন হওয়া উচিত৷

কিভাবে লিনাক্স স্টেবল কার্নেলকে একটি অ্যান্ড্রয়েড কার্নেলে একত্রিত করবেন

প্রথমে আপনাকে খুঁজে বের করতে হবে আপনার অ্যান্ড্রয়েড ডিভাইসটি কোন কার্নেল সংস্করণে চলছে৷

এটি যতটা তুচ্ছ মনে হয়, আপনার কোথায় শুরু করা দরকার তা জানা প্রয়োজন। আপনার কার্নেল ট্রিতে নিম্নলিখিত কমান্ডটি চালান:

কার্নেল সংস্করণ তৈরি করুন

এটি আপনি যে সংস্করণে আছেন সেটি ফিরিয়ে দেবে। প্রথম দুটি সংখ্যা আপনার প্রয়োজনীয় শাখাটি বের করতে ব্যবহার করা হবে (যেমন যেকোন 4.4 কার্নেলের জন্য linux-4.4.y) এবং শেষ নম্বরটি ব্যবহার করা হবে আপনাকে একত্রিতকরণের সাথে শুরু করতে কোন সংস্করণটি নির্ধারণ করতে হবে (যেমন আপনি যদি 4.4 এ থাকেন) .21, আপনি পরবর্তী 4.4.22 মার্জ করবেন।

kernel.org থেকে সর্বশেষ কার্নেল উত্সটি নিন৷

kernel.org লিনাক্স-স্থিতিশীল সংগ্রহস্থলে সর্বশেষ কার্নেলের উৎস রয়েছে। সেই পৃষ্ঠার নীচে, তিনটি আনয়ন লিঙ্ক থাকবে। আমার অভিজ্ঞতায়, Google এর মিরর সবচেয়ে দ্রুত হতে থাকে কিন্তু আপনার ফলাফল পরিবর্তিত হতে পারে। নিম্নলিখিত কমান্ডগুলি চালান:

গিট রিমোট যোগ করুন linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit আনুন linux-stable

আপনি সম্পূর্ণ কার্নেল মার্জ করতে চান নাকি চেরি-পিক কমিট করতে চান তা স্থির করুন

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

দ্রষ্টব্য: যদি আপনার কার্নেল উত্সটি একটি টারবলের আকারে হয়, তবে আপনাকে সম্ভবত চেরি-পিক করতে হবে, অন্যথায় আপনি হাজার হাজার ফাইল দ্বন্দ্ব পাবেন কারণ গিট সম্পূর্ণরূপে আপস্ট্রিমের উপর ভিত্তি করে ইতিহাস তৈরি করছে, OEM বা CAF যা পরিবর্তন করেছে তা নয়। শুধু ধাপ 4 এ চলে যান।

চেরি-পিকিং:

সুবিধা:

• বিরোধের সমাধান করা সহজ কারণ আপনি জানেন ঠিক কোন দ্বন্দ্ব কোন সমস্যার কারণ হচ্ছে।
• রিবেস করা সহজ কারণ প্রতিটি কমিট তার নিজস্ব।
• সমস্যা থাকলে দ্বিখণ্ডিত করা সহজ

কনস:

• এটি আরও বেশি সময় নেয় কারণ প্রতিটি প্রতিশ্রুতি আলাদাভাবে বাছাই করতে হয়৷
৷
• প্রথম নজরে কমিট আপস্ট্রিম থেকে হয় কিনা তা বলা আরও কঠিন

মার্জ করুন৷

সুবিধা :

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

কনস:

• দ্বন্দ্বের সমাধান করা একটু বেশি কঠিন হতে পারে কারণ আপনাকে দেখতে হবে কোন প্রতিশ্রুতিটি গিট লগ/গিট ব্লেম ব্যবহার করে দ্বন্দ্বের কারণ হচ্ছে, এটি আপনাকে সরাসরি বলবে না।
• রিবেসিং কঠিন কারণ আপনি একটি মার্জ রিবেস করতে পারবেন না, এটি পৃথকভাবে সমস্ত কমিট চেরি-পিক করার প্রস্তাব দেবে। যাইহোক, আপনার প্রায়শই রিবেস করা উচিত নয়, পরিবর্তে যেখানে সম্ভব গিট রিভার্ট এবং গিট মার্জ ব্যবহার করুন।

আমি একটি চেরি-পিক করার সুপারিশ করব প্রাথমিকভাবে যেকোন সমস্যা দ্বন্দ্ব বের করার জন্য, একটি মার্জ করুন, তারপরে সমস্যাটি প্রত্যাবর্তন করুন যাতে আপডেট করা সহজ হয় (যেহেতু আপ টু ডেট হওয়ার পরে মার্জ করা দ্রুত হয়)।

আপনার উৎসে প্রতিশ্রুতি যোগ করুন, একবারে একটি সংস্করণ

এই প্রক্রিয়ার সবচেয়ে গুরুত্বপূর্ণ অংশ হল এক সময়ে এক সংস্করণ। আপনার আপস্ট্রিম সিরিজে একটি সমস্যা প্যাচ থাকতে পারে, যা বুট করতে সমস্যা হতে পারে বা শব্দ বা চার্জিং এর মতো কিছু ভাঙতে পারে (টিপস এবং কৌশল বিভাগে ব্যাখ্যা করা হয়েছে)। ক্রমবর্ধমান সংস্করণ পরিবর্তন করা এই কারণে গুরুত্বপূর্ণ, কিছু সংস্করণের জন্য 2000 কমিটের চেয়ে 50টি কমিটের মধ্যে একটি সমস্যা খুঁজে পাওয়া সহজ। আমি শুধুমাত্র একটি সম্পূর্ণ একত্রীকরণ করার সুপারিশ করব যখন আপনি সমস্ত সমস্যার প্রতিশ্রুতি এবং বিরোধের সমাধানগুলি জানেন৷

চেরি বাছাই

বিন্যাস:

গিট চেরি-পিক ..

উদাহরণ:

git চেরি-পিক v3.10.73..v3.10.74

মার্জ করুন

বিন্যাস:

গিট মার্জ 

উদাহরণ:

git merge v3.10.74

আমি সুপারিশ করছি যে # মার্কারগুলি সরিয়ে দিয়ে মার্জ কমিটের দ্বন্দ্বগুলির উপর নজর রাখা।

কীভাবে দ্বন্দ্ব সমাধান করতে হয়

আমরা প্রতিটি একক দ্বন্দ্ব সমাধানের জন্য ধাপে ধাপে নির্দেশিকা দিতে পারি না, কারণ এতে সি ভাষার একটি ভাল জ্ঞান জড়িত, তবে এখানে কয়েকটি ইঙ্গিত রয়েছে।

যদি আপনি একত্রিত হন, তাহলে কি প্রতিশ্রুতি দ্বন্দ্ব সৃষ্টি করছে তা বের করুন। আপনি দুটি উপায়ে এটি করতে পারেন:

1. git log -p v$(make kernelversion).. আপনার বর্তমান সংস্করণ এবং আপস্ট্রিম থেকে সর্বশেষ সংস্করণের মধ্যে পরিবর্তনগুলি পেতে। -p পতাকা আপনাকে প্রতিটি প্রতিশ্রুতি দ্বারা করা পরিবর্তনগুলি দেবে যাতে আপনি দেখতে পারেন৷
৷
2. এলাকায় প্রতিটি কমিটের হ্যাশ পেতে ফাইলে গিট ব্লেম চালান। তারপর আপনি git show –format=fuller চালাতে পারেন যে প্রতিশ্রুতিদাতাটি মেইনলাইন/স্টেবল, Google বা CodeAurora থেকে এসেছে কিনা।

• আপনার ইতিমধ্যেই প্রতিশ্রুতি আছে কিনা তা বের করুন। Google বা CAF এর মতো কিছু বিক্রেতা ডার্টি কাউ ফিক্সের মতো জটিল বাগগুলির জন্য আপস্ট্রিমে তাকানোর চেষ্টা করবে এবং তাদের ব্যাকপোর্টগুলি আপস্ট্রিমের সাথে বিরোধ করতে পারে। আপনি git log –grep="" চালাতে পারেন এবং দেখতে পারেন যে এটি কিছু দেয় কিনা। যদি এটি হয়ে থাকে, আপনি প্রতিশ্রুতিটি এড়িয়ে যেতে পারেন (যদি গিট রিসেট ব্যবহার করে চেরি-পিকিং –হার্ড &&গিট চেরি-পিক –কন্টিনিউ) অথবা দ্বন্দ্বগুলিকে উপেক্ষা করতে পারেন (<<<<<< এবং এর মধ্যে থাকা সবকিছু সরিয়ে ফেলুন ======এবং >>>>>>)।
• কোন ব্যাকপোর্ট আছে যা রেজোলিউশনে গোলমাল করছে কিনা তা বের করুন। Google এবং CAF কিছু নির্দিষ্ট প্যাচ ব্যাকপোর্ট করতে চায় যা স্থিতিশীল হবে না। স্থিতিশীলকে প্রায়শই মেইনলাইন কমিটের রেজোলিউশনকে কিছু নির্দিষ্ট প্যাচের অনুপস্থিতিতে মানিয়ে নিতে হবে যা Google ব্যাকপোর্ট করতে বেছে নেয়। আপনি গিট শো <হ্যাশ> (স্থির প্রতিশ্রুতির প্রতিশ্রুতি বার্তায় মেইনলাইন হ্যাশ উপলব্ধ হবে) চালিয়ে মেইনলাইন কমিট দেখতে পারেন। যদি কোন ব্যাকপোর্টে গোলমাল হয়, আপনি হয় পরিবর্তনগুলি বাতিল করতে পারেন অথবা আপনি মেইনলাইন সংস্করণ ব্যবহার করতে পারেন (যা আপনাকে সাধারণত করতে হবে)।
• কমিটটি কী করার চেষ্টা করছে তা পড়ুন এবং সমস্যাটি ইতিমধ্যেই ঠিক করা হয়েছে কিনা দেখুন। কখনও কখনও CAF আপস্ট্রিম থেকে স্বাধীন একটি বাগ ঠিক করতে পারে, যার অর্থ আপনি হয় আপস্ট্রিমের জন্য তাদের সংশোধন ওভাররাইট করতে পারেন বা উপরের মত এটি বাতিল করতে পারেন৷

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

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

উদাহরণ URL: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

আপনি কমান্ড লাইনের মাধ্যমেও এটি করতে পারেন:

গিট লগ .. git show 

রেজোলিউশন সমাধান করা প্রসঙ্গ সম্পর্কে সব. আপনার যা করা উচিত তা হল দুটি পৃথক উইন্ডোতে নিম্নলিখিত কমান্ডগুলি চালিয়ে আপনার চূড়ান্ত পার্থক্য আপস্ট্রিমের সাথে মেলে তা নিশ্চিত করুন:

git diff HEADgit diff v$(make kernelversion)..$(git tag --sort=-taggerdate -l v$(make kernelversion | cut -d . -f 1,2)* | head -n1) 
rerere সক্ষম করুন৷ 
 

 গিট-এর একটি বৈশিষ্ট্য রয়েছে যার নাম rerere (পুনঃব্যবহার রেকর্ড করা রেজোলিউশনের জন্য), যার অর্থ হল যখন এটি একটি দ্বন্দ্ব শনাক্ত করে, তখন এটি রেকর্ড করবে যে আপনি কীভাবে এটি সমাধান করেছেন যাতে আপনি পরে এটি পুনরায় ব্যবহার করতে পারেন। এটি একত্রিতকরণ এবং চেরি-পিকিং উভয়ের সাথে দীর্ঘস্থায়ী রিবেসারদের জন্য বিশেষভাবে সহায়ক কারণ আপনাকে শুধুমাত্র গিট অ্যাড চালাতে হবে। &&git  –আপস্ট্রিম আনয়ন পুনরায় করার সময় চালিয়ে যান কারণ আপনি পূর্বে যেভাবে এটি সমাধান করেছিলেন সেইভাবে বিরোধের সমাধান হবে।
 

 আপনার কার্নেল রেপোতে নিম্নলিখিত কমান্ডটি চালানোর মাধ্যমে এটি সক্রিয় করা যেতে পারে:
 
git config rerere.enabled true
 
একটি কম্পাইলার বা রানটাইম ত্রুটির মধ্যে চলাকালীন দ্বিখণ্ডিত কীভাবে গিট করবেন 
 

 প্রদত্ত যে আপনি একটি বড় সংখ্যক কমিট যোগ করবেন, আপনার পক্ষে একটি কম্পাইলার বা রানটাইম ত্রুটি প্রবর্তন করা খুব সম্ভব। শুধু হাল ছেড়ে দেওয়ার পরিবর্তে, আপনি সমস্যার মূল কারণ খুঁজে বের করতে গিটের বিল্ট-ইন দ্বিখণ্ডিত টুল ব্যবহার করতে পারেন! আদর্শভাবে, আপনি এটি যোগ করার সাথে সাথে প্রতিটি একক কার্নেল সংস্করণ তৈরি এবং ফ্ল্যাশিং করবেন তাই দ্বিখণ্ডিত করতে কম সময় লাগবে তবে আপনি কোন সমস্যা ছাড়াই 5000টি কমিটকে বিভক্ত করতে পারেন৷
 

 git bisect যা করবে তা হল বিভিন্ন ধরনের কমিট নেওয়া, যেখানে সমস্যাটি উপস্থিত থেকে যেখানে এটি উপস্থিত ছিল না, এবং তারপর কমিট রেঞ্জকে অর্ধেক করা শুরু করে, আপনাকে তৈরি করতে এবং পরীক্ষা করতে এবং এটি ভাল কিনা তা জানাতে দেয় . এটি আপনার সমস্যা সৃষ্টিকারী প্রতিশ্রুতিটি বের না করা পর্যন্ত এটি চালিয়ে যাবে। সেই মুহুর্তে, আপনি হয় এটি ঠিক করতে পারেন বা এটিকে প্রত্যাবর্তন করতে পারেন৷
৷ 
 
দ্বিভাগ করা শুরু করুন: গিট দ্বিখণ্ডিত শুরু
 
বর্তমান রিভিশনটিকে খারাপ হিসেবে লেবেল করুন:git bisect bad
 
একটি সংশোধনকে ভালো হিসেবে লেবেল করুন:git bisect good 
 
নতুন সংশোধনের সাথে তৈরি করুন
 
ফলাফলের উপর ভিত্তি করে (যদি সমস্যাটি উপস্থিত থাকে বা না থাকে), গিটকে বলুন: git bisect good or git bisect bad
 
সমস্যা কমিট না পাওয়া পর্যন্ত 4-5 ধাপ ধুয়ে ফেলুন এবং পুনরাবৃত্তি করুন!
 
সমস্যা কমিট প্রত্যাবর্তন বা সমাধান করুন।
 
 

 দ্রষ্টব্য: মার্জারগুলিকে সাময়িকভাবে গিট রিবেস -i  চালতে হবে সঠিকভাবে দ্বিখণ্ডিত করার জন্য আপনার শাখায় সমস্ত প্যাচ প্রয়োগ করতে, কারণ জায়গায় একত্রিতকরণের সাথে দ্বিখণ্ডিত করা প্রায়শই আপস্ট্রিম কমিটগুলিতে চেকআউট করবে, মানে আপনার কাছে Android নির্দিষ্ট প্রতিশ্রুতিগুলির মধ্যে কোনোটি নেই . অনুরোধের ভিত্তিতে আমি এই বিষয়ে আরও গভীরে যেতে পারি তবে আমাকে বিশ্বাস করুন, এটি প্রয়োজন। একবার আপনি সমস্যার প্রতিশ্রুতি চিহ্নিত করলে, আপনি এটিকে একত্রীকরণে প্রত্যাবর্তন বা রিবেস করতে পারেন।
 
আপস্ট্রিম আপডেটগুলি স্কোয়াশ করবেন না 
 

 অনেক নতুন বিকাশকারী এটি করতে প্রলুব্ধ হয় কারণ এটি পরিচালনা করা "পরিচ্ছন্ন" এবং "সহজ"। এটি কয়েকটি কারণে ভয়ানক:
 
 
লেখকত্ব হারিয়ে গেছে। অন্য ডেভেলপারদের তাদের কাজের জন্য তাদের ক্রেডিট বন্ধ করাটা অন্যায়।
 
বিভাগ করা অসম্ভব। আপনি যদি একটি সিরিজ কমিট স্কোয়াশ করেন এবং সেই সিরিজে কিছু একটা সমস্যা হয়, তাহলে স্কোয়াশে কোন কমিটের কারণে সমস্যা হয়েছে তা বলা অসম্ভব।
 
ভবিষ্যত চেরি-পিক আরও কঠিন। যদি আপনাকে একটি স্কোয়াশড সিরিজের সাথে রিবেস করতে হয়, তাহলে কোথা থেকে বিরোধের ফলাফল তা বলা কঠিন/অসম্ভব।
 
 
সময়মত আপডেটের জন্য লিনাক্স কার্নেল মেলিং লিস্টে সদস্যতা নিন 
 

 যখনই একটি আপস্ট্রিম আপডেট থাকে তখন বিজ্ঞপ্তি পাওয়ার জন্য, linux-kernel-announce list-এ সদস্যতা নিন . এটি আপনাকে প্রতিবার একটি নতুন কার্নেল প্রকাশ করার সময় একটি ইমেল পাওয়ার অনুমতি দেবে যাতে আপনি যত তাড়াতাড়ি সম্ভব আপডেট করতে এবং পুশ করতে পারেন৷