Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-08 06:09:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Kernel/Storage/Partition/DiskPartition.h

64 lines
2.5 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 09:38:21 +01:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
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 18:58:59 +10:00
#pragma once
AK: Rename RetainPtr.h => RefPtr.h, Retained.h => NonnullRefPtr.h.
2019-06-21 18:45:35 +02:00
#include <AK/RefPtr.h>
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-08 02:17:26 +01:00
#include <Kernel/Devices/BlockDevice.h>
Kernel: Introduce a new partitioning subsystem The partitioning code was very outdated, and required a full refactor. The new subsystem removes duplicated code and uses more AK containers. The most important change is that all implementations of the PartitionTable class conform to one interface, which made it possible to remove unnecessary code in the EBRPartitionTable class. Finding partitions is now done in the StorageManagement singleton, instead of doing so in init.cpp. Also, now we don't try to find partitions on demand - the kernel will try to detect if a StorageDevice is partitioned, and if so, will check what is the partition table, which could be MBR, GUID or EBR. Then, it will create DiskPartitionMetadata object for each partition that is available in the partition table. This object will be used by the partition enumeration code to create a DiskPartition with the correct minor number.
2020-12-26 16:53:30 +02:00
#include <Kernel/Storage/Partition/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 18:58:59 +10:00
Kernel: Move all code into the Kernel namespace
2020-02-16 01:27:42 +01:00
namespace Kernel {
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-08 02:17:26 +01:00
class DiskPartition final : public BlockDevice {
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 18:58:59 +10:00
public:
Kernel: Introduce a new partitioning subsystem The partitioning code was very outdated, and required a full refactor. The new subsystem removes duplicated code and uses more AK containers. The most important change is that all implementations of the PartitionTable class conform to one interface, which made it possible to remove unnecessary code in the EBRPartitionTable class. Finding partitions is now done in the StorageManagement singleton, instead of doing so in init.cpp. Also, now we don't try to find partitions on demand - the kernel will try to detect if a StorageDevice is partitioned, and if so, will check what is the partition table, which could be MBR, GUID or EBR. Then, it will create DiskPartitionMetadata object for each partition that is available in the partition table. This object will be used by the partition enumeration code to create a DiskPartition with the correct minor number.
2020-12-26 16:53:30 +02:00
static NonnullRefPtr<DiskPartition> create(BlockDevice&, unsigned, DiskPartitionMetadata);
Kernel: Rename OffsetDiskDevice to DiskPartition
2019-06-02 19:38:37 +10: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 18:58:59 +10: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 11:16:01 -07: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 18:58:59 +10: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 23:18:47 +10:00
// ^BlockDevice
Kernel: Refactor storage stack with u64 as file operations offset
2021-03-17 13:18:51 +01:00
virtual KResultOr<size_t> read(FileDescription&, u64, UserOrKernelBuffer&, size_t) override;
Kernel: Add explicit offset parameter to File::read etc
2020-04-10 19:44:42 +10:00
virtual bool can_read(const FileDescription&, size_t) const override;
Kernel: Refactor storage stack with u64 as file operations offset
2021-03-17 13:18:51 +01:00
virtual KResultOr<size_t> write(FileDescription&, u64, const UserOrKernelBuffer&, size_t) override;
Kernel: Add explicit offset parameter to File::read etc
2020-04-10 19:44:42 +10:00
virtual bool can_write(const FileDescription&, size_t) 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 23:18:47 +10:00
Kernel: Add a method to determine the desired permissions of a Device This method will be used later in DevFS, to set the appropriate permissions for each device node.
2020-12-25 19:01:19 +02:00
// ^Device
virtual mode_t required_mode() const override { return 0600; }
Kernel: Make device generate their own names Besides removing the monolithic DevFSDeviceInode::determine_name() method, being able to determine a device's name inside the /dev hierarchy outside of DevFS has its uses.
2021-01-21 18:49:56 +01:00
virtual String device_name() const override;
Kernel: Add a method to determine the desired permissions of a Device This method will be used later in DevFS, to set the appropriate permissions for each device node.
2020-12-25 19:01:19 +02:00
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 13:17:03 +02:00
const DiskPartitionMetadata& metadata() const;
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 18:58:59 +10:00
private:
virtual const char* class_name() const override;
Kernel: Introduce a new partitioning subsystem The partitioning code was very outdated, and required a full refactor. The new subsystem removes duplicated code and uses more AK containers. The most important change is that all implementations of the PartitionTable class conform to one interface, which made it possible to remove unnecessary code in the EBRPartitionTable class. Finding partitions is now done in the StorageManagement singleton, instead of doing so in init.cpp. Also, now we don't try to find partitions on demand - the kernel will try to detect if a StorageDevice is partitioned, and if so, will check what is the partition table, which could be MBR, GUID or EBR. Then, it will create DiskPartitionMetadata object for each partition that is available in the partition table. This object will be used by the partition enumeration code to create a DiskPartition with the correct minor number.
2020-12-26 16:53:30 +02:00
DiskPartition(BlockDevice&, unsigned, DiskPartitionMetadata);
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 18:58:59 +10:00
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-08 02:17:26 +01:00
NonnullRefPtr<BlockDevice> m_device;
Kernel: Introduce a new partitioning subsystem The partitioning code was very outdated, and required a full refactor. The new subsystem removes duplicated code and uses more AK containers. The most important change is that all implementations of the PartitionTable class conform to one interface, which made it possible to remove unnecessary code in the EBRPartitionTable class. Finding partitions is now done in the StorageManagement singleton, instead of doing so in init.cpp. Also, now we don't try to find partitions on demand - the kernel will try to detect if a StorageDevice is partitioned, and if so, will check what is the partition table, which could be MBR, GUID or EBR. Then, it will create DiskPartitionMetadata object for each partition that is available in the partition table. This object will be used by the partition enumeration code to create a DiskPartition with the correct minor number.
2020-12-26 16:53:30 +02:00
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 18:58:59 +10:00
};
Kernel: Move all code into the Kernel namespace
2020-02-16 01:27:42 +01:00
}
Reference in a new issue Copy permalink