From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Tue 20 Apr 2004 - 09:33:23 EEST
Selamlar..
> > Selamlar..
> >
>
> Selam,
>
> >
> Ben kernel kısmından bahsediyorum glibc kısmından değil. Kernel için
> strcmp türü fonksiyonlara eklediğin kısımların smbfs içinde zaten
> herhangi bir etkisi yok fakat uygulamalarında kernel space olmadıklarını
> düşünürsek hiçbir etkisi olmaz.
smbfs'ye dogrudan etkisi yok. Ama smb'nin yazdigi dosyalara digerlerinin
erismesi icin faydali "olabiliyor". Kabaca, wine ornegin, "isapi.dll"
acamiyor, cunku, "İSAPİ.DLL" ariyor diskte.
Kernel capindaki duzeltme, cok fazla sorun gidermiyor, ama bazi
sorunlari gideriyor. Elbette, baska sorunlara yolacabilmesi de kuvvetle
muhtemel.
> Dolayısı ile neden lib/string.h içinde değişiklik yapma gereğini
> duyduğunu sormam gerekiyor. Glibc kısmı ayrı bir olaydır. Onunla ilgili
> olarak zaten kodları gördükten sonra konuşabilirim.
Bazen, her zaman degil, yukaridaki gibi sorunlari cozebilmek icin
dusundum. Dogrusu, fayda/zarar analizinide, gercekten faydali olup
olmadigini da cok fazla, hatta biraz olsun incelemedim.
> Bunları glibc tabanlı söylüyorsun sanırım.
SMB kodu icinde, strcmp ve turevlerini kullanamazsiniz. Size dogrudan
"__XX_ERROR__DON'T_USE_STRCMP" gibi bir error sunuverir.
> > Kernel uzerinde fnmatch icin gerekli duzeltme yapilirsa, smb veya mesela
>
> Kernel? fnmatch? Kernel hiçbir şekilde fnmatch kullanmaz. Glibc tabanlı
> bir fonksiyonun ise ne alakası var kernel ile?
Kernelde yapilacak duzeltme ile, fnmatch benzeri durumlar icin bir tur
kompanzasyon yapmak bahsettigim. Yani, kernelde yapilan "İ" = "I"
duzeltmesi, ust duzey fnmatch vb. fonksiyonlar icin faydali olabiliyor
(tez sadece, dogrulugunu tartisirim, israrci da olmam).
> Bu şekilde bir düzenleme yapılamaz.
>
> > http oraya "İ" yaziyorum diyor mesela, ama, kernel dosya adinda bunu "I"
> > ya ceviriyor. Sonra da acarken, ararken, "İ" istenirse bile "I" olani
> > aciyor. Bu da sorunu bir hayli kokten cozuyor, ama guvenilir olup
> > olmadigi cok supheli.. Bunu 2.4 icin yapmistim, 2.6 icin hic bakmadim.
>
> kernel dosya isimlerinde bu şekilde çalışmalarda bulunmaz. Kernelin
> dosya ismi ile bir işi yoktur çünkü. Kernel için sadece inode lar
> önemlidir ve hiçbir filesystem içinde bu şekilde bir yapılanma yok.
>
> kernel tabanlı konuşulacaksa sadece ve sadece smb,nfs,cifs vs gibi
> network tabanlı filesystemler üzerine konuşulabilir. http gibi bir
> protokolun kernel ile hiçbir ilişkisi olmaz. (kernel based web server
> olmadığı sürece ki 2.6 kernelda yok)
>
> Dolayısı ile 2.4 kernel da ne yaptığını yine merak ediyorum.
>
>
> Glibc kısmında ne yaptığınızı kodları gördükten sonra söyleyebilirim.
> Ama dediğin şekillerde eğer kernel üzerinde oynama yapmış/yapıyor
> iseniz, userspace kısmına dokunmadan kernel içinde sağlamlığı
> bozmuşsunuz demektir. Bu ise en baştan ULUDAG ın bir dağıtım olarak
> kaybetmesi anlamına geliyor.
>
> Umarım Türkçe sorunlarını çözeceğiz diye yanlış yönde çalışarak
> başlatmış olduğunuz oluşumu en temelinden yani kernel dan sarsarak
> hüsrana uğramazsınız.
>
Biraz misinformasyon veya yanlis anlatim sozkonusu Murat hocam. Burada,
dosya sistemi uzerinde yapilacak, "open" gibi, hatta dogrudan, bizatihi
open cagrisi icin, open_namei uzerinde yapilan bir duzeltme. Aslen
strcmp uzerinde degil, do_getname gibi fonksiyonlarda,
strcpy_from_user(..) gibi fonksiyonlardan sonra "İ->I", "ı->i" cevrimini
yapmaktan ibaretti. Diger yandanda, lib/string.h icinde duzeltmeler
yaparak oradaki kodlarin glibc uzerindekilerle uyumlu olmasini saglamaya
calistim ki, olmadik bir seyler cikmasin. Soyledim, gene soyluyorum,
bunun cozum olup olmayacagi, faydasi olsa bile, zararinin olup
olmayacagini cok fazla tartmadim. Fakat, su an, benim makinemde
calisiyor ve bir takim faydalarini gordum. En azindan, WINE
calistirmadan once "LC_CTYPE=C" gibi bir suru sey yazmak gerekmedi.
Aslen, en buyuk sorun glibc uzerinde yapilabilecek duzeltmelerle
asilabilecek gibi duruyor. Bu dosya adlari problemi nispeten minor bir
konu. Windows ucubesini sokmazsin ortaya kurtulursun. Ama, ornegin,
PHP'nin calismamasi, evolution'un acilmamasi daha buyuk sorunlar. Iste
bir PHP mesaji :"name prıntf not found" gibi acayip bir sey. Bunlari
asmak gerekiyor bir sekilde. Dogru, cozum icin adres kernel degil, hatta
belki glibc'de degil. Dogrudan ilgili kodlar olabilir. Ama her
uygulamayi yazanin Turkce bilmesini beklemek hayal olur.
Diger yandan, dosya isimleri ve/veya diger yerlerde, "I" == "İ" yapmanin
(yada oyle farzetmenin) pratikte kerneli "eyvah eyvah" denecek bir hale
sokmayacagini dusunuyorum. Belki yanlis dusunuyorumdur. Ama, iste su
durumda soyle bir sey olur, bu da kerneli perisan eder gibi bir bildigin
varsa, paylasmaktan memnun olurum. Burada kas yapayim derken goz
cikarmak istemeyiz elbet. Fakat, kullanicilarin orada duran dosyayi
acamiyor olmalari ne kadar aci bir durumdur, bu duruma dusen kullanici
ne kadar mahzun ve melul olur iyi biliyorum. Bu sorunu cozmek icin
gereken kernel'de bir seyse, yapilmalidir. Saglam olmazsa,
saglamlastirilmalidir. Supheli ise denenmelidir vs. Ama bu sorun
cozulmelidir. Kisaca, bu, kabul edilemez bir durum ve ben de bunu cozmek
icin ne gerekiyorsa yaparim.. Umarim basarili olurda, hepimize faydali
olur.. Mesela, iste bir durum:
binfmt_elf.c:
if (strcmp(elf_interpreter,"/usr/lib/libc.so.1") == 0 ||
strcmp(elf_interpreter,"/usr/lib/ld.so.1") == 0)
Simdi, eger, "/usr/lıb" gibi bir dizin varsa, veya o dizinde
"/usr/lib/lıbc.so.1" dosyasi varsa, dengesiz bir durumdasiniz demek
olur. Ama, eger, bu dosyalari buraya koyarken, tum "ı" lari, "i"
yaparsaniz, sorununuz otomatikman cozulur (Acaba !? Bir iyice incelemek
lazim muhakkak).
Saygi ve sevgiler..