środa, 1 czerwca 2022 o 10:40:15 UTC+2 heby napisał(a):
> 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.

Segmentacja daje to samo co stronicowanie.
Bo stronicowanie to segmentacja z wieloma segmentami o tej samej wielkości.
Ma zalety, ale też wady - większe zapotrzebowanie na pamięć.
A w takim Linuxie (szczególnie na x86) masz i segmentację i stronicowanie -
wykorzystywane
są zalety jednej i drugiej metody.

do góry

wtorek, 31 maja 2022 o 23:06:56 UTC+2 heby napisał(a):
> On 31/05/2022 22:57, J.F wrote:
> > Ale mapowanie pamieci chyba powinien miec
> Nie. Jesli masz dużo ramu, to po co coś gdzieś mapować. Masa OSów
> działała bez tego.

Masa OSów pozwalała też na uruchomienie tylko jednego procesu na raz
i też "działała bez tego". Tylko kijowo.
Tzn. jak wystarczało to w porządku - ale często "wystarczało"
w takim sensie, jak mówił Henry Ford: "gdybym spytał moich klientów,
czego potrzebują, odpowiedzieliby, że szybszych koni".
Ja też długo puszczałem na 386 z 4MB RAM DOSa i się męczyłem,
żeby było wolnych 620kB pamięci "konwencjonalnej" - a obok megabajty puste leżały.
Były oczywiście protezy w rodzaju TSRów - które trzeba było usuwać,
żeby jakąś lepszą grę uruchomić.
Do dziś zachodzę w głowę, w czym był problem, że potrzeba 620kB, a 600kB nie
wystarczy.
Przecież pliki są na dysku...

No i jeszcze OS nie musi się męczyć, żeby program załadować w jakieś inne miejsce
pamięci
niż to, na jakie był skompilowany.
Choć hmm, czy DOS tak musiał robić? I tak był jednozadaniowy, a ew. drivery można
było ładować
na koniec pamięci, więc programy użytkowe zawsze mogły się ładować od tego samego
adresu
(żeby było trudniej, oczywiście nie mogło to być zero).
Oczywiście *.com można było relokować po różnych segmentach ;> (choć to raczej śmiech
przez łzy).

do góry

On 01/06/2022 10:52, Dawid Rutkowski wrote:
> Bez protekcji pamięci nie będzie unix-like

Dlaczego?

> A OP nie chce "systemu zabawkowego", tylko system, na którym zadziała Linux.
> Linux, a nie ucLinux czy amigaos.

W sensie, że protekcja pamieci jest niezbedna aby to był Linux;) ? Mi si
wydawało, że wystarczy mieć kernel Linux-like i już;) No może być
zgodnym troche z POSIXem.

Unix to płynne pojęcie... 68000 na ten przykład:

http://marc.retronik.fr/motorola/68K/68000/Unix_and_
the_MC68000_[BYTE_1986_12p].pdf

[...] The memory management primi-
tives in the UNIX system make no as-
sumptions about the sophistication of
memory management hardware avail-
able to them. UNIX systems have
been implemented with no memory
management and with sophisticated,
paged, segmented systems. Even a
memory protection scheme can be
dispensed with if the system being de-
signed is to be just an applications
engine. [...]

do góry

środa, 1 czerwca 2022 o 11:14:54 UTC+2 heby napisał(a):
> On 01/06/2022 10:52, Dawid Rutkowski wrote:
> > Bez protekcji pamięci nie będzie unix-like
> Dlaczego?

Chyba że rozumiesz "unix-like" jako "prawie jak unix", parafrazując reklamę.

Bez protekcji będzie to raczej dos-like.
Żeby coś nazwać unixem, a tym bardziej Linuxem, musi to przede wszystkim NIE MIEĆ
pewnych problemów, jakie zastosowanie unixa/Linuxa gwarantuje rozwiązać (oczywiście
zapewne pewnym kosztem).
Protekcja kernel space - user space to podstawa.
Protekcja między procesami w user-space - bardzo pożądana (poza wyjątkami
opisanymi w specyfikacji, umożliwiającymi IPC - ale TYLKO wtedy, gdy OBA procesy się
na to zgodzą).

