On 08/01/2021 22:42, Maciej Sobczak wrote:
>> Taki producent odpowiednika STM32 ale opartego o rdzeń RISC może ściąć
>> cenę swoich cpu o dolara, powiedzmy. A to robi różnicę kiedy ich
>> sprzedajesz setki milionów, choćby jako sterowniki dildo i szczoteczek
>> do zębów.
> Ale przecież do tego już mają rdzenie.

Nie wiesz jakie mają kryteria. Jak dildo ma 40 programów i trzeba tak
pod 1Ghz FPU do tego?

> Texas ma MSP430

I sprzedają go jako IpCores coby sobie ASICowy SoC dorobić na około?

> To po co jakiś RISC-V?

Bo pewnego dnia Texas zatrudni na CEO Balmera, który znowu będzie rzucał
krzesłami?

Od jakiegoś czasu jest tendencja aby w miarę mozliwości nie zamykac się
ze swoimi projektami za bardzo. RISC-V to jest taki "opensource ARM".
Tak jest postrzegany. W razie jak na stanowisku CEO ARMa stanie świr,
mamy się gdzie ewakuować.

>> POSIX w embedded nie jest dobry.
> Nadal nie napisałeś, dlaczego.

Wiele systmów embedded:
a) nie ma plików
b) nie ma procesów
c) nie ma rurek
d) nie ma sygnałów
e) nie ma konsoli
f) a wniej interaktywnych poleceń

Ale ma 40 programów w dildo, albo 20 programów w respiratorze. W tym
drugim nawet formalnie weryfikowanych.

POSIXa w jakiejś implementacji ciężko będzie formalnie weryfikować, on
sam z siebie jest bardzo kiepski i mocno chaotyczny, oraz *NIE DO TEGO*.

>> Osobiscie wolałbym aby mój respirator niekoniecznie pracował na POSIXie.
> Na pewno nie chcesz, żeby opracował na FreeRTOSie, bo to ma poziom poniżej
amatorskiego.

Jednak wolę dalej FreeRTOSa nad POSIXa w respiratrorze, jesli już mam
wykitować z powodu OSa. Może sygnał przyjdzie w wątku z obsługa, a może
nie. POSIX? Nie, dziękuję.

> Ale ponieważ POSIX to jest tylko API a nie implementacja, to dlaczego nie?

Bo POSIX jest niezwykle trudny do weryfikacji. Z powodu komplikacji
swojego API.

> Mogę mieć dobrej jakości implementację

Możesz. A masz?

> z interfejsem POSIX. Nadal nie napisałeś niczego, co by temu przeczyło.

Weryfikacji formalnej by przeczyło. Z tego powodu czasem wybiera się
takie cuda na kiju jak jadra formalnie zweryfikowane (L4) i dziwaczne
metody kostrukcji scalaków.

Niekiedy, aby dostać jakiś konkretny certyfikat, musisz wykazac że dany
kawałek softu jest *dobrze* napisany. To kłopotliwe pojęcie, ale fakt że
wsadziłeś POSIXa do migania diodą lub kontroli oddechu może być powaznym
problemem w odpowiedzi na pytanie czy jest dobrze napisany.
Najzwyczajniej możesz nie dać rady jej formalnie udzielić. Dlatego
istnieją znacząco mniejsze systemy w któych masz na to jakąś szansę.

> Przykładowo, dobrej jakości systemem do embedded z interfejsem POSIX jest QNX.
> W szczególności, jest używany w systemach medycznych:
> https://blackberry.qnx.com/en/software-solutions/emb
edded-software/medical
> Więc jednak masz POSIX w urządzeniu medycznym. I dobrze.

Tak, istnieją systemy, narzędzia, cores certyfikowane. Nie ma problemu
aby były zgodne w jakiejś częsci z posix. Nic tak nie powoduje ulgi
doczesnej jak to że na moim respiratorze można zrobić fread z EINTR i
jest na to 15 ifów, a miało być 16.

>> Ale musisz mieć abstrkację. Masz, prawda? Jak byś inaczej mógł
>> to testować. Wiec musisz mieć.
> Przecież napisałem, że mam. Nazywa się POSIX.

Nie, to tylko kilka implementacji. Abstrakcja to nie jest.

>> Zaznajom się np. z Qt.
> Już mnie kiedyś chciałeś do tego zachęcić, ale słabo wyszło.

