dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Kernel/Storage/DiskPartition.h

42 lines
1.3 KiB
C
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 05:38:21 -03:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 05:38:21 -03:00
*/
Kernel: Implement OffsetDiskDevice to prepare for partition support This implements a passthrough disk driver that translates the read/write block addresses by a fixed offset. This could form the basis of MBR partition support if we were to parse the MBR table at boot and create that OffsetDiskDevice dynamically, rather than seeking to a fixed offset. This also introduces a dependency in the form of grub. You'll need to have 32-bit grub binaries installed to build the project now. As a bonus, divorcing Serenity from qemu's kernel loading means we can now *technically* boot on real hardware. It just... doesn't get very far yet. If you write the `_disk_image` file to an IDE hard drive and boot it in a machine that supports all the basic PC hardware, it *will* start loading the kernel.
2019-06-02 05:58:59 -03:00
#pragma once
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-07 22:17:26 -03:00
#include <Kernel/Devices/BlockDevice.h>
Kernel: Make self-contained locking smart pointers their own classes Until now, our kernel has reimplemented a number of AK classes to provide automatic internal locking: - RefPtr - NonnullRefPtr - WeakPtr - Weakable This patch renames the Kernel classes so that they can coexist with the original AK classes: - RefPtr => LockRefPtr - NonnullRefPtr => NonnullLockRefPtr - WeakPtr => LockWeakPtr - Weakable => LockWeakable The goal here is to eventually get rid of the Lock* classes in favor of using external locking.
2022-08-19 15:53:40 -03:00
#include <Kernel/Library/LockRefPtr.h>
#include <Kernel/Library/LockWeakPtr.h>
Kernel+LibPartition: Move DiskPartitionMetadata into LibPartition This commit creates a new library LibPartition which will contain partition related code sharable between Kernel and Userland and includes DiskPartitionMetadata as the first shared class.
2022-02-12 16:21:28 -03:00
#include <LibPartition/DiskPartitionMetadata.h>
Kernel: Implement OffsetDiskDevice to prepare for partition support This implements a passthrough disk driver that translates the read/write block addresses by a fixed offset. This could form the basis of MBR partition support if we were to parse the MBR table at boot and create that OffsetDiskDevice dynamically, rather than seeking to a fixed offset. This also introduces a dependency in the form of grub. You'll need to have 32-bit grub binaries installed to build the project now. As a bonus, divorcing Serenity from qemu's kernel loading means we can now *technically* boot on real hardware. It just... doesn't get very far yet. If you write the `_disk_image` file to an IDE hard drive and boot it in a machine that supports all the basic PC hardware, it *will* start loading the kernel.
2019-06-02 05:58:59 -03:00
Kernel: Move all code into the Kernel namespace
2020-02-15 21:27:42 -03:00
namespace Kernel {
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-07 22:17:26 -03:00
class DiskPartition final : public BlockDevice {
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-11 03:19:20 -03:00
friend class DeviceManagement;
Kernel: Implement OffsetDiskDevice to prepare for partition support This implements a passthrough disk driver that translates the read/write block addresses by a fixed offset. This could form the basis of MBR partition support if we were to parse the MBR table at boot and create that OffsetDiskDevice dynamically, rather than seeking to a fixed offset. This also introduces a dependency in the form of grub. You'll need to have 32-bit grub binaries installed to build the project now. As a bonus, divorcing Serenity from qemu's kernel loading means we can now *technically* boot on real hardware. It just... doesn't get very far yet. If you write the `_disk_image` file to an IDE hard drive and boot it in a machine that supports all the basic PC hardware, it *will* start loading the kernel.
2019-06-02 05:58:59 -03:00
public:
Kernel: Make self-contained locking smart pointers their own classes Until now, our kernel has reimplemented a number of AK classes to provide automatic internal locking: - RefPtr - NonnullRefPtr - WeakPtr - Weakable This patch renames the Kernel classes so that they can coexist with the original AK classes: - RefPtr => LockRefPtr - NonnullRefPtr => NonnullLockRefPtr - WeakPtr => LockWeakPtr - Weakable => LockWeakable The goal here is to eventually get rid of the Lock* classes in favor of using external locking.
2022-08-19 15:53:40 -03:00
static NonnullLockRefPtr<DiskPartition> create(BlockDevice&, MinorNumber, Partition::DiskPartitionMetadata);
Kernel: Rename OffsetDiskDevice to DiskPartition
2019-06-02 06:38:37 -03:00
virtual ~DiskPartition();
Kernel: Implement OffsetDiskDevice to prepare for partition support This implements a passthrough disk driver that translates the read/write block addresses by a fixed offset. This could form the basis of MBR partition support if we were to parse the MBR table at boot and create that OffsetDiskDevice dynamically, rather than seeking to a fixed offset. This also introduces a dependency in the form of grub. You'll need to have 32-bit grub binaries installed to build the project now. As a bonus, divorcing Serenity from qemu's kernel loading means we can now *technically* boot on real hardware. It just... doesn't get very far yet. If you write the `_disk_image` file to an IDE hard drive and boot it in a machine that supports all the basic PC hardware, it *will* start loading the kernel.
2019-06-02 05:58:59 -03:00
Kernel: Implement an asynchronous device request stack This allows issuing asynchronous requests for devices and waiting on the completion of the request. The requests can cascade into multiple sub-requests. Since IRQs may complete at any time, if the current process is no longer the same that started the process, we need to swich the paging context before accessing user buffers. Change the PATA driver to use this model.
2020-11-02 15:16:01 -03:00
virtual void start_request(AsyncBlockDeviceRequest&) override;
Kernel: Implement OffsetDiskDevice to prepare for partition support This implements a passthrough disk driver that translates the read/write block addresses by a fixed offset. This could form the basis of MBR partition support if we were to parse the MBR table at boot and create that OffsetDiskDevice dynamically, rather than seeking to a fixed offset. This also introduces a dependency in the form of grub. You'll need to have 32-bit grub binaries installed to build the project now. As a bonus, divorcing Serenity from qemu's kernel loading means we can now *technically* boot on real hardware. It just... doesn't get very far yet. If you write the `_disk_image` file to an IDE hard drive and boot it in a machine that supports all the basic PC hardware, it *will* start loading the kernel.
2019-06-02 05:58:59 -03:00
Kernel: mount system call (#396) It is now possible to mount ext2 `DiskDevice` devices under Serenity on any folder in the root filesystem. Currently any user can do this with any permissions. There's a fair amount of assumptions made here too, that might not be too good, but can be worked on in the future. This is a good start to allow more dynamic operation under the OS itself. It is also currently impossible to unmount and such, and devices will fail to mount in Linux as the FS 'needs to be cleaned'. I'll work on getting `umount` done ASAP to rectify this (as well as working on less assumption-making in the mount syscall. We don't want to just be able to mount DiskDevices!). This could probably be fixed with some `-t` flag or something similar.
2019-08-02 10:18:47 -03:00
// ^BlockDevice
Kernel: Replace KResult and KResultOr<T> with Error and ErrorOr<T> We now use AK::Error and AK::ErrorOr<T> in both kernel and userspace! This was a slightly tedious refactoring that took a long time, so it's not unlikely that some bugs crept in. Nevertheless, it does pass basic functionality testing, and it's just real nice to finally see the same pattern in all contexts. :^)
2021-11-07 20:51:39 -03:00
virtual ErrorOr<size_t> read(OpenFileDescription&, u64, UserOrKernelBuffer&, size_t) override;
Everywhere: Run clang-format
2022-04-01 14:58:27 -03:00
virtual bool can_read(OpenFileDescription const&, u64) const override;
virtual ErrorOr<size_t> write(OpenFileDescription&, u64, UserOrKernelBuffer const&, size_t) override;
virtual bool can_write(OpenFileDescription const&, u64) const override;
Kernel: mount system call (#396) It is now possible to mount ext2 `DiskDevice` devices under Serenity on any folder in the root filesystem. Currently any user can do this with any permissions. There's a fair amount of assumptions made here too, that might not be too good, but can be worked on in the future. This is a good start to allow more dynamic operation under the OS itself. It is also currently impossible to unmount and such, and devices will fail to mount in Linux as the FS 'needs to be cleaned'. I'll work on getting `umount` done ASAP to rectify this (as well as working on less assumption-making in the mount syscall. We don't want to just be able to mount DiskDevices!). This could probably be fixed with some `-t` flag or something similar.
2019-08-02 10:18:47 -03:00
Kernel+LibPartition: Move DiskPartitionMetadata into LibPartition This commit creates a new library LibPartition which will contain partition related code sharable between Kernel and Userland and includes DiskPartitionMetadata as the first shared class.
2022-02-12 16:21:28 -03:00
Partition::DiskPartitionMetadata const& metadata() const;
Kernel: Allow to boot from a partition with partition UUID Instead of specifying the boot argument to be root=/dev/hdXY, now one can write root=PARTUUID= with the right UUID, and if the partition is found, the kernel will boot from it. This feature is mainly used with GUID partitions, and is considered to be the most reliable way for the kernel to identify partitions.
2020-12-31 08:17:03 -03:00
Kernel: Implement OffsetDiskDevice to prepare for partition support This implements a passthrough disk driver that translates the read/write block addresses by a fixed offset. This could form the basis of MBR partition support if we were to parse the MBR table at boot and create that OffsetDiskDevice dynamically, rather than seeking to a fixed offset. This also introduces a dependency in the form of grub. You'll need to have 32-bit grub binaries installed to build the project now. As a bonus, divorcing Serenity from qemu's kernel loading means we can now *technically* boot on real hardware. It just... doesn't get very far yet. If you write the `_disk_image` file to an IDE hard drive and boot it in a machine that supports all the basic PC hardware, it *will* start loading the kernel.
2019-06-02 05:58:59 -03:00
private:
Kernel/Storage: Don't hardcode a maximum of 16 partitions per drive In the near future, we will be able to figure out connections between storage devices and their partitions, so there's no need to hardcode 16 partitions per storage device - each storage device should be able to have "infinite" count of partitions in it, and we should be able to use and figure out about them.
2022-07-23 05:15:35 -03:00
DiskPartition(BlockDevice&, MinorNumber, Partition::DiskPartitionMetadata);
Kernel: Make various T::class_name() and similar return StringView Instead of returning char const*, we can also give you a StringView.
2021-07-10 20:46:09 -03:00
virtual StringView class_name() const override;
Kernel: Implement OffsetDiskDevice to prepare for partition support This implements a passthrough disk driver that translates the read/write block addresses by a fixed offset. This could form the basis of MBR partition support if we were to parse the MBR table at boot and create that OffsetDiskDevice dynamically, rather than seeking to a fixed offset. This also introduces a dependency in the form of grub. You'll need to have 32-bit grub binaries installed to build the project now. As a bonus, divorcing Serenity from qemu's kernel loading means we can now *technically* boot on real hardware. It just... doesn't get very far yet. If you write the `_disk_image` file to an IDE hard drive and boot it in a machine that supports all the basic PC hardware, it *will* start loading the kernel.
2019-06-02 05:58:59 -03:00
Kernel: Make self-contained locking smart pointers their own classes Until now, our kernel has reimplemented a number of AK classes to provide automatic internal locking: - RefPtr - NonnullRefPtr - WeakPtr - Weakable This patch renames the Kernel classes so that they can coexist with the original AK classes: - RefPtr => LockRefPtr - NonnullRefPtr => NonnullLockRefPtr - WeakPtr => LockWeakPtr - Weakable => LockWeakable The goal here is to eventually get rid of the Lock* classes in favor of using external locking.
2022-08-19 15:53:40 -03:00
LockWeakPtr<BlockDevice> m_device;
Kernel+LibPartition: Move DiskPartitionMetadata into LibPartition This commit creates a new library LibPartition which will contain partition related code sharable between Kernel and Userland and includes DiskPartitionMetadata as the first shared class.
2022-02-12 16:21:28 -03:00
Partition::DiskPartitionMetadata m_metadata;
Kernel: Implement OffsetDiskDevice to prepare for partition support This implements a passthrough disk driver that translates the read/write block addresses by a fixed offset. This could form the basis of MBR partition support if we were to parse the MBR table at boot and create that OffsetDiskDevice dynamically, rather than seeking to a fixed offset. This also introduces a dependency in the form of grub. You'll need to have 32-bit grub binaries installed to build the project now. As a bonus, divorcing Serenity from qemu's kernel loading means we can now *technically* boot on real hardware. It just... doesn't get very far yet. If you write the `_disk_image` file to an IDE hard drive and boot it in a machine that supports all the basic PC hardware, it *will* start loading the kernel.
2019-06-02 05:58:59 -03:00
};
Kernel: Move all code into the Kernel namespace
2020-02-15 21:27:42 -03:00
}
Reference in a new issue Copy permalink