С ба Unix-ийн Yнэн түүх

Би анх энэ нийтлэлийг програмчлалын франц хэл дээрх сэтгүүлээс Pascal-н дурсгалд зориулж бичсэнийг уншиж байлаа. Сэтгүүлээс уг нийтлэлийг "from a US BBS" хэмээн тэмдэглэсэн байсан. Интернэтээс олох гэж нэлээн махран зүтгэсний хүчээр олж авсанаа мартахгүй гэж өөрийнхөө хуудсан дээр хадаж, жинхэнэ Yнэнийг ирээдүй үед хадгалж байхаар шийдлээ.

С ба Unix ийн үнэн түүх

Ken Thompson, Dennis Ritchie болон Brian Kernighan нарын зарласан Unix үйлдлийн систем болон C програмын хэл нь тухайн үедээ компьютер хэрэглэдэг үйлдвэр байгууллагуудыг цочоон гайхуулж, эдүгээ одоо болтол 20 гаран жил өнгөрчээ. Саяхны UnixWorld Development чуулган дээр Thompson дараах зүйлийг дэлгэж ярьсан юм:

1969 онд GE/Honeywell/AT&T Multics гэсэн төслөө AT&T дөнгөж дуусгаад байлаа. Brian бид хоёр Профессор Niklaus Wirth-н зохисон Pascal хэлний анхдагч хувилбарыг бүтээхэд туслахаар Швейцар улс дахь ETH лабораторд нь ажиллаж эхэлж байсан үе. Dennis тэр үед Tolkien-ий 'Lord of the Rings' хэмээх гурван ботийг элэглэж хошигносон 'Bored of the Rings' номыг дөнгөж дуусгасан байлаа. Ингээд зүгээр л зугаа болгож Multics систем болон Pascal хэлийг хошигносон юм бүтээхээр шийдэв. Dennis бид хоёр үйлдлийн систем орчныг нь хариуцаж авав. Бид хоёр Multics системийг судлаад хэрэглэгчийн уур уцаарыг дэд хэмжээнд тулгаж болохуйц төвөгтэй нууцлаг шинэ үйлдлийн систем бүтээж Multics нэрийг элэглэн Unix гэж нэрлэв. Туршин хэрэглэх сонирхолтой хүмүүсд цөөн хэдэн тушаал бэлдэж өгөөд үүнийгээ та нарыг удаан урт бичихээс чинь чөлөөлж байгаа юм хэмээн тайлбарладаг байв.

Дараа нь Dennis Brian хоёр Pascal-н нэлээн муу эвдэрхий хувилбарыг бэлдээд 'A' гэж нэр өглөө. 'A' хэл Pascal-тай нэлээн төстэй байлаа. Тухайн үедээ Pascal хэлний санах ой руу шууд ханддаг ( Wirth сүүлд нь энэ чанарыг нь хассан ) шинж чанарыг нь 'A' хэлний гол цөм ухагдахуун болгосон байсан. Үнэхээр аюултай муухай бүтэц бүтээх аргаа нууж 'pointer' хэмээх цэвэрхэн нэр томъёог бүтээж оруулсан хүн бол Dennis байв.

Ямар ч стандартад нийцэхгүй I/O оролт гаралтын журам гаргасан Brian-ыг бараг шагнахаар байв. Ингэснээр хэн нэгэн хэрэв төхөөрөмжөө солих тохиолдолд үйлдлийн системтэйгээ зохицуулахын тулд ердийн худалдаанд байдаг програмын бараг 50 хувийг нь шинээр кодлох ёстой болгосон юм. Ингэж I/O ийг нь үгүй болгосноо тухайн системийн шинж чанар болгож зарлахыг Brian сэдсэн бөгөөд энэ нь уг програмын хэлийг "truly portable" буюу ямар ч төхөөрөмж дээр ажилладаг хэмээн сурталчлахад хэрэгддэг болов. Өөр хүмүүс А хэлээр бүр жинхэнэ програм бичээд байгааг бид мэдэнгүүтээ функцийн аргументийн төрлийг шалгадаг (type-checking) нэн шаардлагатай байсан боломжийг хасаж хаяв. Сүүлд нь бид өөрсдөө "casting" гэж нэрлэдэг байсан тэмдэглэл шинээр нэмээд, энэ нь програм бичигч хүнд integer тоог 50kb хэмжээтэй хэрэглэгчид зориулсан зай мэт хандаж болдог болгов. Дараа нь зарим програм бичигч хүмүүс pointer ашиглахгүй програм бичээд байгааг бид мэдэнгүүтээ функц рүү энгийн дамжуулалт хийдэг байсан бүтцийг алга болгож энгийн програм бичихээр байсан ч pointer хэрэглэдэг болголоо. Энэ хэлээ бид зардаг байлаа. Хэлний үр бүтээмжийг сайжруулагч хэмээсэн янз бүрийн шинж чанаруудыг ч бас зардаг байлаа. Энэ замаар бидний хагас хугас хэл B, BCPL хэмээн нэрлэгдэж өөрчлөгдсөөр төгсгөлд нь С болсон юм. Ингэж нэрлэж өөрчлөх явцыг бид дараах бичлэгийг цэвэрхэн хөрвүүлж компайлдсан үед л зогсоосон:

for (;P("\n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("|"+(*u/4)%2);

Нэг удаа бид энэ хэлээрээ тохуу хийж Зөвлөлт улсын компьютерийн хөгжлийг 20, бүр түүнээс ч олон жилээр ухраахаар тэдэнд зарж байлаа.

Харамсалтай нь AT&T болон америкийн бусад корпорациуд Unix болон С хэлийг хэрэглэж эхлэв. Бид энэ тухай амаа хамхихаар шийдэж энэ бүх явцыг түр зуурынх болно тооцсон. Гэтэл үнэн хэрэгтээ 1960 аад оны элэглэж бүтээсэн технологиор хэрэглэж болохоор програм бичиж чаддаг хангалттай мэргэжлийн хүмүүсийг америкийн компаниуд 20 гаран жилд бүтээдэг болов. Ердийн Unix систем дээр C програм бичиж байгаа програмист хүмүүсийн шаргуу бууж өгөхгүй байгаа чанар биднийг гайхшруулж байлаа. Үнэнийг хэлэхэд Brian, Dennis бид хэд энэ үйлдлийн систем дээр хэзээ ч албан ёсны програм бичих оролдлого хийгээгүй.

Бидний олон жилийн өмнө хайш яайш хийсэн зүйлээс үүдсэн эмх замбараагүй байдал, гутрал эсвэл гайхалтай төслүүдийг хараад бид буруутайгаа мэдэрдэг байлаа.

Dennis Ritchie нэг удаа: "Bjarne Stroustrup бидний онигоог мэдсэн нь үнэхээр балиар юм болов (тэр үед дөнгөж AIDA үүсэж байх үе ). Цаадах чинь бүр өнөөх хошигнолыг цаашлуулаад Smalltalk бүтээчихлээ. Тэгээд хэн ч инээхгүй байхыг хараад их гайхаж байсан, яг бид нар шиг. Тэгэхээр нь цаадах чинь бүр multiple inheritance, virtual base classes мөн сүүлд нь templates хүртэл нэмчихсэн. Ерөөсөө хэн ч хэрэглэхээргүй болгох гэж. Одоо тэгээд бидэнд 100.000 мөртэй кодыг секундын дотор хөрвүүлчихдэг компайлер байгаа мөртлөө Hello World гэсэн үг гаргахын тулд header файлуудыг нь 25 минутын турш боловсруулж байна" гэж билээ.

Thompson-ы энэ Yнэнийг илчилсэн ярианы дараа гол гол Unix болон С хэл борлуулж түгээдэг байгууллагууд AT&T, Microsoft, Hewlett-Packard, GTE, NCR мөн DEC тэр үед ямар нэгэн тайлбар өгөхөөс татгалзсан юм. Харин алдарт Turbo Pascal болон Borland C++ хэмээх обьект хандалтад програмчлалаар тэргүүлэх байранд явдаг бүтээгдэхүүн зарагч Borland International байгууллага энэ бүхнийг нэлээн хэдэн жил сэжиглэж байсан хэмээн мэдэгдсэн. Үнэнийг хэлэхэд Windows дээр ажилладаг Quattro Pro програм анх C++ дээр бичигдсэн байлаа. Тэр үед хөгжүүлэгч байсан Phippe Kahn: "Хоёр жил хагас програмчилж, маш олон програмистууд burn-out болж мэдрэлтэх үед бид бүх юмаа Turbo Pascal дээр шинээр бичээд гуравхан сарын дотор дуусгаж байлаа. Turbo Pascal тэр үед бидний аминд орсон гэдгийг шударгаар хэлэх нь зүйтэй" гэж хэлж байсан. Бас Borland ийн хэвлэлийн төлөөлөгч нь Pascal бүтээгдэхүүнээ цаашид илүү сайжруулан хөгжүүлж C/C++ бүтээгдэхүүндээ хагас анхаарлаа хандуулах болно гэж мэдээлсэн.

Харин Pascal, Modula2 мөн Oberon гэх мэт хэлний эцэг болох ETH институтын профессор Wirth "P.T. Barnum-ын зөв байсан" гэсэн нууцлаг өгүүлбэрээс өөр ямар ч тайлбар тавиагүй билээ.

Эх хувилбарыг нь эндээс уншаарай.

Simlock & building android kernel module

Аль өнгөрсөн өвөл 30 еврогоор simlock-той Huawei u8180 (Ideos X1) гэдэг Андройд гар утас авав. Simlock-ыг нь эс тооцвол дажгүй хөөрхөн утас аж. Уг нь 10 ногооноор simlock гаргана гэсэн үйлчилгээнүүд интернетээр дүүрэн байна. 30 евроны утсыг 10 доллар төлж түгжээ гаргахад дэндүү харамсалтай санагдаад, дээрээс нь бас ер нь яаж simlock гаргадаг юм бол гэсэн сониуч зан хөдөлсөн тул өөрөө түгжээ гаргадаг баатар болов. Simlock-ын тухай мэдээлэл интернетээр их ховор юм, бодвол зарим улсад түгжээ гаргах хориотой дээрээс бас зарим нөхдүүд мөнгө олох аргаа алдахгүй гэсэн юм болов уу даа.

Андройд гар утас маань Qualcomm MSM7225 гэсэн SoC-той юм байна. MSM7225 нь дотроо 2 ширхэг ARM процессор агуулдаг аж. 528 Mhz-ын хурдтай ARM11 процессор дээр нь Андройд үйлдлийн систем харин арай удаан ARM9 дээр нь GSM/UMTS-г хариуцсан AMSS (Advanced Mobile Subscriber Software) хэмээх үйлдлийн систем тус тус ажиллана. Энэ хоёр процессор дундаа 512MB-ын хэмжээтэй нэг л flash memory хувааж ашиглана. Гэхдээ AMSS нь Android-ын ашиглаж байгаа санах ойд хандаж болдоггүй, Андройд нь ч гэсэн нөгөө процессорын flash санах ойг хардаггүй аж.

Андройд, AMSS хоёр хоорондоо AT коммандын тусламжтайгаар харьцана. Хэрвээ та 99110000 гэсэн дугаар руу залгавал Андройд үйлдлийн систем AMSS руу зөвхөн "ATD 9911000" тушаал илгээнэ. Энэ тушаалыг аваад AMSS өгөгдсөн дугаар руу залгана. Андройд өөр юу ч хийхгүй, бусад дуудлагатай холбоотой бүх зүйлсийг зөвхөн AMSS хариуцна. Нэг ёсондоо Андройд маань гар утасны үйлдлийн систем биш харин зөвхөн гар утасны UI л гэсэн үг, харин AMSS маань гар утасны жинхэнэ үйлдлийн систем нь юм.

AMSS-д зориулсан flash санах ой дотор EFS2 гэсэн нэг partition байна. Энэ дотор IMEI (International Mobile Equipment Identity), SPL (Service Programming Code), simlock гэх мэт GSM/UMTS-тэй холбоотой бүх чухал мэдээлэл хадгалагдана. Тиймээс ямар нэгэн аргаар Андройдоос EFS2 partition-руу хандаж чаддаг байж түгжээ гаргадаг болно. Ингэхийн тулд янз бүрийн юм оролдож үзсэнээс хамгийн гайгүй арга нь kernel module бичиж харагдахгүй байгаа partition-уудыг харагдуулах арга байв.

Энэ аргыг ашиглахын тулд та гар утсаа шоронгоос гаргасан байхаас гадна Андройд SDK болон NDK 5b суулгасан байх хэрэгтэй. Үүний дараа та гар утсандаа тохирсон kernel олох хэрэгтэй. Би гар утсандаа таарсан kernel эндээс олов. Татаад задалсныхаа дараа гар утсаа компьютертэйгээ холбоод доорх тушаалуудыг бүрхүүл дээр бичээрэй:

1. cd /path/to/kernel
2. adb pull /proc/config.gz .
3. gunzip config.gz
4. mv config .config
5. make ARCH=arm CROSS_COMPILE=/path/to/android/ndk5b/toolchains/arm-eabi-4.4.0/prebuilt/bin/linux-x86/bin/arm-eabi- modules_prepare

Одоо та шинэ хавтас үүсгээд дотор нь доорх файлыг mtd-hack.c гэж хадгална уу.


mtd-hack.c-г хадгалсан хавтас дотроо та хоосон Makefile үүсгээд дотор нь obj-m += mtd-hack.o гэж бичиж хадгалаарай. Одоо та доорх тушаалуудыг ашиглаад kernel module-аа build хийгээд, гар утас руугаа хуулж ажиллуулаарай:

1. cd /path/to/mtd-hack-module
2. make ARCH=arm CROSS_COMPILE=/path/to/android/ndk5b/toolchains/arm-eabi-4.4.0/prebuilt/bin/linux-x86/bin/arm-eabi- -C /path/to/kernel M=/path/to/mtd-hack-module modules
3. adb push mtd-hack.ko /sdcard/mtd-hack.ko
4. adb shell
5. su
6. cd /sdcard
7. insmod mtd-hack.ko

Хэрвээ бүх зүйл амжилттай болсон бол таны бүх flash memory тань /dev/mtd/mtd9 гэсэн шинэ partition болж орж ирсэн байгаа. (EFS2 partition яаг хаана байгааг нь сайн мэдэхгүй байгаа учир бүх flash-аа нэг partition болгов) Та одоо энэ partition-ыг backup хийж авч болно:

1. dd if=/dev/mtd/mtd9 of=/sdcard/fulldump.bin bs=4096
2. rmmod mtd_hack

IMEI гэх мэд чухал мэдээллүүд EFS2 partition дотор хадгалагддаг гэж урьд нь бичсэн билээ. Энэ чухал мэдээлэл/тохиргоо бүрийг NV (non volatile) item гэж нэрлэх бөгөөд item болгон өөрийн дугаартай байна. IMEI жишээ нь 550 дахь item, харин AMSS version нь 60001 дэх item. Та одоо fulldump.bin файлаа дурын HEX editor-оор онгойлгоод "550n" эсвэл "60001n" гэж хайгаад үзээрэй, олдож байвал яаг тэнд чинь IMEI, AMSS version item-ууд хадгалагдсан байгаа.

Харамсалтай нь sim unlock key нь NV item биш, харин EFS2 дотор өөрийн гэсэн файл систем дотор perso.txt гэсэн файл дотор хадгалагдана. Тэгэхээр үүнийг эхлээд reverse engeneering хийж байж unlock key олно. Би одоохондоо үүнийг хийж амжаагүй байгаа. Гэхдээ цаад учрыг нь ольё гэхгүйгээр түгжээ гаргая гэвэл маш амархан арга нэг бий. Түгжээгүй утас нэгийг олоод EFS2-ыг нь backup хийгээд энэ backup-аа түгжээтэй утасруугаа хуулахад л хангалттай. Ингээд гар утас тань түгжээгүй болчихно. Гэхдээ арай л fun багатай арга юм даа...

Чөтгөрийн зүрхэнд хүрэх замд ...

За надад бол мэргэн цоохор, бусдад бол эрээн цоохор байж болох нэг юм энд сараачаад орхие.

FreeBSD үйлдлийн системийг үүнээс хойш чөтгөр гэж нэрлэе.

За тэгэхээр чөтгөрийн цөмийн эх код нь /usr/src/sys санд байдаг. Цөмийн эх кодоос хайлт хийхдээ хэд хэдэн аргаар хайж болно. Жишээ нь:

find /usr/src/sys -name "*.c"|xargs grep -i 'sockbuf_waste_factor'
grep -R 'sockbuf_waste_factor' /usr/src/sys/*

гэх мэт.
Програм бичихэд цөмийн талбар эсвэл хэрэглэгчийн талбар гэсэн үндсэн ойлголтыг санаж үзэх хэрэгтэй. Хэрэглэгчийн талбарын програмуудын ихэнх нь олон урсгалт биш боловч цөмийн код нь асар төвөгтэй олон урсгалт програм бөгөөд ихэнх хэцүү асуудлууд нь урсгалын загваржилт болон цөмийг илүү параллел болгоход чиглэсэн байдаг.

Хэрэглэгчийн талбарын програм цөмийн хамгаалагдсан эсвэл хамгаалагдаагүй хэсгээс хувьсагч эсвэл утга шууд авах бол sysctl(3) эсвэл kvm(3) интерфэйс ашиглана. Өөрөөр хэлбэл цөмийн хамгаалагдсан өгөгдлийн бүтцийн хувьсагч руу шууд хандаж утга авч болохгүй гэсэн үг юм. Цөм нь хэрэглэгчийн талбараас авч болох утгыг SYSCTL макронууд ашиглан хэрэглэгчийн талбараас авч болохоор гаргаж болно. Мөн цөмийн талбарт програм бичих эсвэл өөрчлөлт хийх, жишээ нь тогтмолууд нэмэх зэрэг зүйлс хийх бол ABI буюу application binary interface болон зохих дүрэм журмыг харгалзан үзэх ёстой.

Цөмийн өгөгдлийн бүтцийг шууд тэр чигээр нь хэрэглэгчийн талбар руу авч болохоор хийж болохгүй. Өөрөөр хэлбэл тийм өгөгдлийн бүтцэд заагч эсвэл тогтмол массив зэргийг зарлаж болохгүй юм. Нэг шалтгаан нь заагч нь 64 бит болон 32 битийн систем дээр хэмжээ нь өөр байдаг явдал юм. Мөн ингэж зарласан тохиолдолд цөмийн хувьсагч руу хэрэглэгчийн програм шууд хандаж цөмийг сүйрүүлэх боломжтой болох юм. Цөмийн заагч болон өгөгдлийн бүтцийг хэрэглэгчийн талбарт шууд авах боломжтойгоор хийх нь ABI-г зөрчиж байгаа явдал юм.

Мөн хэрэглэгчийн санах ойгоос өгөгдлийн бүтэц авах эсвэл хэрэглэгчийн санах ой руу өгөгдлийн бүтэц хуулах бол тийм өгөгдлийн бүтэц дотор аль болох заагч хэрэглэхгүй байх хэрэгтэй. Учир нь цөмийн талбарын заагчийн хэмжээ хэрэглэгчийн талбарын заагчийн хэмжээнээс өөр байх боломжтой. Ингэж өөр байх тохиолдолд 32-бит/64-битийн compat shim-үүд буюу таарамжтай нийцтэй байлгах тохиргоонууд хэрэгтэй болно.

Цөмийн талбарын програмд хувьсагч зарлахдаа санах ойд аль болох бага зай эзлэхээр зарлаж өгөх хэрэгтэй. Жишээ нь:

гэсэн өгөгдлийн бүтэц байя гэж бодоё. Энэ бүтцийг ашиглах үндсэн програмд struct ipfw_port_table_entry *ent гэж зарлан санах ойн талбарт зай гарган өгвөл энэ хувьсагч нь 64 битийн систем дээрх заагчийн хэмжээтэй адил санах ойн хэмжээ эзлэх болно.

64 бит архитектурын гол дутагдал нь 32 битийн архитектуртай харьцуулбал өгөгдөл нь санах ойд 32 битийнхээс илүү хэмжээний зай эзэлдэг (заагчийн хэмжээ, бусад төрлүүд болон тэдгээрийг зэрэгцүүлж адил болгох гэснээс болоод). Ингэснээр өгөгдсөн процессийн санах ойн шаардлагыг ихэсгэж процессорын кэшийн хэрэглээг үр ашигтай ашиглахад сөрөг нөлөө үзүүлж болзошгүй юм.

Цөмийн өгөгдлийн бүтцийг (жишээ нь struct дотор struct байхад тус тусад нь санах ойн талбар зааж өгөхөд санах ойн зайны хувьд үр ашиггүй ашиглагдахаас гадна заагчтай ажиллахад төвөгтэй болно) аль болох цугт нь бүтнээр нь allocate хийх буюу санах ойн талбар зааж өгөх хэрэгтэй. Цугт нь санах ойн талбар хуваарилан зааж өгвөл санах ойн кэшийг үр дүнтэй ашиглахаас гадна өгөгдлийн бүтцийг унших үеийн эзлэх зайг багасгана.

Мөн өгөгдлийн бүтцүүдийг тодорхойлох бэлэн аргууд байдаг, бүх төрлийн list-үүд, queue, hash зэрэг өгөгдлийн бүтцүүдтэй ажиллах макронууд sys/queue.h толгой файлд заагдсан байдаг бөгөөд queue(3) гарын авлагаас уншиж болно.

Бичсэн кодоо style(9)-д дурдсан загварын дагуу хэлбэржүүлэх ёстойг бас мартаж болохгүй юм.