Nie namawiam, to tylko przykład co to jest abstrakcja na OS a nie
abstrkacja na rodzię OSów.

>> POSIX nie jest przenośny. Istnieje masa systemów z nim niezgodnych.
> Ręce opadają, nic nie rozumiesz.
> To nie POSIX ma być przenośny, tylko programy napisane pod to API.

Staje się wtedy tak samo nieprzenośne jak implementacja POSIXa. Na
przykład sa nieprzenośne na to i tamto.

> I zapewniam, że takie programy są przenośne pomiędzy systemami, które ten standard
implementują.

Czyli wąska grupa unixo-podobnych + duperele.

> Np. kod, który napisałem na Linuksie zadziałał od ręki na QNX.

A na freeRTOS? A na Windows CE?

Ok, ustalmy wobec tego że masz program *częściowo* przenośny. Tak lepiej?

> Właśnie na tym polega ta przenośność.

Nie. Ale może takie masz warunki pracy, w których interesuje Cie
przenośnośc z Ubuntu na NetBSD i wtedy POSIX faktycznie można uznać za
jakiś rodzaj abstrakcji. Ja nie mam takiego komfortu. Nie tylko ja.

>> Zaś wszystkei zgodne maja mała użytecznośc w embedded. POSIX jest do
>> stacji roboczych a nie migania diodami lub kontroli oddechu. Naprwadę,
>> nie potrzebujesz parentpid i fopen w respiratorze.
> Czyli dalej nie rozumiesz. Kto powiedział, że system ma mieć wszystkie funkcje?

Czyli nie jest zgodny z POSIX?

> Chodzi o to, że jeśli już ma np. funkcję inicjalizującą mutex, to niech ta funkcja
się nazywa pthread_mutex_init a nie ourMutexCreate.

Wycinasz przenośność na nieposixy.

> I jeśli system ma tylko 10 takich funkcji, to niech one się nazywają tak jak 10
funkcji z POSIX.

Nie, to już za daleko. Przecieka Ci implementacja przez abstrkację.
Dotyczy ona nie tylko nazw, ale przede wszystkim sposobu użycia. W sumie
bez znaczenia czy masz pthread_mutex_init nazwany dupa. Istotne jest że
w innym systemie (niezgodnymz POSIX) może w ogóle nie itnieć inicjacja
poza miejscem deklaracji, albo istnieć przyjmująca paramter resursive.
Itd itp. Przeciekanie POSIXa do kodu to nie tylko nazwy, to sposoby ich
używania.

Dlatego masz class MyMutex a nie void MyMutexInit(). To drugie
faktycznie nic by nie dało.

> zrobić mu unit-testy na innym systemie, np. na Linuksie, bo akurat taki jest
łatwiej dostępny.

A na windowsie?

>>> Albo korzystam ze standardów. Takim standardem jest POSIX.
>> Dalej nie pojmujesz że posix nie jest abstrakcją.
> Dalej nie przeczytałeś nawet pierwszego zdania z Wikipedii na ten temat. A dałem
linka.

Przeczytałem. Zmartwie Cie równiez. Na codzień piszę kod na POSIXie i
Windowsie *jednoczesnie*. Powiedzmy że mam zielone pojęcie gdzie POSIX
jest przenośny. Powiedzmy że nieco powyżej średniej, mam to pojęcie.
Nijak nie udało mi się zawołać funkjci Posixowych w Windowsie.
Najwyraźniej Wikipedia pisze od rzeczy lub nie pojmujesz o co chodziło
autorom.

>> Abstrakcją jest
>> MyTools::MyMutex a nie pthread_mutex.
> To jest abstrakcja na abstrakcję.

To jest abstrakcja na więcej implementacji OSów niż tylko POSIX.

> Też tak robię - ale to jest dodatkowy koszt

Kosztuje mnie absolutnie 0 czasu w runtime, absolutnie 0 czasu w
pisaniu. Ba, jest tańszy niż POSIX bo mogę używać RAII, więc robie mniej
błedów emulując ręcznie RAII, tak jak chce POSIX.

> I teraz masz milion firm robiących systemy embedded i każda z nich robi wrapper
MyTools::MyMutex. Dlaczego?

