Kernel Traffic #179 For 2002/08/12

There were 447 different contributors. 244 posted more than once. 175 posted last week too.

Jest to najnowsza wersja łatki ,,lockassert''. Zawiera ona:

MUST_HOLD dla wszystkich architektur
MUST_HOLD_RW dla architektur implementujących rwlock_is_locked (w tym momencie tylko ia64, jako część tej łatki)
MUST_HOLD_RWSEM dla architektur używających rwsem-spinlock.h
MUST_HOLD_SEM dla ia64
wywołanie MUST_HOLD(&inode_lock) w inode.c:__iget().

Byłbym wdzięczny za przysłanie mi dodatkowych łatek implementujących powyższe procedury dla innych architektur lub/i za łatki, które użyją makr tam, gdzie jest to wskazane.

Joshua MacDonald wskazał, że opiekunowie ReiserFS czekali na asercję MUST_NOT_HOLD. Jesse odpowiedział: " Cóż, Znajdowało się to w jednej z wersji łatki, lecz ludzie sądzili, że jest to nieprzydatne. Może chciałbyś przeczytać komentarze Olivera na http://marc.theaimsgroup.com/?l=linux-kernel&m=102644431806734&w=2 i wyrazić swoje zdanie? Jeżeli istnieje zapotrzebowanie na MUST_NOT_HOLD, to z chęcią je dodam, tym bardziej, że jest to łatwe." Robert Love zasugerował dodanie asercji CAN_SLEEP oraz CANNOT_SLEEP.

Ponieważ w jądrach 2.5 pojawił się zupełnie nowy kod obsługi portów szeregowych, David Gibson próbował go uruchomić na swoim PowerPC (płyta EP405). Ale port szeregowy 8250 na jego systemie sprawił pewne trudności. Opisał dokładne symptomy złego działania i obejścia problemów, które zastosował, a ponadto zauważył: "Obecny nadmiar podobnych, ale nie takich samych struktur opisujących porty szeregowe (serial_state, serial_struct, uart_port, old_serial_port), jest także raczej myląca. Domyślam się, że część z nich jest już nieważna i pozostała tylko jako pomocna przy zmianie, ale nie jestem pewny, które to są." Russell King odpowiedział:

Nie widzę prostego sposobu na poradzenie sobie z tym:

serial_struct jest API w przestrzeni użytkownika.
old_serial_port przykleja asm/serial.h do 8250.c; asm/serial.h nie może być zmienione, (głównie) dlatego, że ppc go wszędzie używa. Inne architektury zachowują się chyba podobnie.

Jeśli ppc i inni nie zechcą się męczyć z istotnymi zmianami gdy zmienię asm/serial.h, to nie uda mi się tego wyczyścić. Komentarze w tej dziedzinie są mile widziane.

Tom Rini zapytał jakie zmiany miał na myśli Russell i dostał następującą odpowiedź:

1. Inicjalizacja portu szeregowego

Pierwszą rzeczą która tu przychodzi do głowy jest to, na co Alan mówi ,,bądź miły, żeby upewnić się, że to było znacznie wcześniej''. Sądzę, że Alan ma racje, zatem możemy dostać oopsa w jądrze dość łatwo, nawet jeśli używamy konsoli z buforem ramki.

Jestem pewien, że Alan oświeci nas jeśli chodzi o dokładne powody, jeśli będzie taka potrzeba.

Było kilka propozycji naprawienia tej tablicy:

a. zamiast utrzymywać tablicę w serial.h, architektury dostaraczają podmodułów do 8250.c, które zawierają szczegóły dotyczące portów. To oznaczałoby, w idealnym świecie, zupełne pozbycie się serial.h. Wynikowy obiekt byłby podłączony do 8250.c, a 8250 byłoby skompilowane jako moduł.

b. tworzymy 8250_hub6.c, 8250_generic.c, 8250_multiport.c i podobne, każdy zawierający parametry konkretnej karty i obsługujemy je jak wyżej.

c. zostawić w jądrze tylko porty niezbędne do uzyskania konsoli szeregowej, resztę odpowiedzialności za wiele portów szeregowych przenieść do przestrzeni użytkownika, która byłaby odpowiedzialna za przekazanie jądru informacji o tych portach. (patrz poniżej: problem 2)

d. zatrzymujemy serial.h, ale zgodny jedynie z portami 8250 i zmieniamy CONFIG_SERIAL_MULTIPORT i podobne na CONFIG_SERIAL_8250_MULTIPORT. To jest najprostszy sposób i najmniejsze ryzyko, że popsuje to inny kod. Z drugiej strony w 2.6 stracimy obsługę tablicy ISA i strukturę old_serial_port.

2. setserial API

To jest tak naprawdę bardzo związane z inną kwestią; Chciałbym się pozbyć głupiego pomysłu, dzięki któremu możemy otwierać nieistniejące porty szeregowe (to znaczy, z UART ustawionym na 'unknown'). Takie zachowanie wydaje się być podyktowane korzyściami ze strony setserial, pozwala mu bowiem na modyfikację adresów bazowych portu, stopni przerwań itp. Usunięcie tego udogodnienia wymagałoby nowego API. Najlepsza propozycja do tej pory to zrobienie czegoś takiego:

# echo "add 0x2e8,3,autoconfig" >/dev/serialctl
# echo "remove 0x2e8" >/dev/serialctl

(albo s,/dev/serialctl,/proc/tty/driver/serial, który istnieje wcześniej)

gdzie mamy 'add ioport,irq,flags' i 'remove ioport' (zauważcie, że nie ma tu portów mmio, bo wymagają one sztuczek z ioremap, które są raczej zależne od karty!)

Po co robić tę zmianę? Cóż, mamy sporo nadmiarowych rzeczy, które zostały wrzucone tu i tam, by obsłużyć konfigurację otwartego portu i żeby dawało się otwierać nieistniejące porty. Naprawdę chciałbym się pozbyć tego nadmiarowego bagażu.

3. /dev/ttyS, /dev/ttySA, /dev/ttyCL, /dev/ttyAM, itp

Wszystko powyżej to porty szeregowe różnych typów. Parę razy już wyrażono opinię, że ludzie woleliby, aby wszystkie one pojawiały się jako /dev/ttyS* (rzeczywiście, na ten temat odbyła się, hm, raczej gorąca dyskusja parę lat temu.) Chciałbym pozostać neutralny w tej kwestii.

