pre/postcall wrapper around the exported namei, since postcall no
longer needs to execute VFS_ROOT (which is a bad thing to do while
potentially holding on to a locked vnode, mmkay).
tricky) with the help of rump system calls instead of calling namei
by themselves. Trust me when I say it was non-trivial to get the
namei calls right.
to 1, hold on tight to your hat, and call recycle. The reason is
that we might pick up extra references such as from lookup and we
don't really care about tracking those. For example with p2k,
puffs in the kernel already does all the refcounting we could ever
dream of, and therefore it's left to the client and unnecessary.
can now be developed in userspace using puffs for development
(I hate emulators, they are annoyingly clumsy).
To e.g. mount psshfs using puffs-on-puffs, run fs/bin/syspuffs/syspuffs
with the regular mount_psshfs command line as an argument:
golem> ./syspuffs /usr/sbin/mount_psshfs ftp.netbsd.org:/pub /puffs
This will make the mount appear as usual, with the exception that the
requests will be passed through puffs both in the kernel and userspace:
ftp.netbsd.org:/pub on /puffs type puffs|p2k|puffs|psshfs
* I heard a wild rumor that vp_interlock is a mutex these days (hi ad!)
* init new locks (hi ad)
* observe that with simple_locks only deadlocks would be caught while
releasing unlocked locks would go unnoticed. make locking work (hi pooka)
Ok, ok, a few more words about it: stop holding puffs_cc as a holy
value and passing it around to almost every possible place (popquiz:
which kernel variable does this remind you of?). Instead, pass
the natural choice, puffs_usermount, and fetch puffs_cc via
puffs_cc_getcc() only in routines which actually need it. This
not only simplifies code, but (thanks to the introduction of
puffs_cc_getcc()) enables constructs which weren't previously sanely
possible, say layering as a curious example.
There's still a little to do on this front, but this was the major
fs interface blast.
The general trend is to remove it from all kernel interfaces and
this is a start. In case the calling lwp is desired, curlwp should
be used.
quick consensus on tech-kern
locking and makes it possible to run file systems which create
threads. It also makes rump file system behaviour better match
file system behaviour in the kernel.
pooka