summaryrefslogtreecommitdiff
path: root/Kernel/FileSystem/Inode.cpp
diff options
context:
space:
mode:
authorAndreas Kling <kling@serenityos.org>2021-03-04 15:08:37 +0100
committerAndreas Kling <kling@serenityos.org>2021-03-04 15:42:51 +0100
commit2871df6f0d131f4777847665d9cbc0ca93e3e752 (patch)
treeca48c01c10acaa5a588d2a330bf67726deb661c2 /Kernel/FileSystem/Inode.cpp
parent9547846a1855d5c3da580c49d0f3d73157e6562e (diff)
downloadserenity-2871df6f0d131f4777847665d9cbc0ca93e3e752.zip
Kernel: Stop trying to keep InodeVMObject in sync with disk changes
As it turns out, Dr. POSIX doesn't require that post-mmap() changes to a file are reflected in the memory mappings. So we don't actually have to care about the file size changing (or the contents.) IIUC, as long as all the MAP_SHARED mappings that refer to the same inode are in sync, we're good. This means that VMObjects don't need resizing capabilities. I'm sure there are ways we can take advantage of this fact.
Diffstat (limited to 'Kernel/FileSystem/Inode.cpp')
-rw-r--r--Kernel/FileSystem/Inode.cpp14
1 files changed, 0 insertions, 14 deletions
diff --git a/Kernel/FileSystem/Inode.cpp b/Kernel/FileSystem/Inode.cpp
index 8858fd4a6d..d89e9411b6 100644
--- a/Kernel/FileSystem/Inode.cpp
+++ b/Kernel/FileSystem/Inode.cpp
@@ -137,20 +137,6 @@ void Inode::will_be_destroyed()
flush_metadata();
}
-void Inode::inode_contents_changed(off_t offset, ssize_t size, const UserOrKernelBuffer& data)
-{
- LOCKER(m_lock);
- if (auto shared_vmobject = this->shared_vmobject())
- shared_vmobject->inode_contents_changed({}, offset, size, data);
-}
-
-void Inode::inode_size_changed(size_t old_size, size_t new_size)
-{
- LOCKER(m_lock);
- if (auto shared_vmobject = this->shared_vmobject())
- shared_vmobject->inode_size_changed({}, old_size, new_size);
-}
-
int Inode::set_atime(time_t)
{
return -ENOTIMPL;