Aby się uniezależnić od OSa. Aby móc przeprowadzić unit testy. Aby móc
łatwiej znaleźć błedy. Aby szybciej pisać kod. Aby łatwiej go czytać.
Aby łatwiej go refaktorować.

Zgadnij dlaczego mamy (wreszcie) std:: z obsługą wątków, i to nie jest
POSIX like API. Najwidoczniej ktoś kombinuje jak ja - abstrakcja na OS.

> Ile jest interesujących systemów w użyciu, nawet wliczając te dziadoskie typu
FreeRTOS? No ile?

Co najmniej kilkanaście. Twoje POSIXy, Win32/64, mikroskopijne RTOSy,
dedykowane dziwadła jak L4 i systemy pisane pod zagadnienie, np. do
lotów kosmicznych. I pewnie masę, których nie wymieniam, bo przecież
znam je tylko z tego że się obiły o uszy.

> To zobacz teraz, jaki jest stosunek kosztów: milion firm robi własne abstrakcje do
abstrakcji

Które kosztują, zwyczajowo prawie nic i dzięki temu, że sa pisane z
myslą o czymś nowoczesniejszym niż kompilatory z lat 70, pozwalaja
dodatkowo zredukować koszta pisania kodu, używając nowocześniejszych
technik generujacych mniej błedu. std::lock_guard jest nieskończenie
lepszym wyborem niż ręczne dziubdzianie mutex lock/unlock w posixie.

Nie robią własnych. Wiele z tych abstrakcji jest już napisanych:
boost/std i masa pomniejszych dupereli.

> , bo w przybliżeniu 2-3 systemy koniecznie musiały mieć ourMutexCreate

Zniknąłeś pozostałe zalety.

>. Czyli sumaryczny koszt tych wszystkich abstrakcji jest większy

Jest prawie zerowy. Przykładowo moja abstrakcja na rurki, zajeła mi 2h
do napisania i otestowania i od lat nie zmieniłem w niej bajta. Ta sama
funkcjonalność, reimplemntowana ręcznie kończy się deadlockiem bo ktoś
zapomniał ponowić ::read, bo wyleciał EINTR.

Koszta takich bugów są niebotyczne, bo wylatują tylko przy pełni
księżyca w Kambodży podczas monsunów. Po to owijamy, między innymi,
POSIXa w dodatkową abstrakcję wysokopoziomową, aby chronić się od
popełniania w kółko tych samych błedów tego dziwdowskiego interfejsu.

Zauważyłeś ile jest makr które "ułatwiają" pracę z funkcjami POSIXowymi?
To dlatego, że to jest wyjątkowo żałosne API i nawet najbardziej
zatwardziali unixiarze w końcu poddali się, wrapując te klocki w makra.

> To jest choroba naszej branży.

Nie. Pisanie na wysokim poziomie nie jest chorobą.

>> Abstrakcją może byc też Qt
> Ale czemu sobie żałować? Zróbmy abstrakcję na to też.

Oczywiście że się robi i na to abstrkację. Chcesz aby po Twoim kodzie
latały QString czy std::string? Co jest bardziej niebezpieczne?

Wybór może być biznesowy. Przykładowo kilka lat temu zamieszanie z
licencjonowaniem Qt spowodowało że "ludzie" poważnie zastanowili się czy
warto się od Qt uzależnić. I zauważyli że część abstrakcji z Qt można
znaleźc w boost/std.

> Przecież nie wszystkie frameworki są zgodne, prawda?

Nie są. Dlatego najlepiej oddzielić wartwę logiki od wartwy GUI aby w
razie czego "łatwo" GUI wymienić. To rodzaj sztuki, w prewnym sensie
robienie abstrkacji na GUI uważam za znacznie trudniejsze niż na OS.

> A co jak management zdecyduje, że zmieniamy Qt na coś innego?

To mam do przepisania jakieś 10% kodu, często tylko poprawienia.
Pozostały jest abstrakcyjny, przetestowany, nic się w nim nie zmienia.

> I teraz, jeśli programiści nie są idiotami, to pójdzie sprawnie, bo mają
abstrakcje, tak?

Nie, bo używanie Qt jest mocno zaraźliwe. Znacznie bardziej niż uzywanie
POSIXa. Wiec, o ile można część apliakcji skompilować w oderwaniu od Qt
(np. modele i częsciowo kontrolery) to już widoki będą wymagały wymiany.

