Searched +hist:58 +hist:f6e8e5 (Results 1 - 5 of 5) sorted by relevance

/haiku/src/system/kernel/vm/
H A DJamfilediff 0606074f Tue Sep 04 09:58:38 MDT 2012 Alexander von Gluck IV <kallisti5@unixzen.com> Kernel VM: Improve swap file selection

* Heavily based on Hamish Morrison's GCI work with some
modified logic and cleanup. #3723
* Adds automatic swap as well as user specified swap
* Limits:
Automatic: (ram * 2) up to 25% of the disk
User: user specified up to 90% of the disk
* Supports changing the swap disk location
diff 58f6e8e5 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 0606074fd9e8ba5c10ef854c44a475fce65fca21 Tue Sep 04 09:58:38 MDT 2012 Alexander von Gluck IV <kallisti5@unixzen.com> Kernel VM: Improve swap file selection

* Heavily based on Hamish Morrison's GCI work with some
modified logic and cleanup. #3723
* Adds automatic swap as well as user specified swap
* Limits:
Automatic: (ram * 2) up to 25% of the disk
User: user specified up to 90% of the disk
* Supports changing the swap disk location
diff 58f6e8e5e4aeee797ecd3bb7bed17d5a3a2029c0 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A Dvm.cppdiff d4823423 Fri Apr 05 08:58:50 MDT 2013 Ingo Weinhold <ingo_weinhold@gmx.de> VM: Fix vm_block_address_range() area protection

B_ALREADY_WIRED, which was erroneously passed for the area protection
parameter to map_backing_store(), has the value 7 which implies user
readable and writable. Hence the address ranges around 0xdeadbeef and
0xcccccccc could actually be read and written from anywhere.
diff 176f7588 Wed Feb 17 08:58:12 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> Added warning to vm_map_physical_memory_vecs().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35508 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff cff6e9e4 Tue Jan 26 07:44:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * The system now holds back a small reserve of committable memory and pages. The
memory and page reservation functions have a new "priority" parameter that
indicates how deep the function may tap into that reserve. The currently
existing priority levels are "user", "system", and "VIP". The idea is that
user programs should never be able to cause a state that gets the kernel into
trouble due to heavy battling for memory. The "VIP" level (not really used
yet) is intended for allocations that are required to free memory eventually
(in the page writer). More levels are thinkable in the future, like "user real
time" or "user system server".
* Added "priority" parameters to several VMCache methods.
* Replaced the map_backing_store() "unmapAddressRange" parameter by a "flags"
parameter.
* Added area creation flag CREATE_AREA_PRIORITY_VIP and slab allocator flag
CACHE_PRIORITY_VIP indicating the importance of the request.
* Changed most code to pass the right priorities/flags.

These changes already significantly improve the behavior in low memory
situations. I've tested a bit with 64 MB (virtual) RAM and, while not
particularly fast and responsive, the system remains at least usable under high
memory pressure.
As a side effect the slab allocator can now be used as general memory allocator.
Not done by default yet, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35295 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff b4e5e498 Mon Jan 25 06:46:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> MemoryManager:
* Added support to do larger raw allocations (up to one large chunk (128 pages))
in the slab areas. For an even larger allocation an area is created (haven't
seen that happen yet, though).
* Added kernel tracing (SLAB_MEMORY_MANAGER_TRACING).
* _FreeArea(): Copy and paste bug: The meta chunks of the to be freed area
would be added to the free lists instead of being removed from them. This
would corrupt the lists and also lead to all kinds of misuse of meta chunks.

