On 10/01/2021 16:56, Maciej Sobczak wrote:
> Osobiście nie mam problemu z określeniem "POSIX subset".

Super. To wiele wyjaśnia.

> Więc chcę, żeby januszowe RTOSiki implementowały "POSIX subset"

A jeśli sa z nim niezgodne, tak fundamentalnie? Na przykłąd są
cooperative-multitasking a nie preemptive? Co wtedy? Nie pisać softu na
cooperative bo ktoś 50 lat temu zrobił dziadowskie api?

>> Każda konfiguracja, inna niż *wszystko*, nie jest już POSIXem.
> I w konsekwencji program, który nie korzysta ze *wszystkiego* nie jest programem
POSIXowym?

Nie. Bo to nie działa w tą stronę. Musisz mieć pełny POSIX aby nazywać
to "POSIX". nie musisz używać całego PISOXu aby mówić "potrzebuje POSIXU".

> A program, który nie korzysta ze *wszystkiego* z biblioteki standardowej C++ nie
jest programem w C++?

Nie, to najzwyczajniej głupota.

Ale kompilator nie majacy RAII nie jest kompilatorem C++. To analogia w
tą samą stronę co "POSIX bez pipes". POSIX bez pipes to nie POSIX.
Możesz sobie użyć tego "subset". To dalej nie POSIX.

>>> I niepotrzebnych rzeczy nie ma, zwłaszcza w systemach embedded.
>> To po co tam wciskać POSIXa skoro używa się 5% jego api?
> Dokładnie po to, co opisano w pierwszym zdaniu na wikipedii, któro nadal uporczywie
ignorujesz. Po to, żeby zapewnić "compatibility between operating systems".

Które nie działa, w szczególności embedded.

Mam wrażenie że tuptasz ze złością nózką krzycząc "wszystko powinno być
POSIXem" a tu bach, prawie nic w emebdded nie jest, i tylko troche, w
większym świecie, jest.

>>> Sam sobie zaprzeczasz. "W jakiejś implementacji"?
>> Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior.
> Czyli tego określenia też nie rozumiesz. Może podaj przykład.

Proszę:

1:

Mam jedną rurę. Jedne deskryptor do zapisu i jeden do odczytu.

Zrób dwa wątki piszące do tego samego deskryptora do zapisu.

Określ jakie dane będą lądować po drugiej stronie.

2: Zwołaj ::read i loscią dancyh większą niż SSIZE_MAX (dozwolone).

> Ciekawe, że UB nie przeszkadza w osiągnięciu celu, którym jest przenośność. Tak
jest też w C albo w C++.

Nic dziwnego, nie używa się konstrukcji tego typu w poważnym sofcie.

>> Jeśli z ::read może wylecieć 20 róznych stanów to nie jest to dobre API.
> To, że może, to nie znaczy, że musi (patrz subset)

Oczywicie, jak widzę szybko redukujesz swojego POSIXa do jakiegoś
stabilnego iface, tak trzymaj!

>> Który to SafeRTOS jest bez wątpienia POSIX like. I w dodatku bazujący na
>> API FreeRTOS :D Ależ to życie jest złośliwe.
> Jest bazujący na API FreeRTOS

OK, czyli nie POSIXie.

> z takiego powodu, że ktoś chce zarobić na tych wszystkich ludziach

Albo może są inne powody? Na przykład komplikacja?

>, którzy zaczęli robić projekty na januszowym FreeRTOS

A ci co zaczeli na januszowym Linuxie? Ich też będzie obrażał że mogli
od razu na pełnej profesce HP Unix? A na ch?

> Wtedy płacą cenę (w formie licencji za SafeRTOS) za januszostwo i olewanie
standardów.

Albo najzwyczajniej wliczyli to w projekt. Startujemy na OS, a potem
przejdziemy na CS.

> A gdyby tak zaczęli, od początku, zgodnie ze standardami?

To by nigdy nie wystarowali.

> To nie byliby skazani na tą jedyną ofertę "nie do odrzucenia".

Ale oni nie są to tego stopnia głupi żeby nie mieć abstrakcji na to
FreeTROS. Naprawdę, ludzie nie są aż tak głupi.

> To się nazywa ten vendor-lockin, o którym pisałeś.

Nie, poza jakimiś kiepsko napisanymi aplikacjami które uzależniły się od
FreeRTOSa albo POSIXa, to ogólnie nie jest problem.

> Tutaj, oczywiście, wykażasz się odpornością na to zjawisko, bo napisałeś sobie
wrapper.

I kompiluje sie pod kilkoma rodzinami OSów.

> Ja się wykażę odpornością, bo piszę pod standard.

I kompiluje się pod jadna rodziną OSów prawie nieprzydatną w embedded.

>>> Od kiedy API utrudnia weryfikację? W jaki sposób?
>> W taki sposób:
>> switch ( fooResult )
>> {
>> case Error:
>> case OtherError:
>> case UlikelyError:
>> case SomethingBroken:
>> case DoItAgainPlease:
>> case MabyeLater:
>> case OKButNotQuite:
>> case Almost:
>> case NeedRest:
>> case Interrupt!:
>> }
> Dalej nie rozumiesz. Nikt nie każdy RTOSowi zwracać wszystkich możliwych błędów.

Ale musisz mieć ich obsługę. W końcu piszesz coś komaptybilnego z POSIX,
prawda? A POSIX mówi że "Almost" wyleci w piątek po 16. A ty nie masz
case. To nie przejdzie przez review.

> Standard mówi, jakie błędy można zwrócić, a nie jakie trzeba.

A pisanie zgodnie ze standardem nie ma takiego komfortu. Musisz obsłuzyć
wszystko, inaczej nie przejdziesz certyfikacji.

