GKI-এর জন্য কার্নেল কোড ডেভেলপ করা

জেনেরিক কার্নেল ইমেজ (GKI) আপস্ট্রিম Linux কার্নেলের সাথে ক্লোজলি অ্যালাইন করে কার্নেল ফ্র্যাগমেন্টেশন কমায়। তবে, কিছু প্যাচ কেন আপস্ট্রিম গ্রহণ করা যায় না তার বৈধ কারণ আছে এবং প্রোডাক্ট শিডিউল মেনে চলতে হয়, তাই কিছু প্যাচ Android Common Kernel (ACK) সোর্সে রক্ষণাবেক্ষণ করা হয় যেখান থেকে GKI তৈরি করা হয়।

ডেভেলপারদের প্রথম পছন্দ হিসেবে Linux Kernel Mailing List (LKML) ব্যবহার করে আপস্ট্রিম কোডে পরিবর্তন জমা দিতে হবে এবং আপস্ট্রিম কোড জমা দেওয়ার উপযুক্ত না হওয়ার কোনও শক্তিশালী কারণ থাকলে তবেই ACK android-mainline শাখায় কোডে পরিবর্তন জমা দিতে হবে। সঠিক কারণের উদাহরণ এবং সেগুলি কীভাবে ম্যানেজ করতে হয় তা নিচে তালিকাভুক্ত করা হয়েছে।

• প্যাচটি LKML-এ জমা দেওয়া হয়েছে, কিন্তু প্রোডাক্ট রিলিজের জন্য সময়মতো গ্রহণ করা হয়নি। এই প্যাচটি প্রয়োগ করতে:

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

• প্যাচটি একটি ভেন্ডর মডিউলের জন্য EXPORT_SYMBOLS_GPL() সংজ্ঞায়িত করে, কিন্তু আপস্ট্রিমে জমা দেওয়া যায়নি কারণ কোনও ইন-ট্রি মডিউল নেই যা সেই প্রতীকটি ব্যবহার করে। এই প্যাচ ম্যানেজ করতে, আপনার মডিউল কেন আপস্ট্রিমে জমা দেওয়া যাচ্ছে না এবং এই অনুরোধ করার আগে আপনি কী কী বিকল্প বিবেচনা করেছেন সেই সম্পর্কে বিবরণ দিন।

• প্যাচটি আপস্ট্রিমের জন্য যথেষ্ট জেনেরিক নয় এবং প্রোডাক্ট রিলিজের আগে এটি রিফ্যাক্টর করার সময় নেই। এই প্যাচটি ম্যানেজ করতে, একটি আনুমানিক সময় দিন যার মধ্যে একটি রিফ্যাক্টর করা প্যাচ আপস্ট্রিম জমা দেওয়া হবে (পর্যালোচনার জন্য আপস্ট্রিমে রিফ্যাক্টর করা প্যাচ জমা দেওয়ার পরিকল্পনা না থাকলে ACK-তে প্যাচটি গ্রহণ করা হবে না)।

• আপস্ট্রিম এই প্যাচ গ্রহণ করতে পারবে না কারণ... <insert reason here>. এই প্যাচটি ম্যানেজ করতে, Android কার্নেল টিমের সাথে যোগাযোগ করুন এবং প্যাচটি রিফ্যাক্টর করার বিকল্পের ব্যাপারে আমাদের সাথে কাজ করুন যাতে এটি পর্যালোচনা করার জন্য জমা দেওয়া যায় এবং আপস্ট্রিম গ্রহণ করা যায়।

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

প্যাচ সংক্রান্ত প্রয়োজনীয়তা

