lkml.org 
[lkml]   [1997]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Msdos patch for aliased names


On Wed, 30 Jul 1997, Alain Knaff wrote:
>
> In which way does it slow down the critical path? Is it the
> kmalloc() in msdos_canonize that you're worried about, or is it
> something else?

No, I'm not worried about what happens inside the call, I'm worried about
the testing whether we should do the call at all. And what I'm more
worried about is actually the fact that the call can change the dentry
outside the VFS layer - something I don't like from a conceptual
standpoint.

I'd like _all_ name lookup logic to be in the VFS layer so that there
aren't any surprises. And I do see that people would prefer for the msdos
filesystem to be case-insensitive..

I certainly agree that my stupid "name_translate_char()" is by no means
very good, and as you correctly point out we should actually change the
character itself, not just the hash value. And we can't really do that in
the place I envisioned for it, because the buffer that the name is in can
be a symbolic link or similar, and we obviously shouldn't change that..

Hmm..

I'd like this al to be done in some sane place - and your patch works but
doesn't count as "sane" in my book. It looks like a hack (having people
malloc memory and exchange it for non-malloced stuff, having somebody
_else_ free it etc). The iso9660 filesystem used to do a lot of ugly stuff
like that for directory handling (happily cleaned up these days), and I
let things like that pass, but I don't like it when it's in the kernel
proper..

Linus


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:2.305 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site