iPhone moim okiem - recenzja
Najpierw była niewiedza:
iPhone? Jaki iPhone? Pewnie znowu coś z tej śmiesznej firmy Apple co to robi buble w niebotycznych cenach?
Później przyszło zaciekawienie:
Co oni tak dużo piszą o tym iPhone? Riddle sobie też kupił. Cholera, nawet blogi na Joggerze powstały tylko i wyłącznie o tym sprzęcie. Coś w tym musi być.
Następnie - rozczarowanie:
Co oni tak się rozczulają nad tym telefonem?! To nawet BlueTooth porządnego nie ma! Zresztą - taki nieudany telefon. Głupota, jeszcze tak drogi.
Na końcu: oświecenie (tudzież zakochanie)
- Patrz Kochanie! Za 1200 na Allegro jest!
- ... ale soft 1.1.2..
- Kurde. Masz rację... HEJ! Patrz na to...
Finał historii:
- --DRYŃDRYŃ--
- Tak, słucham?
(kolega obok w barze)
- Ło k***a co to?!
Kupiłem iPhone'a. I po długim (kilku tygodniowym) użytkowaniu przyszła odpowiednia pora na zrecenzowanie owego cacka. Steve Jobs swoją oficjalną prezentację podzielił na 3 główne grupy: telefon, iPod, internet. Tak zrobię i ja, a zaczniemy od najważniejszego:
iPhone jako TELEFON
Czyli właściwie jego podstawowa funkcja. Czy kiedyś zastanawialiśmy się, czego potrzebujemy od telefonu? Nie, nie od smartphone'a, wielkiej kobyły z Javą na pokładzie czy też innego "telefonu" za >=500zł. Chodzi mi o zwykły telefon. Więc? Na pewno dobrej jakości rozmów. Chcemy słyszeć naszego rozmówcę głośno i wyraźnie równocześnie sami będąc dobrze rozumianymi. iPhone jest pod tym względem najlepszym z posiadanych dotychczas przeze mnie telefonów. Jakość rozmów jest idealna, tak przez wbudowany mikrofon//słuchawkę jak i przez dołączone do telefonu słuchawki (oczywiście w kolorze białym ;-)). Z tego co udało mi się zauważyć - oprogramowanie samo ustala poziom głośności słuchawki//mikrofonu zgodnie z głośnością otoczenia. Nigdzie nie czytałem dotąd o takiej funkcji, jednak jestem w 100% pewien że funkcjonalność ta została dodana. Wszelkie inne funkcje jak konferencje, zawieszanie połączeń, obsługa książki adresowej, zdjęcia dla kontaktów - jest i działa :-).
Super, mamy zatem możliwość rozmowy. Od dość dawna mamy jednak XXI wiek i to troszkę za mało jak na telefon... Czego jeszcze potrzebujemy? SMS'y? Jedna z moich ulubionych funkcji w iPhone. Historia SMSów przechowywana jest w formie chatu z daną osobą, a pisanie na wirtualnej klawiaturze jest kilkukrotnie szybsze od pisania na standardowym telefonie (nawet uwzględniając fakt wykorzystania słownika T9). Zaprawdę powiadam - wysyłanie SMSów z iPhone jest przyjemnością! Jest jeden drobny feler, który może być odebrany jako wada. Brak licznika znaków i powiadamiania o zakończeniu limitu 160 liter. W dobie darmowych SMSów to chyba nie jest już problem, jednak przeciwnicy Jabłuszka do wszystkiego się potrafią przyczepić ;-). iPhone nie udostępnia także możliwości wysyłania wiadomości SMS do wielu odbiorców. Ale! Oba te "niedostatki" naprawia aplikacja o nazwie "SMSD" dostępna w Instalatorze iPhone'a.
MMSy? Naczytaliście się, że iPhone nie obsługuje MMS'ów? Cóż, może w standardzie nie obsługuje, jednak... Instalujemy program o nazwie "MMS", 3 kliknięcia i wysyłamy MMSy.
Cóż jeszcze? Można napisać w tym miejscu o takich szczegółach jak wyciszanie muzyki w momencie przychodzącego połączenia i jej ponownym włączeniu bezpośrednio po zakończeniu rozmowy (wszystko w formie 'fade in <-> fade out'), o czujniku zbliżeniowym, który wyłącza ekran w sytuacji zbliżenia telefonu do twarzy (do teraz nie wiem jak oni to zrobili - to DZIAŁA i to perfekcyjnie), o bardzo rozbudowanej książce telefonicznej, w której możemy przechowywać wszystko, od telefonów znajomych po ich adresy (widoczne dynamicznie w Google Maps), strony internetowe (automatycznie jako zakładki w Safari), czy maila (puknięcie w mail przenosi do klienta poczty i rozpoczynamy pisanie). Poezja :-)
Niestety, zauważyłem 2 wady funkcji telefonu w iPhone. Po pierwsze - niemożliwym jest korzystanie z głównej funkcji tego sprzętu w sytuacji, gdy stoi on na "docku" (dołączanym do zestawu). Aby odebrać telefon należy wówczas zdjąć iPhone z docka, odebrać połączenie a po zakończeniu - ponownie go odłożyć. A co jeśli na docku stoi, bo się ładuje? Idealnym byłoby przekierowanie rozmowy na komputer (co mogłem zrobić w moim poprzednim SE K510i). To dla mnie dość duża wada, gdyż na docku telefon stoi jakieś 50% swojej całej pracy.
Druga wada jest kosmetyczna i nie wpływa na ogólny obraz użytkowania sprzętu, jednak istnieje i sprawia wielki "ból" na samym początku. Mam na myśli brak możliwości łatwego importu kontaktów z karty SIM lub z innego telefonu. Albo masz wszystko w iCal i korzystasz z iTunes albo masz pecha i wklepujesz ręcznie... 300 kontaktów z palca - to nie jest fajne... Apple w tym miejscu mogło by pomóc w "konwersji" z innych telefonów na swój produkt.
iPhone jako iPod
A właściwie - iPod Touch. Cóż mogę napisać... 8GB muzyki, filmów zawsze przy sobie, dostępne za naciśnięciem 1 przycisku. Jakość dźwięku oraz obrazu jest znakomita, ekran idealnie nadaje się do oglądania filmów np. w autobusie bądź też pociągu. Słuchawki na uszy, iPhone w ręce i nawet 6 godzinna podróż nam nie straszna! Na szczególną uwagę zasługuje tutaj sposób wgrywania mediów. Apple mówi - "iTunes!". Czy naprawdę tak jest? Odpowiem już teraz - NIE! A opis zmagań "Tux vs. iPhone" przeczytacie sobie na TechBlogu :-). Od samego zakupu mój iPhone nie zobaczył iTunes i komputera z Windows (tym bardziej MacOSX) i mam nadzieję że tak zostanie. Ale - wróćmy do funkcji iPoda.
Słuchawki dołączane do zestawu są bardzo dobrej jakości (w końcu kosztują 129zł), jednak musimy bardzo uważać na swój słuch. Przypadkowe "odkręcenie rury" na maksymalną wartość poskutkuje naprawdę niemiłym doznaniem. Nie należę do ludzi cicho słuchających muzyki, jednak iPhone w tym przypadku potrafi przyprawić mnie o duży szum w uszach po kilkunastu minutach. Dlatego - uważajcie!
Jeśli chcecie dokładnie przyjrzeć się funkcji iPod polecam skierować swe kroki do dowolnego MediaMarktu tudzież Saturna, gdzie wystawione są działające iPody. Doświadczenie z korzystania jest takie samo jak w przypadku iPoda wbudowanego w iPhone'a. Tylko uważajcie - ciężko jest potem odejść a za Wami się robi kolejka...
iPhone jako narzędzie internetowe
Jedna z głównych funkcjonalności, dla której kupiłem tego smartphone'a. iPhone posiada jedną z najlepszych przeglądarek w historii urządzeń mobilnych - MobileSafari - oraz czytnik poczty - MobileMail. Do tego kilka tuzinów aplikacji korzystających pośrednio z sieci, o których opowiem później. Opcje połączenia z internetem to GPRS/EDGE oraz WiFi. Oba działają doskonale, automagicznie i po prostu przecudnie. Jeśli jesteśmy w zasięgu sieci WiFi iPhone łączy się z nią (lub pyta o podłączenie jeśli jest to dla niego nowa sieć), jeśli nie jesteśmy w zasięgu WiFi a chcemy połączyć się z internetem aktywuje połączenie EDGE. Jeśli chcemy zaoszczędzić pieniądze możemy trwale wyłączyć połączenia GPRS/EDGE, dzięki czemu nie przyjdzie nam kosmiczny rachunek za transmisję danych :-). A co z komfortem przeglądania sieci? Cóż... Strony wyglądają dokładnie tak, jak na komputerze, nawigacja jest bardzo prosta i intuicyjna (ot, przesuwamy stronę palcem po ekranie, przybliżamy bądź oddalamy jej fragmenty itp.). W momencie aktywacji pola wpisywania danych pojawia się klawiatura. Jedyny minus to prędkość działania. Strony wczytują się wolno. A raczej - renderują wolno. Strona główna Joggera potrzebuje około 3 sekund na pełne załadowanie (na grubej rurce). Nie jest to jednak upierdliwe, w końcu iPhone nie został zaprojektowany jako główne narzędzie dla webdesignerów, programistów itp. Normalne przeglądanie sieci, czytanie newsów czy buszowanie po Google za odpowiedzią na nurtujące nas pytania działa znakomicie i nie ma się do czego przyczepić.
Wbudowany czytnik poczty działa, choć powiem szczerze - nie używam. Maile odbieram 3 razy dziennie i jest ich tak wiele, że gdybym miał zaprząc do tego celu iPhone musiałbym dosłownie non stop odpisywać na nową pocztę. To nie dla mnie.
Zauważam jednak 2 minusy w tej kategorii. Po pierwsze - Safari nie jest idealne i nie wczytuje na raz całej strony. W przypadku przeglądania sieci kolejne fragmenty strony ładują się dynamicznie, przez co często zauważymy niewyrenderowane fragmenty oznaczone biało czarną szachownicą, które po sekundzie zamienią się w stronę. Drugi minus - brak Javy i Flasha. Możemy zapomnieć o filmikach czy też aplikacjach webowych. Jednocześnie możemy zapomnieć o oczojebnych reklamach na większości portali. ;-)
Inne
Czyli - inne funkcje, oferowane przez aplikacje zewnętrzne, dostępne na odblokowanym iPhone:
konsola - za pomocą konsoli możemy... Właśnie, nie wiem jak to napisać... Wszystko? Chyba wszystko, bo ostatnio postawiłem serwer Apache + PHP + Python na swoim iPhone. I to działało.. Więc chyba naprawdę możemy wszystko! A przecież nie piszę o tak oczywistej rzeczy jak zalogowanie się po ssh na swój serwer aby sprawdzić czy wszystko gra.
aparat foto - robi zdjęcia. I tylko tyle. Nic więcej nic mniej. Fildmiku nie nagramy, nie zastosujemy filtrów, nie ustawimy jakości. Po prostu - pstryk i 2Mpix zdjęcie ląduje w pamięci telefonu. Proste do bólu. Jakość zdjęć jest zadowalająca (porównywalna ze zdjęciami z SE K750i)
EBooks - po prostu EBooki na ponad 3 calowym wyświetlaczy dotykowym. Chyba łapiecie o co chodzi :-) I to nie tylko format *.txt czy *.html, również *.pdf czyta zupełnie normalnie!
VNsea - klient serwera VNC. Leżymy w łóżku, komputer stacjonarny z ogromnym monitorem wyświetla nam film. Film się kończy, wstajemy... Nieeee! Bierzemy iPhone'a i włączamy kolejny film na ekranie zdalnym. Jedna z najpiękniejszych aplikacji jakie mam obecnie zainstalowane na tym sprzęcie.
MobileScrobbler - KILLERAPP! Klient LastFM z pełnym wsparciem dla wszystkich funkcji tego serwisu! Nudzi Ci się muzyka na iPod? Włącz radio LastFM. 10/10!
... a gdzie gry? Nie, tego opisywać nie będę... Zajęłoby to znacznie za dużo czasu i miejsca w tym przydługawym już wpisie. Wiedzcie jednak, że nudzić się nie można.
Na koniec dwa słowa o wytrzymałości urządzenia. Mimo wszystko wyświetlacz troszkę się rysuje (delikatnie) w czasie zwyczajnego używania i bardzo polecam posiadanie pokrowca. Można go także zarysować w bardzo mocny sposób np. upuszczając z dużej wysokości na beton. Cóż, w końcu to tylko szyba a nie diament. Tył iPhone'a bardzo szybko pokrywa się dużą ilością mikroskopijnych rysek.
Wytrzymałość baterii? Przy MAKSYMALNYM użyciu (non stop WiFi + EDGE włączone), plus oglądanie filmów bądź słuchanie muzyki (dziennie +-4h), sporo rozmów telefonicznych (dziennie od około 10 minut do 2h) i masa SMSów - trzyma równo 48 godzin. Przy zmniejszonym użyciu (przyciemniony wyświetlacz, wyłączony internet, brak filmów) potrafi przeżyć około 3-4 dni. Nie potrafię podać dokładnego czasu, gdyż nie udało mi się do tej pory nie używać go przez tak długi czas. Spokojnie można jednak liczyć 2 dni pracy na maksymalnym użyciu.
I na koniec - iPhone to zabawka. Zabawka pokroju kolejek elektrycznych, które tatusiowie kupują dzieciom aby po kryjomu sami się nimi bawić. Zabawka pokroju samochodu w skali 1:1 ukrywająca kompleks zabawek w skali 1:43 w dzieciństwie. Zabawka, która podobnie jak kolejka elektryczna sprawia masę przyjemności i podobnie jak samochód w skali 1:1 - daje wiele wygody. I któż z nas nie marzy o kolejce elektrycznej czy dobrym aucie? :-)
psDooM - zarządzaj swoimi procesami!
psDooM to monitor systemowy dla systemów Linuksowych. Z użytkownikiem komunikuje się poprzez wygodny i ładny interfejs graficzny (screen obok). Posiada funkcjonalność programów takich jak 'ps', 'renice' oraz oczywiście 'kill' :-).
psDooM (strona projektu) to implementacja XDoom jako środowiska do zarządzania procesami. Twórca projektu David Koppenhofer, nudząc się zapewne w pracy, przeglądał kod źródłowy Doom'a i dopisał do niego kilka funkcji bazujących na wywołaniach systemowych. Dlatego też w psDooM każdy potworek to określony proces z przyporządkowanym PID'em oraz nazwą. Jak widać na screenie powyżej nasze procesy zbyt grzeczne nie są... 'xv' potrafi dać w kość.
Niestety, psDooM posiada wiele błędów. Jeden z takich opiszę. Wyobraźmy sobie wielkiego i groźnego Basha szarżującego na nas i zasypującego gradem kul. My, w panicznej ucieczce chowamy się za pierwszy z brzegu proces, który całkowitym przypadkiem nazywa się 'init'. Kule groźnego Basha dosięgnęły niewinnego 'inita'. Chyba nie trzeba pisać co się stało z systemem? :-)
Dodatkowo: w systemie z wieloma uruchomionymi procesami psDooM staje się symulatorem hipermarketu w dzień świąteczny. Dodatkowym problemem staje się szef.. Bo jak mu wytłumaczyć, że właśnie zarządzamy największym klastrem w firmie a nie gramy w DooM'a? :-)
Z plusów psDooM'a autor wymienia:
- Stopniowe zarządzanie procesem. Admin może tylko zranić proces dając mu do zrozumienia, że zrobił coś źle.
- Młodzi admini mogą dostawać do ręki mniej niszczycielskie bronie, tym samym nie powodując szkód w najważniejszych procesach. Prawdziwi admini dysponują BFG.
- Bardzo obciążane systemy zyskują mechanizm samoregulacji. W przypadku zbyt zatłoczonej planszy potwory zabijają same siebie pozostawiając na placu boju najlepsze (najmocniejsze) procesy. Selekcja naturalna w GNU/Linux! Nigdy więcej zarządzania obciążeniem!
- SysAdmini mogą kooperować robiąc 'ustawki' na co gorsze procesy. Paczka Adminów może w końcu razem radzić sobie ze złą sytuacją na serwerach!
Cóż, nie można odebrać Davidowi dobrego poczucia humoru :-). psDooM to tylko ciekawostka i swoisty żart ze strony programisty//admina GNU/Linux. Pamiętajcie - używanie go w swoich systemach może prowadzić do niestabilności Twojego systemu. Zresztą oboje wiemy - po to go uruchamiasz ;-).
Oto strona, która opisuje sposób instalacji psDooM. A ja spadam. Chyba firefox-bin za bardzo urósł i się do Amaroka mi dobiera... EOT.
ENJOY! :-) ps. Niestety, psDooM to projekt zapomniany, David już się nim nie zajmuje. W chwili wolnego czasu chciałbym kontynuować jego pracę, dobrałem się do kodu źródłowego DooM'a (świetnie opisany!) oraz zaczynam rozumieć mechanizmy, które zaimplementował David. Może psDooM nie umrze - pomysł jest genialny! Zainteresowani?
DCOP - komunikacja międzyprocesowa
Zastanawialiście się kiedyś, czemu Iceweasel tak chętnie 'wskakuje' na pasek kicker, Opera tak ładnie ładuje się do tray'a a Wasz ulubiony player muzyczny oferuje Wam wygodne sterowanie głośnością czy też paskiem postępu utworu przez mini-interfejs? Desktop Communication Protocol [DCOP] to protokół umożliwiający komunikację między procesami w środowisku KDE3. W momencie gdy piszę te słowa KDE4 zbliża się wielkimi krokami (3 miesiące), a wraz z nim całkowite odejście od DCOP w kierunku D-BUS SYSTEM, więc póki jeszcze czas postaram się opisać to cudowne narzędzie - ot dla potomnych :-).
Przyjrzyjmy się zatem interfejsowi DCOP, a konkretniej - klientem DCOP. Używając skonfigurowanego dopełniania poleceń w Bashu możemy przeglądać strukturę aplikacji w bardzo wygodny sposób.
$ dcop kaccess khotkeys kmix ksmserver kcookiejar kicker knotify kwin kded klauncher konqueror-6695 kdesktop klipper konsole-9344
Widzimy tutaj wszystkie programy korzystające z interfejsu DCOP do wymiany informacji. Chcemy "skontaktować się" z kmix odpowiadającym za mikser systemowy. Wpiszmy zatem:
$ dcop kmix kmix Mixer0 kmix-mainwindow#1 Mixer1 MainApplication-Interface qt
Otrzymaliśmy wykaz wszystkich funkcji, jakie oferuje nam kmix. Posiadam w systemie dwie karty dźwiękowe, zatem mam do dyspozycji Mixer0 oraz Mixer1. Sprawdzę, czy Mixer0 to moja podstawowa karta dźwiękowa.
$ dcop kmix Mixer0 mixerName Intel 82801DB-ICH4
Tak jest. Zacznijmy zatem "magię". Mixer0 oferuje nam takie funkcje:
$ dcop kmix Mixer0 absoluteVolume int mute setMute absoluteVolumeMax interfaces open setRecordSource absoluteVolumeMin isAvailableDevice QCStringList setVolume bool isRecordSource QString toggleMasterMute close long setAbsoluteVolume toggleMute decreaseVolume masterMute setBalance void functions masterVolume setMasterMute volume increaseVolume mixerName setMasterVolume
I już po krótkiej zabawie możemy (konsolowo!) zmieniać głośność, wyciszać kartę czy też nawet zamknąć program. Aby dowiedzieć się, w jaki sposób używać wybranej funkcji wpisujemy:
$ dcop kmix Mixer0 QCStringList interfaces() QCStringList functions() void setVolume(int deviceidx,int percentage) void setMasterVolume(int percentage) void increaseVolume(int deviceidx) void decreaseVolume(int deviceidx) int volume(int deviceidx) int masterVolume() void setAbsoluteVolume(int deviceidx,long int absoluteVolume) long int absoluteVolume(int deviceidx) long int absoluteVolumeMin(int deviceidx) long int absoluteVolumeMax(int deviceidx) void setMute(int deviceidx,bool on) void setMasterMute(bool on) void toggleMute(int deviceidx) void toggleMasterMute() bool mute(int deviceidx) bool masterMute() void setRecordSource(int deviceidx,bool on) bool isRecordSource(int deviceidx) void setBalance(int balance) bool isAvailableDevice(int deviceidx) QString mixerName() int open() int close()
Skorzystajmy z tego i wyciszmy naszą kartę:
$ dcop kmix Mixer0 setMute 0 1
I ponownie ją włączmy:
$ dcop kmix Mixer0 setMute 0 0
Zabawy z DCOP nie ograniczają się tylko do tak prostych spraw, jak sterowanie głośnością czy zamykanie aplikacji. Pokaże Wam teraz, jak można użyć DCOP do oskryptowania własnego "wyświetlacza" tekstów aktualnego utworu na ekranie. Potrzebujemy do tego uruchomionego Amaroka.
$ dcop amarok player
Nie wklejam tutaj wyniku tej komendy, gdyż jest on zbyt duży :-). Amarok daje nam dostęp do tak wielkiej ilości funkcji poprzez interfejs DCOP, że z wykorzystaniem języków skryptowych możemy napisać własny "wrapper" czy też mini-interfejs dla tej kobyłki. Zobaczmy na kilka przykładów:
$ dcop amarok player nowPlaying LOST HORIZON - World Through My Fateless Eyes
$ dcop amarok player currentTime 0:48
$ dcop amarok player lyrics
Ostatnia komenda pokaże nam tekst aktualnie odtwarzanego utworu (o ile mamy skonfigurowany moduł Lyrics w skryptach Amaroka). Jak zatem pokazać to cudo na ekranie? Skorzystamy z Conky :-). Najpierw stwórzmy skrypt "lyrics"
$ cat /bin/lyrics
#!/bin/bash
dcop amarok > /dev/null
if [ $? != 0 ]; then
echo "Amarok nie jest włączony";
else
dcop amarok player lyrics
fi
exit 0
I podepnijmy go pod Amaroka (linijka do wklejenia w Conky'm, wyjście poddane obróbce "śmieci" xml'a).:
${execi 10 lyrics | tail -n +2 | sed "s/'/'/g"}
Tym oto prostym sposobem zmusiliśmy Conky do ukazywania tekstu aktualnego utworu. Podobnie możemy konfigurować swoje skrypty odwołujące się do danego programu (co widać w skrypcie "lyrics" w instrukcji warunkowej 'if'. Ale czy to koniec?
Oczywiście że nie! Czemu by nie użyć DCOP jako systemu powiadomień (np. o nowej poczcie, albo o wydarzeniu)? To się da zrobić!
$ dcop knotify default notify eventname appname 'Witaj swiecie!' '' '' 2 0
Opis poszczególnych parametrów funkcji "notify" uzyskamy poprzez:
$ dcop knotify Notify | grep notify void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level) void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level,int winId) void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level,int winId,int eventId)
Jak widzicie interfejs DCOP jest bardzo wygodny dla programistów języków skryptowych (np. jak w moim przypadku - Basha). Sprawia, że moje programy otrzymują nowe funkcjonalności i działają w różnych warunkach (np. potrafią sprawdzać, czy dany program jest uruchomiony czy nie, jeśli nie wyświetlać graficzne powiadomienie itp.). DCOP posiada jeszcze jeden, ogromny plus. Jest bardzo szybki. W moim odczucie o wiele szybszy od D-BUS. Nie rozumiem czemu twórcy KDE4 zrezygnowali z DCOP. Obiecują interfejs zastępczy, wrapper zapytań. Mówią że będzie kompatybilnie. Już to widzę... Ja od DCOP niezbyt chcę odchodzić. I na koniec kilka ciekawostek:
$ dcop kdesktop KDesktopIface runAutoStart
W ten sposób KDE uruchamia wbudowany Autostart.
$ dcop kdesktop KBackgroundIface setWallpaper
Wasz program ma zmieniać domyślną tapetę?
$ dcop kdesktop KDesktopIface setIconsEnabled
Ukrywać ikony?
$ dcop knotify default notify eventname appname 'Gorion TVN-Style HACK3d!!!!111' '' '' 2 0
I straszyć kumpla? :-)) Życzę Wam miłej zabawy w odkrywaniu możliwości tego systemu!
I jak zwykle: ENJOY! Bo Linux to masa zabawy :-)
Pytanie na marginesie: czy Gnome posiada podobny interfejs? Czy używa D-BUS? Przyznaję - nie wiem bo nie używam od bardzo dawna.
Wywołania systemowe w systemie GNU/Linux
Na początku krótkie wyjaśnienie tego czym jest wywołanie systemowe w ogólnym tego słowa znaczeniu. Wywołanie systemowe (System Call) to funkcja używana przez proces w celu zażądania od systemu operacyjnego (a ściślej - jądra) określonej usługi. Wywołania systemowe są generowane przez przerwania w samym programie (procesie).
Nowoczesne procesory przetwarzają instrukcje w kilkudziesięciu trybach dostępu (różniących się poziomem bezpieczeństwa oraz np. czasem trwania). W systemie GNU/Linux, definiujemy tylko dwa tryby - Tryb Użytkownika oraz Tryb Nadzorcy. Poziomy dostępu zostały stworzone po to, aby system mógł w prosty i jasny sposób decydować o przyznaniu dostępu do zasobów dla procesu. Jądro systemu operacyjnego GNU/Linux uruchamiane jest zawsze w uprzywilejowanym trybie - z oczywistej przyczyny - musi przyznawać dostęp do warstwy sprzętowej dla aplikacji (warstwy programowej), zarządzać przerwaniami, zmieniać tryb dostępu procesora czy też zarządzać pamięcią (tutaj przychodzi ku pomocy sheduler, którego opisałem całkiem niedawno).
Jednak system (kernel) sam w sobie nie potrafi kontrolować mechanizmu zmiany trybu dostępu. Aby zapewnić obsługę sytuacji, w której mnie uprzywilejowany kod transferuje swoje dane (lub jakiekolwiek wygenerowane przez niego) do wyżej uprzywilejowanego kodu potrzebujemy małego "włamu" i przełamania zabezpieczeń. Oczywiście - nie dosłownie. Nie możemy dopuścić do hipotetycznej sytuacji, w które mniej uprzywilejowany proces stara się wymusić na procesie o wyższym priorytecie np. błąd stosu. Standardowo system operacyjny dostarczany jest z biblioteką obsługującą zdarzenia i pośredniczącą między jądrem a procesem. W GNU/Linux tą biblioteką jest libc (Biblioteka C). To ona zarządza i nadzoruje wszystkie niskopoziomowe przepływy informacji pomiędzy procesami i kernelem, a także dzięki niej odbywa się "magiczna zamiana" trybu pracy procesora (z mniej uprzywilejowanego na bardziej lub na odwrót).
Posiadamy więc bibliotekę, którą użytkownik może wywołać w swoim programie i skorzystać z jej funkcji, aby przekazać "coś" "gdzieś" (mówiąc kolokwialnie:)). Przyjrzyjmy się zatem troszkę bliżej libc a w szczególności tematem wywołań systemowych. Jako przykład zatem - kawałek kodu odpowiedzialny za ustawienie UID w GNU/Linuksie.
_syscall1(int,setuid,uid_t,uid); _setuid: subl $4,%exp pushl %ebx movzwl 12(%esp),%eax movl %eax,4(%esp) movl $23,%eax movl 4(%esp),%ebx int $0x80 movl %eax,%edx testl %edx,%edx jge L2 negl %edx movl %edx,_errno movl $-1,%eax popl %ebx addl $4,%esp ret L2: movl %edx,%eax popl %ebx addl $4,%esp ret
Jak widać - operujemy assemblerem. Każda funkcja posiada co najmniej 2 argumenty: numer wywołania systemowego i rodzaj (definicję) działania tegoż wywołania. Każda funkcja wywołania systemowego biblioteki libc zwalnia przerwanie 0x80. Z tego adresu możemy pobrać (np. strace'm) wszystkie wywołania systemowe dowolnego programu. Gdy przerwanie zwolni się (najczęściej po określonym w jądrze "tiku"(czasie)) kod wyjścia jest pobierany z pamięci i możliwy do odczytania przez inną funkcję, bądź też przez wymieniony strace. Argumenty przekazywane są w rejestrach w następującej kolejności: eax, ebx, ecx, edx, edi, esi, ebp. Numer funkcji systemowej jest przekazywany w eax.
Całą pracę za wywołania przejmuje system przerwań. Po wywołaniu funkcji system_call() "praca" rozpoczyna się w 'adresie wejścia', który jest zdefiniowany w arch/i386/kernel/entry. Niestety, rutyny te zapisane są w języku niezrozumiałym dla przeciętnego człowieka. Stąd też krótki algorytm, jako ilustracja tego co dzieje się w czasie wywołania systemowego:
zwraca typ system_call(sys_call_number, sys_call_arguments)
{
Zapisz rejestry procesu;
Sprawdź, czy sys_call_number reprezentuje prawdziwą wartość wywołania;
jeśli nie pokaż błąd
w innym wypadku
{
Sprawdź flagę PF_TRACESYS wybranego procesu;
Wywołaj planistę (jeśli potrzebny);
Przekaż sygnały;
Swolnij rejestry procesu;
}
}
I krótkie wyjaśnienie//opis opisanego algorytmu. Dwie zmienne są przekazywane do rutyny: Sys_call_number odwołuje się do wcześniej zdefiniowanej liczby identyfikującej wywołanie systemowe. Sys_call_arguments przekazuje kolejne argumenty dla wywołania (jeśli potrzebne). Zapisanie rejestrów jest potrzebne, gdyż bez tego wywołanie planisty w późniejszym czasie mogłoby skutkować SIGSEGV. Następnie - sprawdzenie czy numer wywołania jest prawidłowy. Flaga PF_TRACESYS pozwala stwierdzić, czy dany proces nie ma procesu-rodzica. Tutaj wchodzi do gry funkcja syscall_trace (oto jej kod źródłowy arch/i386/kernel/ptrace.c). Jeśli wykryje rodzica przesyła mu SIGTRAP, wcześniej ustawiając procesowi potomnemu flagę TASK_STOPPED. Tutaj wkracza nasz dzielny planista i robi co do niego należy - zajmuje się pamięcią obu procesów (bądź jednego, jeśli proces nie miał rodzica). Jeśli wysłaniu sygnału SIGTRAP i pracy planisty proces dostał//wysłał jakikolwiek sygnał zostaje on przetworzony w tym momencie, po czym przywracane są rejestry.
I na koniec przykład użycia. Oto kawałek strace dla /bin/true:
brk(0) = 0x804a308 brk(0x804b308) = 0x804b308 brk(0x804c000) = 0x804c000 _exit(0)
Przepiękny pogląd na funkcję brk(), która poprzez przerwanie (wywołanie systemowe) odwołała się do pamięci (adres 0x804a308). Program bez praw dostępu do pamięci (przynajmniej bezpośrednio - nie działający w trybie uprzywilejowanym) poprzez System Call odwołał się do jądra, aby ten dał mu mały fragment wolnej pamięci.
Celowo nie opisuję sposobu tworzenia własnych wywołań systemowych. Zainteresowani zajrzą zapewne do Google, a niezainteresowani w końcu skończą czytać ten nudny wpis :-).
I tą oto jogg-notką powracam do żywych :-) Witajcie już oficjalnie! Następny odcinek mam już praktycznie napisany - a w nim... DCOP - jedna z rzeczy za które kocham KDE! :-) Stay Tuned!