প্যাচগুলি অবশ্যই Linux সোর্স ট্রি-তে বর্ণিত Linux কার্নেল কোডিং স্ট্যান্ডার্ডের সাথে সামঞ্জস্যপূর্ণ হতে হবে, সেগুলি আপস্ট্রিমে বা ACK-তে জমা দেওয়া হোক না কেন। scripts/checkpatch.pl স্ক্রিপ্ট Gerrit প্রি-সাবমিট টেস্টিংয়ের অংশ হিসেবে রান করা হয়, তাই এটি পাস করবে কিনা তা নিশ্চিত করতে আগে থেকে রান করুন। প্রি-সাবমিট টেস্টিংয়ের মতো একই কনফিগারেশন সহ checkpatch স্ক্রিপ্ট রান করতে, //build/kernel/static_analysis:checkpatch_presubmit ব্যবহার করুন। বিস্তারিত জানতে, build/kernel/kleaf/docs/checkpatch.md দেখুন।

ACK প্যাচ

ACK-তে জমা দেওয়া প্যাচগুলিকে অবশ্যই Linux কার্নেল কোডিং স্ট্যান্ডার্ড এবং কন্ট্রিবিউশন নির্দেশিকা মেনে চলতে হবে। আপনাকে কমিট মেসেজে Change-Id ট্যাগ যোগ করতে হবে; আপনি একাধিক শাখায় প্যাচ জমা দিলে (যেমন, android-mainline ও android12-5.4), আপনাকে সব প্যাচের জন্য একই Change-Id ব্যবহার করতে হবে।

আপস্ট্রিম পর্যালোচনার জন্য প্রথমে LKML-এ প্যাচ জমা দিন। প্যাচটি যদি:

• আপস্ট্রিম গ্রহণ করেছে, এটি android-mainline-এ অটোমেটিক মার্জ হয়ে যাবে।
• আপস্ট্রিম গ্রহণ না করলে, android-mainline-এ জমা দিন। এর সাথে আপস্ট্রিম জমা দেওয়ার রেফারেন্স বা কেন এটি LKML-এ জমা দেওয়া হয়নি তার ব্যাখ্যা দিন।

আপস্ট্রিম বা android-mainline-এ কোনও প্যাচ গ্রহণ করার পরে, এটিকে উপযুক্ত LTS-ভিত্তিক ACK-তে ব্যাকপোর্ট করা যেতে পারে (যেমন, android12-5.4 এবং android11-5.4, Android-নির্দিষ্ট কোড ঠিক করে এমন প্যাচের জন্য)। android-mainline-এ জমা দিলে, নতুন আপস্ট্রিম রিলিজ ক্যান্ডিডেটের সাথে টেস্টিং চালু হয় এবং প্যাচটি পরবর্তী LTS-ভিত্তিক ACK-তে আছে কিনা তা নিশ্চিত করে। এর ব্যতিক্রম হল সেইসব কেস যেখানে একটি আপস্ট্রিম প্যাচ android12-5.4-এ ব্যাকপোর্ট করা হয় (কারণ প্যাচটি সম্ভবত আগেই android-mainline-এ আছে)।

আপস্ট্রিম প্যাচ

কন্ট্রিবিউশন নির্দেশিকাতে যেমন উল্লেখ করা আছে, ACK কার্নেলের জন্য নির্ধারিত আপস্ট্রিম প্যাচ নিম্নলিখিত গ্রুপে পড়ে (গ্রহণ করার সম্ভাবনা অনুসারে তালিকাভুক্ত)।

