Autor: trashcan man (trash_at_military.milnet.pl)
Data: Mon 25 Dec 2000 - 03:56:51 MET
On Fri, 22 Dec 2000 21:37:25 +0100, Witold Wilk wrote:
> ma zwiazek z windows :) Inaczej - mamy sobie kernela windy. Mamy tam cos
> rozwiazane tak "jak komunikowac sie z dyskami twardymi". Ten modul jest
> zly - wolno chodzi, itp. teraz - wypiepszamy caly stary moduł, wkładamy
> ten od linuxa (ale przekonwertowany, by zachowac kompatybilnosc - tzw.
> stare funkcje nadal dzialaja, ale "nowym" silnikiem), modyfikujemy i co?
> Moze sie okazac, ze:
wiesz co ? obejrzyj sobie driver development kit pod windows nt,
potem zerknij na zrodla linuxa i powiedz jakie widzisz punkty
wspolne. to nei jest kwestia wywalenia kawalka zrodel i wstawienia
nowych, to jest kwestia przerobienia wszystkiego do zupelnie
innych warunkow pracy i calkowicie innego api kernela. a poza tym,
dlaczego przestales mowic o xwindow i zaczales o kernelu ? zdecyduj
sie ;->
> Kernele oba obsluguja systemy przez assemblera, oba maja duza ilosc
> modulow pisana rowniez w c/c++. eby bylo ciekawie - minic trochu kod sie
afaik kernel winnt jest pisany w wiekszosci w c++, kernel linuxa
nie zawiera c++ i nie bedzie zawieral przez najblizsze pare lat.
natomiast asembler w ogole nie ma zadnego zwiazku.
> da... i to nawet latwo... :) Wymaga trochu pracy, jednak ponawiam
> pytanie:
>
> po co pisac cos od nowa, skoro mozna sobie zakosic, przerobic i w
> zasadach closed-source wypuscic. Przecie nikt sie nie dowie :)
podam ci przyklad: jest sobie xfs. totalnie wyj[..] system plikow,
opracowany przez sgi. problemow patentowych nie ma, sgi jest zdecydowane
to wypuscic w wersji na linuxa, pracuje przy tym pewna grupa osob. wiesz
ile czasu im to dotychczas zajelo ? jakis rok, i doprowadzili to dopiero
do stadium bety. i to jest portowanie miedzy dwoma systemami unixowymi,
portowanie czegos do windows byloby trudniejsze. podobna sytuacja jest
z ibm (jfs).
> : > niekoniecznie... zauwaz ze one sa caly czas rozwijane... odpowiednie
> : > moduly obslugujace i juz
> :
> : nie da rady, zbyt niskopoziomowe. moznaby dorobic wrapper, tylko
> : chodziloby strasznie wolno.
>
> skad ta pewnosc? przyklad - win4lin prowadzi programy czasem szybciej niz
> oryginalny produkt m$ :) A on chodzi afaik calkiem niskopoziomowo :)
a jaki to ma zwiazek z tym, co napisalem ?
> : > potestowac to zauwazam, ze kernel windy me w porowniu do 98se potrafi
> : > weszcie obslugiwac system tak, ze przy odczycie z dysku nie ma 100%
> : > obciazenia systemu. Po trochu to jest pewnie wna programistow m$, jednak
> :
> : pod zadnym systemem odczyt z dysku nie powoduje 100% obciazenia systemu.
>
> to tylko oczekiwanie i/o blokuje system... coz... nie kcialo im sie
> napisac ciut wiecej kodu :)
jakie oczekiwania ? to jest realizowane na przerwaniach. przynajmniej
mam taka nadzieje ;-)
> : moze wzieli korepetycje od kolegow z ekipy nt ?
>
> a moze koledzy z ekipy nt brali korepetycje od ekipy open-source.
mozliwe. tyle, ze przeportowanie kodu z linuxa byloby trudne i raczej
nieoplacalne.
> Programista micro$oftu nei jest to jakis los z ulicy, tylko zwykle czlek,
> ktory uzywa mozgu i caly czas sie uczy. Jak sie najlepiej uczyc jak
> zaimplementowac 'x', nawet jesli sie nie ma pojecia jak? alez oczywiscie
> - open source - bierze sie zrodla i oglada...
w windows nie ma odpowiednika x, nie ma niczego, co by to chociaz
z daleka przypominalo.
> : > implementacja odpowiednia kodu (jest to mozliwe) dalaby powiekszyc
> :
> : owszem, jest mozliwe, ale przenoszenie kodu z linuxa jest praktycznie
> : niewykonalne. szybciej napisalbys to od nowa.
>
> Napisac caly modul i/o ide/scsi? no nie bylbym taki pewny :) Pozatym male
wiekszosc ide to robota Andre Hedrick'a i Marka Lorda. z dokonan
tego drugiego afaik duzo juz nie zostalo, zostalo zastapione
przez dokonania Andre. nie zajelo mu to polowy zycia ;-)
> windy to tylko nakladki na DOS + kilka rzeczy "osobnych", jednak nadal
> posiadajace balast nieziemski... w moim katalogu c:/windows/system mam
> pliki "ostanio modyfikowany 1987"...
albo masz stary system, albo zrypany system plikow ;-)
> Nie wiadomo rowniez, czy m$ nie korzystal z tego kodu od dawna w NT - a
> teraz to powoli portuja do malych wind. NT jest juz ciut ciekawiej
> zrobiony (widzialem go kilka razy, - i tak malo, by cokolwiek o nim
> powiedziec), i przenoszeni kodu wcale nie musi byc trudne - NT nie wisi
> na DOSie...
a jaki zwiazek ma wiszenie na dosie z portowaniem kodu ?
> : zrozum, nie jest mozliwa, bo musialbys pisac wszystkie drivery od nowa.
> : mozna jakos to obejsc, tyle, ze kosztem stabilnosci. poza tym linux
> : ma z windows naprawde malo wspolnego pod wzgledem ideologii pracy
> : systemu, co jeszcze bardziej utrudnia takie dzialanie. a ide jest
> : na tyle prostym zagadnieniem, ze znalezienie osoby kompetentnej
> : nie powinno byc trudne nawet wsrod ekipy microsoftu.
>
> obsluga pamieci, alokacja swapa, cpu, i/o... i nie mowimy tutaj tylko o
obsluga pamieci to domena freebsd a nie linuxa. alokacja swapa...
nie bardzo rozumiem, swap po prostu jest i sie go uzywa, zalicza
sie to do zarzadzania pamiecia. cpu... cpu sie nie obsluguje, cpu
po prostu dziala. i/o - zalezy jakie, usb ma z flopem raczej malo
wspolnego.
> malych windach - nei wiadomo rowniez jak jest z NT - portowanie moglo byc
> takie: z linuxa do NT, z NT do windy_malej. Jest to mozliwe juz bardziej
> - jadro NT nie ma ograniczen jak z dos'a rodem. Nadal sie przypominaja,
windows nt z windows 9x ma bardzo malo wspolnego. nie przypominaja
sie zbytnio.
> jednak podsystem jest ciut inny. W NT jest tak jakby ciut w strone
> linuksa. Obsluga urzadzen, zasobow jest o wiele lepiej dopracowana,
w nt jest jakby ciut w strone wszystkich innych sensownych
systemow operacyjnych ;->
> system nie wisi caly czas, nawet przy duzej ilosci programow (to, ze ma
> wymagania systemowe jak jasna cholera to inna rzecz, chociaz...
> zastanawiales dlaczego tak jej rosna wymagania? moze to sa te porty
> linuxa? :) )
jakby to byly porty linuxa, to win2k smigaloby na 486dx 16mb ram.
> : mozna za to zrobic cos odwrotnego - napisac emulacje windowsowego
> : kernela pod np. linuxa, tzn. loader do binariow, handler dla int0x2e,
> : kilka podstawowych funkcji kernela (OpenFile() itp)
>
> mozna w jena strone - da sie i w druga ;)
to nie jest kwestia 'w jedna czy w druga strone', te rzeczy nie sa zwiazane.
uruchomienie binarek linuxowych pod windows nt jest raczej proste, wystarczy
dorobic loader do plikow elf i handler dla int 0x80, kompatybilnosc
z posixem juz jest (libpsx.dll). tylko jaki to ma zwiazek z wlaczaniem czesci
linuxowego kernela do windows ? tak poza tym, to wlasciwie dlaczego akurat
linuxowego, a nie np. freebsd ? zwlaszcza, ze z bsd mogliby to zrobic
calkowicie legalnie.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 21:04:43 MET DST