Bionic to implementacja libC (lub przynajmniej tak powinna być kojarzona) w Android. Głównymi powodami stworzenia niezależnej implementacji były:
- pozbycie się licencji GNU z libC
- uszczuplenie i przyśpieszenie implementacji
Bardzo przypadły mi do gustu rozwiązania użyte w Bionic, jako że zajmuję się rozwiązaniami embedded. Z krótkim opisem można się zapoznać tutaj
Ciekawe jest że autorzy uznali np międzyprocesowe semafory i zmienne warunkowe za zbyt "ciężkie" i postanowili nie implementować ich obsługi w wywołaniach POSIX-like.
Ciekawe są również następujące stwierdzenia "Note that Posix mandates a minimum of 128 (thread local storage) slots, but we do not claim to be Posix-compliant"
Jeszcze innym ciekawym rozwiązaniem są tzw property, coś co starałem się wprowadzić w naszej firmie. "Android provides a simple shared value/key space to all processes on the system. It stores a liberal number of 'properties', each of them being a simple size-limited string that can be associated to a size-limited string value".
Najciekawsze jest jednak poniższe stwierdzenie "Bionic intentionally does not provide support for System-V IPCs mechanisms, like the ones provided by semget(), shmget(), msgget(). The reason for this is to avoid denial-of-service.". Ciekawe podejście do problemu :)
2011/03/22
2011/03/21
2011/03/18
Skimming numerów PIN możliwy na kartach chipowych
Skimming numerów PIN możliwy na kartach chipowych: "Czwórka ekspertów zademonstrowała praktyczne możliwości zastosowania skimmingu wymierzonego w karty chipowe – i to zarówno w przypadku układów niechronionej klasy, jak też klasy DDA.
"
 |  |