Ale dalej, poprawna higiena ratuje 90% apliakcji.

> Wszystkie Twoje argumenty można tu zastosować.

Tak, Qt było przykładem jak wygląda abstrakcja na OS 3-rd party, a nie
wzorzec w dyskusji jak ją robić. Co napisałem wyraźnie. Uzycie Qt jako
abstrakcji to wybór biznesowy i niekoniecznie poprawny wszędzie i zawsze.

> [POSIX]
>> Przeczytałeś cos nie na temat. To jest abstrkacja do konkretnej rodziny
>> systemów.
> Konkretnej? Nie, żadnej rodziny tam nie było. Niektórych systemów w ogóle jeszcze
nie było, jak ten standard powstał.

I jakimś trafem mało który system suwerena ten standard implementuje,
podobnie w embedded OSa może w ogóle nie być, ba, może być napisany na
miejscu, do potrzeb. Nikt nie będzie implementował dziadowskich
koncepcji z POSIXa tylko dlatego że jest jakiś "standard" pochodzący z
mainframes.

>> W tej rodzinie nie ma FreeRTOSa ani Widnowsa CE, a są one w
>> embedded używane.
> No są. Niestety. Bo po co być zgodnym ze standardami, skoro można mieć - *beż
żadnej wartości dodanej* - ourMutexCreate?

Pisałem juz kilka razy o tej wartości dodanej. W sprawie zgodności z
POSIxem udaj się do MS. Zaznaczam, ze mimo lat dziubdziania Cywina i
ostatnio samego MS, POSIXa w windowsie nie zobaczysz, są fundamentalne
problemy z faktem że posix to nie przemyslany standard, tylko zbiór
aktualnie działajacego stanu jakiegoś wiekowego UNIXa, zamrożony i
nazwany "abstrakcją", pełen debilizmów i workaroundów.

> Ale o to można obwiniać tylko autorów tych systemów.

Zgadza się, jednak z jakiejś przyczyny WinApi, mimo stwojej śmieszności
w tak wielu kwestiach, nie ma kompletych bzdur w np. obsłudze pipes, jak
jest w unixie. Nie ma sygnałów wyskakujących w dowolnym wątku i
kopiących programistę prosto w dupę. Itd itp. Może jednak WinAPI było
bardziej przemyślane i nie po drodze im z POSIXem. To co, postulujesz
nie używać Windowsa w programowaniu bo niezgodny z tym zbiorem głupich
rozwiązań nazywancyh POSIX i oferujący swój własny zbiór głupich
rozwizań nazywanych WinAPI? A może jednak odciąc się od obydwu, co?

> POSIX jest standardem. QNX spełnia ten standard. FreeRTOS nie spełnia tego
standardu. Co zrobić.

Odciąć się abstrakcją.

>> Co najwyżej na wąską
>> grupę bardzo podobnych systemów, o nikłej uzytecznosci w embedded.
> Nadal czekam na wyjaśnienie, dlaczego nie do embedded.

Bo mało kiedy potrzebujesz mieć procesy, rurki, pliki w systemie
embedded. A jak ich nie masz, to nie masz POSIXa.

> Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest.

Bo jest nieprzenośne na inne embedded.

> To ciekawe bardzo. Funkcja się inaczej nazywa i już nie nadaje się do embedded.

Tak, właśnie odkryłeś na czym polega abstrakcja w wyjaśnieniu dla
przedszkolaka.

> Kurdę, muszę uważać, jak funkcje nazywam.

Dokładnie tak, jesteś na własciwym trope. Dodatkowo jeśli dodasz że
musisz uważać jakich typów są zmienne, jakich flag używasz itd itp to
szybko dojdzieszdo tego co to jest *prosta* abstrakcja na system
operacyjny. Tylko nie zakładaj że to koniec, dalsze tematy są bardziej
skomplikoane, ale do ogarnięcia. Tak, trzeba zacząć od uszelniania
szamba, aby POSIX nie przeciekał do kodu, a potem małymi krokami usuwasz
kod supportujący dziwactwa i przenosisz go do wspólnych miejsc i jesteś
już o krok od abstrakcji w której nie ma supportu dla EINTR czyli
przeciekania szamba.

>> Abstrakcja na systemy operacyje jest wysokopoziomowa. Tam gdzie nie
>> wiadomo czy mutex to int, handle, pointer czy foo.
> Właśnie tak jest w POSIX.

