On 01/06/2022 07:03, J.F wrote:
>> Nie. Jesli masz dużo ramu, to po co coś gdzieś mapować. Masa OSów
>> działała bez tego.
> Chocby dlatego, ze procesy maja te same adresy dla roznych pamieci.
> forka zrobisz i co?

Masa OSów nie ma forka ;) Zerknij choćby na eCos.

>>> , protekcje
>> Jeśli ma być "bezpieczny". Ale nie musi.
> Wielozadaniowy to w zasadzie musi :-)

Mało który *mały* system embedded jest w ogóle preemptive. Za to pełno
cooperative/event.

Ogólnie to nie tak, że poważne rzeczy da się robić tylko na poważnych
systemach z grep i apt-get. Małe kontrolery, nie obciązone masą
skomplikowanych detali, bywają łatwiejsze w ogarnięciu przy formalnej
weryfikacji/certyfikacji niż Unix-like.

PS. Amiga była preemptive i nie miała protekcji pamięci. A to nie był
system embedded tylko bardzo duzy i skomplikowany OS, choć w czasach
przedinternetowych. Nie naciskałbym, że "musi mieć protekcję".
Protekcja/separacja procesów jest raczej zagadnieniem bezpieczeństwa a
nie funkcjonalności, ale jeśli jesteś juz w zakresie, gdzie uzywa się
fork, to w zasadzie to już nie jest embedded tylko normalny unix...

do góry

On 01/06/2022 06:58, J.F wrote:
>> On Tue, 31 May 2022 23:05:57 +0200, heby <h...@p...onet.pl> wrote:
>>> O Matko, tylko nie to badziewie.
>> On chyba miał na myśli tą segmentację od "segmentation fault".
> Bardziej taka, ze jest segment kodu, segment danych, segment stosu,
> i wszyskie niekreslonej wielkosci i jeszcze zmienne.

A po co te segmenty i w czym są lepsze w porównaiu gdy proces ma
najzwyczajniej pamięc RAM dla siebie, jak chce?

do góry

On Wed, 01 Jun 2022 01:09:51 +0200, Marek wrote:
> On Tue, 31 May 2022 23:05:57 +0200, heby <h...@p...onet.pl> wrote:
>> Nie. Jesli masz dużo ramu, to po co coś gdzieś mapować. Masa OSów
>> działała bez tego.
>
> Dużo tzn. ile? Chcesz zniknąć mmap??

Aczkolwiek

https://en.wikipedia.org/wiki/Mmap

"The original design of memory mapped files came from the TOPS-20
operating system.
mmap and associated systems calls were designed as part of the
Berkeley Software Distribution (BSD) version of Unix.
Their API was already described in the 4.2BSD System Manual, even
though it was neither implemented in that release, nor in 4.3BSD.[1]

Sun Microsystems had implemented this very API, though, in their SunOS
operating system.
The BSD developers at U.C. Berkeley requested Sun to donate its
implementation, but these talks never led to any transfer of code;

4.3BSD-Reno was shipped instead with an implementation based on the
virtual memory system of Mach.[2]"

To moze da sie bez mmap.
W dodatku ... wczesne implementacje nie mialy jakiegos limitu na
wielkosc pamieci uzywanej?
Np 16KB :-)
Wiec mozna normalnie wczytac do pamieci.

J.

do góry

On Wed, 1 Jun 2022 07:10:15 +0200, heby <h...@p...onet.pl> wrote:
> W embedded bardzo dużo, małe OSy nie uważają sztuczek z pamiecią za
> jakieś specjalnie krytyczne. Cała rodzina FreeRTOS, uCLinux, eCos,
> rózne
> klony MDSOS i pewnie Xdziesiąt innych.

IMHO nazywanie tego OSem tak jak nazywanie świnki morską.

--
Marek

do góry

On Wed, 1 Jun 2022 07:17:33 +0200, heby <h...@p...onet.pl> wrote:
> Ogólnie to nie tak, że poważne rzeczy da się robić tylko na
> poważnych
> systemach z grep i apt-get. Małe kontrolery, nie obciązone masą
> skomplikowanych detali, bywają łatwiejsze w ogarnięciu przy
> formalnej
> weryfikacji/certyfikacji niż Unix-like.

Tak, ale niebo tym jest dyskusja. Atlantis nie pyta o małe
kontrolery.

--
Marek

do góry

On Wed, 1 Jun 2022 07:18:52 +0200, heby <h...@p...onet.pl> wrote:
> A po co te segmenty i w czym są lepsze w porównaiu gdy proces ma
> najzwyczajniej pamięc RAM dla siebie, jak chce?

Właśnie po to by bronić inne zasoby przed tym jego *jak chce*.

