Subject: Re: proposal: simplifying cache_lookup() interface
To: Jaromir Dolecek <firstname.lastname@example.org>
From: Bill Sommerfeld <email@example.com>
Date: 08/07/1999 16:54:45
I don't have any objection to the proposed change regarding having
cache_lookup do the lock manipulation on the returned vnodes, assuming
it's been tested adequately.
> One remaining issue: our cache code doesn't handle
> case-insensitive filesystems quite well - i.e. it won't generate
> hit if the name to be found is differs from that cached in case only.
> Maybe we should introduce some flags to cache_enter() so that
> it would be possible to search case-insensitively optionally.
> This is kind of hard doing right (thing "national character sets"),
> but even beeing case-insensitive for ASCII chars would be much better
> than what we (do not) have now.
I don't think this is the right approach; the matching and
case-conversion rules are going to be inherently filesystem-specific.
Also, cache_lookup uses a hash table; it's somewhat hard to fold a
case-insensitive string compare into that as you'd be looking in the
wrong hash bucket most of the time.
You can deal with this in a monocase filesystem by canonicalizing the
case of the component name before calling cache_lookup() and
cache_enter(); reverse lookups in the cache (for sys_getcwd) will get
the canonical form of the name, which is presumably the right thing..
However *case-preserving* case-insensitive filesystems makes life even
more interesting.. and would require a mod to the lookup cache to
store the canonical form and the form to return via the reverse-lookup
code; also, creates would have to keep around the canonical and