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
non-canonical forms. 

					- Bill