ladybird/Kernel/Devices/NullDevice.cpp
Liav A aee4786d8e Kernel: Introduce the DeviceManagement singleton
This singleton simplifies many aspects that we struggled with before:
1. There's no need to make derived classes of Device expose the
constructor as public anymore. The singleton is a friend of them, so he
can call the constructor. This solves the issue with try_create_device
helper neatly, hopefully for good.
2. Getting a reference of the NullDevice is now being done from this
singleton, which means that NullDevice no longer needs to use its own
singleton, and we can apply the try_create_device helper on it too :)
3. We can now defer registration completely after the Device constructor
which means the Device constructor is merely assigning the major and
minor numbers of the Device, and the try_create_device helper ensures it
calls the after_inserting method immediately after construction. This
creates a great opportunity to make registration more OOM-safe.
2021-09-17 01:02:48 +03:00

47 lines
1.0 KiB
C++

/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <AK/Singleton.h>
#include <Kernel/Devices/DeviceManagement.h>
#include <Kernel/Devices/NullDevice.h>
#include <Kernel/Sections.h>
namespace Kernel {
UNMAP_AFTER_INIT NonnullRefPtr<NullDevice> NullDevice::must_initialize()
{
auto null_device_or_error = DeviceManagement::try_create_device<NullDevice>();
// FIXME: Find a way to propagate errors
VERIFY(!null_device_or_error.is_error());
return null_device_or_error.release_value();
}
UNMAP_AFTER_INIT NullDevice::NullDevice()
: CharacterDevice(1, 3)
{
}
UNMAP_AFTER_INIT NullDevice::~NullDevice()
{
}
bool NullDevice::can_read(const OpenFileDescription&, size_t) const
{
return true;
}
KResultOr<size_t> NullDevice::read(OpenFileDescription&, u64, UserOrKernelBuffer&, size_t)
{
return 0;
}
KResultOr<size_t> NullDevice::write(OpenFileDescription&, u64, const UserOrKernelBuffer&, size_t buffer_size)
{
return buffer_size;
}
}