giFT - home_etc

[Pawel Wilk]

On Tue, Dec 09, 2003 at 03:38:07PM +0100, Witold Filipczyk wrote:
> 
> Może zupełnie inne podejście do sprawy.
> Przeładowanie systemowych funkcji open i access.

Myslalem o czyms takim pare miesiecy temu i gdy zaczalem sobie
uzmyslawiac wszystkie minusy takiego rozwiazania to zarzucilem pomysl.

Gdyby cos takiego bylo to kernel musi grzebac w environment procesu,
musi otwierac czasami sobie pliki (jesli proces nie ma HOME_ETC w
srodowisku bo jest na przyklad MTA lub innym demonem), musi umiec
korzystac z nsswitch (celem uzyskania katalogu domowego zgodnie z
konwencjami, jesli nie mozna odczytac ze srodowiska), musi robic
operacje na lancuchach tekstowych i wykonywac akrobacje do/z
user-kernel kontekst, a gdy juz to wszystko spelni to jak napisales
spowolni to dzialanie podstawowych funkcji (bo przecie in unix almost
everything is a file), a poza tym zawsze istnieje prawdopodobienstwo,
ze dla jakiestam aplikacji mechanizm zwyczajnie sie pomyli. Myslalem
tez nad przechwyceniem tego w glibcach, a nie w module do jaja, czyli
zrobic wrappery dla wszystkich funkcji operujacych na deskryptorach,
ale choc ponad polowa problemow znika to i tak mamy mozliwosc buga,
czyli pomylki mechanizmu w stosunku do konkretnych aplikacji.

> Obecnie nie ma szans, nawet z biblioteką, na utrzymywanie łatek z HOME_ETC.
> Zajmuje to za dużo czasu i jest za bardzo "błędotwórcze".

To prawda, ale sprobuje powalczyc i zobaczyc na ile aplikacje sa
podobnie napisane (licze na automake/autoconf). Tak naprawde mamy tu
teraz proste makra, ktorymi wrappujemy zmienne (katalog domowy
_HEdir; lub nazwa pliku konfiguracyjnego _HE(oryginalna_nazwa); ). Przy
przeniesieniu odpowiedzialnosci za operacje pozyskiwania tych rzeczy na
biblioteke "bledotworczosc" spada mocno.

Pozostaje tylko sprawa pamieci na HOME lub sciezke do configa
przydzielanej przez jakies malloc(), ktora aplikacja pragnie potem
zwolnic. Ale to jest do zalatwienia i mysle nad kolejnymi wrapperami,
tylko musze troche tych aplikacji poogladac czy jest taka potrzeba a
jesli tak to jakie statystycznie najczesciej informacje sa potrzebne
przy wolaniu takiego wrapka, ktory albo sam robi malloc() ktory
aplikacja potem free()uje, albo wypelnia jakis przydzielony przez
aplikacje buforek. Po to, zeby zwiekszyc czytelnosc i pomniejszyc
ryzyko bledu.

> A jest mało prawdopodobne, żeby HOME_ETC się przyjęło na świecie.

Licze na to, ze jak to jest biblioteka i aplikacja ma automake/autoconf
to dla autora nic nie szkodzi zmienic pare linijek kodu i wrzucic test
do configure.in, wtedy ma support do mechanizmu, ktorego jak ktos chce
to uzywa a jak nie to mu nic nie szkodzi.

:>


--
siefca