பல லினக்ஸ் ஆர்வலர்கள் லினஸ் டொர்வால்ட்ஸின் புகழ்பெற்ற , “we don’t break user space”, எனும் அறிவுரையை நன்கு அறிந்திருப்பார்கள்ஆனால் இந்த சொற்றொடரை அங்கீகரிக்கும் அனைவரும் அதன் உண்மையான பொருள் என்ன என்பது பற்றி உறுதியாக தெரிந்துகொள்வதில்லை.
பயன்பாடுகளின் இரும இடைமுகத்தின் நிலைத்தன்மையைப் பற்றி “#1 எனும் விதி” மேம்படுத்துநர்களுக்கு நினைவூட்டுகிறது, இதன் மூலம் பயன்பாடுகள் உருவாக்கமையத்துடன் தொடர்புகொண்டு கட்டமைக்கப்படுகின்றது. பின்வருபவை ABI இன் கருத்துருவை வாசகர்களுக்கு அறிமுகப்படுத்தவும், ABI இன் நிலைத்தன்மை ஏன் முக்கியம் என்பதை விவரிக்கவும், லினக்ஸின் நிலையான ABI இல் என்ன சேர்க்கப்பட்டுள்ளது என்பதை துல்லியமாக விவாதிக்கவும் நோக்கமாக கொண்டுள்ளது. லினக்ஸின் தற்போதைய வளர்ச்சியானது , அதன்புதியபரிணாம வளர்ச்சிக்கான ABI இல்மாற்றங்கள் தேவைப்படுகின்றன, அவற்றில் சில சர்ச்சைக்குரியவை. இந்நிலையில்
ABI என்றால் என்ன? எனும் சந்தேகம் எழும் நிற்க
ABI என்பது பயன்பாடுகளின் இரும இடைமுகத்தைக் குறிக்கிறது. இது ABI இன் கருத்துருவைப் புரிந்துகொள்வதற்கான ஒரு வழி, அது இல்லாததைக் கருத்தில் கொள்வதாாகும். பயன்பாடுகள் நிரலாக்க இடைமுகங்கள் (APIகள்) பல மேம்படுத்துநர்களுக்கு மிகவும் பரிச்சயமானவை. பொதுவாக, நூலகங்களின் தலைப்புகளும் ஆவணங்களும் அவற்றின் API ஆகக் கருதப்படுகின்றன, எடுத்துக்காட்டாக, HTML5 போன்ற தரநிலை ஆவணங்கள். நூலகங்களுக்குள் அழைக்கும் அல்லது சரமாக-வடிவமைக்கப்பட்ட தரவை பரிமாறிக்கொள்ளும் நிரல்கள் API இல் விவரிக்கப்பட்டுள்ள மரபுகளுடன் இணங்க வேண்டும் அல்லது தேவையற்ற முடிவுகளை எதிர்பார்க்க வேண்டும்.
ABIகள் API களைப் போன்றே இருக்கின்றன, அவை கட்டளைகளின் விளக்கம் இரும தரவு பரிமாற்றத்தை நிருவகிக்கின்றன. சி நிரல்களுக்கு, ABI பொதுவாக திருப்பும் வகைகள் ,செயல்பாடுகளின் அளவுரு பட்டியல்கள், கட்டமைப்புகளின் தளவமைப்பு , எண்ணிடப்பட்ட வகைகளின் பொருள், வரிசைப்படுத்துதல் , வரம்பு ஆகியவற்றை உள்ளடக்கியது. லினக்ஸ் உருவாக்கமையம் 2022 ஆம் ஆண்டு வரை, கிட்டத்தட்ட முழுவதுமாக ஒரு C நிரலாகவே உள்ளது, எனவே அது இந்த விவரக்குறிப்புகளுக்கு இணங்க வேண்டும்.
“உருவாக்கமைய அமைவுஅழைப்பு இடைமுகம்(The kernel syscall interface)” என்பது லினக்ஸின் வழிகாட்டி பக்கங்களின் பிரிவு 2ல் விவரிக்கப்பட்டுள்ளது , இடைநிலைமென்பொருள் பயன்பாடுகளிலிருந்து அழைக்கக்கூடிய “mount” , “sync” போன்றவை நமக்குபழக்கமான செயலிகளின் சி பதிப்புகளை உள்ளடக்கி யவைகளாகும். இந்த செயலிகளின் இரும தளவமைப்பு லினக்ஸின் ABI இன் முதல் முக்கிய பகுதியாகும்.
“லினக்ஸின் நிலையான ABI இயில் என்ன இருக்கிறது?” என்ற கேள்விக்கு பதில். பல பயனர்கள் , மேம்படுத்துநர்கள் “sysfs (/sys) , procfs (/proc) இன் உள்ளடக்கங்களுடன் பதிலளிப்பார்கள். உண்மையில், அதிகாரப்பூர்வ லினக்ஸ் ABI ஆவணங்கள் பெரும்பாலும் இந்த மெய்நிகர் கோப்பு முறைமைகளில் கவனம் செலுத்துகிறது.
லினக்ஸ் ABI நிரலாக்கங்களால் எவ்வாறு செயல்படுத்தப்படுகிறது என்பதில் முந்தைய உரை கவனம் செலுத்துகிறது, ஆனால் சமமான முக்கியமான மனித நோக்கத்தைப் பிடிக்கத் தவறிவிட்டது. கீழே உள்ள படம் விளக்குவது போன்ற, ABI இன் செயல்பாட்டிற்கு உருவாக்கமைய குழு, சி இயந்திரமொழிமாற்றிகள் ( GCC அல்லது clang போன்றவை), அமைவு அழைப்புகளை செயல்படுத்தும் பயனாளியின் காலிஇட சி நூலக்ததினை (பொதுவாக glibc) உருவாக்குகின்ற மேம்படுத்துநர்களின் கூட்டாக, தொடர்ந்த முயற்சி தேவையாகும். இரும பயன்பாடுகள், செயற்படுத்தக்கூடியவை இணைப்புவடிவமைப்பிற்கு (ELF) இணங்க அதிகாக அமைக்கப்பட்டுள்ளன.
1
ABI பற்றி நாம் ஏன் அக்கறைகொள்ளவேண்டும்?
லினக்ஸ் ABI நிலைத்தன்மை உறுதியளித்தல், என்பது டார்வால்ட்ஸிடமிருந்து வரும் லினக்ஸ் வெளியீடுகள் , தனிப்பட்ட பயனர்கள் இயக்க முறைமையில் இருந்து சுதந்திரமாக உருவாக்கமையத்தினைப் புதுப்பிக்க முடியும்.
லினக்ஸில் நிலையான ABI இல்லை என்றால், ஒவ்வொரு முறையும் பாதுகாப்புச் சிக்கலைத் தீர்க்க உருவாக்கமையத்திற்கு ஒட்டுநிரலாக்கம் தேவைப்படும்போது, இயக்க முறைமையின் பெரும்பகுதி, முழுவதுமாக இல்லாவிட்டாலும், மீண்டும் நிறுவுகைசெய்யப்பட வேண்டும். வெளிப்படையாக, இரும இடைமுகத்தின் நிலைத்தன்மை லினக்ஸின் பயன்பாட்டிற்கு பரந்த ஏற்புகைக்கு ஒரு முக்கிய பங்களிக்கும் காரணியாகும்.
2.
இரண்டாவது படம் விளக்குவது போன்று, உருவாக்கமையத்தில் (linux-libc-dev இல்) , Glibc (libc6-dev இல்) ஆகியஇருகோப்பு அனுமதிகளை வரையறுக்கும் துன்மிமறைப்புகளை வழங்குகின்றன. வெளிப்படையாக இரண்டு தொகுப்பு வரையறைகளும் ஒத்துக்கொள்ள வேண்டும்! ஒவ்வொரு கோப்பையும் எந்த மென்பொருள் செயல்திட்டம் வழங்கியது என்பதை apt தொகுப்பு மேலாளர் அடையாளம் காட்டுகிறது. Glibc இன் ABI இன் நிலையற்ற பகுதி துன்மிகள்/ அடைவில் காணப்படுகிறது.
பெரும்பாலும், Linuxஇன் ABI நிலைத்தன்மை உத்தரவாதம் நன்றாக உள்ளது. Conway’s இன் சட்டத்திற்கு இணங்க, லினக்ஸுக்கு பங்களிக்கும் வெவ்வேறு மென்பொருள் மேம்பாட்டு சமூக குழுக்களுக்கிடையேயான தவறான புரிதல்கள் அல்லது கருத்து வேறுபாடுகள் காரணமாக அதன்வளர்ச்சியின் போது எழும் தொழில்நுட்ப சிக்கல்கள் அடிக்கடி நிகழ்கின்றன. மேலே உள்ள படத்தில் காட்டப்பட்டுள்ளபடி, சமூககுழுக்களுக்கிடையேயான இடைமுகம் லினக்ஸ் தொகுப்பு மேலாளர்மீப்பெரும்தரவு வழியாக கற்பனை செய்வது எளிது.
Y2038: ABI பிரிப்பதற்கான ஒரு எடுத்துக்காட்டு
செயலிலிருக்கின்ற, மெதுவான இயக்கமான “Y2038” என்பது ABI பிரிப்பதற்கான எடுத்துக்காட்டினைக் கருத்தில் கொண்டு Linux இல் ABI சிறப்பாகப் புரிந்துகொள்ளப்படுகிறது. ஜனவரி 2038 இல், பழைய வாகனத்தின் odometer ஐப் போன்றே, 32-பிட் காலக்கணக்கீடுகள் அனைத்து பூஜ்ஜியங்களுக்கு செல்லும் . ஜனவரி 2038 தொலைவில் உள்ளது, ஆனால் 2022 இல் விற்கப்படும் பல IoT சாதனங்கள் இன்னும் செயலில்உள்ளன. இந்த ஆண்டு நிறுவப்பட்ட திறன்மின்அளவிகள் , திறன்நிறுத்தஅமைவுகள் போன்ற சாதாரண உருவாக்கங்களில் 32-பிட் செயலி கட்டமைப்புகளாாக இருக்கலாம் அல்லது அவ்வாறு இல்லாமளும் இருக்கலாம் மென்பொருள் புதுப்பிப்புகளை ஆதரிக்கலாம் அல்லது ஆதரிக்காமலும் இருக்கலாம்.
லினக்ஸ்உருவாக்கமையம் ஏற்கனவே 64-பிட் time_t ஒளிபுகா தரவு வகைக்கு நகர்ந்துள்ளது. time() போன்ற கணினி அழைப்புகள் ஏற்கனவே 64-பிட் கணினிகளில் அவற்றின் செயல்பாட்டு கையொப்பத்தை மாற்றிவிட்டன என்பதே இதன் உட்குறிப்பாகும். இந்த முயற்சிகளின் கடினமான தன்மை time_types.h போன்ற உருவாக்கமைய தலைப்புகளில் தயாராக காட்சியளிக்கிறது, இதில் தரவு கட்டமைப்புகளின் புதிய மற்றும் “_old” பதிப்புகளும் அடங்கும்.
3.
Glibc செயல்திட்டமானது 64-பிட் நேரத்தையும் ஆதரிக்கிறது, ஆம், நாம் இதனை செய்து முடித்துவிட்டோம், இல்லையா? துரதிர்ஷ்டவசமாக, இன்னும் செய்து முடிக்கவில்லை என்பதே உண்மையான களநிலவரமாகும், டெபியனின் மின்னஞ்சல் பட்டியல் பற்றிய விவாதம் தெளிவாக்குகிறது. 32-பிட் அமைப்புகளுக்கான அனைத்து இரும தொகுப்புகளின் இரண்டு பதிப்புகள் அல்லது நிறுவுகைக்கான பல்லூடகத்தின் இரண்டு பதிப்புகளை வழங்குவதற்கான விரும்பத்தகாத தேர்வை Distros எதிர்கொள்கிறது. பிந்தைய வழக்கில், 32-பிட் நேர பயனர்கள் தங்கள் பயன்பாடுகளை மீண்டும் தொகுத்து மீண்டும் நிறுவுகைசெய்திட வேண்டும். எப்போதும் போன்று, தனியுரிமை பயன்பாடுகள் உண்மையான தலைவலியாக இருக்கும்.
லினக்ஸின் நிலையான ABIஇல் துல்லியமாக என்ன இருக்கிறது?
நிலையான ABIஐப் புரிந்துகொள்வது சற்று நுட்பமானது. பெரும்பாலான sysfs ஆனவை நிலையான ABIஆக இருந்தாலும், பிழைத்திருத்த இடைமுகங்கள் உருவாக்கமைய உள்ளகங்களை பயனர்வெளியில் வெளிப்படுத்துவதால் அவை நிலையற்றதாக இருக்கும். பொதுவாக, லினஸ் டோர்வால்ட்ஸின், “don’t break userspace” என்பதன் மூலம், உருவாக்கமைய ஆவணங்களை , மூலத்தைப் படிக்கக்கூடிய கணினி நிரலாளர்கள் , உருவாக்கமைய பொறியாளர்களைக் காட்டிலும் “அது செயல்பட விரும்பும்” சாதாரண பயனர்களைப் பாதுகாப்பதாகும். வெளியீடுகளுக்கு இடையில் என்ன மாறிவிட்டது என்பதைக் கண்டறிய குறிமுறைவரிகளின். வேறுபாடு கீழே உள்ள படத்தில் விளக்கப்பட்டுள்ளது.
4
சாதாரண பயனர்கள் லினக்ஸ் ABI இன் நிலையற்ற பகுதிகளுடன் தொடர்பு கொள்ள வாய்ப்பில்லை, ஆனால் கணினி நிரலாளர்கள் கவனக்குறைவாக அவ்வாறு செய்யலாம். /sys/kernel/debug தவிர அனைத்து sysfs (/sys), procfs (/proc) நிலையானதாக உத்தரவாதம் அளிக்கப்படுகிறது.
ஆனால் /dev இல் உள்ள சாதனக் கோப்புகள், உருவாக்கமைய பதிவுக் கோப்பு (dmesg எனும் கட்டளையுடன் படிக்கக்கூடியது), கோப்பு முறைமை மீப்பெரும்தரவு அல்லது உருவாக்கமைய “கட்டளை வரியில்” வழங்கப்பட்ட “bootargs” போன்ற இதர ABI துனுக்குகள் உட்பட, பயனர்வெளியில் காணக்கூடிய பிற இரும இடைமுகங்களைப் பற்றி என்ன சொல்லலாம். GRUB அல்லது u-boot போன்ற துவக்கபதிவேற்றயில் தெரியும்? இயற்கையாகவே, “அதனை சார்ந்துள்ளது.”
பழைய கோப்பு முறைமைகளை பதிவேற்றுதல்
துவக்க வரிசையின் போது லினக்ஸ் அமைவு செயலிழப்பதைக் கவனிப்பதற்கு அடுத்ததாக, ஒரு கோப்பு முறைமை நிறுவுகை செய்யத் தவறியது மிகப்பெரிய ஏமாற்றம். பணம் செலுத்தும் வாடிக்கையாளருக்குச் சொந்தமான SSD இல் கோப்பு முறைமை இருந்தால், அந்தசெய்தி மிகவும் முக்கியமானதாகும். பழைய உருவாக்கமைய பதிப்பில் நிறுவுகை செய்யும் லினக்ஸ் கோப்பு முறைமை உருவாக்கமையத்தினை மேம்படுத்தப்படும்போதும் பதிவேற்றப்படும், இல்லையா? உண்மையில், “அதனையே சார்ந்துள்ளது.”
2020 இல் பாதிக்கப்பட்ட லினக்ஸ் மேம்படுத்தநர் உருவாக்கமையத்தின் மின்னஞ்சல் பட்டியலில் புகார் செய்தல்:
உருவாக்கமையத்தில் ஏற்கனவே இதை ஒரு சரியான நிறுவுகைசெய்யப்பட்ட கோப்பு முறைமை வடிவமாக ஏற்றுக்கொண்டது, எந்த ஒரு பிழையும் அல்லது எந்த வித எச்சரிக்கையும் இல்லாமல், பல ஆண்டுகளாக நிலையான முறையில் செய்து வருகிறது. . . . தற்போதுள்ள வழிசெலுத்தியின் கோப்பு முறைமைகளை நிறுவுகை செய்வது kernel<->userspace or kernel<->existing-system boundaryஎன்ற எண்ணத்தில் பொதுவாகும், இது உருவாக்கமையம் ஏற்றுக்கொள்கிறது ஏற்கனவே உள்ள பயனர்வெளி வெற்றிகரமாக பயன்படுத்தியதன் மூலம் வரையறுக்கப்படுகிறது. உருவாக்கமையம் ஏற்கனவே உள்ள பயனர்வெளி, கணினிகளுடன் செயல்பட வேண்டும்.
ஆனால் ஒரு பிடித்தம் உள்ளது: நிறுவுகை செய்யத் தவறிய கோப்பு முறைமைகள் தனியுரிமைக் கருவி மூலம் உருவாக்கப்பட்டன, அது உருவாக்கமையத்தால் வரையறுக்கப்பட்ட ஆனால் பயன்படுத்தப்படாத அடையாளசுட்டியை நம்பியிருந்தது. இந்தக் அடையாளசுட்டி Linux இன் API தலைப்புக் கோப்புகள் அல்லது procfs/sysfs இல் தோன்றவில்லை, மாறாக செயல்படுத்தலில் விவரமாக இருந்தது. எனவே, பயனர்வெளிக் குறிமுறைவரிகளில் அடையாளச்சுட்டியை விளக்கமளிப்பது என்பது “வரையறுக்கப்படாத நடத்தை”யை நம்புவதாகும், இது மென்பொருள் உருவாக்குநர்களை உலகளவில் பயந்திட வைத்துவிடும். உருவாக்கமைய சமூககுழு அதன் உள்ளக சோதனையை மேம்படுத்தி, புதிய சீரான சோதனைகளைச் செய்யத் தொடங்கியபோது, “man 2 mount” எனும்அமைவின் அழைப்பு திடீரென்று தனியுரிமை வடிவத்துடன் கூடிய கோப்பு முறைமைகளை நிராகரிக்கத் தொடங்கியது. வடிவமைப்பை உருவாக்கியவர் ஒரு மென்பொருள் உருவாக்குநராக இருந்ததால், அவர் உருவாக்கமைய கோப்பு முறைமை பராமரிப்பாளர்களிடமிருந்து சிறிதளவு அனுதாபத்தைப் பெறலாம்.
5.
உருவாக்கமைய்த்தின் dmesg பதிவைத் திரித்தல்
/dev இல் உள்ள கோப்புகளின் வடிவம் நிலையானதா அல்லது இல்லையா? dmesg கட்டளை /dev/kmsg கோப்பிலிருந்து படிக்கிறது. 2018 ஆம் ஆண்டில், ஒரு மேம்படுத்துநரின் dmesg எனும்திரிக்கப்பட்ட வெளியீட்டை உருவாக்கினார், இது உருவாக்கமையத்தினை “இடையிடல்கள் /அல்லது பிற இழைகளில் இருந்து ஒரே நேரத்தில் printk() மூலம் தொந்தரவு செய்யாமல் பணியகங்களுக்கு தொடர்ச்சியான printk() செய்திகளை அச்சிட உதவுகிறது.” உண்மையில் நன்றாக இருக்கின்றதல்லவா! /dev/kmsg வெளியீட்டின் ஒவ்வொரு வரியிலும் ஒரு நூலின் சுட்டியைச் சேர்ப்பதன் மூலம் இழை சாத்தியமானது. /dev/kmsg இன் ABI ஐ மாற்றியமைத்ததை நெருக்கமாகப் பின்தொடர்பவர்கள் புரிந்துகொள்வார்கள், அதாவது அந்தக் கோப்பைப் பாகுபடுத்தும் பயன்பாடுகளும் மாற வேண்டும். பல வெளியீடுகள் புதிய அம்சத்துடன் தங்கள் உருவாக்கமையங்களை தொகுக்காததால், /bin/dmesg இன் பெரும்பாலான பயனர்கள் கவனித்திருக்க மாட்டார்கள், ஆனால் இந்த மாற்றம் GDB பிழைத்திருத்தியின் உருவாக்கமைய பதிவைப் படிக்கும் திறனை உடைத்தது.
நிச்சயமாக, பிழைத்திருத்தங்கள் மேம்படுத்திடும் கருவிகள் என்பதால் GDBயின் பயனர்களுக்கு அதிர்ஷ்டம் இல்லை என்று புத்திசாலி வாசகர்கள் நினைப்பார்கள். உண்மையில், அவ்வாறெல்லாமில்லை, ஏனெனில் புதிய /dev/kmsg வடிவமைப்பை ஆதரிக்க புதுப்பிக்க வேண்டிய குறிமுறைவரி “in-tree,” ஆகும், அதாவது உருவாக்கமையத்தின் சொந்த Git மூல களஞ்சியத்தின் ஒரு பகுதியாகும். ஒற்றைrepo இல் உள்ள நிரல்கள் ஒன்றாகச் செயல்படத் தவறுவது, எந்த ஒரு புத்திசாலித்தனமான செயல்திட்டத்திற்கும் ஒரு out-and-out பிழையாகும்.
BPF செயல்திட்டங்கள் என்றால் என்ன?
BPF என்பது இயங்கும் உருவாக்கமையத்தினைக் கண்காணிக்கவும், மாறும் வகையில் கட்டமைக்கவும் ஒரு சக்திவாய்ந்த கருவியாகும். BPF இன் உண்மையான நோக்கம், கட்டளை வரியிலிருந்து பொதிவடிகட்டிகளை உடனடியாக மாற்றுவதற்கு அமைவுநிருவாகிகளை அனுமதிப்பதன் மூலம் on-the-fly வலைபின்னலின் உள்ளமைவை ஆதரிப்பதாகும். Alexei Starovoitov போன்ற பலர் BPF ஐ பெரிதும் நீட்டித்தனர், இது தன்னிச்சையான உருவாக்கமைய செயல்பாடுகளைக் கண்டறியும் சக்தியைக் கொடுத்தது. Tracing என்பது சாதாரண பயனர்களை விட மேம்படுத்துநர்களின் களமாகும், எனவே இது நிச்சயமாக எந்த ABI உத்தரவாதத்திற்கும் உட்பட்டது அன்று ( bpf() எனும் அமைவு அழைப்பு மற்றவற்றைப் போலவே நிலைத்தன்மை வாக்குறுதியைக் கொண்டிருந்தாலும்). மறுபுறம், புதிய செயல்பாட்டை உருவாக்கும் BPF நிரல்கள் “உருவாக்கமைய தொகுதிகளை உருவாக்கமைய்ததினை நீட்டிப்பதற்கான நடைமுறை வழிமுறையாக மாற்றும்” சாத்தியத்தை முன்வைக்கின்றன. உருவாக்கமைய தொகுதிகள் சாதனங்கள், கோப்பு முறைமைகள், மறைக்குறியீடுcrypto, வலைபின்னல்கள் போன்றவற்றைச் செயல்பட வைக்கின்றன, எனவே தெளிவாக “அது செயல்பட வேண்டும்” பயனர் நம்பியிருக்கும் ஒரு வசதி. பெரும்பாலான திறமூல உருவாக்கமைய தகவமைவுகள் இருப்பது போன்று BFP நிரல்களும் பாரம்பரியமாக “in-tree,” ஆக இல்லை என்பதால் பிரச்சனை எழுகிறது. 2022 ஆம் ஆண்டு வசந்த காலத்தில், சுட்டிகள் , விசைப்பலகைகள் போன்ற பரந்த அளவிலான மனித இடைமுக சாதனங்களுக்கு (HID கள்) ஆதரவை வழங்குவதற்கான முன்மொழிவு, சாதன இயக்கிகளுக்கான இணைப்புகளை விட சிறிய BPF நிரல்களின் மூலம் சிக்கலை தீவிர கவனத்திற்கு கொண்டு வந்தது.
இதைத் தொடர்ந்து சூடான விவாதம் நடந்தது, ஆனால் திறமூல உச்சி மாநாட்டில் டொர்வால்ட்ஸின் கருத்துக்கள் மூலம் பிரச்சினை தீர்க்கப்பட்டது:
‘சாதாரண (உருவக்கமையம் அல்லாத மேம்படுத்துநர்கள்) பயனர்கள் பயன்படுத்தும் உண்மையான பயனர் விண்வெளி கருவிகளை உடைத்தால், அது eBPF ஐப் பயன்படுத்துகிறதா இல்லையா என்பதைப் பொருட்படுத்தாமல் அதை சரிசெய்ய வேண்டும் என்று அவர் குறிப்பிட்டார்.
தங்கள் BPF நிரலாக்கங்கள் உருவாக்கமைய புதுப்பிப்புகளைத் தாங்கும் என்று எதிர்பார்க்கும் மேம்படுத்துநர்கள் அவற்றை உருவாக்கமைய மூலக் களஞ்சியத்தில் இன்னும் குறிப்பிடப்படாத இடத்தில் சமர்ப்பிக்க வேண்டும் என்று ஒருமித்த கருத்து உருவாகிறது. BPF , ABI ஆகியவற்றின் நிலைத்தன்மை தொடர்பாக உருவாக்கமைய சமூகம் என்ன கொள்கையை பின்பற்றுகிறது என்பதை அறிய காத்திருங்கள்.
முடிவுரை முக்கிய விதிவிலக்குகளுடன், உருவாக்கமைய ABI நிலைத்தன்மை உத்தரவாதமானது procfs, sysfs , கணினி அழைப்பு இடைமுகத்திற்கு பொருந்தும். “in-tree, குறியீடு அல்லது பயனர்வெளி பயன்பாடுகள் உருவாக்கமைய மாற்றங்களால் “உடைக்கப்படும்” போது, ஏற்படும் இணைப்புகள் பொதுவாக விரைவாக மாற்றப்படும். தனியுரிமை குறியீடு பயனர்வெளியில் இருந்து தற்செயலாக அணுகக்கூடிய உருவாக்கமைய செயல்படுத்தல் விவரங்களைச் சார்ந்திருக்கும் போது, அது பாதுகாக்கப்படாது . Y2038ஐப் போலவே, ABI இடைவேளையைத் தவிர்க்க எந்த வழியும் இல்லாதபோது, மாற்றமானது முடிந்தவரை அதிக சிரத்தையுடனும் முறையாகவும் செய்யப்படுகிறது. BPF செயல்திட்டங்கள் போன்ற புதிய அம்சங்கள் ABI-நிலைத்தன்மை எல்லை சரியாக எங்கு உள்ளது என்பது பற்றிய இன்னும் பதிலளிக்கப்படாத கேள்விகளையே முன்வைக்கிறது.