• UPSTREAM: - 'android-mainline` থেকে বেছে নেওয়া প্যাচগুলি যুক্তিসঙ্গত ব্যবহারিক তথ্য থাকলে ACK-তে গ্রহণ করা হতে পারে।
• BACKPORT: - আপস্ট্রিম থেকে এমন প্যাচ যা পরিষ্কারভাবে চেরি-পিক করা হয়নি এবং পরিবর্তন করার প্রয়োজন আছে, সেগুলিও যুক্তিসঙ্গত ব্যবহারের কেস থাকলে গ্রহণ করা হতে পারে।
• FROMGIT: - Linux মেইনলাইনে জমা দেওয়ার প্রস্তুতি হিসেবে মেন্টেনার ব্রাঞ্চ থেকে বেছে নেওয়া প্যাচ আসন্ন ডেডলাইন থাকলে গ্রহণ করা হতে পারে। কন্টেন্ট ও শিডিউল, দুটির ক্ষেত্রেই এটি যুক্তিযুক্ত হতে হবে।
• FROMLIST: - LKML-এ জমা দেওয়া হয়েছে কিন্তু এখনও কোনও মেইনটেনার ব্রাঞ্চে গ্রহণ করা হয়নি এমন প্যাচ গ্রহণ করার সম্ভাবনা কম, যদি না প্যাচটি আপস্ট্রিম Linux-এ (আমরা ধরে নিচ্ছি যে এটি হবে না) ল্যান্ড করুক বা না করুক, সেটি গ্রহণ করার জন্য যথেষ্ট যুক্তি থাকে। Android কার্নেল টিমের সাথে আলোচনা করার জন্য FROMLISTপ্যাচ সম্পর্কিত কোনও সমস্যা থাকতে হবে।

Android-নির্দিষ্ট প্যাচ

আপস্ট্রিম কোডে প্রয়োজনীয় পরিবর্তন করতে না পারলে, আপনি সরাসরি ACK-তে আউট-অফ-ট্রি প্যাচ জমা দেওয়ার চেষ্টা করতে পারেন। আউট-অফ-ট্রি প্যাচ জমা দেওয়ার জন্য আপনাকে IT-তে একটি সমস্যা তৈরি করতে হবে যেখানে প্যাচ ও তার কারণ উল্লেখ করা থাকবে যে কেন আপস্ট্রিম জমা দেওয়া যাবে না (উদাহরণ দেখতে আগের তালিকা দেখুন)। তবে, এমন কিছু ঘটনা আছে যেখানে কোডটি আপস্ট্রিম জমা দেওয়া যায় না। এইসব কেস নিম্নলিখিতভাবে কভার করা হয় এবং Android-নির্দিষ্ট প্যাচের জন্য কন্ট্রিবিউশন নির্দেশিকা অবশ্যই অনুসরণ করতে হবে এবং সাবজেক্টে ANDROID: প্রিফিক্স সহ ট্যাগ করতে হবে।

gki_defconfig-এ পরিবর্তন

gki_defconfig-এ করা সব CONFIG পরিবর্তন arm64 এবং x86 ভার্সন, দুটিতেই প্রয়োগ করতে হবে, যদি না CONFIG আর্কিটেকচার-নির্দিষ্ট হয়। CONFIG সেটিংয়ে পরিবর্তনের অনুরোধ করতে, পরিবর্তন নিয়ে আলোচনা করার জন্য IT-তে একটি সমস্যা তৈরি করুন। কার্নেল মডিউল ইন্টারফেস (KMI) ফ্রোজেন হওয়ার পরে CONFIG এতে কোনও পরিবর্তন করা হলে তা বাতিল করা হয়। যেসব ক্ষেত্রে পার্টনাররা একটি কনফিগের জন্য পরস্পরবিরোধী সেটিংয়ের অনুরোধ করেন, সেইসব ক্ষেত্রে আমরা সংশ্লিষ্ট বাগ নিয়ে আলোচনার মাধ্যমে বিবাদ সমাধান করি।

আপস্ট্রিম না থাকা কোড

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

এই বিভাগে অন্যান্য পরিবর্তনের মধ্যে রয়েছে KMI রিপ্রেজেন্টেশন ফাইল, KMI প্রতীক তালিকা, gki_defconfig, বিল্ড স্ক্রিপ্ট বা কনফিগারেশন অথবা আপস্ট্রিমে নেই এমন অন্যান্য স্ক্রিপ্ট আপডেট করা।

আউট-অফ-ট্রি মডিউল