Dokładnie, nie czyni to z niego jednk abstrakcji na Windows.

>> Pewnego dnia januszowy RTOSik zostanie zamieniony na mirkowy CE bo taki
>> się zwidziało właścicielowi biznesu. Jesli Janusz nie był iditiotą to
>> zmiana na to CE może być mało bolesna.
> Niestety nie jest to zgodne z moimi obserwacjami. Zmiana jednego systemu POSIX na
drugi system POSIX może być mało bolesna, ale zmiana OurRTOS na TheirRTOS to większy
problem, bo jak już ktoś miał gdzieś standardy, to zwykle w różnych, niezależnych
kierunkach. Wtedy to nie jest kwestia taniego wrappera.

Nikt tu nie pisze o *darmowej* migracji. Owszem, napisałem niedawno o
zmianie kompilatora w makefile, ale to dotyczyło rekompilacji kodu na
Macu z x86 na ARM, kiedy API systemu się nie zmienia, zmienia się tylko
cpu i ABI. Wiele projektów embedded też będzie miało łatwo, bo nie
zależą od CPU.

Zmiana ma być mało bolesna. Przepisanie kilku adapterów nie kosztuje
mało, ale na pewno taniej niż przepisanie całego kodu zasranego
odwołaniami do POSIXa i logiką z EINTR.

> Zwłaszcza, jak to tego dołożymy stos TCP

To tego POSIX nie załatwił? A to niegrzeczny!

>. Np. popularnym partnerem dla dziadoskiego FreeRTOSa jest dziadoski LwIP. To jest
dopiero duet, wszystko wtedy opada.

Nie miałem przyjemnosci, chętnie sprawdzę na ile jest rozsądniejszy od
impelemntacji z unixów. Bo ta, moim skromnym zdaniem, wyznacza jednak
poziom podłogi. Nie da się gorzej.

>> Pamiętaj o czym rozmawiamy: stwierdziłeś że zmiana procesora to nie
>> tylko zmiana makefile, tylko bardzo ciezka rzecz.
>> No więc to cieżka rzecz, jak się ma dziadowski kod.
> Jeszcze cięższa, jak się nie ma kodu.

Nie wydaje mi się, aby taki był temat dyskutowania.

> O tej możliwości też cały czas mówimy, bo to jest realna możliwość.

Pewnie, ktoś musi stworzyc puste repo na nowy projekt, jednak w dużych
firmach jest super jak można go zapełnić gotowcami z poprzeniego
projektu. I to wszystko dzięki abstrakcji. O dzieki Ci, abstrakcjo!

> Ale trochę rozwlekła nam się ta dyskusja zrobiła, więc może skupmy się: dlaczego
POSIX nie jest dobry do embedded?

Napisałem wyżej. Zawiera śmieci, które nie są użyteczne, oraz sam z
siebie jest wyjątkowo dziadowski.

> Dlaczego funkcja, która się nazywa na literkę "p" nie nadaje się do embedded a
funkcja robiąca dokładnie to samo, ale na inną literkę się nadaje?

Aby nie musieć zmieniać jej nazwy w 100 miejscach kiedy zmieniasz OS,
poprawiajac przy okazji kod supportujacy też 100 razy.

Aby udostepnić wysokopoziomy interfejs uzywajacy wspólczesnych jezyków
zamiast POSIXowego, kieskiego API.

Aby umożliwić unit testy.

Aby odstrzec że czasem ta funkcja nie może być wywołana w innym systemie
i trzeba pakować ją do wyższysz struktur języka.

Pisałem to chyba ze 100 razy. Prosze, nie pytaj więcej, jestem zmęczony.

> "U mnie działa."

U mnie też. Przeciez wymieniamy doświadczenia. Ty masz jakieś, ja mam
jakieś.

Ja nie mogę spobie pozwolić na komfort "tylko POSIX" bo inaczej trace
połowę klientów, dzięki temu wypracowałem metody uszczelniania szamba
POSIXa i WinAPI tak, aby nie przeciekały do kodu.

Ty najwidoczniej możesz sobie pozwolić na ogarnieniae abstrakcji w
POSIXowym OSie.

Stąd różne opinie. Moja w tym wypadku jest mojsza i tyle.