Wokół tego można wymienić kilka problemów:

a. Plik core.c z obsługi portu szeregowego prawie zawsze potrafi dać sobie radę z tą abstrakcją, z jedym wyjątkiem - zarejestrowany port może być w jedym czasie tylko w jednej grupie. Takie ograniczenie wynika ze sposobu, w jaki warstwa tty obsługuje swoje porty tty.

(Obsługa podwójnej rejestracji dla dwóch różnych numerów głównych _naprawdę_ miesza - to znaczy dwa wbudowane porty 16550A i dwa porty SA1100, na które przeznaczone jest ttyS0 do ttyS3. Potem dodajesz kolejne 16550A - modem na PCMCIA, który staje się ttyS4. A, a porty SA1100 widać w systemie także jako ttySA0 i ttySA1. _prawdziwe_ bałaganiarstwo. Nie, dziękuję.)

b. konsole szeregowe. Każdy sterownik sprzętu sam obsługuje własne konsole szeregowe, a jeśli masz wbudowane dwa lub więcej sterowników sprzętowych obsługujących konsolę szeregową, to musisz móc je odróżnić w jądrze parametrem console= .

I znowu, można to rozwiązać, jeśli mielibyśmy takie samo spojrzenie na wszystko, przez 'ttyS' (core.c byłoby wtedy odpowiadzialne za rejestrację konsoli z printk.c i przesunięcie różnych metod do odpowiedniego sprzętu).

c. Ludzie z wieloma portami szeregowymi. _Moglibyśmy_ zmienić przywiązania numerów urządzeń tak, by ttyS pożarło ttySA, ttyCL, ttyAM, i tym podobne numerzy urządzeń, co dałoby taką samą liczbę dostępnych miejsc na porty dla tych, którzy mają w swoich maszynach wiele, wiele portów szeregowych.

Nastąpiło potem wiele komentarzy i krytyk, ale ostatecznie nic nie zdecydowano. Patrz: BROKEN KCREF; tam jest więcej na ten temat w jądrze 2.5.30.

Tim Hockin przepuścił drivers/char/nvram.c przez Lindenta, dodał kilka ręcznych zmian kosmetycznych i podesłał łatkę. Linus Torvalds odpowiedział:

Hmm.

Jeśli robisz tego typu zmiany przy użyciu Lindent, to mógłbyś także poprawić inny nielinuksizm:

        return (x);     ->      return x;

Nie mam pojęcia dlaczego niektórzy ludzie sądzą, że ,,return'' jest funkcją jednoargumentową..

Podejrzewam, że nie wspomniano o tym w pliku CodingStyle. Jestem leniwy. Zły, niedobry Linus.

Tim wykonał poprawki i podesłał dwie nowe łatki, jedną na 2.4 i jedną na 2.5. Pavel Machek zaproponował uaktualnienie przy okazji CodingStyle...

W trakcie dyskusji o tym, czy różne operacje WE/WY (takie jak czytanie plików) mogą być przerywane sygnałami, Linus Torvalds wyraził swoją opinię na temat POSIX:

POSIX jest archaicznym standardem i nie ma co się nim przejmować.

Nie robimy ,,systemu operacyjnego zgodnego z POSIX''. Ludzie to już robili: popatrz na wszystkie systemy RT tutaj, popatrz nawet na podsystem NT POSIX.

Nie są interesujące.

Linux jest _prawdziwym_ systemem operacyjnym, a nie czymś w rodzaju ,,wykonaliśmy papierkową robotę i teraz to jest zgodne ze standardami''.

To, że Linux jest prawdziwym systemem oznacza, że musimy brać pod uwagę świat realny.

A świat realny podpowiada, że nie akceptuje, gdy wymyślasz sobie własną sematykę, no chyba, że masz _diabelnie_ dobry powód by to zrobić.

Peter J. Braam powiedział, że jego firma chciałaby używać plików o rozmiarach wiekszych niż 16TB oraz systemów plikowych mogących pomieścić więcej niż trylion plików. Dodał: " Rozumiem ludzi, którzy protestują przeciwko umieszczaniu w plikach jądra typów u64 argumentując, że możemy poczekać jeszcze rok lub dwa i zacząć używać 64 bitowych architektur, więc nie będę robił z tego problemu. Tak, czy inaczej, informuję, że istnieją organizacje, które _naprawdę_ potrzebują obsługi dużych plików i pojemnych systemów plikowych oraz są zawiedzione z powodu ,,small integers''. Z tego powodu nie będziemy mogli wykonać, zgodnie z żądaniem, zapisu 50TB." Andrew Morton zauważył, że pomimo iż te zmiany nie potrzebują dużego nakładu pracy i wystarczy przejrzeć kod, zamieniając odpowiednie wystąpienia ,,unsigned long'' na ,,pgoff_t'' oraz dostosować kilka innych partii kodu, zmiany te nie mogły doczekać się akceptacji. Powiedział też:

Linus miał trojakie wątpliwości: rozszerzy to struktury, arytmetyka 64-bitowa jest powolna, a gcc ma tendencję do jej błędnej obsługi. Dodałbym jeszcze fakt, że ,,większość deweloperów nie przetestowałaby obsługi 64bit pgoff_t, więc ciągle byłoby to zepsute''.

Rozrost struktur opisujących strony oraz spadek wydajności wyznacza granicę pomiędzy kosztem a zyskiem z tego rozwiązania. Dla pewnej grupy ludzi 32-bitowy indeks pamięci podręcznej stron jest zbyt wielką zmianą, mogącą spowodować opóźnienie w procesie tworzenia jądra, a takie rozwiązanie może zostać przez nich zaakceptowane.

Wstawienie wszędzie ,,pgoff_t'' nie jest, moim zdaniem, takie złe - to zwiększy czytelność kodu, ponieważ wiemy do czego służy dana zmienna.

Co do gcc generującego błędny kod, orędownicy 64-bitowego pgoff_t będą musieli zidentyfikować poprawną wersję kompilatora i doprowadzić do tego, by gcc generowało poprawny kod.

