the gDeviceNameList[] entries are no longer in the same order.
* This fixes bug #3124.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29593 a95241bf-73f2-0310-859d-f6bbb57e9c96
is done with it, since we still need to serve file cache requests.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29587 a95241bf-73f2-0310-859d-f6bbb57e9c96
put_vnode() might be removed from our map, if that was the last reference to
the node, so _DecrementVNodeCount() would emit an error message -- harmless
but annoying. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29586 a95241bf-73f2-0310-859d-f6bbb57e9c96
and probably only works for CDs as is (ie. not for USB sticks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29584 a95241bf-73f2-0310-859d-f6bbb57e9c96
something comes in -- this could be greatly improved, though.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29583 a95241bf-73f2-0310-859d-f6bbb57e9c96
device additions/removals can be monitored.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29582 a95241bf-73f2-0310-859d-f6bbb57e9c96
kernel implementation ignores, so we should allow that in userland, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29580 a95241bf-73f2-0310-859d-f6bbb57e9c96
too. It's slightly adjusted to use the thread blocking syscalls and a benaphore
style threads spinlock replacement. This solves the following problems:
* The static mutex/rwlock initializers are safe now.
* The rwlock implementation is compatible with the kernel implementation. E.g.
a write lock owner can acquire a read lock, which would dead-lock before.
* We don't use semaphores anymore. With a userland BFS one could quite easily
hit the global semaphore limit before.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29579 a95241bf-73f2-0310-859d-f6bbb57e9c96
makes them more convenient to use, since the caller doesn't need to know the
target threads' user thread structure.
* Adjusted the pthread rwlock implementation accordingly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29578 a95241bf-73f2-0310-859d-f6bbb57e9c96
the free list. Do that with the threads lock held. This allows other threads
to freely access a thread's user thread structure while holding the threads
lock.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29577 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Increment the vnode reference count in NewVNode().
* Introduced a VNode::published flag that allows PublishVNode() (a) to discard
the node on error and (b) not to increment the node's reference count in case
the node had been created by NewVNode() before.
* Added missing fVNodeCountingEnabled check in _RemoveInvalidVNode().
* _PutAllPendingVNodes():
- nodeFound was never reset, so it would loop forever, if there was at
least one node that needed to be put.
- VNode::useCount needs to be set to 0 explicitely. Since vnode reference
count tracking is already disabled PutVNode() doesn't decrement it and
thus we would loop forever, respectively cause the VFS to panic() first.
- If the node has not been published, we need to publish it before putting
it, since otherwise the VFS would complain that the node is busy.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29576 a95241bf-73f2-0310-859d-f6bbb57e9c96
class must take care of these things.
* Automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29574 a95241bf-73f2-0310-859d-f6bbb57e9c96
We do some caching using a hash table indexed by the operations vector.
* Pass the vnode capabilities to the kernel module.
* In the kernel tailor the operation vectors for volumes and vnodes passed to
the VFS according to the respective capabilities. This way those vectors look
pretty much like those from the client FS. This saves unnecessary calls when
hooks are not implemented and should also fix compatibility problems in cases
where not implementing a hook and returning an error don't mean the same to
the VFS.
* Inlined some of the kernel module Volume class getters.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29572 a95241bf-73f2-0310-859d-f6bbb57e9c96
FileCacheWriteRequest. Stacking requests is now possible, so reentering the
file system while serving those requests is no problem anymore. BFS seems to
be quite happy as far as I've tested it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29566 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Send() now also gets the message to send as parameter.
- Added methods to reserve and unreserve space in the buffer.
* RequestAllocator: Uses the port buffer reservation methods now. This allows
to let more than one RequestAllocator use a Port in a stack-like manner.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29565 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Change Port::Receive() semantics. It does no longer use the buffer associated
with the object. Instead it allocates heap memory for the caller. Since
there's only one caller who clones the message anyway, we save one copy this
way (though we have an additional syscall in userland) and don't overwrite
a request being prepared for sending.
* Changed RequestAllocator::ReadRequest() to also read the request from the
port.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29563 a95241bf-73f2-0310-859d-f6bbb57e9c96
the header is used for compiling with -std=c99 or -std=gnu99 and GCC4, which
has a reverted meaning of "extern inline" (now standard compliant).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29558 a95241bf-73f2-0310-859d-f6bbb57e9c96
libavcodec ASM code to fix the GCC4 build. Tested with GCC4 on Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29557 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The loop is unnecessary, since the call doesn't block anyway, so it can't
be interrupted.
* Set the holder, if KDEBUG is enabled. Otherwise the panic() in
recursive_lock_unlock() would be triggered.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29556 a95241bf-73f2-0310-859d-f6bbb57e9c96
file_cache_read() will reenter the file system which will overwrite the
buffer associated with the port, so we can't allocate space in the buffer
before calling it.
* FileCacheWriteRequest still has a similar problem, though it's probably better
to rethink the kernel-userland communication completely.
BFS basically seems to work in userland, now. Didn't really test write
operations though. They will probably run into problems due to the issue above.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29555 a95241bf-73f2-0310-859d-f6bbb57e9c96
to userland, since typically the file cache for the node is created there
and our FileCacheCreate() method requires and existing VNode object.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29554 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Passing a NULL parameter to file_cache_delete() is OK.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29553 a95241bf-73f2-0310-859d-f6bbb57e9c96
* don't create the directory with the link name, only the parent
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29549 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Pass the request offset and length with the DoIORequest. This allows us to
already get the first vecs for do_iterative_fd_io() in userland, saving a
trip back and forth.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29546 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo Weinhold