[lkml]   [1998]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.021 / U:17.432 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site