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/