আপস্ট্রিম Linux সক্রিয়ভাবে আউট-অফ-ট্রি মডিউল তৈরির জন্য সহায়তাকে নিরুৎসাহিত করে। এটি একটি যুক্তিসঙ্গত অবস্থান কারণ Linux রক্ষণাবেক্ষণকারীরা ইন-কার্নেল সোর্স বা বাইনারি কম্প্যাটিবিলিটি সম্পর্কে কোনও গ্যারান্টি দেন না এবং ট্রি-তে নেই এমন কোডকে সাপোর্ট করতে চান না। তবে, GKI করে ভেন্ডর মডিউলের জন্য ABI গ্যারান্টি দেয়, এর ফলে নিশ্চিত করা যায় যে KMI ইন্টারফেস, কার্নেলের সাপোর্টেড লাইফটাইমের জন্য স্থিতিশীল থাকে। তাই, ভেন্ডর মডিউলকে সাপোর্ট করার জন্য এক ধরনের পরিবর্তন করা হয় যা ACK-এর জন্য গ্রহণযোগ্য হলেও আপস্ট্রিমের জন্য গ্রহণযোগ্য নয়।

যেমন, এমন একটি প্যাচের কথা ভাবুন যা EXPORT_SYMBOL_GPL() ম্যাক্রো যোগ করে যেখানে এক্সপোর্ট ব্যবহার করা মডিউল সোর্স ট্রিতে নেই। আপনাকে অবশ্যই EXPORT_SYMBOL_GPL() আপস্ট্রিম করার অনুরোধ করতে হবে এবং নতুন এক্সপোর্ট করা সিম্বল ব্যবহার করে এমন একটি মডিউল সাপ্লাই করতে হবে। তবে, মডিউলটি আপস্ট্রিমে জমা না দেওয়ার কোনও বৈধ কারণ থাকলে, আপনি ACK-তে প্যাচ জমা দিতে পারেন। মডিউলটি কেন আপস্ট্রিম করা যাবে না তার কারণ আপনাকে ইস্যুতে উল্লেখ করতে হবে। (GPL নয় এমন ভেরিয়েন্টের অনুরোধ করবেন না, EXPORT_SYMBOL()।)

লুকানো কনফিগারেশন

কিছু ইন-ট্রি মডিউল অটোমেটিক লুকানো কনফিগারেশন বেছে নেয় যা gki_defconfig-এ নির্দিষ্ট করা যায় না। যেমন, CONFIG_SND_SOC_SOF=y কনফিগার করা হলে CONFIG_SND_SOC_TOPOLOGY অটোমেটিক বেছে নেওয়া হয়। আউট-অফ-ট্রি মডিউল বিল্ডিংয়ের জন্য, GKI-তে লুকানো কনফিগারেশন চালু করার একটি মেকানিজম অন্তর্ভুক্ত থাকে।

কোনও লুকানো কনফিগারেশন চালু করতে, init/Kconfig.gki-এ একটি select স্টেটমেন্ট যোগ করুন যাতে এটি CONFIG_GKI_HACKS_TO_FIX কার্নেল কনফিগারেশনের উপর ভিত্তি করে অটোমেটিক বেছে নেওয়া হয়, যা gki_defconfig-এ চালু করা আছে। এই মেকানিজমটি শুধুমাত্র লুকানো কনফিগারেশনের জন্য ব্যবহার করুন; কনফিগারেশন লুকানো না থাকলে, এটি অবশ্যই gki_defconfig-এ স্পষ্টভাবে বা একটি নির্ভরতা হিসেবে উল্লেখ করতে হবে।

লোড করা যায় এমন গভর্নর

কার্নেল ফ্রেমওয়ার্কের (যেমন cpufreq) জন্য যা লোড করা যায় এমন গভর্নরকে সাপোর্ট করে, আপনি ডিফল্ট গভর্নরকে (যেমন cpufreq-এর schedutil গভর্নর) ওভাররাইড করতে পারবেন। যেসব ফ্রেমওয়ার্ক (যেমন, থার্মাল ফ্রেমওয়ার্ক) লোড করা যায় এমন গভর্নর বা ড্রাইভারের সাথে কাজ করে না, কিন্তু তারপরেও ভেন্ডর-নির্দিষ্ট প্রয়োগের প্রয়োজন হয়, সেগুলির জন্য IT-তে একটি সমস্যা তৈরি করুন এবং Android কার্নেল টিমের সাথে পরামর্শ করুন।