"
2011/03/10
Sygnaly
Przyszedł czas na odświeżenie wiedzy o sygnałach.
http://www.kernel.org/doc/man-pages/online/pages/man7/signal.7.html
Streszczenie:
Sygnały dostarczane do procesu traktujemy jak przerwania w systemie z bezpośrednim dostepem do procesora.
W Linuxie występują 2 rodzaje sygnałów, Standardowe i RealTime. Cytujac zródło:
"Real-time signals are distinguished by the following:
1. Multiple instances of real-time signals can be queued. By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued.
2. If the signal is sent using sigqueue(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving process establishes a handler for this signal using the SA_SIGINFO flag to sigaction(2) then it can obtain this data via the si_value field of the siginfo_t structure passed as the second argument to the handler. Furthermore, the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.
3. Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent. If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals have highest priority.) By contrast, if multiple standard signals are pending for a process, the order in which they are delivered is unspecified.
If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other implementations, gives priority to standard signals in this case."
Sygnały mogą zostać wysłane do procesu lub wątku. Zazwyczaj funkcje pozwalające wysłać sygnał do wątku posiadają przedrostek pthread- . Sygnał wysłany do procesu zostanie dostarczony do dowolnego z wątków który w danym momencie go nie blokuje. Jeśli wszystkie wątki blokują sygnał skierowany do procesu, pozostanie on nieobsłużony do czasu aż przynajmniej jeden z wątków zezwoli na jego przetwarzanie.
Nalezy pamietać że istnieja 2 pojęcia dotyczące sygnałów, dyspozycje oraz maska. Dyspozycja sygnałów określa czy sygnał ma wykonać domyślna akcje (zależna od sygnału np zakończyć proces lub wykonać core dump), czy należny go zignorować czy przechwycić/dostarczyć. Natomiast maska pozwala na tymczasowe skolejkowanie sygnału w przypadku dyspozycji dostarczenia, do czasu kiedy nie zostanie wyczyszczona (maska). Sygnał skolejowany nazwany jest sygnałem w stanie "pending".
Dyspozycja jest peer aplikacja, natomiast maski sygnałów są peer watek.
Inną ważną informacją jest to że biblioteka pthread używa 2 lub 3 pierwsze sygnały typu real time, do implementacji jej wewnętrznych usług. Dlatego też należy bezwzględnie używać makra SIGRTMIN aby w aplikacji nie użyć przypadkiem numerów sygnałów wykorzystywanych w bibliotece pthread. Inna rzeczą o której trzeba pamiętać jest to że kernel ogranicza też maksymalna ilość kolejkowanie sygnałów (w zależności od wersji jest do ograniczenie typu system-wide (do 2.6.7) lub user-wide (od 2.6.8)).
Należy pamiętać ze w funkcji obsługi sygnału nie wolno wykonywać dowolnie zdefiniowanego kodu. POSIX wprowadza w tym celu pojęcie Async-"signal-safe" functions.
Następna sprawa są wywołania funkcji systemowych przerwane sygnałami. Wywołania systemowe przerwane sygnałami mogą być automatycznie wznawiane (bez powiadamiania aplikacji o błędzie wywołania) w niektórych przypadkach o ile użyto flagi SA_RESTART w wywoływaniu sigaction lub podobnym.
Następujące funkcje klasyfikują się do wymienionego przypadku:
- read(2), readv(2), write(2), writev(2), and ioctl(2) calls on "slow" devices. A "slow" device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. (A disk is not a slow device according to this definition.) If an I/O call on a slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred)
- open(2), if it can block (e.g., when opening a FIFO; see fifo(7)).
- wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2).
- Socket interfaces: accept(2), connect(2), recv(2), recvfrom(2), recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a timeout has been set on the socket (see below).
- File locking interfaces: flock(2) and fcntl(2) F_SETLKW.
- POSIX message queue interfaces: mq_receive(3), mq_timedreceive(3), mq_send(3), and mq_timedsend(3).
- futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always failed with EINTR).
- POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3) (since Linux 2.6.22; beforehand, always failed with EINTR).
Ważne zaznaczenia jest to ze dysk nie jest uznany za "wolne" urządzenie, dlatego przy pisaniu lub czytaniu z pliku zawsze należny sprawdzać kod powrotu oznaczający ilość wpisanych lub odczytanych danych. 0 nie jest kodem błędu! ale informacja ze żadne dane nie zostały zapisane w momencie przyjęcia sygnału.
http://www.kernel.org/doc/man-pages/online/pages/man7/signal.7.html
Streszczenie:
Sygnały dostarczane do procesu traktujemy jak przerwania w systemie z bezpośrednim dostepem do procesora.
W Linuxie występują 2 rodzaje sygnałów, Standardowe i RealTime. Cytujac zródło:
"Real-time signals are distinguished by the following:
1. Multiple instances of real-time signals can be queued. By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued.
2. If the signal is sent using sigqueue(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving process establishes a handler for this signal using the SA_SIGINFO flag to sigaction(2) then it can obtain this data via the si_value field of the siginfo_t structure passed as the second argument to the handler. Furthermore, the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.
3. Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent. If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals have highest priority.) By contrast, if multiple standard signals are pending for a process, the order in which they are delivered is unspecified.
If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other implementations, gives priority to standard signals in this case."
Sygnały mogą zostać wysłane do procesu lub wątku. Zazwyczaj funkcje pozwalające wysłać sygnał do wątku posiadają przedrostek pthread- . Sygnał wysłany do procesu zostanie dostarczony do dowolnego z wątków który w danym momencie go nie blokuje. Jeśli wszystkie wątki blokują sygnał skierowany do procesu, pozostanie on nieobsłużony do czasu aż przynajmniej jeden z wątków zezwoli na jego przetwarzanie.
Nalezy pamietać że istnieja 2 pojęcia dotyczące sygnałów, dyspozycje oraz maska. Dyspozycja sygnałów określa czy sygnał ma wykonać domyślna akcje (zależna od sygnału np zakończyć proces lub wykonać core dump), czy należny go zignorować czy przechwycić/dostarczyć. Natomiast maska pozwala na tymczasowe skolejkowanie sygnału w przypadku dyspozycji dostarczenia, do czasu kiedy nie zostanie wyczyszczona (maska). Sygnał skolejowany nazwany jest sygnałem w stanie "pending".
Dyspozycja jest peer aplikacja, natomiast maski sygnałów są peer watek.
Inną ważną informacją jest to że biblioteka pthread używa 2 lub 3 pierwsze sygnały typu real time, do implementacji jej wewnętrznych usług. Dlatego też należy bezwzględnie używać makra SIGRTMIN aby w aplikacji nie użyć przypadkiem numerów sygnałów wykorzystywanych w bibliotece pthread. Inna rzeczą o której trzeba pamiętać jest to że kernel ogranicza też maksymalna ilość kolejkowanie sygnałów (w zależności od wersji jest do ograniczenie typu system-wide (do 2.6.7) lub user-wide (od 2.6.8)).
Należy pamiętać ze w funkcji obsługi sygnału nie wolno wykonywać dowolnie zdefiniowanego kodu. POSIX wprowadza w tym celu pojęcie Async-"signal-safe" functions.
Następna sprawa są wywołania funkcji systemowych przerwane sygnałami. Wywołania systemowe przerwane sygnałami mogą być automatycznie wznawiane (bez powiadamiania aplikacji o błędzie wywołania) w niektórych przypadkach o ile użyto flagi SA_RESTART w wywoływaniu sigaction lub podobnym.
Następujące funkcje klasyfikują się do wymienionego przypadku:
- read(2), readv(2), write(2), writev(2), and ioctl(2) calls on "slow" devices. A "slow" device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. (A disk is not a slow device according to this definition.) If an I/O call on a slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred)
- open(2), if it can block (e.g., when opening a FIFO; see fifo(7)).
- wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2).
- Socket interfaces: accept(2), connect(2), recv(2), recvfrom(2), recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a timeout has been set on the socket (see below).
- File locking interfaces: flock(2) and fcntl(2) F_SETLKW.
- POSIX message queue interfaces: mq_receive(3), mq_timedreceive(3), mq_send(3), and mq_timedsend(3).
- futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always failed with EINTR).
- POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3) (since Linux 2.6.22; beforehand, always failed with EINTR).
Ważne zaznaczenia jest to ze dysk nie jest uznany za "wolne" urządzenie, dlatego przy pisaniu lub czytaniu z pliku zawsze należny sprawdzać kod powrotu oznaczający ilość wpisanych lub odczytanych danych. 0 nie jest kodem błędu! ale informacja ze żadne dane nie zostały zapisane w momencie przyjęcia sygnału.
Subskrybuj:
Posty (Atom)