object caches:
* Implemented CACHE_ALIGN_ON_SIZE. It is no longer set for all small object
caches, but the block allocator sets it on all power of two size caches.
* object_cache_reserve_internal(): Detect recursion and don't wait in such a
case. The function could deadlock itself, since
HashedObjectCache::CreateSlab() does allocate memory, thus potentially
reentering.
* object_cache_low_memory():
- I missed some returns when reworking that one in r35254, so the function
might stop early and also leave the cache in maintenance mode, which would
cause it to be ignored by object cache resizer and low memory handler from
that point on.
- Since ReturnSlab() potentially unlocks, the conditions weren't quite correct
and too many slabs could be freed.
- Simplified things a bit.
* object_cache_alloc(): Since object_cache_reserve_internal() does potentially
unlock the cache, the situation might have changed and their might not be an
empty slab available, but a partial one. The function would crash.
* Renamed the object cache tracing variable to SLAB_OBJECT_CACHE_TRACING.
* Renamed debugger command "cache_info" to "slab_cache" to avoid confusion with
the VMCache commands.
* ObjectCache::usage was not maintained anymore since I introduced the
MemoryManager. object_cache_get_usage() would thus always return 0 and the
block cache would not be considered cached memory. This was only of
informational relevance, though.

slab allocator misc.:
* Disable the object depots of block allocator caches for object sizes > 2 KB.
Allocations of those sizes aren't so common that the object depots yield any
benefit.
* The slab allocator is now fully self-sufficient. It allocates its bootstrap
memory from the MemoryManager, and the hash tables for HashedObjectCaches use
the block allocator instead of the heap, now.
* Added option to use the slab allocator for malloc() and friends
(USE_SLAB_ALLOCATOR_FOR_MALLOC). Currently disabled. Works in principle and
has virtually no lock contention. Handling for low memory situations is yet
missing, though.
* Improved the output of some debugger commands.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35283 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8a65066a Fri Jan 22 12:58:04 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> vm_soft_fault(): map_page() can fail for B_NO_LOCK areas, since it needs to
allocate a page mapping. In that case we do at least have to mark the page
not busy again. Furthermore we enforce the minimum page mappings object cache
reserve, so we'll have more luck on the next fault.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35241 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff cb8617c1 Tue Jan 05 15:02:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> unmap_and_free_physical_pages(): Added missing check whether the page
mapping is actually present. This would have resulted in page 0 being freed
over and over again, if we hadn't also incorrectly tried to look up the page
by the virtual instead of the physical address. So we were actually freeing
random pages. Fortunately the virtual addresses are kernel addresses, so that
the affected pages lay beyond 2 GB and probably weren't used at this point
yet.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34912 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff e717a35b Thu Sep 10 11:58:19 MDT 2009 Michael Lotz <mmlr@mlotz.ch> * Change the way we check for enough available space when searching for spots
to insert areas so we don't overflow.
* Consequently use the area end (base + size - 1) where appropriate which
prevents overflows in a few places.
* Properly check for reaching the address space end.
* If we've already found a spot we don't need to recheck if we've found one.
* Simplify the B_EXACT_ADDRESS checks down to a simpler single if statement
instead of the four seperate ones.
* Properly calculate the search end for B_EXACT_ADDRESS as well, it's also
base + size - 1.
* Block the full last page now that this actually works without overflowing.
* Some style changes and added spacing.