প্রয়োজনীয় সহায়তা যোগ করার জন্য আমরা আপনার ও আপস্ট্রিম মেন্টেনারের সাথে কাজ করব।

ভেন্ডর হুক

আগের রিলিজে, আপনি সরাসরি কোর কার্নেলে ভেন্ডর-নির্দিষ্ট পরিবর্তন যোগ করতে পারতেন। GKI 2.0-এর ক্ষেত্রে এটি সম্ভব নয় কারণ প্রোডাক্ট-নির্দিষ্ট কোড অবশ্যই মডিউলে প্রয়োগ করতে হবে এবং কোর কার্নেল আপস্ট্রিমে বা ACK-তে গ্রহণ করা হবে না। কোর কার্নেল কোডে ন্যূনতম প্রভাব সহ পার্টনাররা নির্ভর করে এমন ভ্যালু-অ্যাডেড ফিচার চালু করতে, GKI ভেন্ডর হুক গ্রহণ করে যা কোর কার্নেল কোড থেকে মডিউলগুলিকে আহ্বান করার অনুমতি দেয়। এছাড়াও, এইসব ফিচার প্রয়োগ করার জন্য ভেন্ডর-নির্দিষ্ট ডেটা স্টোর করতে উপলভ্য ভেন্ডর ডেটা ফিল্ডের সাথে মূল ডেটা স্ট্রাকচার প্যাড করা যেতে পারে।

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

• সাধারণ ভেন্ডর হুক DECLARE_HOOK() ব্যবহার করে trace_name নামের একটি ট্রেসপয়েন্ট ফাংশন তৈরি করে, যেখানে name হল ট্রেসের অনন্য শনাক্তকারী। কনভেনশন অনুযায়ী, সাধারণ ভেন্ডর হুকের নাম android_vh দিয়ে শুরু হয়, তাই sched_exit() হুকের নাম হবে android_vh_sched_exit।
• যেসব ক্ষেত্রে সীমাবদ্ধ ভেন্ডর হুক প্রয়োজন, তার মধ্যে শিডিউলার হুক পড়ে। এখানে CPU অফলাইন থাকলেও অ্যাটাচ করা ফাংশন কল করতে হবে অথবা অ্যাটমিক নয় এমন কনটেক্সট প্রয়োজন। সীমাবদ্ধ ভেন্ডর হুক আলাদা করা যায় না, তাই সীমাবদ্ধ হুকের সাথে অ্যাটাচ করা মডিউল কখনও আনলোড করা যায় না। বিধিনিষেধযুক্ত ভেন্ডর হুক নামের শুরুতে android_rvh থাকে।

ভেন্ডর হুক যোগ করতে, IT-তে একটি সমস্যা ফাইল করুন এবং প্যাচ জমা দিন (সমস্ত Android-নির্দিষ্ট প্যাচের মতো, একটি সমস্যা থাকতে হবে এবং আপনাকে যুক্তি প্রদান করতে হবে)। ভেন্ডর হুক শুধুমাত্র ACK-তে কাজ করে, তাই এই প্যাচগুলি আপস্ট্রিম Linux-এ পাঠাবেন না।

স্ট্রাকচারে ভেন্ডর ফিল্ড যোগ করা

আপনি ANDROID_VENDOR_DATA() ম্যাক্রো ব্যবহার করে android_vendor_data ফিল্ড যোগ করার মাধ্যমে মূল ডেটা স্ট্রাকচারের সাথে ভেন্ডর ডেটা যুক্ত করতে পারবেন। যেমন, ভ্যালু-অ্যাডেড ফিচার কাজ করানোর জন্য, নিম্নলিখিত কোড স্যাম্পলে দেখানো মতো স্ট্রাকচারে ফিল্ড যোগ করুন।