Nico Schottelius zasugerował, że skoro sterowniki kart sieciowych e100 zwracają informację o statusie połączenia, szykości oraz innych danych, to byłoby wspaniale mieć te informacje w pliku lub katalogu w /proc/net. To pozwoliłoby na stworzenie oprogramowania służącego np. jako wskaźnik stanu karty w panelu kontrolnym menedżera okien. Wysłano kilka odpowiedzi sugerujących, że potrzebne dane można uzyskać za pomocą ioctl. Jeff Garzik dodał: "To nie powinno znaleźć się wśród stosu śmieci w procfs ;). Al Viro mówił przez długi czas o udostępnianiu tych informacji za pomocą systemu plikowego. Jeżeli to się stanie, Twoja prośba zostanie w tym momencie spełniona."

Marcin Dalecki podesłał ostatnią łatkę IDE i wymienił następujące kwestie:

Integracja łat Adama J. Richtera, Alana Coxa i Andre Hedricka dotyczących dostępu do rejestru przestrzeni konfiguracyjnej CMD640 PCI.
łatki cs5530 Adama J. Richtera. Małe poprawki związane z wcięciami w kodzie.
poprawki qd65xx cli()/sti().
Poprawka niepotrzebnego polecenia w ide.c zauważona przez Petera Vendrovca.
Eliminacja ide_stall_queue(). Dla zaniepokojonych: w ogóle nie było tam spania.
Eliminacja obsługi ,,przemapowania sektora''. Urządzenia typu loop dają sobie radę z takimi rzeczami. Wszystkie obejścia problemów takie jak w DOSie, używające jakichś sztuczek z BIOSEM nie są teraz potrzebne. Jeśli gdziekolwiek by były, to kod systemu plików FAT powinien być wystarczająco sprytny, bo dać sobie z tym radę, dostosowując swoje metody read/write.
obsługa odwrotnego mapowania w alokacji ,,uszkodzonego zbioru'' PCI autorstwa Adama J. Richtera.
Uproszczone do_ide_request po usunięciu ->sleep.
Zmiana, dzięki której do_ide_request jest preferowane przy obsłudze dopasowywania urządzenia do kolejki żądań. Kolejki RQ są osobne dla urządzeń. W następnym kroku queuedata będzie zmienione tak, by wskazywać na urządzenie, nie na kanał.

Paru gości miało do Marcina pretensje w związku z elimnacją obsługi mapowania sektorów, a Petr Vandrovec dodał, że akurat używa tej odziedziczonej cechy na jednym ze swoich systemów. WyjaśniłL "tam jest BIOS bez LBA32 i bez obsługi dysków >30GB, ale potrzebowałem włożyć tam duży dysk, na którym był już system, a użycie jakiegoś menedżera dysku było jedynym wyjściem (EZDrive, używający przemapowania 0_to_1 )... Wiem, że remap 0_to_1 jest zepsuty dla nr_sectors > 1, ale trudno jest używać urządzenia loop, gdy system nie podnosi się bez boot managera." Marcin ciągle twierdził, że kod IDE nie jest właściwą warstwą, która powinna to obsługiwać. Zaproponował: "co powiesz na temat obsługi tego problemu w trakcie skanowania partycji. Partycje są w końcu niczym innym, tylko urządzeniami z przemapowanymi sektorami. Czy dałbyś radę umieścić w odpowiednim miejscu w paritions/*.c magiczne + 1. Wtedy może to być natychmiast zamienione w globalną opcję jądra - czym w sumie i tak jest." Podrążył trochę, żeby lepiej zrozumieć co Petr ma w swoim systemie i szukając najlepszego sposobu na umieszczenie tego elementu w kodzie; po paru kolejnych wiadomościach wątek wygasł.

Zespół EVMS przedstawia nowe, stabilne wydanie Enterprise Volume Management System, które kiedyś, ewentualnie, stanie się EVMS 2.0. Pakiet z wersją 1.1.0 jest dostępny na stronie:
http://www.sf.net/projects/evms

EVMS 1.1.0 posiada pełne wsparcie dla jądra 2.4 i zawiera łatki dla wszystkich źródeł jądra od 2.4.19-rc3 wzwyż. Wspiera także jądro 2.5 i zawiera łatki dla 2.5.25 oraz 2.5.27.

**** Ważna Informacja ****

W tym wydaniu EVMS-owi został przypisany nowy, stały, główny numer urządzenia równy 117. Poprzedni główny numer, 63, został zarezerwowany dla sterowników będących w stadium eksperymentalnym. Przed użyciem 1.1.0, proszę, przeczytajcie zawartość pliku README_Upgrade_To_1.1.0 zawartego w pakiecie ze źródłami, który mówi o tym, w jaki sposób możecie odczuć zmianę głównego numeru urządzenia. Możesz także przeczytać te informacje na stronie domowej EVMS:
http://evms.sourceforge.net/new_major.html.

************************

Aby uzyskać informacje o trwających testach wydajnościowych oraz o ich wynikach, odwiedź stronę Linux Scalability Effort:
http://lse.sourceforge.net/benchmarks/evms/

Proszę o przesyłanie wszelkich sugestii oraz zapytań na listę pocztową EVMS pod adresem:
evms-devel@lists.sf.net.

syscalltrack-0.73, 9. wersja _alfa_ systemu śledzenia wołań systemowych jest już dostępna. syscalltrack działa dla jądra Linuksa w wersji 2.4.x na architekturach i386 i UML. Wersje 2.2.x i 2.5.x też powinny działać, ale nie były tak dobrze testowane. Obecna wersja zawiera nowe, eksperymentalne narzędzie zgodne ze strace, które nazywa się sctrace, plik z urządzeniem do logowania, parę poprawek błędów i sporo nowych wołań systemowych, włączając w to wszystkie wołania IPC. Poniżej więcej szczegółów.

* Co to jest syscalltrack?

syscalltrack składa się z pary modułów jądra Linuksa i obsługuje środowisko trybu użtykownika, które umożliwia podsłuchanie, logowanie i podejmowanie akcji w trakcie wołań systemowych, które spełniają kryteria definiowane przez użytkownika. syscalltrack może działać w ,,trybie pincetki'', w którym tylko bardzo szczególne operacje są śledzone, takie jak ,,śledź i loguj tylko próby usunięcia /etc/passwd'', albo w trybie zgodnym ze strace(1), w którym śledzone są wszystkie obsługiwane wołania systemowe. syscalltrack może robić rzeczy, których nie da zrobić przy użyciu mechanizmu ptrace, bo jego rdzeń działa w przestrzeni jądra.