This should now really fix #2550. Previously the overflow protection didn't
actually work because on allocation we overflowed and completely missed the
protecting area.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33037 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff eb2bd0e8 Mon Apr 27 12:16:58 MDT 2009 Stephan Aßmus <superstippi@gmx.de> axeld:
* Implemented a way to do asynchronous pre-fetching when mapping files.
* There are slight code duplications in some places that could benefit
from cleaning up, but nothing too bad.
* Implementing smarter ways to trigger prefetching and more analysis of
the situations in the kernel would be nice. Currently up to 10 MB
of every mapped file are pre-fetched without further analysis.
* The speed improvement is nice for certain operations. On our test
system (real hardware), Firefox took 9 seconds from being launched
to display a window. Now it takes 5 seconds. Both measurements
right after booting. The same system took 35 seconds from launching
Haiku in the GRUB menu to displaying the Tracker desktop background
image. Now it takes 27 seconds.
* We didn't have the chance to check out the effects of this on the
CD boot, but potentially, they could speed it up a lot.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30465 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff b64e66fb Tue Jul 08 19:56:58 MDT 2008 Ingo Weinhold <ingo_weinhold@gmx.de> Changes related to the "caches" command:
* The table used for sorting the caches could be too small for the
number of caches in the system. We never checked that, which could
cause a crash or triple faults when invoking the command.
* We now allocate the table as an area. Also increased the table size to
102400 entries.
* Also print the committed memory for non-RAM caches, if they are the
root cache of a cache tree that has committed memory.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26333 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 013f781f Wed Oct 10 03:58:25 MDT 2007 Axel Dörfler <axeld@pinc-software.de> vm_test_map_{modification|activation}(), vm_clear_map_flags(), and
vm_remove_all_page_mappings() all computed the wrong virtual address for the
page in question, and would therefore return incorrect data!
Introduced a virtual_page_address() function that is now used by all of them.
So that's why we were still "losing" modified flags - it took me some hours
to find those (sometimes processes died after stealing pages)...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22498 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/kernel/cache/
H A Dfile_cache.cppdiff cff6e9e4 Tue Jan 26 07:44:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * The system now holds back a small reserve of committable memory and pages. The
memory and page reservation functions have a new "priority" parameter that
indicates how deep the function may tap into that reserve. The currently
existing priority levels are "user", "system", and "VIP". The idea is that
user programs should never be able to cause a state that gets the kernel into
trouble due to heavy battling for memory. The "VIP" level (not really used
yet) is intended for allocations that are required to free memory eventually
(in the page writer). More levels are thinkable in the future, like "user real
time" or "user system server".
* Added "priority" parameters to several VMCache methods.
* Replaced the map_backing_store() "unmapAddressRange" parameter by a "flags"
parameter.
* Added area creation flag CREATE_AREA_PRIORITY_VIP and slab allocator flag
CACHE_PRIORITY_VIP indicating the importance of the request.
* Changed most code to pass the right priorities/flags.

These changes already significantly improve the behavior in low memory
situations. I've tested a bit with 64 MB (virtual) RAM and, while not
particularly fast and responsive, the system remains at least usable under high
memory pressure.
As a side effect the slab allocator can now be used as general memory allocator.
Not done by default yet, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35295 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff eb2bd0e8 Mon Apr 27 12:16:58 MDT 2009 Stephan Aßmus <superstippi@gmx.de> axeld:
* Implemented a way to do asynchronous pre-fetching when mapping files.
* There are slight code duplications in some places that could benefit
from cleaning up, but nothing too bad.
* Implementing smarter ways to trigger prefetching and more analysis of
the situations in the kernel would be nice. Currently up to 10 MB
of every mapped file are pre-fetched without further analysis.
* The speed improvement is nice for certain operations. On our test
system (real hardware), Firefox took 9 seconds from being launched
to display a window. Now it takes 5 seconds. Both measurements
right after booting. The same system took 35 seconds from launching
Haiku in the GRUB menu to displaying the Tracker desktop background
image. Now it takes 27 seconds.
* We didn't have the chance to check out the effects of this on the
CD boot, but potentially, they could speed it up a lot.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30465 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 09149281 Thu Nov 08 02:30:58 MST 2007 Axel Dörfler <axeld@pinc-software.de> The file cache now completely bypasses the cache for writes equal or larger
than 64KB. Reads should probably get a similar logic, at least if memory is
tight.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22857 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 18685752 Mon Aug 01 08:24:58 MDT 2005 Axel Dörfler <axeld@pinc-software.de> cache_prefetch() now comes in two flavours: one with a direct vnode pointer,
the other one with usual device/inode ID pair.
Both versions now accept an offset/size pair to specify the region of the
file to be prefetched - this may be turned into a file_vec_io array later on.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13866 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff cff6e9e406132a76bfc20cb35ff5228dd0ba94d8 Tue Jan 26 07:44:58 MST 2010 Ingo Weinhold <ingo_weinhold@gmx.de> * The system now holds back a small reserve of committable memory and pages. The
memory and page reservation functions have a new "priority" parameter that
indicates how deep the function may tap into that reserve. The currently
existing priority levels are "user", "system", and "VIP". The idea is that
user programs should never be able to cause a state that gets the kernel into
trouble due to heavy battling for memory. The "VIP" level (not really used
yet) is intended for allocations that are required to free memory eventually
(in the page writer). More levels are thinkable in the future, like "user real
time" or "user system server".
* Added "priority" parameters to several VMCache methods.
* Replaced the map_backing_store() "unmapAddressRange" parameter by a "flags"
parameter.
* Added area creation flag CREATE_AREA_PRIORITY_VIP and slab allocator flag
CACHE_PRIORITY_VIP indicating the importance of the request.
* Changed most code to pass the right priorities/flags.