Zaczynasz mówić jak mój kolega, który każde nowe zagadnienie omawiał tak:
"No, wszystko jest jasne. Jest tylko jeden bardzo duży problem."

To coś jak:
"Jedna rana stanowczo śmiertelna, ale pozostałe da się wyleczyć."

> > A OP nie chce "systemu zabawkowego", tylko system, na którym zadziała Linux.
> > Linux, a nie ucLinux czy amigaos.
> W sensie, że protekcja pamieci jest niezbedna aby to był Linux;) ? Mi si
> wydawało, że wystarczy mieć kernel Linux-like i już;) No może być
> zgodnym troche z POSIXem.

A co to jest "kernel Linux-like"?
Zaś zgodność z POSIX - zawracanie głowy oczywiście.
Tyle że do czasu, gdy chcesz uruchomić jakieś oprogramowanie napisane pod system
POSIXowy.

> Unix to płynne pojęcie... 68000 na ten przykład:

unix oczywiście jest o wiele bardziej "płynnym" pojęciem od Linuxa.
Linux zawsze miał ochronę pamięci.
Choć oczywiście jest na tyle elastyczny, że można kernel tej ochrony pozbawić.
Tylko że znów bardzo ograniczysz ilość oprogramowania, które na takim okrojonym
"Linuxie" uruchomisz.
Tzn. uruchomisz oczywiście, tyle że po fork procesy zaczną się dziwnie zachowywać ;>

Z unixów też mogłeś wyciąć ochronę i uruchamiać je na 68k - zresztą inaczej się nie
dało,
do pamięci wirtualnej trzeba było wziąć 68010.
Jak taki komputer miał 128kB pamięci to i tak wiele poza kernelem i jednym procesem
nie uruchomiłeś.
A to przecież i tak było dużo, ludzie liczyli na komputerach z 16kB - a nawet liczyli
na mniejszych
pamięciach, w 16kB to nawet miejsce na OS było ;>

Więc mogły być wersje "unixa" bez ochrony - ale to był "unix" w taki sam sposób jak
S/360 model 20
"należał" do S/360 (IBM zresztą ostro się w takich głupotach powtarzał, PS/2 model 30
to ta sama
historia - "prawie jak PS/2", tyle że nie miał ani VGA, ani MCA - oraz na 8086 nie
można było uruchomić OS/2).
Bo nawet PDP-11 miały ochronę.

Zadziwiającą maszyną był pierwszy macintosh, ze 128kB RAM, z czego 24kB zajmowała
pamięć obrazu
(nie mówiąc już o zajmowaniu przez wyświetlanie 1/4 czasu magistrali, procesor był w
HALT, bo nie miał cache).
Przecież tyle miał Spectrum 128kB (ech, czemu Sir Clive nie pomyślał, i nie dał w
spectrusiu prostego
bankowania + nie umożliwił wykorzystania drugiej połowy tych chipów, które kupował z
uszkodzonym jednym bankiem,
można by z każdego zrobić 80kB - albo mieć 64kB RAM działających z jedną szybkością)
czy komoda 128
(ten miał też Z80 ;)
Oczywiście szybko wszedł model 512kB - ale ta kula u nogi 128kB pozostała.
Tak jak było z S/370 - dwa pierwsze modele nie miały MMU - "bo tak" - ale następne
wszystkie już miały.
I mamy piękną "kompatybilność".

do góry

On 01/06/2022 12:01, Dawid Rutkowski wrote:
> środa, 1 czerwca 2022 o 11:14:54 UTC+2 heby napisał(a):
>> On 01/06/2022 10:52, Dawid Rutkowski wrote:
>>> Bez protekcji pamięci nie będzie unix-like
>> Dlaczego?
> Chyba że rozumiesz "unix-like" jako "prawie jak unix", parafrazując reklamę.

