Page 5 of 5

Posted: Sat Mar 12, 2005 5:20 am
by Floridajin
So Does linux it hides in libc not the kernel the ls command calls libc that does the wildcards on most linuxs(this still can be embeded in the ls command). This is driver construction nothing more.
Maybe I'm misunderstanding your post, but it sounds like what I said. What I mean is, I heard that in the Windows family, it's the opposite - that the wildcard code was in the driver itself (which would be like having it in the linux kernel.) So in Linux, you'd only need one set of "code" in libc to do all wildcards, while in Windows, you'd have to rewrite the code for each filesystem driver. Is that the case, or is there a different set of code in libc for each and every FS?

I'm no expert on the matter, so I could be wrong, but if it's right, it'll make things more difficult.

Personally, I'd love to see Reiser4 on ReactOS. :)

Nop I was just a little confusing.

Posted: Sat Mar 12, 2005 6:42 am
by oiaohm
It does not really matter where wildcard functions are. They can be embed in a linux kernel if you build a driver with them and link libc to it(not recommended).

This is not a factor. Wildcard code is Wildcard code does not matter where it is. One single wildcard code could be used for every filesystem. There sould be no need for Wildcard code in the driver. If it is in the windows driver you should be able to copy Wildcard code from driver to driver with verry little change except for filesystem partical features.

You even find some of the functions required to pull of wildcard features in the standard linux kernel. Mainly for secuity reasons and stable state of linux these are not provided external. But some filesystem perform special translation ie vfat on linux does not care about case on partical size filename. Ie 8 chars with a . 3 chars.

There are many opensource windows filesystem drivers never Have I seen Wildcard code in the driver(I might have missed it too)