Cześć,
W przypadku linuxa często podkreśla się fakt, że "wszystko jest plikiem". Niestety nie do końca rozumiem to stwierdzenie. Mam w związku z tym dwa pytania:
Czym jest plik - jak należy to interpretować?
Mozesz przetwarzac czescia narzedzi do przetwarzania plikow. Czesto takich udawanych plikow nie mozna skopiowac, Ale np mozna wyswietlic co jest dopisywane itd
KamilAdam napisał(a):
Czym jest plik - jak należy to interpretować?
Mozesz przetwarzac czescia narzedzi do przetwarzania plikow. Czesto takich udawanych plikow nie mozna skopiowac, Ale np mozna wyswietlic co jest dopisywane itd
Co wcale samo w sobie nie oznacza że to lepiej, ani że gorzej.
A może jednak gorzej? Kiedyś robiłem taki test - w narzędziu top przytrzymanie spacji (odświeżanie widoku) powodowało znaczny skok użycia CPU pod Linuxem, a pod FreeBSD nie. To było wyjaśnione tym że pod Linuxem tam się dzieją operacje plikowe które są wolniejsze niż proste systemowe calle. Nie wiem czy to tłumaczenie było słuszne, ale różnicę można było zaobserwować.
Po pierwsze primo, nieprawda - nie wszystko jest plikiem.
Po drugie - te rzeczy, które "są plikami" tak naprawdę nie "są plikami" - są bardziej "reprezentowane" przez plik, na którym można dokonywać odczytu, szukania i zapisu.
Przykład klasyczny: napęd CD jest (albo bardziej był, bo teraz mało który komp ma napęd) reprezentowany przez urządzenie-plik /dev/cdrom. To znaczy, że żeby zgrać bajt po bajcie obraz płyty ISO, wystarczy użyć narzędzia np. dd (dd if=/dev/cdrom of=obraz.iso) żeby otrzymać plik ISO. W ten sposób, nie potrzeba żadnych innych narzędzi. Tak samo można zrobić zrzut całej pamięci USB i zrobić np. klon pendrive.
Przykład drugi: system plików /proc. Np. nie ma dedykowanej komendy w Linuksie, która pokaże jaki mamy procesor. Ale ta informacja znajduje się w pliku /proc/cpuinfo. Mogę ten plik odczytać edytorem tekstu, catem, wysłać mailem, cokolwiek - nie potrzebuję żadnych innych narzędzi. Tak samo odczytam aktualnie uruchomione procesy, prędkości wentylatorów w laptopie, jasność ekranu, podmontowane dyski.
Jest tego sporo. Karta dźwiękowa kiedyś (nie wiem czy teraz) była reprezentowana jako plik, i można było (dosłownie) zrobić cat plik.wav > /dev/audio i słychać było muzykę. cat plik.txt > /dev/ttyS0 drukowało na drukarce na porcie szeregowym. Nowe modemy LTE działały bez żadnej konfiguracji na standardowych narzędziach do wdzwaniania się sprzed 30 lat, bo były reprezentowane przez wirtualny port szeregowy np. /dev/ttyUSB0 i nie trzeba było nic zmieniać w sofcie, bo to plik jak każdy inny :) Mogłeś sczytać ruchy myszką czytając z /dev/mouse chyba nawet :)
Innymi słowy, jest to fantastyczna abstrakcja. Czy najlepsza - pewnie nie, ale nie znam tyle historii :)
Kwestia definicji pliku. Pytanie czy takie exe jest w windzie plikiem. Jest to kawałek danych, ale w odpowiedni sposób ułożony i zserializowany.
kelog napisał(a):
Po pierwsze primo, nieprawda - nie wszystko jest plikiem.
Plik jest zbiorem informacji..
Można w nim wydzielać: podkatalogi, podfoldery, podgrupy...
oraz strumienie danych..
Windows coraz bardziej wzoruje się na LINUX :)
Najlepszy plik w Linuksie to /dev/null i nie, nie ma takiego w Windows.
Linux - wszystko jest plikiem!
Nie plikiem tylko plikowym deskryptorem. I nie wszystko bo procesy i wątki nie są plikami.
Czym jest plik - jak należy to interpretować?
W ujęciu unixowym, czymkolwiek do/z czego możemy pisać/czytać bajty z użyciem strumieni C.
Jeśli w Linux-ie wszystko jest plikiem to czym są rzeczy w windowsie, które nie są plikiem i czym o się różni?
Unix/Linux i Windows to są światy równoległe, które nie we wszystkich kategoriach można porównywać jeden do jednego. Everything is a file jest jednym z takich przypadków. Pliki w linuksie obganiają na przykład "bazę danych" dla systemu oraz np. IPC dla których windows ma zupełnie inne alternatywy. Odpowiednio bazą danych jest windowsowy rejestr a do IPC można uzyć COM, pipe, uchwytu okna, socketów na podobę unixa (ale czym są sockety pod spodem w windowsem to nie wiem) i pewnie jeszcze kilku innych rzeczy.
jawlo napisał(a):
Windows coraz bardziej wzoruje się na LINUX :)
Zdecydowanie.
Kiedyś pipe, port szeregowy itd były oddzielnymi bytami, teraz coraz więcej może sie przedstawiać jako plik.
Czy z tego powstanie raj na ziemi ? No nie
Już w samych Unixach / Linuxie wszelkie oboczności, wyciekające abstrakcje "co naprawdę pod tym plikiem jest" się obsługuje nieprzenośnie przez funkcje z gumy ioctl()
A wracając do programowania portu szeregowego pod Windows, w każdym ambitniejszym projekcie NADAL poza koncepcją pliku trzeba łapać eventy
EXE jest oczywiście plikiem, a w momencie uruchomienia staje się read-only swapfile'em – w razie potrzeby program może być ponownie doczytany bezpośrednio z .exe, Windows unika powielania zawartości exe w swapie, skoro wiadomo że to exe znajduje się na dysku. — Azarien dziś, 02:30
NIEEEEEEE
Strasznie pojechałeś po uproszczeniach
Obraz programu, image, plik EXE to jedno.
Może być wystartowany (ale może nigdy do kasacji komputera nie być), i powstaje PROCES.
Proces mozę się cieszyć używaniem swapfile (od miliona lat nie widziałem swapfile dedykowanego do jednego, naklądki na programy klasy DOS tak miały - chyba od dawna wylącznie jeden swapfile systemowy)
Użycie EXE do "doczytywania" elementów programu, obecnie kodu trochę rzadziej ale resoursów całkiem całkiem, prawda, ale to nigdy nie nazywało się swapfile, z braku ":swap"
Najczęstsza komunikacja z kernelem, driverami jest właśnie przez interface pliku, deskryptor.
Gdzie wypełniamy strukturę w C.
static struct file_operations fops = {
.open = dev_open,
.read = dev_read,
.write = dev_write,
.release = dev_release,
};
I teraz dla przykładu jak chcielibyśmy zrobić komunikację jakąś dowolną.
To przy open() syscallu wywołuje się funkcją .open() i tam robimy jakąś inicjalizacje np. ustawienie bitrate, nawiązanie połączeni, konfiguracja.
Potem przy read i write, możemy odczytywać kolejkę danych, które przychodzą od urządzenia lub przy write pisać do kolejki, gdzie kernel sobie wysyła w swoim tempie dane do urządzenia.
Kolejki są bardzo często stosowane czy to przy different clock domains.
W windowsie też często wygląda podobnie komunikacja z driverami kernela, używa się komunikacji za pomocą plików, ale jest trochę inniej wyglądająca ścieżka jak:
\\\\.\\MyDriver
\\DosDevices\\C:\\Users\\dupa\\plik.txt
hDevice = CreateFileA(RegistryPath, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);
DeviceIoControl(hDevice, IO_GET_CLIENTADDRESS, (LPVOID)cmd.c_str(), (DWORD)cmd.size(), Buf, sizeof(Buf), &Bytes, NULL);
Więc to bardzo podobnie wygląda.
Skąd wiem? bo pisałem drivery pod linucha i windę.
Na linuxie open to na windowsie CreateFile, na linuxie read to na windowsie ReadFile i write to WriteFile.
Azarien napisał(a):
A może jednak gorzej? Kiedyś robiłem taki test - w narzędziu
topprzytrzymanie spacji (odświeżanie widoku) powodowało znaczny skok użycia CPU pod Linuxem, a pod FreeBSD nie. To było wyjaśnione tym że pod Linuxem tam się dzieją operacje plikowe które są wolniejsze niż proste systemowe calle. Nie wiem czy to tłumaczenie było słuszne, ale różnicę można było zaobserwować.
Operacje na plikach robi się syscallami więc to są proste systemowe calle, to jest to samo.
Operacja na pliku to wywołanie syscalla open i syscala read lub write.
Linux ma virtual file system, gdzie tam struct inode to może być prawdziwy plik lub jakiś driver oba mają takie same interface to mamy tu doczynienia z polimorfizmem.
Są też inne metody komunikacji, ale ta jest dosyć prosta, swoich syscalli raczej się nie dodaje do systemu.
Komunikacja za pomocą plików jest bardzo popularna na każdym systemie.
Ale wszystko nie jest plikiem, pliki służą do komunikacji na windowsie i linuxie, linux ma prostą strukturę, a w windowsie trzeba szukać jaki path mają dane urządzenia, nie sprawdzisz tego przez file system.
Jądro windowsa to ntoskrnl.exe
Do niektórych bytów w linuxie możesz się dostać z poziomu systemu plików, nawet jeśli te byty nie są (albo nawet nie mogą) być zapisane na dysku. Ale ja nie powiedziałbym że wszystkich.
System plików to tylko abstrakcja na dysk. Można nim reprezentować sporo rzeczy, szczególnie coś co ma interfejs tekstowy albo binarny. Podobną sztuczkę można zrobić z
gajusz800 napisał(a):
Najlepszy plik w Linuksie to /dev/null i nie, nie ma takiego w Windows.
Przespałeś chyba lekcje informatyki w szkole - już w DOSie był specjalny plik o nazwie NUL (jak i parę innych np. CON, COM1 itp)
Potem zostało to zaimportowane do windows, a windows już prawie jest zgodny z posix-em.
Jeśli nie wiesz jakie pliki są używane w windows to pomoże Process Explorer - można się wiele nauczyć oglądając czego używa dany proces.
No co ty powiesz? To skoro ty nie przespałeś to podaj odpowiednik /dev/null w Windows
Jaki jest odpowiednik echo dupa > /dev/null ?
[edit]
Ok zwracam honor, faktycznie jest NUL w Windows, więc miałeś rację