Messages in this thread |  | | | Date | Mon, 21 Sep 1998 12:49:12 -0700 (PDT) | | From | Gordon Chaffee <> | | Subject | Re: [PATCH] Speeding up FAT operations |
| |
Jukka Tapani Santala writes: > Unfortunately the "boundary chars" of the letters many are also allowed > in MSDOS filenames, so a simple bit-operation for switching case isn't > usable. So my thoughts are lead towards an actual table; since I hate > wasting 256 bytes (or worse, aligned) for something like this, not to > mention the cache and alignment issues, I'm thinking of trying something > like 'if (ch&32!=ch) char=tab32[ch&31];' and do away with 32 element > table, which could still be somewhat defensible.
You could replace that code with somethink like c = tolower(c); This uses some tables from lib/ctype.c to go faster. I think it might be adequate for what you want. It should definitely replace the code that was there.
> Another issue worth a test is whether pulling the case-translation stuff > out from the copy-loops and running them in a separate pass on the whole > ptname string would be more effective? My guess is that'd be more > effective... So, does anybody know of a reason not to do that? Is there > anywhere a basic letters-only casetable for conversion, and any reason > the aboive 32 element method would be a bad idea? Opinions on other > issues raised in this discussion?
I suspect you would be correct that pulling it out would be better and cleaner. As for preserving case, the 2.1.x vfat and msdos code can handle case insensitivity without a problem, so preserving case is no longer the issue that it once was. However, I suspect many people would be unable if their msdos filenames suddenly showed up all capitalized. There is a setting in DOS to set which ws they show up by default, capitalized or lowercase.
Its good to have someone looking at the code here. I don't think its really been looked at much in a few years. I added code (and complexity) with vfat handling, but I never looked at the basic code that was there to begin with. As you have shown, it wasn't very good in terms of speed.
I'm somewhat leary of applying these patches this late in 2.1.x as we are trying to get 2.2 out. There are some things that are clearly not a problem such as pulling the 0x05 check out of the inner loop. Others like no longer checking for an ending 0 (only checking for spaces) has me a little more uncomfortable. I don't know why the check was there in the first place, but I wouldn't be too surprised to find that changing it breaks something. Remember, this code works with a large variety of FAT implementations--Atari ST, Microsoft, IBM, etc. Just because something is supposed to follow some dubious "standard" doesn't mean that it always does. If instead the more aggressive patches are held for 2.3.x, we have more time for fixing things if something goes wrong. The FAT filesystems are not heavily used by Linux kernel developers-- I suspect they get far more use from end users. This means that problem reports can take awhile to trickle up after changes break something.
- Gordon
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |