Ideałem (tak żeby użytkownik nie musiał zgadywać czy ttyUSB0 to przejściówka RS-USB, czy może telefon) byłoby używanie znaczących nazw dla urządzeń takich jak telefon, a nie korzystanie z nazw przeznaczonych dla portów (np. ttyUSB). Żeby to osiągnąć, nie trzeba nawet "grzebać w plikach". Wystarczy, że wrzuci się w trakcie instalacji kilkulinijkowy plik dostarczony przez producenta urządzenia do katalogu /etc/udev. Przeszkodą jest tylko to, że producenci urządzeń tych plików nie dostarczają, tak jak robią to z windowsowymi plikami INF. Tutaj najbardziej prawdopodobnym wytłumaczeniem stanu rzeczy wydaje mi się lenistwo.
Sam podałeś sposób na odczytanie nazwy, nie wiem jeszcze tylko jak stworzyć listę urządzeń "szeregowych". Do tej pory wydawało mi się, że wystarczy wylistować ttyS*, ttyUSB* i ttyACM*, ale skoro nazwa może być dowolna to jest to za mało. Odczyt katalogu /sys/bus/usb-serial/devices/ daje tylko informację o urządzeniach podłączanych przez usb. Skąd jeszcze można wydobyć potrzebne informacje?
Ja bym stawiał raczej na 1% udział linuksa w rynku systemów "biurkowych".
Za mało albo za dużo, zależy jak na to patrzeć. Wszystkich plików związanych z urządzeniami i tak się nie znajdzie, bo by trzeba było przeczesać cały system plików, a to mogą być terabajty. Z drugiej strony katalog /dev może zawierać setki "martwych" plików urządzeń, takich które zostały stworzone, ale nie stoi za nimi żaden realny sprzęt. Tak jest w "klasycznych" instalacjach, niekorzystających z dynamicznego tworzenia plików.
A czy możemy założyć, że USB to jedyny dostępny podsystem "hotswap", w którym mogą pojawiać się i znikać urządzenia szeregowe? Jest jeszcze PCMCIA, ale tam też można odczytać katalog. W realnym pececie to już chyba koniec. Wszystko inne musi być podłączone do magistrali PCI (albo ISA) i wykryte przez startujący kernel albo moduł. Skoro tak, to zostaje ślad w dmesg. Można więc przegrepować dmesg zaraz po starcie systemu i być pewnym, że to się w czasie pracy nie zmieni.
Ale znowu najlepiej chyba zaufać systemowi udev i oprzeć się na tym, że dla wszystkich wykrytych urządzeń stworzył właściwe pliki. Tylko nie należy polegać na ich nazwach, lecz na ich właściwościach. Interesują nas pliki urządzeń znakowych (character), a nie blokowych (block). Polecenie "ls -l" pokazuje typ pliku. Pokazuje też "major number" i "minor number" urządzenia. Po nich wnioskujemy, czy są to urządzenia, które nas interesują (urządzenie szeregowe jest urządzeniem szeregowym wtedy i tylko wtedy, gdy kernel kojarzy je z numerami zarezerwowanymi dla urządzeń, które uzanjemy za urządzenia szeregowe).
Kwestia udziału jest trochę z boku. Sterowniki linuksowe jednak powstają, nie tylko w czynie społecznym, a producenci sprzętu coraz częściej dołączają katalog "linux" do nośnika z oprogramowaniem. Tylko sposób w jaki to robią, woła o pomstę do nieba. Wygląda to tak, jakby uważali, że jak ktoś używa Linuksa (obojętnie czy na biurku czy gdzie indziej), to o niczym innym nie marzy, jak tylko o edytowaniu emacsem plików konfiguracyjnych i o tworzeniu diwajsów mknodem. Nie zauważają faktu, że dostępne są w tym systemie metody [auto]konfiguracji urządzeń P'n'P o wiele doskonalsze niż w Windows (taka jest przynajmniej moja opinia wynikająca z obserwacji, a także z niniejszej dyskusji).
W każdej dystrybucji / kernelu? ;) Problem z Linuksem (z punktu widzenia developera) polega na tym, że mało co jest ustandaryzowane. W Windows dokładnie wiadomo, jak się zachowa każda wersja systemu po podpięciu nowego urządzenia, np. na USB. Te mechanizmy opisuje dość dokładnie Microsoft w dokumentacji MSDN. Obecnie wystarczy wspierać trzy wersje systemu: Windows 2000, Windows XP i Vistę
- i to pokrywa zdecydowaną większość użytkowników Windows na świecie. Dużo mechanizmów działa identycznie od lat więc i programy/sterowniki są w pewnej mierze dość uniwersalne.
A dla Linuksa jest wolna amerykanka. Kiedyś była książka "Linux hackers guide", traktująca właśnie o pisaniu sterowników (jeszcze w erze kernela
2.2 i 2.4). Czy teraz wyszło coś nowszego? Konkretne pytanie: skąd przeciętny developer ma czerpać obecnie informacje o niskopoziomowym działaniu Linuxa (bez rozwiązania ostatecznego czyli czytania źródeł kernela)? Czyli np. jak we własnym programie "zaczaić się" na podłączenie urządzenia przez USB?
Druga sprawa to program instalacyjny; powiedzmy, że wydajemy oprogramowanie komercyjne bez kodu źródłowego. Dla Windows wystarczy jeden plik .exe instalatora i każdy będzie zadowolony. A Linux? Ile dystrybucji tyle pomysłów - po co tak komplikować świat? Pliki .deb, .rpm, do tego konieczność wspierania kilku wersji biblioteki glibc.
Czekam z utęskieniem, aż pozostaną na placu boju 2-3 dystrybucje instalowane u 90% linuxiarzy. A może już teraz tak jest? Ubuntu, Fedora, OpenSuse i dalej długo nic.
To akurat nie było o kernelu. O udev było i o podobnych takich.
Bo jak są tylko trzy, to wystarczy wspierać trzy. Tym niemniej to właśnie w Windows zdarzało mi się, że po zainstalowaniu sterownika karty graficznej przestawał działać APM (komputer się nie wyłączał) a po odinstalowaniu działał znowu. Takich przykładów można wymienić więcej, ale nie chodzi o licytację (ja zresztą nie znam szczegółowo innych, plotek powtarzać nie lubię, a ten jeden pamiętam ze swoich nielicznych kontaktów z tym systemem).
Gdy padło stwierdzenie na temat "dalekiej od doskonałości obsługi USB w linuksie", spodziewałem się właśnie takiej argumentacji. Z tym to ja mogę się nawet zgodzić. Nie ma sterowników? Nie ma, bo nikt nie napisał. A nie napisał, bo mu się nie chciało, nie umiał, nie miał książki o hakowaniu kernela 2.6, niedobry producent krzemowego szpeju nie dał dokumentacji, itd. Tak rzeczywiście bywa, chociaż z drugiej strony dawno już nie spotkałem się z problemem, że czegoś nie mogę użyć pod linuksem, bo brakuje sterowników i absolutnie nikt z konkurencji nie produkuje czegoś podobnego, co jest wspierane.
Dyskusja poszła jednak w inną stronę -- że niby linux po ponownym włączeniu potrafi zamienić miejscami diwajsy, a taki Windows, to on nigdy, przenigdy. Bzdura, bo jest przecież dokładnie odwrotnie.
No ale przecież to i tak działa. I to całkem podobnie jak w Windows. To znaczy może tak działać. Ci, co wydają programy bez źródeł (np. AcrobatReader, GoogleEarth, drivery Nvidii etc) przeważnie robią to w formie jednego uruchamialnego pliku, który robi to co trzeba. Raczej nie słyszałem, by ktoś narzekał, że coś w związku z tym nie działa. A że istnieją jeszcze systemy administracji pakietami? No to fajnie, one się świetnie sprawdzają w praktyce, daleko lepiej niż execowe instalatory w Windows.
Może rzeczywiście już tak jest. A jeśli nie jest, to co to zmienia? Jest sto pięćdziesiąt dystrybucji, ileś wersji kernela, modyfikowanych i nie, glibców też trochę, programy kompiluje może 1% juzerów, reszta instaluje binarki. I jakoś to działa, rzadko coś się ze sobą gryzie. Ja mogę zapomnieć o tym APM i drajwerach do S3, mogę uznać, że jest pod tym względem tak samo jak w Windows. Ale tam są tylko trzy niemal identyczne mechanizmy działające od lat podobnie. To chyba bardzo dobrze świadczy o podstawach systemu, który musi działać w dużo trudniejszych warunkach.
Ja tam mogę przestać w każdej chwili, ale nikt mi tego jeszcze nie zasugerował (wiem, wiem, wszyscy mają mnie w killfajlu).
Ależ nie, nie wydawało się. Natomniast mnie się zdawało, że to zagadnienie dyskusja ominęła jako zbyt oczywiste. Myślałem, że wystarczyły krótkie wyjaśnienia, że rzecz związana jest ze sprzętem, nie z systemem. Dlatego nawet nie wspomniałem przykładu komputera (W95) losującego karty sieciowe.
To co może być tu ciekawe, to metody poprawiania konceptu P'n'P. Wciąż oczywiście jest tak, że Linux startujący z podłączonymi urządzeniami USB może zarejestrować je *SOBIE* przy każdym starcie inaczej. Ale ważne jest, że *MNIE* pokaże je zawsze tak samo.
Dobrze dzałający udev, do zjawisko dość nowe, gdy korzystał jeszcze z programu hotplug, jego działanie mogło być denerwujące. A dyskusja o nowych rzeczach może być interesująca. Pytałem, czy w Windows też się pojawiły jakieś nowe rozwiązania. Odpowiedzi nie poznałem. W to, że tam "dużo mechanizmów działa identycznie od lat więc nie ma z tym kłopotu", po prostu nie uwierzę. Na szczęście chyba nikt nie próbuje
Jeszcze raz napiszę: to system przydziela numerację i byłoby miło z jego strony, gdyby pamiętał co komu przydzielił. A co do W95 nie będę się wypowiadał bo to archeologia z mojego punktu widzenia.
Tak, jak to sobie ręcznie powpisujesz w rozmaite konfiguracje i skrypty. A zwykły użytkownik, co najwyżej zaklnie jak szewc.
No fakt. Byłoby miło. Ale nie każdy system tak robi. W opisanym wcześniej doświadczeniu system zapamiętał sobie jaką nazwę przydzielił karcie sieciowej o określonym MAC w pliku /etc/udev/rules.d/70-persistent-net.rules.
Ale Windows XP też nie pamięta jaki numer przydzielił karcie, więc następnym razem daje jej inny. Co gorsza, zupełnie innej karcie potrafi dać ten sam numer, co poprzedniej! Zapytałem, czy jest jakiś mniej archeologiczny Windows niz XP, który jest tak miły i zapamiętuje. Ale odpowiedzi wciąż nie znam. Jak nie dowiem się wcześniej, to w przyszłym tygodniu zobaczę jak się sprawy mają z Vistą i Seven.
Nie ja powpisuję, bo te konfiguracje i skrypty ktoś zrobił już wcześniej. A zwykły użytkownik... no cóż, ten system ma niewielki udział w ich rynku, większość z nich poszła kląć gdzie indziej.
Linuksiarzom daleko jeszcze brakuje do dokumentacji chociażby takiej jak udostępnia Microsoft o systemach Windows. Pomimo że wiele mechanizmów w Linuxie wcale nie jest dużo prostszych, a napisanie sterownika do jakiejś pośredniej warstwy wymaga przekopania źródeł kernela, demonów i pobocznych procesów. No ale w końcu nie ma się co dziwić: pracownikom Microsoftu zapewne płaci się za pisanie dokumentacji.
Prawda, już 22 października premiera siódemki. :) A na razie olewając powyższy system i wszystkie wersje 64-bitowe (XP i Vistę) traci się na większości rynków conajwyżej kilka procent klientów.
Mimo to zbyt blisko współpracujące z wieloma demonami, aby o nich też można byłoby zapomnieć. No a do tego w istocie niełatwo prześledzić na podstawie samych źródeł, co się właściwie dzieje w systemie po przykładowym podłączeniu urządzenia USB. Przez wiele plików trzeba się przekopać i to bez gwarancji sukcesu. Lepsze byłoby zdebugowanie zachowania kernela krok po kroku, chociażby w środowisku wirtualnym. Ale jakich do tego użyć narzędzi?
Od lat Microsoft próbuje wciskać taki kit ale to nie nam. Pierwszy z brzegu instalator małej aplikacji zrobiony przy pomocy np. NSIS jest 3x mniejszy niż pakiet .msi.
Taa. Jak skompiluję u mnie - to na innym komputerze nie zadziała bo cośtam. A to też Linux na 32-bitowym x86. W Windows rzecz niespotykana, trzeba bardzo się starać aby skorzystać z funkcji API dostępnej tylko np. w Viście.
Heh, w komercji właśnie o to chodzi, aby nie rozdawać źródeł. Spojrzałem właśnie do "gotowców" pod Linuxa: instalka Firefoxa jest w formacie .tar.bz2 (czyli żadne tam binaria tylko zwykłe archiwum), Thunderbird podobnie (.tar.gz), Adobe Reader pod Linuxa - pełen wybór (.bin, .tar.gz, .rpm, .tar.bz2, .deb), Eagle - do pobrania skrypt wspomagający instalację (sic!). Raczej nie chodziło mi o to, abym musiał dla Linuxa generować kilka różnych instalatorów.
Chyba z tego wszystkiego zacznę pisać w Javie - jeden uniwersalny format instalek (.jar) i binariów, a pójdzie tak samo pod każdym systemem. Oby się tylko trzymać najnowszej wersji JRE.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.