DragonFly users List (threaded) for 2009-09
Re: namei.h query
:Here is a newbie query regarding the code in namei.h
:In DragonflyBSD, sys/sys/namei.h
:What is the advantage of the DragonflyBSD approach in this case ?
DragonFly uses a completely different path lookup mechanism,
mostly embodied by sys/nlookup.h, kern/vfs_nlookup.c, and
The DragonFly API is far simpler then the original BSD API (which
FreeBSD still uses). FreeBSD did do a cleanup pass to remove
obsolete flags a few years ago but they still appear to be dependent
on the throw-away nature of their namecache.
The DragonFly implementation uses more deterministic structures in
its name cache and also tracks path components by (mountpt, vnode)
instead of just by (vnode). The biggest real effect this has is
that DragonFly does not have the synthesize vnode aliases for things
like NULLFS mounts... it can pass the actual vnode straight through
and replace only the (mountpt) portion of the resolution. This
allow completely arbitrary mount recursion and unlimited nullfs
mounts as well as separate mount flags (e.g. a read-only nullfs mount
is possible) which cannot be told apart from base mounts from the point
of view of the rest of the system.