* Skąd można go wziąć?

Informacja na temat syscalltrack jest dostępna na stronie domowej projektu: http://syscalltrack.sourceforge.net, oraz w plikach projektu.

Źródła najnowszej wersji można pobrać bezpośrednio z http://osdn.dl.sourceforge.net/sourceforge/syscalltrack/syscalltrack-0.73.tar.gz, albo z innych serwerów lustrzanych sourceforge'a.

* Wołanie o deweloperów:

Projekt syscalltrack poszukuje deweloperów, zarówno do przestrzeni jądra, jak i do przestrzeni użytkownika. Jeśli chcesz przyłączyć się do zabawy, to skontaktuj się z nami na liście hakerów syscalltrack (http://lists.sourceforge.net/lists/listinfo/syscalltrack-hackers).

Tony rzeczy, znowu wszędzie. Dużo łączenia z różnymi ludźmi.

Najbardziej warta zauważenia poprawka (dla mnie osobiście), to poprawka Tronda rozwiązująca okropny problem z RPC, który powodował, że klient NFS dostawał nieprawidłowe wskażniki do dentry, które kompletnie zawieszały warstwę VFS na maszynach SMP.

Ale, jak możecie zobaczyć w ,,krótkiej'' wersji listy zmian (pełna lista ma 63kB), jest tam też sporo innych rzeczy.

Kontynuując temat zawarty w BROKEN KCREF, Axel Siebenwirth zwrócił uwagę, że nie udało się skompilować pliku 8250.x jako modułu. Pojawiły się pewne początkowe pytania, a potem Adam J. Richter wyjaśnił:

linux-2.5.30/include/linux/serialP.h potrzebuje struktury async_icount, która jest zdefiniowana w <linux/serial.h>, co powoduje, oprócz innych problemów, że linux-2.5.30/drivers/serial/8250.c się nie kompiluje. W jądrze linux-2.5.30 nie możesz skompilować pliku, który włącza <linux/serialP.h> bez włączania <linux/serial.h>. Sądzę zatem, że rozwiązaniem będzie umieszczenie w serialP.h linijki #include serial.h. Dołączyłem łatkę, która to robi.

Z komentarzy w serialP.h, wynika trochę, że w linux-2.2 poczyniono pewne wysiłki, by pozwolić włączać serialP.h bez serial.h, ale nie widzę żadnej uwagi na temat tego, jakich miałoby to dostarczyć korzyści.

Ted (albo kto tam zbiera łatki na kod sterowników/portu szeregowego i przesyła je Linusowi), czy chciałbyś podrzucić tę zmianę Linusowi, mam ją sam bezpośrednio posłać, czy chcesz, żeby zrobić jeszcze coś innego?

Ack. Właśnie odkryłem dlaczego ja i wiele innych ludzi możemy go skomilować, a inni nie mogą. Mogę Ci wyjaśnić jak skompilować 8250.c jako moduł.

Dlaczego?

Kiedy wkompilowuję 8250.c w jądro, to plik linux/module.h nie włącza linux/version.h, zatem kiedy włączamy linux/serialP.h, to kompilator zakłada, że LINUX_VERSION_CODE wynosi zero. Zatem w sumie włączamy linux/serial.h.

Jednak, kiedy kompiluje się to jako moduł, to linux/module.h już włącza linux/version.h, zatem nie włączamy linux/serial.h.

Och, te problemy z próbami redukcji użycia #include... Myślę, że powinniśmy ponownie włączać linux/serial.h i wyeliminować linux/serialP.h.

Hmm, ciekawi mnie ile jeszcze dziwów takich jak ten jest w obecnym drzewie. Wydaje się, że chcemy stworzyć zasadę podobną do zasady używania symboli CONFIG_*. Czy to brzmi sensownie: jeśli używasz LINUX_VERSION_CODE, musisz włączać linux/version.h do tego samego pliku, żeby zagwarantować, że symbol został zdefiniowany.

Wziąłem więc checkconfig.pl i stworzyłem checkversion.pl (w załączniku). O boże, proszę, czy mogę te robale zapakować z powrotem do puszki? Teraz? Wydaje się, że jest tu dużo roboty, kupa rzeczy ma na diabła #include <linux/version.h>, a porównywalnie mała liczba nie załącza tego pliku, a używa LINUX_VERSION_CODE.

Podesłał własną poprawkę i napisał, że to on jest tą osobą (osobą w miejsce wskazanego przez Adama Theodore Y. Ts'o), która prześle te zmiany Linusowi. Rusell ostrzegł ludzi, żeby nie wysyłali jego łatki Linusowi, najwyżej ją testowali, bo ma on jeszcze trochę innych rzeczy do dołączenia do niej.

David Mosberger wysłał łatkę dla 2.5 i powiedział: "Poniższa łatka czyści sterownik dźwięku cs4281 tak, aby kompilował się czysto (bez ostrzeżeń) na 64-bitowych architekturach takich, jak ia64. Łatka zawiera również uaktualnione wywołania synchronize_irq(), któe używają nowego interfejsu (z numerem irq jako argument). Ktoś, kto rozumie ten sterownik, może dokładnie sprawdzić, czy to działa jak powinno." Alan Cox powiedział, że to zrobi a następnie przeniesie całą łatkę do 2.4.

Mam nowy zestaw łatek uClinux (bez-MMU) dla 2.5.30 pod adresem:

http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/

Zakodowałem ogólny sterownik mapy MTD, który ma zastąpić stary i dziadowski sterownik blkmem. Sterownik blkmem zniknie w przyszłych łatkach.

Poza tym wszystko ładnie działa.

Dave Jones nie przyglądał się zbytnio kodowi, ale powiedział, że wygląda na to, że można by to współdzielić z kodem Grega i zwykłym kodem zarządzania pamięcią. Greg odparł:

rzeczywiście jest wiele wspólnego. Jakieś 70%. To jest pytanie o ogranizację całości.

Zdecydowanie bardziej wolałbym ujrzeć obsługę nie-mmu w mm. Ale to będzie oznaczało dodanie kilku #ifdefów, aby móc rozróżniać te przypadki.

Dave odparł: "Mając do wyboru to i duplikację całej masy kodu, wolę już te ifdefy, zwłaszcza jeśli można to ukryć w nagłówkach."

John Weber zauważył, że obsługa laptopów Toshiba była zepsuta w jądrze 2.5.30 i wysłał łatkę, która to naprawiała. Alan Cox powiedział, że łatka wygląda ,,po prostu porządnie'' i zasugerował kilka rzeczy w implementacji, John wysłał nową łatkę i wątek się zakończył.

To jest nieco uaktualniona wersja łaty, którą dwukrotnie nadesłałem w trzech częściach i trzy razy jako jeden plik. Tym razem zmiany polegają jedynie na dodaniu obsługi 64-bitowego jądra i 23-bitowej przestrzeni użytkownika od ludzi z grupy parisc, a także na include/asm/parisc/rtc.h, obydwie od Randolpha Chunga.

Łata nr 1 to aktualna wersja sterownika (przenieśliśmy się na inicjalizatory w stylu C99, włączone w aktualnym CVS m64k); wymagał zmian aby dało się w ogóle wybrać/kompilować. Pytałem już społeczność m68k, czy ktokolwiek zgłasza jakieś sprzeciwy, abym to ja nadesłał łatę i dostałem błogosławieństwo Richarda Zidlicky'ego (będącego w nagłówku pliku), jaki i zgodę Geerta Uytterhoevena.

Łata nr 2 to fragment związany z PPC tworzący include/asm-ppc/rtc.h. Tę zmianę mieliśmy w bitkeeperze PPC już ponad miesiąc. Mogę poprosić Paula Mackerrasa, aby Wam to przesłał, jeśli sobie życzycie.

Łata nr 3 to mój własny kawałek roboty, jak i trochę pracy wykonanej przez Randolpha Chunga. Zmienia set_rtc_time(struct *rtc_time) tak, aby zwracała liczbę całkowitą zamiast pustej wartości. Zrobiliśmy tak, aby kod specyficzny dla danej architektury mógł wykonać dodatkowe testy i w razie co zwrócić błąd. Wtedy na scenę wkracza include/asm-generic/rtc.h, include/asm-i386/rtc.h i include/asm-alpha/rtc.h. include/asm-generic/rtc.h zawiera logikę get_rtc_time i set_rtc_time znajdujące się w drivers/char/rtc.c i było testowane na SMP i386. Zmienia również include/asm-ppc/rtc.h tak, aby zwracało -ENODEV, jeśli nie ma żadnego sprzętu rtc.

Dodatkowo Dave Jones wskazał mi miejsce, w którym mogą być kłopoty z bezpieczeństwem, kiedy jiffies się przekręcają, zatem łata zmienia to na time_after().

Od Randolpha Chunga dostaliśmy obsługę 64-bitowego jądra i 32-bitowej przestrzeni użytkownika.

A teraz trochę historii sterownika.

Sterownik włączono w drzewo m68k już kilka lat temu, zatem ogólny kod jest sprawdzony. Został również doprowadzony do tego, że działa na innych architekturach (głownie ze względu na maszyny hybrydowe m68k/PPC). To dość przydatne, ponieważ cała gama architektur nie może korzystać z drivers/char/rtc.c z powodu różnic w sprzęcie lub z innych powodów.

Powinien być także przydatne na MIPS-ach, które jakiś czas temu miały skopiować sterownik rtc dla PPC (drivers/macintosh/rtc.c) i będzie prawdopodobnie całkiem przeydatne na innych architekturach.

Ludzie od parisc-linux już od jakiegoś czasu korzystają z tego sterownika, a wersja podobna do tej była przetestowana przez nich w 2.5.

W oparciu o prywatne komentarze, wierzę, że po kilku rozszerzeniach, ia64 będzie mogła również z tego korzystać. I jeśli społeczność MIPS kiedykolwiek stworzy sterownik rtc podobny do drivers/macintosh/rtc.c, powinni móc skorzystać z niego bez kłopotów.

UML został zaktualizowany do 2.5.30 i UML 2.4.18-49. Wiele rzeczy UML-owych było w hppfs, który nie jest zawarty w tej łatce. Wyjątkiem jest poprawka błędu powodującego pad po zamknięciu xterma w UML.

Ponieważ UML nie znalazło się w 2.5.30, będę wysyłał tę łatkę Linusowi.

Łatka dostępna jest pod adresem http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.30-1.bz2

Mirrory UML i innych plików znajdziecie pod adresem http://user-mode-linux.sourceforge.net/dl-sf.html

Inne ciekawe odnośniki:

Strona domowa projektu UML : http://user-mode-linux.sourceforge.net
Strony społeczności UML : http://usermodelinux.org

Marcelo Tosatti ogłosił 2.4.19, które jest niezmienioną kopią 2.4.19-rc5. James W. Laferriere zauważył, że paczka ze źródłami jądra rozpakowała się do katalogu o nazwie linux-2.4.19/, zamiast, jak zwykle, do katalogu linux/. Alan Cox napisał: "Aż do niedawna jądra rozpakowywały się do /linux. Linus to zmienił i podoba mi się, że Marcelo zrobił tak samo, nowy sposób jest rozsądniejszy." Bill Davidsen zaś dodał: "Miejmy nadzieję, że w ważniejszych drzewach z poprawkami, takich jak -aa, czy -ac, też zostanie przyjęta ta konwencja. Nie mam problemów ze zmianami (swoje rzeczy trzymam właśnie w ten sposób), ale mam nadzieję, że to się rozpropaguje."

Nowa migawka jądra linux/x86-64 opartego na 2.4.19 została opublikowana. Aby uzyskać więcej informacji zobacz: http://www.x86-64.org

Pełen tarball: ftp://ftp.x86-64.org/pub/linux/v2.4/linux-x86_64-2.4.19-1.tar.bz2 (ciągle jest uploadowany/podsyłany, niedługo ukaże się na serwerze)

Łatka dla standardowego 2.4.19 z kernel.org ftp://ftp.x86-64.org/pub/linux/v2.4/x86_64-2.4.19-1.bz2
55331b0973fe86549102b0ca720be109 x86_64-2.4.19-1.bz2

Lista zmian:

Integracja z ostatecznym 2.4.19.
Kilka małych poprawek oraz czyszczenie kodu.

Właśnie wysłałem Ci 6 ,,bitkeeperowych'' łatek dla układów serii i8xx:

ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-1.txt Ta łatka zawiera uaktualnienia pci.ids dla układów i8xx
ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-1.txt Ta łatka dostosowuje dokumentację i810_rng do tego, co jest w 2.4.19
ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-3.txt Ta natomiast dodaje zestaw definicji do pci_ids.h dla 82801E oraz dla 82801DB I/O Controller Hub PCI-IDS. Nie mogłem dodać ich wszystkich, dopóki dwie z nich, o niezbyt dobrych nazwach, znajdowały się już wcześniej w kontrolerach IDE. To jest powód dla którego łatka 5 i 6 to naprawia.
ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-4.txt Ta łatka aktualizuje moduł i810-tco do obecnego poziomu 2.4.19.
ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-5.txt Ta łatka naprawia definicję PCI-ID dla kontrolera IDE 82801DB.
ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-6.txt Ta naprawia definicję PCI-ID dla kontrolera IDE 82801E.

Linus odpowiedział: "Proszę, nie używaj ,,bk send'' w celu przysyłania mi łatek z bitkeepera. Są one całkowicie niemożliwe do odczytania a także trudniejsze do zaaplikowania niż pozostałe możliwości (zwyczajne łatki lub pull drzewa bk) i doprowadzają do tworzenia w mojej skrzynce odbiorczej listów z zupełnie nic nie znaczącym Tematem: linie, więc natychmiast je kasuję."

Ukazała się nowa wersja przeniesionego NTFS-TNG do 2.4. Ta wersja synchronizuje łatę zarówno z ostatnim sterownikiem NTFS -- 2.0.22 oraz z ostatnim jądrem Linuksa -- 2.4.19.

Łatę możecie pobrać z serwerów sourceforge. Więcej szczegółów pod adresem http://linux-ntfs.sf.net/downloads.html

W trakcie dyskusji Tomas Szepe zauważył: " czy nie byłoby użytecznym stworzenie dedykowanej strony z poprawkami do ostatniego, stabilnego jądra, gdzie ważne łatki (takie jak: poprawka personality w 2.4.18, poprawka oopsów samby w 2.4.18, czy też nadchodzące poprawki ide dla 2.4.19) byłyby publikowane? Znajdując odnośnik do takiej strony w Kernel FAQ ludzie po prostu nakładaliby łatki na swoje jądra, zamiast wysyłać listy na lkml, co spowodowałoby spadek liczby pokrywających się raportów o błędach oraz wyeliminowałoby konieczność czekania 6 miesięcy lub więcej na oficjalną łatkę naprawiającą dany błąd." Alan Cox odpowiedział: "Opiekowałem się czymś takim dla niektórych drzew 2.2. Jeżeli istnieje zapotrzebowanie, to mogę również stworzyć stronę z poprawkami na linux.org.uk dla drzewa 2.4.19. Jak na razie liczba poprawek będzie niewielka, więc łatwo będzie nad tym zapanować."

Zdenerwowany Felix Seeger zauważył, że jego myszka USB przestała działać po aktualizacji jądra do 2.4.19. Brad Harris wskazał mu, że w 2.4.19 pojawiła się nowa opcja konfiguracyjna, CONFIG_USB_HIDINPUT, która powinna zostać zaznaczona przy myszkach USB. Dodał: "Przeszukanie archiwum listy dyskusyjnej również by pomogło."

Pavel Machek wysłał krótką łatkę i powiedział: "Łatka umożliwia kompilację i właściwie jest prawidłowa, skoro i tak nie możemy zawieszać komputerów SMP. W przyszłości będziemy musieli coś zrobić z pozostałymi procesorami przy zawieszaniu." Ktoś spytał, która część kodu zapewnia, że zawieszanie nigdy nie zadziała na komputerze SMP. Pavel odparł: "To było zepsute i zostawiłem zepsute. Drugi procesor zabije proces zawieszający najprawdopodobniej na tyle szybko, że żadne dane nie zostaną uszkodzone." Ta sama osoba zaproponowała, aby kod programowego zawieszania uczynić zależnym od wyłączenia opcji CONFIG_SMP. Nie było odpowiedzi.

Linus, zrób, proszę:

bk pull http://linux-ntfs.bkbits.net/ntfs-tng-2.5

Dzięki!

Tym razem dość dużo poprawek różnych błędów. Mam komputer z dwoma athlonami i 3G RAM do testów, więc byłem w stanie znaleźć sporo wyścigów, rekursywnych blokowań i wyniikających z nich zakleszczeń.

Łata powinna rozwiązać również zgłaszany problem z błędami we/wy przy ntfs na loopbacku. Przynajmniej ja nie jestem w stanie powtórzyć tych błędów po tym, jak zoptymalizowałem barrier() w fs/ntfs/compress.c. Podejrzewam, że bez tej optymalizacji gcc dostaje szaleju...

Wolfgang Pichler podesłał informację o błędzie w kodzie HFS w jądrze 2.4.19, dodając, że jest to już czwarty, identyczny raport, który wysyła od czasu pojawienia się 2.4.12; Alan Cox odpowiedział: "Nikt nie opiekuje się HFS. Prawdopodobnie, cały ten kod zostanie usunięty przed pojawieniem się 2.6, chyba, że znajdzie się nowy opiekun i usunie istniejące błędy." Benjamin Herrenschmidt dodał: "Zauważyłem, że Al oszukał mnie po nałożeniu kilku poprawek blokad w HFS w 2.5. Jestem pewien, że potrzeba ich znacznie więcej, a ja mam plan, by naprawić kilka z nich, zarówno w 2.4 jak i w 2.5, tylko, że zawsze znajdowałem coś ważniejszego w czasie poświęconym przeze mnie linuksowi ;)"

Paul Mackettas wysłał łatkę i napisał: "Załączam łatkę, która pozwala na poprawną kompilację oraz działanie na PPC sterowników offb oraz atyfb. Łatka ta jest przeznaczona dla 2.5.30. Posiadam także łatki dla aty128fb oraz radeonfb, lecz są one bardziej rozbudowane i chciałbym nad nimi jeszcze trochę popracować." Nie było odpowiedzi.

Załączona łatka aktualizuje sterownik OSS Maestro3 w celu:

Zmian w obsłudze przerwań.
Dostosowania inicjalizatorów do standardu C99.

Ale Alan Cox powiedział: "To nie wystarcza. To musi używać blokad w stosunku do przerwań karty oraz innych, z góry źle zdefiniowanych (nota bene w 2.4) rzeczy, powodujących przestoje. Zakładając, że warstwa PM potrafi zająć się dzisiaj swoimi sprawami, ty próbujesz, co najmniej, założyć blokadę na kartę. Myślę, że jest to wystarczające dla maestro w większości przypadków. Nie ma zgodności co do pytania, czy kod wznawiający powinien kończyć się wywołaniem obsługi przerwań aby usunąć wszelkie przerwania pojawiające się podczas przestojów karty? - pytanie to jest także prawdziwe w przypadku 2.4." Koniec wątku (tm)

Tim Hocking wysłał łatkę i powiedział: "Łatka ta dodaje wsparcie dla systemów Cobalt w sterowniku nvram. W międzyczasie zostały wyeksportowane symbole nvram i wyczyszczone niektóre partie kodu. Zostanie to niedługo udostępnione za pośrednictwem bk, lecz pomyślałem, że jeszcze trochę ponarzekam nim je tam umieszczę ;). To jest kolejna z serii łatek, próbująca desperacko zsynchronizować nasze drzewa. Jeżeli wszystko będzie wyglądało w porządku, poproszę Marcelo i Linusa o uwzględnienie tych zmian. " Nie było odpowiedzi.

Christoph Hellwig nadesłał łatkę i napisał: "Ta łatka, przeznaczona dla 2.4.20-pre1, konwertuje /proc/partitions na interfejs seq_file, tak jak jest to w 2.5, co pozwala na rozszerzone statystyki dyskowe ,,sard-style'' zależne od CONFIG_BLK_STATS oraz wyłącza alternatywne sposoby zbierania tych danych dla zaoszczędzenia pamięci i mocy obliczeniowej." Kurt Garloff, autor oryginalnego kodu przepisanego przez Chritopha dodał: "Właściwie, to oczekiwałem na słowa ostrej krytyki w związku z użyciem kodu ifdef oraz chciałem napisać coś lepszego. Nauczyłem się w międzyczasie nie wkładania wysiłku w sprawy, co do których nikt mnie wcześniej nie poprosił... Twoja łatka wydaje się być dobra. Dzięki za jej przygotowanie."

Andries Brouwer zauważył, że /proc/partitions nie jest najlepszym miejscem na umieszczenie tych danych. Powiedział: " Być może /proc/partitions zniknie, zastąpione przez statystyki dostępne przez driverfs lub coś w tym stylu. Ale jak na razie /proc/partitions jest ciągle używane, planowane są także pewne zmiany wprowadzające łatwiejszą identyfikację urządzeń. Wprowadzanie ton śmieci do pliku, tylko dlatego, że ten plik już istnieje jest niezbyt ładne. Jeżeli potrzebujesz statystyk dyskowych, to dlaczego nie umieścisz ich w /proc/diskstatistics?" Christoph odpowiedział, że rozmaite narzędzia oczekują tych informacji w /proc/partitions, ale Andries stwierdził: " Zaśmiecasz oficjalne jądro ponieważ twoje narzędzia są zepsute? I łatwiejszym jest zaaplikowanie łatki na jądro, niż ewentualna ich naprawa? A do tego przeróbka tych programów zawiera się w zmianie nazwy jednego pliku? "

Gdzie indziej, Randy Dunlap również uważał, że te dane powinny znaleźć się w innym miejscu, na co Christoph odpowiedział: " Twoja sprawa, czy chcesz to zaimplementować. To jest interfejs używany przez wszystkich, wiekszych twórców dystrybucji od wieków, znajduje się on także w w serii jąder -ac. Jest on wspierany przez zestaw ,,niezałatanych'' programów realizujących testy wydajnościowe. Trzymałem tę łatkę dla tych kilku biednych duszyczek, które nie mogły używać tej funkcjonalności po uaktualnieniu do najnowszych źródeł z kernel.org."

Chris Wright ogłosił uaktualnienie Modułów Bezpieczeństwa Linuksa dla jąder z serii 2.5:

Projekt Modułów Bezpieczeństwa Linuksa dostarcza ogólnego środowiska do kontroli dostępu. Interfejs LSM umożliwia tworzenie reguł bezpieczeństwa w formie ładowalnych modułów jądra. Po więcej szczegółów zajrzyjcie na http://lsm.immunix.org.

łata 2.5.30-lsm1 opublikowana. Jest przeniesieniem na 2.5.30 i zarazem kontynuacją włączania w główne drzewo.

Cała łata lsm-2.5 (LSM i wszystkie moduły) jest dostępna tutaj: http://lsm.immunix.org/patches/2.5/2.5.30/patch-2.5.30-lsm1.gz

Listę zmian tej wersji można poczytać tu: http://lsm.immunix.org/patches/2.5/2.5.30/ChangeLog-2.5.30-lsm1

Drzewo LSM 2.5 BK można pociągnąć stąd: bk://lsm.bkbits.net/lsm-2.5

2.5.30-lsm1

włączenie w 2.5.27 (Greg KH)
włączenie w 2.5.28-30 (me)
łączenie plików w bk, aby poradzić sobie ze zmianami w głównym drzewie (Greg KH)
usunięcie deklaracji BUS_ISA (Greg KH)
dodanie opcji settime (Robb Romans)
SELinux: poprawki w kodzie mapującym PSID (Stephen Smalley)
uaktualnienie inicjalizacji do stylu C99 dla modułów zaślepiających (cap and dummy modules). (Adam)
Usunięcie wycieków pamięci w opcjach IPC LSM. (Stephen Smalley)
Poprawienie opcji file_lock. (Matthew Wilcox)
akutalizacja modułów wg zmian w opcji file_lock (me)
DTE: czyszczenie logiki (Serge Hallyn)
SELinux: czyszczenie tablicy sysctl (Chris Vance)
czyszczenie __FUNCTION__ (Anton Blanchard)
usunięcie atrybutu __exit z selinux_nf_ip_exit (me)

Nie było odpowiedzi, ale gdzie indziej, w temacie: [ANNOUNCE] 2.4.19-lsm1, ogłosił uaktualnienie LSM dla jąder z serii 2.4:

łata 2.4.19 lsm jest opublikowana. Zawiera poprawki i łączenie z aktualnym stabilnym drzewem Linuksa 2.4.

Cała łata lsm-2.4 (LSM wraz ze wszystkimi modułami) jest dostępna tutaj: http://lsm.immunix.org/patches/2.4/2.4.19/patch-2.4.19-lsm1.gz

Cała lista zmian dla tej wersji jest tutaj: http://lsm.immunix.org/patches/2.4/2.4.19/ChangeLog-2.4.19-lsm1

Stabilne drzewo LSM 2.4 BK można pociągnąć stąd: bk://lsm.bkbits.net/lsm-2.4

2.4.19-lsm1

włączenie poprzez 2.4.19-rc5 (me)
dokończenie łączenia z 2.4.19 (James Morris)
SELinux: poprawki w kodzie mapującym PSID. (Stephen Smalley)
Usunięcie wycieków pamięci w opcjach IPC LSM. (Stephen Smalley)
Poprawienie opcji file_lock. (Matthew Wilcox)
uakutalizacja modułów wg zmian w opcji file_lock (me)
dodanie opcji settime (Robb Romans)
usunięcie atrybutu __exit z selinux_nf_ip_exit (me)

Guillaume Boissiere podał odnośnik do swojej strony ze stanem z 7 sierpnia, pisząc: "W tym tygodniu zrobiło się fajowo kolorowo. Zaznaczyłem wszystkie rzeczy na po zamrożeniu na szaro. Jeśli coś opuściłem, dajcie mi znać. " Nie było odpowiedzi.

Keith Owens ogłosił, że pod adresem ftp://oss.sgi.com/projects/kdb/download/v2.3/ dostępne jest kdb v2.3 dla 2.4.18 i 2.4.19. Dodał: "Te łatki mają jakość kodu w stadium alfa, przeszły ograniczone testy. Kod klawiatury usb wywala się u mnie na ia64, ustaw CONFIG_KDB_USB=n, chyba, że umiesz naprawić ten problem." Nie było odpowiedzi.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	25 lip 2002 - 2 sie 2002	(11 posts)	Aktualizacja łatki zapewniającej blokowanie
2.	28 lip 2002 - 1 sie 2002	(27 posts)	Stan obsługi portu szeregowego w 2.5
3.	30 lip 2002 - 1 sie 2002	(5 posts)	Poprawki w stylu kodowania
4.	31 lip 2002 - 3 sie 2002	(36 posts)	Związek między Linuksem a POSIX
5.	31 lip 2002 - 6 sie 2002	(38 posts)	Obsługa dużych plików i systemów plikowych
6.	31 lip 2002 - 4 sie 2002	(7 posts)	Eksport informacji sterowników sieciowych do /proc lub gdzieś indziej
7.	31 lip 2002 - 1 sie 2002	(10 posts)	IDE w 2.5: ciąg dalszy opowieści
8.	1 sie 2002	(1 post)	Wydanie EVMS 1.1.0
9.	1 sie 2002	(1 post)	Wydano syscalltrack 0.73 ALPHA
10.	1 sie 2002	(21 posts)	2.5.30 ogłoszone; kolejne kłopoty ze sterownikiem portu szeregowego
11.	1 sie 2002 - 2 sie 2002	(3 posts)	Czyszczenie sterownika karty dźwiękowej CS4281 w 2.4 i 2.5
12.	1 sie 2002 - 5 sie 2002	(10 posts)	Łatki bez-MMU
13.	2 sie 2002 - 3 sie 2002	(6 posts)	Status obsługi laptopów Toshiby w 2.5
14.	2 sie 2002	(1 post)	Stan ogólnego sterownika RTC dla 2.5
15.	2 sie 2002	(1 post)	User-Mode Linux dla 2.5.30
16.	2 sie 2002 - 6 sie 2002	(10 posts)	Konwencja rozpakowywania archiwów ze źródłami
17.	3 sie 2002	(1 post)	Nowa migawka Linux/x86/64 z 2.4.19
18.	3 sie 2002	(4 posts)	Uaktualnienie i8xx dla 2.5.30; Polityka BitKeepera
19.	3 sie 2002	(1 post)	Przenoszenie NTFS do 2.4
20.	4 sie 2002 - 5 sie 2002	(6 posts)	Strona z poprawkami dla jąder 2.4
21.	4 lip 2002	(2 posts)	Zmiany w opcjach konfiguracyjnych USB w 2.4
22.	4 lip 2002	(4 posts)	ACPI i programowe zawieszanie
23.	4 sie 2002	(1 post)	Poważna aktualizacja NTFS w 2.5
24.	5 sie 2002	(3 posts)	Stan HFS w 2.4 i 2.5
25.	5 sie 2002	(1 post)	Stan sterowników offb i atyfb w 2.5/PowerPC
26.	5 sie 2002	(2 posts)	Stan sterownika dźwięku Maestro3 w 2.5
27.	5 sie 2002	(1 post)	Wsparcie dla Cobalt w sterowniku NVRAM
28.	6 sie 2002 - 7 sie 2002	(7 posts)	Stan /proc/partitions w 2.4 i 2.5
29.	6 sie 2002	(2 posts)	Uaktualnienia LSM dla 2.4 i 2.5
30.	6 sie 2002	(1 post)	Strona ze stanem jądra z 7 sierpnia
31.	7 sie 2002	(1 post)	Uaktualnienie kdb w 2.4
32.	7 sie 2002	(1 post)	Uaktualnienie MatroxFB w 2.5

Kernel Traffic #179 For 2002/08/12

By Zack Brown

Translated By: Damian Wojslaw , Maja Królikowska , Paweł Kot and Robert Święcki

1. Inicjalizacja portu szeregowego

2. setserial API

3. /dev/ttyS, /dev/ttySA, /dev/ttyCL, /dev/ttyAM, itp

Kernel Traffic #179 For 2002/08/12

By Zack Brown

Translated By: Damian Wojslaw , Maja Królikowska , Paweł Kot and Robert Święcki

1. Inicjalizacja portu szeregowego

2. setserial API

3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, itp

3. /dev/ttyS, /dev/ttySA, /dev/ttyCL, /dev/ttyAM, itp