* Replaced the use of offsetof() for structs that aren't PODs. Add a
offset_of_member() macro to util/khash.h because that's what it's used for
in our cases.
* Change the signature of add_debugger_command()/remove_debugger_command() on
GCC > 2 to avoid the depricated conversion from string constants to char *.
* Adding some "suggested" parenthesis. I know that not everyone likes that, but
it pointed out at least one bug that is fixed here as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29113 a95241bf-73f2-0310-859d-f6bbb57e9c96
will now accepted and regarded as sparse file data. FileMap::_Add() also
correctly joins multiple vecs with that offset together, FileMap::Translate()
will always report offset -1 even for offsets into that extent.
* read_file_io_vec_pages() (or rather, its backend common_file_io_vec_pages())
now supports sparse files, and will just clear the memory it should read from
offset -1 instead of passing a request to the vnode.
* ext2 now correctly reports sparse files. This should close bug #2889, as well
as #975.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28648 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Turned the checks for all those macros to "#if"s instead of "#ifdef"s.
* Introduced macro KDEBUG_LEVEL which serves as a master setting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28248 a95241bf-73f2-0310-859d-f6bbb57e9c96
vector at the end of the file will be aligned to the given value.
* BFS uses an alignment of 512 bytes (should be block size of the
underlying device or BFS block size, whatever is less), which should
be fine, since file data are only stored in BFS blocks. This totally
avoids any partial operations at the I/O scheduler level, thus saving
disk operations. Not that I could measure any performance difference.
Theoretically it should help a lot though, particularly when dealing
with lots of small files, since we avoid using bounce buffers, which
are (a) limited in number and (b) require copying of the data.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27246 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added file_map_set_mode() function that you can use to keep a whole file
cached. This is needed for the swap file support: FILE_MAP_CACHE_ALL will
not only precache all file_io_vecs when called, but it will also cause all
file_map_translate() calls to fail that would require further caching (ie.
if the file size had changed).
* Updated the fs_shell file map code to the latest one (with several bug fixes).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26785 a95241bf-73f2-0310-859d-f6bbb57e9c96
introduces the following relevant changes:
* VMCache:
- Renamed vm_cache to VMCache, merged it with vm_store and made it a
C++ class with virtual methods (replacing the store operations).
Turned the different store implementations into subclasses.
- Introduced MergeStore() callback, changed semantics of Commit().
- Changed locking and referencing semantics. A reference can only be
acquired/released with the cache locked. An unreferenced cache is
deleted and a mergeable cache merged when it is unlocked. This
removes the "busy" state of a cache and simplifies the page fault
code.
* Added VMAnonymousCache, which will implement swap support (work by
Zhao Shuai). It is not integrated and used yet, though.
* Enabled the mutex/recursive lock holder asserts.
* Fixed DoublyLinkedList::Swap().
* Generalized the low memory handler to a low resource handler. And made
semaphores and reserved memory handled resources. Made
vm_try_resource_memory() optionally wait (with timeout), and used that
feature to reserve memory for areas.
...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26572 a95241bf-73f2-0310-859d-f6bbb57e9c96
* FileMap::_InvalidateAfter():
- Off-by-one error. The last extend (which normally should be kept)
was thrown away, too, but still accessed afterwards. Worst case
could be a write to free()d memory.
- Drop the last extend when it would be truncated to zero size.
* FileMap::Translate():
- Incorrect handling of B_BUFFER_OVERFLOW case in the
vfs_get_file_map() loop. After the loop the function would return
incorrectly, making the caller think all vectors in the provided
array had been initialized correctly. This could cause a file system
implementation using the file map to read from or write to random
disk locations, in the latter case possibly corrupting the file
system.
- Some readability improvements in the final loop. Removed incorrect
check.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26523 a95241bf-73f2-0310-859d-f6bbb57e9c96
systems like BFS only hold a read lock when reading the map, accessing the
file map wasn't safe.
* Made FileMap::Free() private, and renamed it to _Free().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26295 a95241bf-73f2-0310-859d-f6bbb57e9c96
* adjacent vecs are now joined.
* partial invalidation no longer frees all cached extents.
* the array can now be larger than the needed number of entries, allowing
for a saner array allocation policy.
* it does no longer read the whole file map when the first translation is
requested, but only as much as required (it will still ask the file system
for the maximum file size, but it won't traverse further as long as the
initial request is fulfilled).
* This should help a lot with the ext2 file system that doesn't support real
file extents (but keeps a list of blocks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26260 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved the file_extent array into its own structure (unnamed union problem
with GCC4), and added max_count field (currently unused).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26259 a95241bf-73f2-0310-859d-f6bbb57e9c96
set when the first chunk of the file could be read in directly, causing it
to read data to a wrong place in the buffer.
* Reading in the first chunk directly would have also only worked if vecIndex
and vecOffset was 0 when calling the function.
* Applied the fs_shell changes in file_map to the kernel version as well (the
constructor already worked correctly, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23265 a95241bf-73f2-0310-859d-f6bbb57e9c96
the complete extent info or not.
* file_map_translate() now cuts down the request to the file bounds.
* Adjusted BFS and FAT to the API changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22913 a95241bf-73f2-0310-859d-f6bbb57e9c96
that can be used by file systems.
* Changed the way the file cache works: instead of reading/writing to the
underlying device directly, it can now be used for any data source, ie.
also network file systems.
* As a result, the former pages_io() moved to the VFS layer, and can now be
called by a file system via {read|write}_file_io_vec_pages() (naming
suggestions are always welcomed :-)). It now gets an FD, and uses that to
communicate with the device (via its fs_{read|write}_pages() hooks).
* The file_cache_{read|write}() functions must now be called without holding
an I/O relevant file system lock. That allows the file cache to prepare the
pages without colliding with the page writer, IOW the "mayBlock" flag can
go into the attic again (yay!).
* This also results in a much better performance when the system does I/O and
is low on memory, as the page writer can now finally write back some pages,
and that even without maxing out the CPU :)
* The API changes put slightly more burden on the fs_{read|write}_pages()
hooks, but in combination with the file_map it's still pretty straight
forward. It just will have to dispatch the call to the underlying device
directly, usually it will just call its fs_{read|write}_pages() hooks
via the above mentioned calls.
* Ported BFS and FAT to the new API, the latter has not been tested, though.
* Also ported the API changes to the fs_shell. I also completely removed its
file cache level page handling - the downside is that device access is no
longer cached (ie. depends on the host OS now), the upside is that the code
is greatly simplified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22886 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo Weinhold