ভেন্ডরদের প্রয়োজনীয় ফিল্ড এবং OEM-দের প্রয়োজনীয় ফিল্ডের মধ্যে সম্ভাব্য সংঘাত এড়াতে, OEM-দের অবশ্যই ANDROID_VENDOR_DATA()ম্যাক্রো ব্যবহার করে ঘোষণা করা ফিল্ড ব্যবহার করা উচিত নয়। এর পরিবর্তে, OEM-কে android_oem_data ফিল্ড ঘোষণা করতে ANDROID_OEM_DATA() ব্যবহার করতে হবে।

#include <linux/android_vendor.h>
...
struct important_kernel_data {
  [all the standard fields];
  /* Create vendor data for use by hook implementations. The
   * size of vendor data is based on vendor input. Vendor data
   * can be defined as single u64 fields like the following that
   * declares a single u64 field named "android_vendor_data1" :
   */
  ANDROID_VENDOR_DATA(1);

  /*
   * ...or an array can be declared. The following is equivalent to
   * u64 android_vendor_data2[20]:
   */
  ANDROID_VENDOR_DATA_ARRAY(2, 20);

  /*
   * SoC vendors must not use fields declared for OEMs and
   * OEMs must not use fields declared for SoC vendors.
   */
  ANDROID_OEM_DATA(1);

  /* no further fields */
}

ভেন্ডর হুক সংজ্ঞায়িত করা

DECLARE_HOOK() বা DECLARE_RESTRICTED_HOOK() ব্যবহার করে ঘোষণা করার মাধ্যমে কার্নেল কোডে ট্রেসপয়েন্ট হিসেবে ভেন্ডর হুক যোগ করুন এবং তারপরে ট্রেসপয়েন্ট হিসেবে কোডে যোগ করুন। যেমন, আগে থেকে থাকা do_exit() কার্নেল ফাংশনে trace_android_vh_sched_exit() যোগ করতে:

#include <trace/hooks/exit.h>
void do_exit(long code)
{
    struct task_struct *tsk = current;
    ...
    trace_android_vh_sched_exit(tsk);
    ...
}

trace_android_vh_sched_exit() ফাংশনটি প্রথমে শুধুমাত্র কোনও কিছু অ্যাটাচ করা আছে কিনা তা চেক করে। তবে, কোনও ভেন্ডর মডিউল register_trace_android_vh_sched_exit() ব্যবহার করে হ্যান্ডলার রেজিস্টার করলে, রেজিস্টার করা ফাংশন কল করা হয়। হ্যান্ডলারকে অবশ্যই লক, RCS স্ট্যাটাস এবং অন্যান্য ফ্যাক্টরের বিষয়ে সচেতন থাকতে হবে। হুকটি অবশ্যই include/trace/hooks ডিরেক্টরির একটি হেডার ফাইলে সংজ্ঞায়িত করা উচিত।

যেমন, নিম্নলিখিত কোডটি include/trace/hooks/exit.h ফাইলে trace_android_vh_sched_exit()-এর জন্য একটি সম্ভাব্য ঘোষণা দেয়।

/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM sched
#define TRACE_INCLUDE_PATH trace/hooks

#if !defined(_TRACE_HOOK_SCHED_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_HOOK_SCHED_H
#include <trace/hooks/vendor_hooks.h>
/*
 * Following tracepoints are not exported in tracefs and provide a
 * mechanism for vendor modules to hook and extend functionality
 */

struct task_struct;

DECLARE_HOOK(android_vh_sched_exit,
             TP_PROTO(struct task_struct *p),
             TP_ARGS(p));

#endif /* _TRACE_HOOK_SCHED_H */

/* This part must be outside protection */
#include <trace/define_trace.h>

