Re: Symulowanie juniksa w EMX

Autor: Jan Stożek (jasio_at_nowhere.pl)
Data: Fri 03 Dec 1999 - 13:24:31 MET


On Fri, 3 Dec 1999 08:26:32, root_at_microsoft.com (Bart/2 (Bartosz
Tomasik)) wrote:

> >Otóż juniks dopuszcza kasowanie i zmianę
> >[...]
> > pozwala na wykonanie polecenia ALTER TABLE (i paru innych poleceń na
> > tablicach), bo najwyraźniej próbuje skasować albo zmienić nazwę
> > plikowi, który sam był otworzył.
> sądze, że ten problem wynika z czego innego.. najpierw spróboj dopisać
> do cinfiga ten parametr zwiększający ilość otwarych pzez EMX plików

        Mam to od zawsze, więc to nie to. Poza tym jak daję DROP TABLE, to
tabela znika, ale potrafią mi zostać nie skasowane indeksy... takich
"drobiazgów" jest więc więcej.

        Alter table powinno zmienić nazwę tabel na tymczasową, założyć tabele
o nowej strukturze i przenieść dane ze starej tabeli do nowej. Jeżeli
w tym czasie tabele są otwarte (a dlaczego nie, skoro demon może nadal
obsługiwać dostęp do tabel), albo operacje są wykonywane w innej
kolejności niż (D)OS dopuszcza - ale dopuszczalnej w juniksie - to
mamy problem.

> > Now: programy portowane z Linucha zwykle wykorzystują EMX. Czy nie
> >[...]
> > awaryjnego) itp, ale chodzi mi o zasadę.
> myślę, że dało by się... w każdym razie można spróbować, druga droga
> to tak jak w linuksie - to jest zawarte w systemie plików, a więc i u
> nas tam to zawrzeć - autorzy ext2, fat32, vfat, hfs mógliby to
> spokojnie zrobić, gorzej z samym HPFSem i JFSem, bo IBMowi się nie
> będzie chciało.. oczywiście można też napisać IFS'a który będzie stał
> na dowolnym z wymienionych powyżej file systemów i robił to samo.

        A jesteś pewien, że to ograniczenie jest zawarte w systemie plików, a
nie innej warstwie systemu albo np. w jądrze?
        Być może dodatkowy IFS załatwiłby sprawę, ale czy IFS nie ma zbyt
wysokiego priorytetu w systemie? Jednak im mniej kodu w ring 0 tym
stabilniej, co pokazują zgłaszane niedawno problemy z FAT32... Poza
tym, software pisany natywnie na OS-a (a także przenoszony z DOS-a i
systemów DOS-opodobnych) lepiej lub gorzej uwzględnia takie właśnie
zachowanie systemu (choćby w kolejności wykonywania operacji), bo
przecież blokowanie dostępu do otwartych plików jest de facto
dziedzictwem z DOS-a. Problem dotyczy więc głównie programów
przenoszonych z uniksa (głównie Linucha). A te i tak są portowane
głównie przez EMX.

        BTW - czy EMX ma jakieś dane globalne, czy też każdy program
dysponuje własną kopią EMXRT i tylko jej danymi lokalnymi? Bo jak tak,
to pierwszy uruchomiony program mógłby uruchomić rezydujący handler
plików, a ostatni zamykany - posprzątać po wszystkich poprzednich, na
wypadek, gdyby operacje były blokowane przez dostęp do plików "z
zewnątrz".

> Konkluzja: da się - ale trzeba znaleźć kogoś kto to zrobi...

        Czyli to samo co zawsze. :)

        Mamy więc dwie luki w architekturze OS-a do rozwiązania:
        - obsługa długich nazw plików w sesji DOS (może być przez TSR
komunikujący się z natywnym serwerem)
        - juniksopodobna obsługa operacji plikowych w EMXRT lub dodatkowym
handlerze systemowym

        Czy są jacyś ochotnicy? Tematy są ambitne i chyba nadają się na pracę
dyplomową. ;)

-- 
Pozdrawiam,
Jan.
PS. Mój adres: nowhere = Polbox. 


To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:24:40 MET DST