--
Marek

do góry

On 01/06/2022 09:46, Marek wrote:
>> W embedded bardzo dużo, małe OSy nie uważają sztuczek z pamiecią za
>> jakieś specjalnie krytyczne. Cała rodzina FreeRTOS, uCLinux, eCos,
>> rózne klony MDSOS i pewnie Xdziesiąt innych.
> IMHO nazywanie tego OSem tak jak nazywanie świnki morską.

A jednak to OS. W końcu mówa cały zas o embedded, bywa, że kiepski
filesystem, memtop i put/get na ekran to już OS na dużych komputerach.

do góry

On 01/06/2022 09:49, Marek wrote:
>> Ogólnie to nie tak, że poważne rzeczy da się robić tylko na poważnych
>> systemach z grep i apt-get. Małe kontrolery, nie obciązone masą
>> skomplikowanych detali, bywają łatwiejsze w ogarnięciu przy formalnej
>> weryfikacji/certyfikacji niż Unix-like.
> Tak, ale niebo tym jest dyskusja. Atlantis nie pyta o  małe kontrolery.

Raczej pyta o "małe". Współczesne gołe linuxy to gigabaty dysku i
gigabajty ramu i to na SAM9 raczej nie ruszy, ogólnie w grę wchodziły by
tylko jakieś prosto lutowalne SoC jak choćby procesory Hixxxx stosowane
w rejestratorach kamer czy wynalazki z okolic bardziej przyjaznych dla
hobbysty S3C2440, ale one wszystkie są obarczone problemami z żałosną
dokumentacją i zerowym wsparciem w porównaniu z Pi.

Można mieć unix-like experience bez protekcji pamięci. W zasadzie, jesli
to system zabawkowy, to nie ma dużej różnicy dla hobbysty. "Muszę mieć
koniecznie Linuxa z forkiem" może być złym kierunkiem bo zaczną się
problemy które są cięzki i nieistotne jednocześnie.

do góry

On 01/06/2022 09:54, Marek wrote:
>> A po co te segmenty i w czym są lepsze w porównaiu gdy proces ma
>> najzwyczajniej pamięc RAM dla siebie, jak chce?
> Właśnie po to by bronić inne zasoby przed tym jego *jak chce*.

Do tego służy stonicowanie.

Segmentacja to był bardzo, bardzo zły pomysł. Obecnie w poważnych
systemach nie używana (czytaj: olewana) bo generuje tylko kłopoty bez
wyraźnych zysków.

do góry

środa, 1 czerwca 2022 o 10:05:23 UTC+2 heby napisał(a):
> On 01/06/2022 09:49, Marek wrote:
> >> Ogólnie to nie tak, że poważne rzeczy da się robić tylko na poważnych
> >> systemach z grep i apt-get. Małe kontrolery, nie obciązone masą
> >> skomplikowanych detali, bywają łatwiejsze w ogarnięciu przy formalnej
> >> weryfikacji/certyfikacji niż Unix-like.
> > Tak, ale niebo tym jest dyskusja. Atlantis nie pyta o małe kontrolery.
> Raczej pyta o "małe". Współczesne gołe linuxy to gigabaty dysku i
> gigabajty ramu i to na SAM9 raczej nie ruszy, ogólnie w grę wchodziły by
> tylko jakieś prosto lutowalne SoC jak choćby procesory Hixxxx stosowane
> w rejestratorach kamer czy wynalazki z okolic bardziej przyjaznych dla
> hobbysty S3C2440, ale one wszystkie są obarczone problemami z żałosną
> dokumentacją i zerowym wsparciem w porównaniu z Pi.
>
> Można mieć unix-like experience bez protekcji pamięci. W zasadzie, jesli
> to system zabawkowy, to nie ma dużej różnicy dla hobbysty. "Muszę mieć
> koniecznie Linuxa z forkiem" może być złym kierunkiem bo zaczną się
> problemy które są cięzki i nieistotne jednocześnie.

Bez protekcji pamięci nie będzie unix-like tylko jakiś taki wymysł typu amigaos.
A OP nie chce "systemu zabawkowego", tylko system, na którym zadziała Linux.
Linux, a nie ucLinux czy amigaos.

Na temat tego, co stosować w embedded i czy lepszy Linux - jako "gorszy" OS,
np. bez realtime, ale za to z kupą softu - czy też coś innego, np. lepsze
jako OS (ale i gorsze, bo jednozadaniowe, np. eCos - bardzo fajny, ale to nie ledwo
co OS, raczej biblioteka)
ale bez oprogramowania - można długo dyskutować - ale tutaj jest to zdecydowanie nie
w temacie.

do góry