ভেন্ডর হুকের জন্য প্রয়োজনীয় ইন্টারফেস ইনস্ট্যান্টিয়েট করতে, drivers/android/vendor_hooks.c-এ হুক ডিক্লারেশন সহ হেডার ফাইল যোগ করুন এবং সিম্বল এক্সপোর্ট করুন। যেমন, নিম্নলিখিত কোডটি android_vh_sched_exit() হুক ঘোষণা করা সম্পূর্ণ করে।

#ifndef __GENKSYMS__
/* struct task_struct */
#include <linux/sched.h>
#endif

#define CREATE_TRACE_POINTS
#include <trace/hooks/vendor_hooks.h>
#include <trace/hooks/exit.h>
/*
 * Export tracepoints that act as a bare tracehook (i.e. have no trace
 * event associated with them) to allow external modules to probe
 * them.
 */
EXPORT_TRACEPOINT_SYMBOL_GPL(android_vh_sched_exit);

মনে রাখবেন: হুক ডিক্লারেশনের মধ্যে ব্যবহৃত ডেটা স্ট্রাকচারকে সম্পূর্ণভাবে সংজ্ঞায়িত করতে হবে যাতে ABI স্টেবিলিটি নিশ্চিত করা যায়। অন্যথায়, অপেক পয়েন্টারকে ডিরেফারেন্স করা বা সাইজড কনটেক্সটে স্ট্রাক্ট ব্যবহার করা নিরাপদ নয়। এই ধরনের ডেটা স্ট্রাকচারের সম্পূর্ণ সংজ্ঞা প্রদান করে এমন include drivers/android/vendor_hooks.c-এর #ifndef __GENKSYMS__ বিভাগের মধ্যে থাকতে হবে। include/trace/hooks-এর হেডার ফাইলে CRC পরিবর্তন এড়াতে, KMI ভেঙে যায় এমন টাইপ ডেফিনিশন সহ কার্নেল হেডার ফাইল থাকা উচিত নয়। পরিবর্তে, টাইপগুলি ঘোষণা করুন।

ভেন্ডর হুকের সাথে অ্যাটাচ করুন

ভেন্ডর হুক ব্যবহার করতে, ভেন্ডর মডিউলকে হুকের জন্য একটি হ্যান্ডলার রেজিস্টার করতে হবে (সাধারণত মডিউল ইনিশিয়ালাইজেশনের সময় করা হয়)। যেমন, নিম্নলিখিত কোড trace_android_vh_sched_exit()-এর জন্য মডিউল foo.ko হ্যান্ডলার দেখায়।

#include <trace/hooks/sched.h>
...
static void foo_sched_exit_handler(void *data, struct task_struct *p)
{
    foo_do_exit_accounting(p);
}
...
static int foo_probe(..)
{
    ...
    rc = register_trace_android_vh_sched_exit(foo_sched_exit_handler, NULL);
    ...
}

হেডার ফাইল থেকে ভেন্ডর হুক ব্যবহার করা

হেডার ফাইল থেকে ভেন্ডর হুক ব্যবহার করতে, আপনাকে ভেন্ডর হুক হেডার ফাইল আপডেট করতে হতে পারে যাতে TRACE_INCLUDE_PATH আনডিফাইন করা যায়। এর ফলে বিল্ড সংক্রান্ত এমন সমস্যা এড়ানো যায় যা থেকে বোঝা যায় যে ট্রেস পয়েন্ট হেডার ফাইল খুঁজে পাওয়া যায়নি। যেমন,

In file included from .../common/init/main.c:111:
In file included from .../common/include/trace/events/initcall.h:74:
.../common/include/trace/define_trace.h:95:10: fatal error: 'trace/hooks/initcall.h' file not found
   95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE'
   90 | # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system)
      |                                ^~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE'
   87 | # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h)
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:10:27: note: expanded from macro '__stringify'
   10 | #define __stringify(x...)       __stringify_1(x)
      |                                 ^~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1'
    9 | #define __stringify_1(x...)     #x
      |                                 ^~
