Budowa własnego linuksowego komputerka

Ale w Unixie to podstawa :-)

Preemptive byl tez wczesny Windows :-)

Jak masz komputer ogolnego przeznaczenia, na ktorym maja dzialac rozne programy z roznych zrodel, a nawet i produkcja wlasna uzytkownikow, to musi :-) A teraz jeszcze wirusy, internet, szpiegowanie :-)

Mowa o li/unixie.

J.

Jak masz uprawnienia.

Napisać lepszy kod. Przkroczenie 2MB/8MB na stosie jest oznaką bardzo źle napisanego kodu.

Wytyczne? To się ma we krwi ;)

Jeśli rekurencja, to tylko ogonowa. Zwykłymi wywołaniami bez rekurencji bardzo trudno przekroczyć stos w normalnym programie.

Naprawdę duże apliakcja, takie DUŻE DUŻE nie maja problemu z działaniem na stosie kilku MB. Są najzwyczajniej poprawnie napisane.

Segmentacja miała za zadanie ułatwić widzialnosc większego obszaru RAMu dla procesora 8086, który tak naprawdę jest lekko odpicowanym 8-bit

Nie, segmentacja. Dodanie dodatkowego "offsetu adresu" do normalnych adresów. Potem dorobiono do tego ideologię i workaroundy (że niby pozwala na pracę wielu maszyn wirtualnych, ochrania dostep, itp śmiesznosci). Pierwotnie jedyne co chcieli osiągnąc to przekroczyć 64kB bez zrywania z 8-bit. Co im się udało w prześmieszny sposób (A20). Reszta to paniczne szukanie jak to jeszcze bardziej popsuć.

To był 8080 z doszytymi segmentami, z punktu widzenia programisty. Róznica taka, zę mój Atari 65XE przełączenie banków miał w hardware na płycie, a 8086 w procesorze. Ot, postęp i profesjonalizm.

MC68000 nie potrzebuje segmentacji. Pojawił się na rynku chwile po 8086.

Z jakiejś przyczyny ludzie do dzisiaj dorabiają idiotyczne ideologie jaka ta segmentacja jest super i potrzebna do czegoś.

Niewiarygodne. Czasami wcinam popkorn oglądając takie dysputy, to lepsze niż kabaret.

Nie. Do prawidłowej pracy biblotek współdzielonych przy separacji procesów wymagana jest translacja adresów i to dość swobodnie, w różnych miejscach pamieci wirtualnej w różne miejsca pamieci fizycznej. Segmentacja nic to nie pomoże, a tylko przeszkadza.

Można ją zrealizować bez MMU, tylko mało wydajnie.

Win do 3.11 był cooperative. Pierwszy domowy Win z preemptive to 95. Dokładnie 10 lat po Amidzie i Sinclair Ql.

Nie. To kwestia bezpieczeństwa. Nie mueisz go mieć aby dalej mieć użyteczny system.

uCLinux to nie Linux ;)? Wystarczy że zgodny z POSIX. To czy masz w nim paging czy nie, w sumie nie musi być wiadome dla aplikacji. Nie ma to znaczenia.

Nie bardzo czuje jak. Jest program, ma kod, ma dane, ma gdzies zapamietane adresy tych danych, i nagle to trzeba zduplikowac.

Kod moglby zostac ten sam, ale co z adresami w pamieci?

A, ok, pomylilo mi sie. Ale preemptive byly tez chyba widowsy 3.x, o ile uruchamiane na 386.

A co to za uzyteczny system, ktory nie wiadomo kiedy wyleci, z winy jednego programu :-)

Wirusy sa stare :-)

J.

Ale nie mowie o 8086, tylko o 80286. Tryb "protected". Rozwineli skrzydla w segmentacji, i to juz byla konstrukcja 16-bit. Ktore zreszta przestalo wystarczac, wiec na smietnik :-)

Ale tam nie miales "offsetu adresu", tylko przełączanie stron pamieci.