Rozumiem jako system oparty o POSIX i kilka innych dupereli na około. W
zasadzie, jeśli tak się naprawdę dobrze zastanowić, to protekcja pamieci
nikomu nie jest niezbędna, aby mieć Unixa.

> Bez protekcji będzie to raczej dos-like.

Nie, DOS-like to tylko gówniany filesystem, memtop i kilka funkcji do
printowania na ekran.

Główna róznica to wielozadaniowość i IPC.

> Żeby coś nazwać unixem, a tym bardziej Linuxem, musi to przede wszystkim NIE MIEĆ
> pewnych problemów

Zaryzykuje, że to Twoja definicja, subiektywna.

Wiele osób używa pojęcia "Unix" choćby tylko dlatego, że jest POSIX. W/g
tej definicji Windows jest troche POSIX bo sporo rzeczy pasuje, też ma
rury, a APi da się nagiąć co pokazuje cygwin i WSL. No i ma protekcję :P

> Protekcja kernel space - user space to podstawa.

E tam. Mało ważne, w prostym embedded praktycznie wcale.

> Protekcja między procesami w user-space - bardzo pożądana (poza wyjątkami
> opisanymi w specyfikacji, umożliwiającymi IPC - ale TYLKO wtedy, gdy OBA procesy
się na to zgodzą).

To dalej jest problem natury jakościowej/bezpieczeństwa a nie bycia lub
nie Unixem.

> Zaczynasz mówić jak mój kolega, który każde nowe zagadnienie omawiał tak:
> "No, wszystko jest jasne. Jest tylko jeden bardzo duży problem."

Niezupełnie. Pamietaj, że mowa o embedded. To nie system ktory ma
przejmować się bezpieczeństwem bo wszystkie apliakcje sa zaufane. Jedyne
co protekcja pamieci ułatwia, to że pad jednego programu nie zabija
innych. Ale to słabe rozróżnienie: jak Ci coś padnie w powaznym systemie
to i tak często jesteś w d... czy protekcja czy nie.

> A co to jest "kernel Linux-like"?

Taki np. uCLinux. Cholera wie czy to Linux czy nie. Ale w sumie, gdybyś
nie wiedział nic o kernelu, to nie poznałbyś.

> Zaś zgodność z POSIX - zawracanie głowy oczywiście.

Te małe linux-like bez MMU są jako-tako POSIX.

> Tyle że do czasu, gdy chcesz uruchomić jakieś oprogramowanie napisane pod system
POSIXowy.

Nie powinno być problemu z *kompilacją*.

> unix oczywiście jest o wiele bardziej "płynnym" pojęciem od Linuxa.
> Linux zawsze miał ochronę pamięci.

Chyba nie zawsze. O ile pamiętam, pierwsze wersje, ekperymentalne, nie
miały, lub nie działała poprawnie. Z reszt on chyba jest bazowany na
Minixie (tzn to taki żart) wiec puryści Unixowi nie nazywaj go Unixem.

A Minix to najczęsciej używany system operacyjny na świecie.

> Choć oczywiście jest na tyle elastyczny, że można kernel tej ochrony pozbawić.

I czy wtedy dalej jest Linuxem? Czym w zasadzie jest Linux że odkrojenie
MMU powoduje że już nie jest?

> Tylko że znów bardzo ograniczysz ilość oprogramowania, które na takim okrojonym
"Linuxie" uruchomisz.

Raczej wątpię.

> Tzn. uruchomisz oczywiście, tyle że po fork procesy zaczną się dziwnie zachowywać
;>

A niby czemu? fork bez MMU jest możliwy, tylko cieżki i nierozsądny.

