Budowa własnego linuksowego komputerka

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

Dlaczego?

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:

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 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 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ść".

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.

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

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

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

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

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

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.

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

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

Nie powinno być problemu z *kompilacją*.

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.

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

Raczej wątpię.

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

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.

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.

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

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

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

Mowa ogolnie czy o DOS?

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

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.

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.

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

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.

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 :-)

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

J.

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.

Oczywiście.

Stosy w typowych systemach operacyjnych są śmiesznie małe. Tak około

Nie stanowią problemu, choć nie mogę wykluczyć, że bardzo źle napisany program może marudzić. S*it happens.

To nie ma związku z segmentacją. Segmentacja to tylko dziadowski system przełączania banków pamięci z 8-bit maszyn, zaszyty w procesorze. Tak, troche przesadzam, ale prawdę mówiąc niewiele. Jak zerkniesz na to jakie machnizmy były popluarne na Z80 i 6502 do ogarniania pamięcu >64k to niebezpiecznie blisko koncepcji segmentacji wylądujesz. x86 zrobił to tylko "lepiej" czyli skrajnie skomplikował proste zagadnienie adresacji pamięci a potem dodawał w kolejnych wersjach procesorów coraz to nowsze "usprawnienia w odpowiedzi na potrzeby rynku" które zakończyły się tym, że obecnie z tego nikt nie korzysta, bo to guano, zaprojaktowanie skrajnie bezmyślnie i psute iteracyjnie przez dziesięciolecia.

Czyli wyszło jak wykle, u Intela.

Bibliteki shared sa zazwyczaj kompilowane z kodem position independent (sprawdzić, czy to nie zabawkowy Windows) i znowu, to nie ma związu z segmentacją. Procesory bez segmentacji też ładuja te bibliteki w trybie współdzielenia i też je dzielą. x86 się do tego nie nadaje z powodu żałosnych problemów z kodem PI, ale już AMD64 tak.

Co zabawne, współdzielenie biblitek jest znacznie łatwiejsze w systemach bez ochrony pamieci (Amiga OS). I było powszechne w latach 80 w systemach bez MMU, co nie oznacza, że było rozsądne (fragmentacja była problemem).

Aleś sobie źródło znalazł. Piłeś, nie pisz. Tak jak o kompilacji jako działaniu programu... Chyba że o emoticonach zapominasz. Ale nawet jeśli, to kiepski żart.

Pierwsze z brzegu. Potrzebujesz więcej?

Ale zdajesz sobie sprawę, że ta rada działa w obie strony?

Zdecydowanie. Tym bardziej że pochodzi z humorystycznej ksiązki "Understanding the Linux Kernel". Najwidoczniej autor nie czyta usenetu, bo by wiedział jak jest naprawdę.

Albo Ty nie czytałeś książki i/lub tego, co ja napisałem. W Linuxie stronicowanie jest podstawą, z segmentacji używane jest niedużo - i tylko to, co dobre. Można tak, bo to, co złe, ale niezbędne w segmentacji, załatwia - o wiele lepiej - stronicowanie. A samo stronicowanie jest segmentacją z wieloma segmentami o jednakowej (albo max. kilku ustalonych) wielkości segmentu. Załatwia całość OS, więc aplikacje w ogóle o tym nie muszą wiedzieć, chyba że wchodzą niuanse Harvard/Princetown.

Bardzo możliwe, że jedno z tych dwóch na pewno.

A co konkretnie jest dobre w segmentacji i używane?

Zdecydowanie łatwiej i szybciej sprawdzić, czy adres, z którego pobierane/zapisywane są dane, mieści się w granicach JEDNEGO segmentu (o danym adresie bazowym i długości), niż we wszystkich stronach. I czy atrybuty segmentu pozwalają na przeprowadzenie danej operacji. Zapewne rodzaj cache dla danych jednego segmentu danego typu (pewnie tego wskazywanego przez rejestry segmentowe) jest też w procesorze. A samą pamięć wirtualną robimy oczywiście na stronicowaniu, nie trzeba wywalać całych segmentów - lub kombinować z dzieleniem ich na kawałki.

I tego się uzywa?

I tego się używa?

I tego się używa?

W Linuxie na x86 tak - tak realizowana jest ochrona pamięci, zarówno kernel space / user space jak i separacja procesów. Po prostu dlatego, że 386 to ma.

Samo się używa, jak to cache. A atrybutów segmentu - oczywiście, do ochrony. Np. żeby nie pozwolić wykonać danych. Co i tak by mogło nie pójść z powodu cache, szczególnie w wieloprocesorowości.

Stronicowania chyba jednak na pewno tak. Znowu piłeś?

Zapytam na wszelki wypadek: sugerujesz, że Linux używa segmentacji do

Zgadnij ile procesorów na świecie ma segmentację. Zastanów się, również ostrożnie, jakie interesujace ficzery generuje segmentacja po stronie kodu asseblerowego. Podpowiem: podobne miewa architektura Harvard i pozostawiają traume taką samą jak powórnywanie pointerów pod DOSem.

Możesz przybliżyć nam po ch.. komu segmentacja w systemie Unixowym, który nie ma takowej segmentacji na ani jednej implementacji użytecznej do czegokolwiek?

Ja pytam nie o to, jak jest zworkaroudowane w procesorze bo tego nie wiemy. Czy Linux *używa* segmentacji do czegokolwiek użytecznego.

A czego ochrony? Jest coś dodatkowego do ochrony, czego nie chroni paging?

Ojej. To już nonexec bit w stronicowaniu się nie nadaje?

Zaznaczam też, że to relatywnie nowy ficzer, tak na marginesie.

Interesujące. Dalej mówimy o x86 czy sobie przeskoczyliśmy na jakies DEC Alpha z jego niespójnym cache?

Pytanie było o *segmentację*. To że się używa stronicowania, nie powoduje że segmentacja ma jakiekolwiek użyteczne funckcje.

Mam wrażenie, że troche się pogubiliśmy w dyspucie między segmentacją a stronicowaniem.

Pozwól więc, że wyklaruje: segmantacji się nie używa poza problem, że nie da się jej wyłaczyć, więc Linux zamiata ją pod dywan olewajac mniej więcej w 100%.

Stronicowania się używa.

Pisałeś że coś z segmentacji Linux używa.

Chciałbym wiedzieć *CO* używa. Głównie dlatego że 40 lat temu i dzisiaj segmantacja to jedne z najbardziej debilnych pomysłów w technologii CPU i mam nadzieje że autor będzie się w piekle przewracał.

Ale 386 ma tez ochrone pamieci na poziomie pamieci stronicowania.

A na poziomie segmentow ... nie wymaga to jawnego poslugiwania sie segmentami? A Linux chyba tego nie robi.

J.