🚀 go-pugleaf

On Fri, 2 Apr 2004 07:50:04 +0000 (UTC), Pawel Jakub Dawidek wrote:

>> Wcześniej w takim razie miałem sporo szczęścia, zreszta przy EBUSY też
>> musze zrestartować :P
> Przede wszystkim możesz czysto zamknąć system. Poza tem to powinna być
> kwestia reguł ewentualnie. Powinna być możliwość usunięcia reguł i wtedy
> odładowania cerba.

Wiem, że jak z tym reloadowaniem przesadziłem to dochodziło do takiej
sytuacji że albo nie mogłem rozładować starych regułek albo załadować
nowych, już dokładnie nie pamiętam. (raczej chyba to drugie, bo wydaje mi
się że mogłem załadować do danego slotu ale nie mogłem go zrobić aktywnym)

> Wiesz, kłopotów uniknąć się nie da i tak. Nawet zaimplementowanie takiego
> blokowania nie musi być łatwe. Programowanie VM-a nie jest raczej trywialne.
> Jest sporo ograniczeń, których może się nie dać łatwo przeskoczyć.
> Generalnie takie blokowanie musiało by polegać na markowaniu obszaru
> jako read-only i czekaniu na page faulty i ich obsłudze. Wtedy musimy
> stwierdzić który to wątek próbuje dokonać zapisu i czy mu wolno, itp.
> Bez zmian w kernelu raczej się nie obędzie.

Nie programowałem nic na poziomie kernela, więc dla mnie takie rzeczy nie
są oczywiste, najpewniej masz rację. Ale czy modyfikacja kernela byłaby aż
taka zła? Tzn jak już by do tego doszło to polecałbym zmienić tylko
minimum. Porobić np odpowiednie mechanizmy, dodać pewne informacje i
wszystko obsługiwać z modułu.

>> Tzn jest możliwość że dwa syscalle w freebsd mogą być wykonane
>> równocześnie, czy może w sytuacji gdy pojawią się syscalle jednocześnie
>> freebsd wykona pierwszy następnie drugi.
> Więc tak. We FreeBSD 4.x SMP realizowane jest jedynie na poziomie
> userlandu. Przy wejściu do kernela, łapany jest Giant-lock i tylko
> jeden proces wykonuje się w przestrzeni kernela jednocześnie.
> Oczywiście może on być przerwany w wyniku, np. przerwania.
> Jedną z największych rewolucji (powiedzmy to: największą) we FreeBSD 5.x
> było wprowadzenia w pełni SMP kernela. Pociąga to za sobą konieczność
> sychronizacji dostępu do wszystkich współdzielonych zasobów.
> Pociągnęło to też za sobą opóźnienie o ponad rok wydania 5.0,
> ale warto było.

dla cerba to pewnie: D'oh! ;P
A ja i tak go głównie lubię bo potrafi logować execve.

> Ochroną takich wypadków zajmuje się VFS i synchronizacja tam
> zaimplementowana. Obiekty file systemu też można blokować.
> Zresztą jeśli otworzysz plik i go usuniesz, to możesz z niego korzystać
> bez żadnych problemów dopóki nie zamkniesz deskryptora.
> Tak się czasem robi z plikami tymczasowymi. Otwierasz plik tymczasowy,
> dostajesz deskryptor, usuwasz plik i korzystasz z niego do woli, nie
> przejmując się o jego skasowanie przy wyjściu.

tego nie wiedziałem, hmm ale jak to wygląda dla usera czy podczas działania
programu plik jest nadal widoczny, czy już w momencie unlink znika
magicznie?

>> Tutaj nie widzę innego rozwiązania, jak to które jest aktualne w cerbie.
>> Ale czy nazwa pliku nie jest przydatna tylko w momencie gdy się otwiera
>> plik? (zezwolić lub nie na otwarcie danego pliku).
> Ależ skąd. W cerbie masz możliwość pobrania nazwy pliku po numerze
> deskryptora. Dzięki temu możesz kontrolować syscalle takie jak:
> fchmod(2), fchown(2), fchflags(2), ioctl(2), i inne, operujące na
> deskryptorach po nazwie pliku. Co jest niesamowicie wygodne.

Tzn. cerb po prostu ma tabilce:
dekryptor - nazwa pliku

i przechwytuje wszystkie syscalle otwierajace i zamykajace filedeskryptory,
przy okazji uaktualniajac daną tablicę?

Bo chyba jedynie tak można to w miarę normalnie zrobić...

>> przy zaimplementowaniu blokowania dużo problemów się rozwiąże IMHO :)
> Budujący jest Twój optymizm:)

Najpewniej dlatego, że moja wiedza jest nadal mała :P

-- 
takeda@IRCnet.EFnet, ICQ# 15827691, GG# 113344, TLEN: taked4
EMAIL: dp4declo02@NsOnSePaAkMemail.com
(remove CAPITAL letters from email if you want to contact me)
*http://eggdrop.takeda.tk - eggdrop & mods help*