Z uwagi na niedorozwoj MMU tylko zgrubne, np jedna wymiena strona

Jakiegos "offsetu adresu" mozna by sie dopatrzec w Keil C na 8051.

I moze cos bylo w 80251 - tego nie znam.

Tak. Ale tryb protected 286 dzialal inaczej - zawartosc rejestru segmentowego nie byla sumowana do adresu jak 86, tylko stanowila indeks po tablicy (deskryptorow) segmentow. Kazdy segment mial swoj poczatek w pamieci, dlugosc, flagi protekcji. Nie wiem, czy nawet jakiejs namiastki pamieci wirtualnej nie dalo sie na tym zrobic.

Ale to chyba cos piszesz o trybie rzeczywistym. Bo tryb protected nie byl stososowany z uwagi na niekompatybilnosc z programami na MS-DOS.

A tryb protected 286 ... niby fajny, niby ma mozliwosci, ale segmenty tylko 64KB, i setki problemow z tym zwiazane, jak danych jest wiecej niz te 64KB.

No wlasnie - atari mialo ubogie stronnicowanie na plycie, wraz ze zwiazanymi z tym klopotami, 86 mialo w miare wygodne ofsety w adresie.

A potem pamieci bylo w komputerze pojawilo sie 4GB pamieci, zaczal sie problem dla procesorow :-)

Zrobilismy procesory 64 bit i znow nie trzeba segmentacji :-) I to raczej na długo :-)

Jesli mowimy o 286/386, to miala pewne zalety. Tylko 286 - za pozno, 386 - prawie niepotrzebne, a tez w praktyce - zc czasem ograniczajace.

Ale taka segmentacja

Dwie rzeczy:

ale

Win3.11 jest cooperative, co nie było niczym specjalnie dziwnym, jabłka też były, jakoś przeoczyli rewolucje siedząc dalej w nakładce na DOSa.

Być może były jakies protezy pod spodem, któe pozwalały odpalać kilka Win na raz (gdzieś to widziałem) i byc może były preemptive, ale nie natywnie w Win.

To nie ma znaczenia. To czy Ci wyleci sterowanik silnika respiratora w procesorze z MMU czy bez MMU jest mało istotne bo w obu wypadkach jesteś w d... To tylko może nieco zmniejszych poziom katastrofy, ale nie zapobiega jej. Zaryzykuje, że ważniejsza jest jakośc kodu niż to, czy jest chroniony w systemie *zamkniętym*.

Tak naprawdę ochrona ma sens dopiero w czasach malware. Wczesniej była fajnym ficzerem, ale niekoniecznie krytycznym, a przez dziesięciolecia olewanym na wszelkie sposoby przez twórców OSów.

Wirusy które robią coś uzytecznego, online, są w miarę nowe.

A w dawnych czasach, posiadanie "protected MMU win95" oznaczało tylko, że trzeba było zawołać ze 3 wywołania WinAPI więcej, żeby uzyskac admina. To żałosny system był, protekcja pamieci to pic na wodę w tamtych czasach. W zasadzie jako taką uwagę przyłożono dopiero w lini NT, a linia 9x była robiona na odpiernicz się.

Dalej, są miejsca (embedded) gdzie protekcja/stronicowanie pamieci nie ma wielkiego znaczenia i gdzie można stosować systemy które wyglądają jak Unix, jesli ktoś potrzebuje. Wymaga to poświęcenia kilku detali, ale one nie są krytyczne.

Uświadomiłem sobie, że gdybym jednak miał się bawić z uCLinux, to jest jeszcze jedna opcja sprzętowa, stojąca gdzieś na pograniczu retro i współczesności. Procesory DragonBall, stosowane m.in. w Palmach (zanim ten producent przeszedł na ARMy od TI i Intela). Z jednej strony klasyczny rdzeń 68k, z drugiej obudowa TQFP oraz trochę zintegrowanych peryferiów.