GKI-এর জন্য কার্নেল কোড তৈরি করুন

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

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

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

    • প্রমাণ দিন যে প্যাচটি LKML-এ জমা দেওয়া হয়েছে এবং প্যাচের জন্য প্রাপ্ত মন্তব্য, বা একটি আনুমানিক সময় যার মধ্যে প্যাচটি আপস্ট্রিম জমা দেওয়া হবে।
    • প্যাচটি ACK-তে অবতরণ করার জন্য একটি পদক্ষেপের বিষয়ে সিদ্ধান্ত নিন, এটি আপস্ট্রিমে অনুমোদিত করুন এবং তারপরে চূড়ান্ত আপস্ট্রিম সংস্করণটি ACK-এ একীভূত হলে এটিকে ACK থেকে বের করে নিন।

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

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

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

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

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

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

ACK প্যাচ

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

একটি আপস্ট্রিম পর্যালোচনার জন্য প্রথমে প্যাচগুলি LKML-এ জমা দিন৷ যদি প্যাচ হয়:

  • আপস্ট্রিমে গৃহীত, এটি স্বয়ংক্রিয়ভাবে android-mainline একত্রিত হয়।
  • আপস্ট্রিমে গৃহীত নয়, আপস্ট্রিম জমা দেওয়ার রেফারেন্স সহ বা কেন এটি LKML-এ জমা দেওয়া হয়নি তার ব্যাখ্যা সহ এটি android-mainline এ জমা দিন।

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

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

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

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

অ্যান্ড্রয়েড-নির্দিষ্ট প্যাচ

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

gki_defconfig এ পরিবর্তন

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

কোড যে আপস্ট্রিম বিদ্যমান নেই

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

এই বিভাগে অন্যান্য পরিবর্তনগুলি হল KMI উপস্থাপনা ফাইল, KMI প্রতীক তালিকা, gki_defconfig , বিল্ড স্ক্রিপ্ট বা কনফিগারেশন, বা অন্যান্য স্ক্রিপ্ট যা আপস্ট্রিমে বিদ্যমান নেই।

গাছের বাইরের মডিউল

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

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

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

কাঠামোতে বিক্রেতা ক্ষেত্র যোগ করুন

আপনি ANDROID_VENDOR_DATA() ম্যাক্রো ব্যবহার করে android_vendor_data ক্ষেত্র যোগ করে মূল ডেটা স্ট্রাকচারের সাথে বিক্রেতার ডেটা যুক্ত করতে পারেন। উদাহরণস্বরূপ, মান-সংযোজিত বৈশিষ্ট্যগুলিকে সমর্থন করার জন্য, নিম্নলিখিত কোড নমুনায় দেখানো কাঠামোতে ক্ষেত্রগুলি যুক্ত করুন।

বিক্রেতাদের প্রয়োজনীয় ক্ষেত্র এবং OEM-এর প্রয়োজনীয় ক্ষেত্রগুলির মধ্যে সম্ভাব্য দ্বন্দ্ব এড়াতে, OEMগুলিকে কখনই ANDROID_VENDOR_DATA() ম্যাক্রো ব্যবহার করে ঘোষিত ক্ষেত্রগুলি ব্যবহার করা উচিত নয়৷ পরিবর্তে, android_oem_data ক্ষেত্রগুলি ঘোষণা করতে OEMsকে অবশ্যই 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 স্থিতিশীলতার গ্যারান্টি দেওয়ার জন্য হুক ঘোষণার মধ্যে ব্যবহৃত ডেটা কাঠামোগুলিকে সম্পূর্ণরূপে সংজ্ঞায়িত করতে হবে। অন্যথায় অস্বচ্ছ পয়েন্টারগুলিকে ডিরেফারেন্স করা বা আকারের প্রসঙ্গে কাঠামো ব্যবহার করা অনিরাপদ। অন্তর্ভুক্ত যা এই ধরনের ডেটা স্ট্রাকচারের সম্পূর্ণ সংজ্ঞা প্রদান করে 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 সংজ্ঞায়িত করা ট্রেস পয়েন্ট তৈরি করার পরে TRACE_INCLUDE_PATH অসংজ্ঞায়িত করতে include/trace/define_trace.h কে বলে।

মূল কার্নেল বৈশিষ্ট্য

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

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

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