> Z unixów też mogłeś wyciąć ochronę i uruchamiać je na 68k - zresztą inaczej się nie
dało,
> do pamięci wirtualnej trzeba było wziąć 68010.

No ale po co chcesz ją chronić? Masa systemów, nawet takich od których
zalezy Twoje życie, nie ma chronionej pamięci. To nie jest wyznacznik
Unixa ani Linuxa.

> Więc mogły być wersje "unixa" bez ochrony - ale to był "unix" w taki sam sposób jak
S/360 model 20
> "należał" do S/360 (IBM zresztą ostro się w takich głupotach powtarzał, PS/2 model
30 to ta sama
> historia - "prawie jak PS/2", tyle że nie miał ani VGA, ani MCA - oraz na 8086 nie
można było uruchomić OS/2).
> Bo nawet PDP-11 miały ochronę.

Ale on miał ochorną z innych przyczyn. Na przykłąd ktoś to projektował
jako wielodostęp.

Unix nie musi być wielodostepowy.

Ba, wiele linuxów embedded składa się z 1 apliakcji typu "kamera
sportowa" i nikogo nie obchodzi jakaś protekcja pamięci.


> Tak jak było z S/370 - dwa pierwsze modele nie miały MMU - "bo tak" - ale następne
wszystkie już miały.
> I mamy piękną "kompatybilność".

Raczej dowiedzenie faktu, że MMU to tylko element dajacy ficzery a nie
identyfikujący, zy komputer jest czy nie popędzany Unixem.

do góry

On Wed, 1 Jun 2022 02:03:40 -0700 (PDT), Dawid Rutkowski wrote:
> wtorek, 31 maja 2022 o 23:06:56 UTC+2 heby napisał(a):
>> On 31/05/2022 22:57, J.F wrote:
>>> Ale mapowanie pamieci chyba powinien miec
>> Nie. Jesli masz dużo ramu, to po co coś gdzieś mapować. Masa OSów
>> działała bez tego.
>
> Masa OSów pozwalała też na uruchomienie tylko jednego procesu na raz
> i też "działała bez tego". Tylko kijowo.
> Tzn. jak wystarczało to w porządku - ale często "wystarczało"
> w takim sensie, jak mówił Henry Ford: "gdybym spytał moich klientów,
> czego potrzebują, odpowiedzieliby, że szybszych koni".
> Ja też długo puszczałem na 386 z 4MB RAM DOSa i się męczyłem,
> żeby było wolnych 620kB pamięci "konwencjonalnej" - a obok megabajty puste leżały.
> Były oczywiście protezy w rodzaju TSRów - które trzeba było usuwać,
> żeby jakąś lepszą grę uruchomić.
> Do dziś zachodzę w głowę, w czym był problem, że potrzeba 620kB, a 600kB nie
wystarczy.

Apetyt rosnie w miare jedzenia :-)
Jest 600kB wolnego, to je uzywasz, a potem brakuje :-)

> Przecież pliki są na dysku...

