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
a bug: the homegrown version neglected to unlock vp
* don't reimplement eopnotsupp()
* init genfs_node earlier vget, protects against error paths in vget
from attempting to destroy a non-inited node
same file were renamed simultaneously, there was a window where
directory entry cached in the vnode during lookup would be replaced
before calling rename. This lead to one directory entry getting
renamed twice and the other one getting zero renames. Do a relookup
in rename to make sure we have the correct directory entry.
Thanks go to Greg Oster for reporting the problem, helping with
debugging and thoroughly testing the patch.
called with NOWAIT.
XXX: this is just a quick fix to stop the diagnostic panic. I
think ENOSPC should be treated elsewhere depending on how much
memory tmpfs claims.
thing and release locks before the userspace wait for operations
which release the lock before exit from the method in any case.
However, releasing the lock after inserting the request on the
operation queue gives us proper ordering possibilities in userspace
(at least if that bit were implemented, but I don't think there
any file system in userspace that depends on kernel locking and
probably there never should be one).
inspired by a conversation with Nacho Navarro
with the file server happen through puffs_msg_enqueue() and
puffs_msg_wait() instead of having a billion different routines.
Build the existing system upon these two. Most importantly though,
decouple insertation into the op queue from the actual wait. This
is useful for a number of reasons coming soon to a cvs repo near you.
unlocked vnode when trying to rename a directory. The fix was to
shuffle some bits around and #pray.
The rename routine actually needs a very very major wide-angle whopping:
* it takes locks out-of-order
* it deals with references from SAVESTART lookups in interesting ways
* I doubt there is any guarantee for correct operation if there
are multiple concurrent accesses
* the error branches might just as well call panic() directly
Rip the transport code completely out of puffs and generalize it
into an independent module which will be used for multiple purposes
in the future. This module is called the Pass-to-Userspace
Transporter (known as "putter" among friends).
This is very much work-in-progress and one dependency with puffs
remains: the request framing format.
The device name is still /dev/puffs, but that will change soon.
Users of puffs need the following in their kernel configs now:
pseudo-device putter
when vclean()ing. Pending an adventure to the genfs/vm labyrinth
to fix this properly, compensate here by not allowing unstrategic
(no pun) return values. They are always due to the userspace server
crashing anyway, so it's no big deal if we lie about the final
resting place of the pages.
userspace, since it doesn't contain any information yet. I should
still rework this more so this is just a quickie to get the read/write
style interface more up to speed with the ioctl version.
interacts with the userspace file server:
* since the kernel-user communication is not purely request-response
anymore (hasn't been since 2006), try to rename some "request" to
"message". more similar mangling will take place in the future.
* completely rework how messages are allocated. previously most of
them were borrowed from the stack (originally *all* of them),
but now always allocate dynamically. this makes the structure
of the code much cleaner. also makes it possible to fix a
locking order violation. it enables plenty of future enhancements.
* start generalizing the transport interface to be independent of puffs
* move transport interface to read/write instead of ioctl. the
old one had legacy design problems, and besides, ioctl's suck.
implement a very generic version for now; this will be
worked on later hopefully some day reaching "highly optimized".
* implement libpuffs support behind existing library request
interfaces. this will change eventually (I hate those interfaces)
userspace call, namely our private mount structure, in the activation
record. This avoids problems in situations where the userspace
file server happens to die during our upcall and the vnode is
forcibly reclaimed before we roll back to the current stack frame.