<scratch space>:14:1: note: expanded from here
   14 | "trace/hooks/initcall.h"
      | ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

এই ধরনের বিল্ড সংক্রান্ত সমস্যার সমাধান করতে, আপনি যে ভেন্ডর হুক হেডার ফাইল অন্তর্ভুক্ত করছেন তাতে সমতুল্য সমাধান প্রয়োগ করুন। আরও তথ্যের জন্য, https://r.android.com/3066703 দেখুন।

diff --git a/include/trace/hooks/mm.h b/include/trace/hooks/mm.h
index bc6de7e53d66..039926f7701d 100644
--- a/include/trace/hooks/mm.h
+++ b/include/trace/hooks/mm.h
@@ -2,7 +2,10 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM mm

+#ifdef CREATE_TRACE_POINTS
 #define TRACE_INCLUDE_PATH trace/hooks
+#define UNDEF_TRACE_INCLUDE_PATH
+#endif

UNDEF_TRACE_INCLUDE_PATH সংজ্ঞায়িত করার অর্থ হল include/trace/define_trace.h-কে বলা যে ট্রেস পয়েন্ট তৈরি করার পরে TRACE_INCLUDE_PATH-কে সংজ্ঞাহীন করতে।

কার্নেলের মূল ফিচার

আগের কোনও কৌশল ব্যবহার করে যদি মডিউল থেকে কোনও ফিচার প্রয়োগ করতে না পারেন, তাহলে আপনাকে অবশ্যই কোর কার্নেলে Android-নির্দিষ্ট পরিবর্তন হিসেবে ফিচারটি যোগ করতে হবে। আলোচনা শুরু করতে ইস্যু ট্র্যাকার (IT)-এ একটি ইস্যু তৈরি করুন।

ব্যবহারকারীর অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেস (UAPI)

• UAPI হেডার ফাইল। Android-নির্দিষ্ট ইন্টারফেসে পরিবর্তন না হলে, পরিবর্তনগুলি UAPI হেডার ফাইলে আপস্ট্রিমেই করতে হবে। ভেন্ডর মডিউল ও ভেন্ডর ইউজারস্পেস কোডের মধ্যে ইন্টারফেস নির্ধারণ করতে ভেন্ডর-নির্দিষ্ট হেডার ফাইল ব্যবহার করুন।
• sysfs নোড। GKI কার্নেলে নতুন sysfs নোড যোগ করবেন না (এই ধরনের সংযোজন শুধুমাত্র ভেন্ডর মডিউলে বৈধ)। SoC- এবং ডিভাইস-অ্যাগনস্টিক লাইব্রেরি এবং Android ফ্রেমওয়ার্কের অন্তর্ভুক্ত Java কোড দ্বারা ব্যবহৃত sysfs নোড শুধুমাত্র মানানসই উপায়ে পরিবর্তন করা যেতে পারে এবং সেগুলি Android-নির্দিষ্ট sysfs নোড না হলে অবশ্যই আপস্ট্রিম পরিবর্তন করতে হবে। আপনি ভেন্ডর ব্যবহারকারী স্পেসের ব্যবহারের জন্য ভেন্ডর-নির্দিষ্ট sysfs নোড তৈরি করতে পারেন। সাধারণত, SELinux ব্যবহার করে ব্যবহারকারীর স্পেসের মাধ্যমে sysfs নোডে অ্যাক্সেস করার অনুমতি দেওয়া হয় না। অনুমোদিত ভেন্ডর সফ্টওয়্যারকে অ্যাক্সেস দেওয়ার জন্য উপযুক্ত SELinux লেবেল যোগ করার দায়িত্ব ভেন্ডরের।
• DebugFS নোড। ভেন্ডর মডিউল শুধুমাত্র debugfs-এ নোডকে ডিফাইন করতে পারে শুধুমাত্র ডিবাগ করার জন্য (কারণ debugfs ডিভাইসটির স্বাভাবিক অপারেশনের সময় মাউন্ট করা হয় না )।