These changes already significantly improve the behavior in low memory
situations. I've tested a bit with 64 MB (virtual) RAM and, while not
particularly fast and responsive, the system remains at least usable under high
memory pressure.
As a side effect the slab allocator can now be used as general memory allocator.
Not done by default yet, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35295 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff eb2bd0e8e3689998717f91d8b9023296e3f32e78 Mon Apr 27 12:16:58 MDT 2009 Stephan Aßmus <superstippi@gmx.de> axeld:
* Implemented a way to do asynchronous pre-fetching when mapping files.
* There are slight code duplications in some places that could benefit
from cleaning up, but nothing too bad.
* Implementing smarter ways to trigger prefetching and more analysis of
the situations in the kernel would be nice. Currently up to 10 MB
of every mapped file are pre-fetched without further analysis.
* The speed improvement is nice for certain operations. On our test
system (real hardware), Firefox took 9 seconds from being launched
to display a window. Now it takes 5 seconds. Both measurements
right after booting. The same system took 35 seconds from launching
Haiku in the GRUB menu to displaying the Tracker desktop background
image. Now it takes 27 seconds.
* We didn't have the chance to check out the effects of this on the
CD boot, but potentially, they could speed it up a lot.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30465 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 09149281e0a088a2a9ad78ea5abd033217c15bb8 Thu Nov 08 02:30:58 MST 2007 Axel Dörfler <axeld@pinc-software.de> The file cache now completely bypasses the cache for writes equal or larger
than 64KB. Reads should probably get a similar logic, at least if memory is
tight.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22857 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5e4aeee797ecd3bb7bed17d5a3a2029c0 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/headers/private/kernel/
H A Dvfs.hdiff eb2bd0e8 Mon Apr 27 12:16:58 MDT 2009 Stephan Aßmus <superstippi@gmx.de> axeld:
* Implemented a way to do asynchronous pre-fetching when mapping files.
* There are slight code duplications in some places that could benefit
from cleaning up, but nothing too bad.
* Implementing smarter ways to trigger prefetching and more analysis of
the situations in the kernel would be nice. Currently up to 10 MB
of every mapped file are pre-fetched without further analysis.
* The speed improvement is nice for certain operations. On our test
system (real hardware), Firefox took 9 seconds from being launched
to display a window. Now it takes 5 seconds. Both measurements
right after booting. The same system took 35 seconds from launching
Haiku in the GRUB menu to displaying the Tracker desktop background
image. Now it takes 27 seconds.
* We didn't have the chance to check out the effects of this on the
CD boot, but potentially, they could speed it up a lot.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30465 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff dfb71e04 Sun Dec 12 13:33:58 MST 2004 Axel Dörfler <axeld@pinc-software.de> Added a query length parameter to _kern_open_query() - it's much easier to
do these things in userland.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10397 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff f8d76107 Wed Jul 10 15:46:34 MDT 2002 Axel Dörfler <axeld@pinc-software.de> Added the syscalls for sys_read_dir(), and sys_rewind_dir().
sys_read_dir() now has a parameter for the maximum number of dirents that
are handled by the upper layer - which is currently 1.
Added a comment in fd.h to ease the location of the sys|user prototypes
of the corresponding functions in fd.c.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@58 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff eb2bd0e8e3689998717f91d8b9023296e3f32e78 Mon Apr 27 12:16:58 MDT 2009 Stephan Aßmus <superstippi@gmx.de> axeld:
* Implemented a way to do asynchronous pre-fetching when mapping files.
* There are slight code duplications in some places that could benefit
from cleaning up, but nothing too bad.
* Implementing smarter ways to trigger prefetching and more analysis of
the situations in the kernel would be nice. Currently up to 10 MB
of every mapped file are pre-fetched without further analysis.
* The speed improvement is nice for certain operations. On our test
system (real hardware), Firefox took 9 seconds from being launched
to display a window. Now it takes 5 seconds. Both measurements
right after booting. The same system took 35 seconds from launching
Haiku in the GRUB menu to displaying the Tracker desktop background
image. Now it takes 27 seconds.
* We didn't have the chance to check out the effects of this on the
CD boot, but potentially, they could speed it up a lot.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30465 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5e4aeee797ecd3bb7bed17d5a3a2029c0 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff dfb71e0444a5e5cc3bce5de3355e20a65f9055e7 Sun Dec 12 13:33:58 MST 2004 Axel Dörfler <axeld@pinc-software.de> Added a query length parameter to _kern_open_query() - it's much easier to
do these things in userland.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10397 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff f8d76107147f6371649c7ab2f8dd7a0cf8146c64 Wed Jul 10 15:46:34 MDT 2002 Axel Dörfler <axeld@pinc-software.de> Added the syscalls for sys_read_dir(), and sys_rewind_dir().
sys_read_dir() now has a parameter for the maximum number of dirents that
are handled by the upper layer - which is currently 1.
Added a comment in fd.h to ease the location of the sys|user prototypes
of the corresponding functions in fd.c.


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@58 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/system/kernel/fs/
H A Dvfs.cppdiff 36c1b695 Thu Mar 21 12:23:58 MDT 2024 Augustin Cavalier <waddlesplash@gmail.com> kernel/vfs: Make vnode_path_to_vnode use VnodePutter internally.