A jak zmienisz OS to już w ogóle w dupie jesteś. Bo tam akurat "Almost"
zwraca się też we wtorek. Bo może.

> Więc jeśli jakiś RTOS ma tylko 3 stany w swojej implementacji, to te trzy stany
mogą się nazywać tak jak w POSIX a nie inaczej "bo tak".

Innymi słowy nie tylko jesteś API-locki ale jeszcze
implementation-lockin. Coraz lepiej.

> Słowo klucz: "subset".

Słowo klucz: zmiana na inny OS.

>> A program napisany w Qt jest jeszcze bardziej przenośny od tego w POSIXie.
> Albo i nie. Systemów POSIXowych jest chyba więcej, niż tych wspieranych przez Qt.

Jeśli liczysz że Debian 3.1 i Debian 3.2 to rózne systemy, to faktycznie.

> W szczególności, wspomniany przeze mnie TI-RTOS (od Texasa) ma interfejs POSIX a
raczej Qt tam nie zadziała.

A ktoś go tam potrzebuje?

PS. Qt miało też własnego OSa.

>> Na przykład obok jest CreateMutex biorący 3 parametry.
> pthread_mutex_init ma argument pthread_mutexattr_t, w dodatku przez wskaźnik, więc
możliwości funkcjonalne tego są właściwie nieograniczone. Może być NULL dla
zachowania domyślnego. Nie ma problemu, żeby w tej jednej funkcji zmieścić zarówno
bezargumentową inicjalizację, jak i specjalne ficzery.
> Właśnie o to chodzi w standardach.

Nie, ktoś te 3 parametry w CreateMutex musi ustawić. Kto to zrobi?

To prosta funkcja, a już problemy.

Jak przejdziesz do named pipes, to okaże się że API POSIXa i API Win
jest fundalemntalnie rózne, nie tylko pod kątem paramterów, ale wzorca
użycia.

>>> Do przenośności wystarczyłby POSIX
>> Nie chcesz takiej przenośności. POSIX to gówno. Pod wieloma względami to
>> zamrożone workaroundy z lat 70tych.
> Nie napisałeś niczego, żeby to potwierdzić.

Ależ napisałem wielokrotnie. Jeden rzut oka na funkcje ::read wystarczy:

EINTR The call was interrupted by a signal before any data was read;

Innymi słowy ::read zajmuje się dodatkowo obsługą sygnałów. Nie kojarzę
innego, równie popsutego API. "Ta funkcja rysuje kwadraty i spuszca wodę
w kiblu, jednocześnie".

>>> , gdyby twórcy januszowych RTOSików
>> A twórcy januszowych Windowsów?
> Również. https://www.integrasources.com/blog/windows-ce-end-o
f-life-medical-devices/

Ale pytam o Windowsy współczesne.

> Tak to jest jak się uwierzy komuś, kto olewa standardy.

Niezupełnie, CE było bardzo popularnym systemem przez wiele lat.

>>> Dlatego chciałbym mieć *jedną* implementację mojej klasy MyMutex. A nie kilka
różnych.
>> Nie ma takiej potrzeby. I tak masz dwie co najmniej. Przecięz masz
>> jeszcze mocka do testów.
> Mocka muteksa? A po co? Normalny muteks po prostu działa, bo... no właśnie, bo jest
standardowy.

Wiec nie da się go łatwo testować.

>>> Jeśli trzeba puścić unit testy, to Cygwin jest do tego jak najbardziej
wystarczający.
>> Ano właśnie, znalazłeś adapter do systemu operacyjnego. Bardzo milutko.
>> Nie sprzedasz jednak aplikcji napisanej na cygwinie,
> Znowu manipulujesz. Aplikacja jest napisana na jakiś system embedded.

Albo nie.

> A konkretnie na POSIXowy system. Sprzedam ją bez problemu. To, że być może testy
nieformalne (!) były puszczane na Cygwinie, nie ma żadnego znaczenia.

Ma, pewnieważ cygwin zachowuje się inaczej niż każdy inny system
POSIXowy, głównie z uwagi na to że jego emulacja POSIXa na windowsie
jest słaba.

>> pozerkaj jak bardzo
>> wieli ból dupy mają twórcy cygwina z powodu niekompatybilnosci POSIXA z
>> WinApi
> Nie jest to problemem dla *subsetu*, którego używam w projektach embedded.

Ten "subset" pojawił się stosunkowo niedawno w tej dyskusji, i chyba
całe szczęscie że znalazłeś ten workaround, inaczej była by bida.

>> POSIX to jest taki standard z przypadku. Microsoft
>> nie ma śadu powodu aby go używac.
> Za to ludzie, którzy użyli Windowsa CE, mają teraz powody, żeby się przenosić gdzie
indziej.

Przez wiele lat nie mieli tych powodów.

>>> Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być
>> Idealista.
> Inżynier. :-)

O tak.

>> Tupanie nogą że świat nie jest POSIXowy i na siłe uzależnianei się od
>> tego kipeskiego API nie jest specjalnie profesjonalne.
> Specjalnie nie jest, jest po prostu racjonalne, o ile w ogóle trzeba na jakimś API
polegać.

Można nie polegać, o czym cała ta dyskusja. Mam wrażenie że ten POSIX to
taka kwestia religijna. Trzeba na nim polegać bo na czymś trzeba. No
więc nie, można być ateistą i nie wierzyć w ani jedno OS API.

> Natomiast specjalnie nieprofesjonalne jest na siłę nieprzestrzeganie standardów,
"bo nie".

To nie mój wybór. Suweren wybrał *również* inne systemy.