Ale nie zawsze chcesz z nich korzystac.
Szczegolnie, jesli modelowa maszyna ma dwie dyskietki bez HD :-(

> No i jeszcze OS nie musi się męczyć, żeby program załadować w jakieś inne miejsce
pamięci
> niż to, na jakie był skompilowany.
> Choć hmm, czy DOS tak musiał robić?

Mowa ogolnie czy o DOS?

ładowal przeciez pod dowolny adres, pliki com byly bezadresowe,
exe relokowalne.

> I tak był jednozadaniowy, a ew. drivery można było ładować
> na koniec pamięci, więc programy użytkowe zawsze mogły się ładować od tego samego
adresu
> (żeby było trudniej, oczywiście nie mogło to być zero).

Moze sie nauczyli z CP/M, ze to nie jest dobry pomysl,
moze przejeli z CPM ladowanie na adres 100h ... i skorzystali z
segmentacji 8086, bo mozna.

> Oczywiście *.com można było relokować po różnych segmentach ;> (choć to raczej
śmiech przez łzy).

Masz na mysli ladowanie, czy "w locie", tzn w dowolnej chwili ?
Te rejestry segmentowe w 86/88 to nieglupia rzecz,
ale jak program rozwinie skrzydelka, to zacznie korzystac z wiekszej
ilosci RAM i bedzie mial gdzies absolutne adresy zapamietane.
"W locie" nie przesuniesz.

J.

do góry

On Wed, 1 Jun 2022 01:55:24 -0700 (PDT), Dawid Rutkowski wrote:
> środa, 1 czerwca 2022 o 10:40:15 UTC+2 heby napisał(a):
>> 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.
>
> Segmentacja daje to samo co stronicowanie.
> Bo stronicowanie to segmentacja z wieloma segmentami o tej samej wielkości.

No wlasnie - a poniewaz typowa segmentacja ma malo segmentow i czesto
duzych, to nie to samo niestety.

> Ma zalety, ale też wady - większe zapotrzebowanie na pamięć.
> A w takim Linuxie (szczególnie na x86) masz i segmentację i stronicowanie -
wykorzystywane
> są zalety jednej i drugiej metody.

Bo razem tez maja sens ... ale linux na x86 naprawde wykorzystuje
obie?
Unixy 32-bitowe segmentacji typu x86 chyba nie lubily, trzeba by API
modyfikować?
Na 286 mialoby to wiekszy sens, ale tam unix i tak ubogi.
Choc czyz nie zaczynal na 16-bit maszynach? :-)

J.

do góry

On Wed, 1 Jun 2022 01:52:35 -0700 (PDT), Dawid Rutkowski wrote:
> ś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.

Linux zadziala, tylko co to bedzie warte, jesli procesy nie bedą
wzajemnie chronione. No cóż, OP chce linuxa do własnej zabawy, bedzie
uzywal tylko zaufane programy :-)

> 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.

Jesli zarzutem jest brak realtime, to chyba jednozadaniowe nie są
alternatywą :-)

J.

do góry

On Wed, 1 Jun 2022 07:18:52 +0200, heby wrote:
> 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?

Sprawa jest taka, ze program unixowy ma swój kod, powiedzmy ze stały,
ma dane w pamieci, ktorych ilosc moze rosnac i ma stos, ktory tez moze
rosnąc.
I te dwa rosnące obszary stanowią problem, bo trzeba je jakos umiescic
w pamieci.
W dodatku Unix to system wielozadaniowy, wiec mamy wiele procesów,
kazdy z apetytem na pamiec. I z pożądaną wzajemną ochroną.

Nowsze programy ładują jeszcze dynamicznie biblioteki, wiec trzeba
wiecej nowego miejsca.

Cos mi chodzi po glowie, ze dawne systemy wykorzystywaly
dwa najstarsze bity adresu do wskazywania "segmentu", a prosty
MMU mogl relokowac obszary. Moze nawet w procesorze bylo to zaszyte.

J.

do góry

On 01/06/2022 10:55, Dawid Rutkowski wrote:
> Segmentacja daje to samo co stronicowanie.
> Bo stronicowanie to segmentacja z wieloma segmentami o tej samej wielkości.
> Ma zalety, ale też wady - większe zapotrzebowanie na pamięć.
> A w takim Linuxie (szczególnie na x86) masz i segmentację i stronicowanie -
wykorzystywane
> są zalety jednej i drugiej metody.

Oczywiście.

https://pl.wikipedia.org/wiki/Segmentacja_pami%C4%99
ci

[...] Segmentacja jest rozwiązaniem bardzo eleganckim, lecz na tyle
kłopotliwym, że obecnie praktycznie się jej nie stosuje [...] Aby
segmentację uczynić niewidoczną, Linux wykorzystuje jeden segment o
adresie bazowym 0x0 i rozmiarze 4GB.[...]

do góry