Eliminates the "goto"s. Should not have any functional change.
diff 8ba3797e Thu Aug 18 11:58:14 MDT 2022 Augustin Cavalier <waddlesplash@gmail.com> kernel/fs: Check HAS_FS_CALL(..., open_dir) in open_dir_vnode.

All filesystems have open_dir calls in their vnode hooks,
but there are some vnode hooks that do not, like FIFOs.
Thus we need to check the hook actually exists.

Fixes #17870.
diff a9c09fca Fri Nov 06 16:02:58 MST 2020 Jérôme Duval <jerome.duval@gmail.com> POSIX: lseek: support SEEK_DATA and SEEK_HOLE constants

this is queued for issue 8: https://www.austingroupbugs.net/view.php?id=415
this implementation calls the ioctl hook of the filesystem with BSD-like constants
FIOSEEKDATA and FIOSEEKHOLE. if the hook doesn't know the constants, we use the stat size
to return the last hole (as proposed in the draft spec).

Change-Id: I5d052eed87e29b70491a7ff534e244896469d03e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3385
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
diff 548836e4 Wed Mar 02 11:58:14 MST 2011 Jérôme Duval <korli@users.berlios.de> * if ioctl hook wasn't found, now returns B_DEV_INVALID_IOCTL
* in case fd_ioctl() was about to return B_DEV_INVALID_IOCTL, translate to ENOTTY to satisfy #7279.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40787 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 095a7d84 Sun Oct 18 16:58:29 MDT 2009 Jérôme Duval <korli@users.berlios.de> using chroot with a mount point wrongly exposed the mount point name: we now avoid resolving the volume root in case we hit the IO context root.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33645 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 67804f25 Mon Oct 27 08:33:58 MDT 2008 Axel Dörfler <axeld@pinc-software.de> * fs_unmount() removed the vnodes of the fs_mount twice since r28215,
triggering an assert.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28344 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 8687956a Sun Sep 09 08:38:58 MDT 2007 Ingo Weinhold <ingo_weinhold@gmx.de> * Added a clarifying comment to free_vnode() and prevented the vnode
reference count to drop below 0 there.
* Added TODO describing a serious race condition between free_vnode()
and the page daemon.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22209 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 58f6e8e5 Tue Jul 17 18:16:27 MDT 2007 Axel Dörfler <axeld@pinc-software.de> * Merged vm_cache_ref and vm_cache to a single structure (Axel & Ingo).
* Renamed vm_cache.c to vm_cache.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21642 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff c926cb8d Mon Feb 19 08:57:58 MST 2007 François Revol <revol@free.fr> Return sensible errors instead of -1. Added some TODO comments.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20166 a95241bf-73f2-0310-859d-f6bbb57e9c96

Completed in 611 milliseconds