From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Wed 21 Apr 2004 - 08:25:45 EEST
Selamlar..
Dusunmek, makul bir yaklasim. Ama elle tutulur bir seyler koyabilmek
gerekiyor. Bu asamada yapilacak olan bence, "su sorun olusabilir, bu
sorun olur" gibi bir liste cikarmak. Bu sorunlari bu listeye bakarak
asmak, minimize etmek vs. mumkun olabilir.
Kernel icindeki atraksiyon, bence de cok ucuk ve buyuk ihtimalle
gereksiz. Ama su ana kadar ben sorun yasamadim. Diyelim ki sorun cikmasi
durumunda, o uygulamaya spesifik bir cozumde yapilabilir kernele,
current meselesi yeterince saglikli olur. Biraz tuple, hash vs. mevzusu
ile basitce cozulur.
GLIBC konusuda ayni sekilde. En guzeli, uygulamalar icinde bu sorunu
gidermek ama maalesef olamiyor her zaman mumkun..
Kisacasi, konu ile ilgili sorun listesini vs. gormek icap ediyor. Bu
sayede belki elle tutulur bir sey cikarilabilir.
Saygi ve sevgiler..
> Selam,
>
>
> > Ben genel cozumlerin daha cok problem yaratacagini dusunuyorum. Sihirli bir
> > "glibc ve/veya kernel" yamasi cok cekici gozukuyor biliyorum, ama boyle bir
> > cozumun problemin esas kaynagini saklayacagini ve uzun vadede cozumu
> > zorlastiracagini dusunuyorum.
>
> Bir başka konu zaten bu tür userspace programlar için çözümlerin kernel
> içinde yapılmaya çalışılmasının anlamsız olduğu. Glibc tabanlı
> çalışamalarda ilerleme sağlanabilir.
>
> Bunun yanında belli uygulamalar taban alınarak kernel tabanlı çözümlere
> gitmek diğer uygulamalarda önceden öngörülemeyen yan etkilere yol
> açabilir ve stabilite bozulabilir. OOo ve yield() gibi ...