From: Murat Koc (murat.koc@frontsite.com.tr)
Date: Mon 19 Apr 2004 - 16:53:26 EEST
> Selamlar..
>
Selam,
>
> > Kernel içindekinin userspace ile herhangi bir alakası yok, çünkü tamamen
> > bazı glibc fonksiyonlarının kernel içinde de uygulanabilmesi için
> > kullanılan libraryler. Ki bunlar üstünde yapılacak değişikliklerin
> > pratik olarak herhangi bir samba veya başka sistem üzerinde bir etkisi
> > yok?
>
>
> Programlar -genelde- bu islevler icin glibc cagrilarini kullaniyorlar,
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.
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.
> Belki smb icin spesifik cozum olmasada, bu cozum en azindan, galeon,
> evolution, php/apache ve wine icin is yapiyor. smb icin durum biraz
> farkli. O, strcasecmp/strncasecmp kullanmaniza bile izin vermez. Cunku
> SMB/CIFS networklarinda multibyte stringler bolca mevcuttur. Demekki
> baska bir sey dusunmek lazim smb ozelinde. Cok dusunmek gerekmiyor,
> 2.7.x icin (??! = oyle bir sey icin) yapmistim bunu.. Fakat 3.0 icin cok
> fazla deneyimim yok.
>
Bunları glibc tabanlı söylüyorsun sanırım.
> 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?
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.
>
> > GNU a göndermeden önce biz de görebiliriz değil mi? Buraya patch yapıp
> > yollarsan veya bir web sayfasına upload edersen sevinirim. Mekanizmanın
> > karışık olması çok sorun değil anlayabileceğimi sanıyorum :)
>
> Elbette, bir iki gun icinde SVN access hizmete girecek, bende oraya
> koyarim. Sanirim patch degilde, patch edilmis dosya/uygulama halinde
> olur basta...
Sevinirim.
-- __________ | | | | Murat Koc | | Manager & IT Consultant | FRONT | |==========| FrontSITE Bilgi Teknolojisi A.S. |_____SITE_| http://www.frontsite.com.tr/-- Attached file included as plaintext by Ecartis -- -- File: signature.asc -- Desc: This is a digitally signed message part
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBAg9nVyHJSQxPy7GoRAjakAJ4mqzEdXAu7mmHAeQjmdB5xVK32FQCfYUeP kHH4BmCuWY8se/w9Om+M4UQ= =Yazc -----END PGP SIGNATURE-----