LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-12-29 06:02:07 +03:00
Code Issues Packages Projects Releases Wiki Activity
c12d153894
ladybird/Kernel/Devices/DiskPartition.h

31 lines
1.1 KiB
C
Raw Normal View History

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 11:58:59 +03:00
#pragma once
AK: Rename RetainPtr.h => RefPtr.h, Retained.h => NonnullRefPtr.h.
2019-06-21 19:45:35 +03:00
#include <AK/RefPtr.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 11:58:59 +03:00
#include <Kernel/Devices/DiskDevice.h>
Kernel: Rename OffsetDiskDevice to DiskPartition
2019-06-02 12:38:37 +03:00
class DiskPartition final : public DiskDevice {
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 11:58:59 +03:00
public:
PartitionTable: Initial GPT Support, Adding Block Limit Also added a script to handle creation of GPT partitioned disk (with GRUB config file). Block limit will be used to disallow potential access to other partitions.
2019-10-07 03:12:37 +03:00
static NonnullRefPtr<DiskPartition> create(DiskDevice&, unsigned block_offset, unsigned block_limit);
Kernel: Rename OffsetDiskDevice to DiskPartition
2019-06-02 12: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 11:58:59 +03:00
AK: Rename the common integer typedefs to make it obvious what they are. These types can be picked up by including <AK/Types.h>: * u8, u16, u32, u64 (unsigned) * i8, i16, i32, i64 (signed)
2019-07-03 22:17:35 +03:00
virtual bool read_block(unsigned index, u8* out) const override;
virtual bool write_block(unsigned index, const u8*) override;
virtual bool read_blocks(unsigned index, u16 count, u8*) override;
virtual bool write_blocks(unsigned index, u16 count, const u8*) 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 11: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 16:18:47 +03:00
// ^BlockDevice
virtual ssize_t read(FileDescription&, u8*, ssize_t) override { return 0; }
virtual bool can_read(FileDescription&) const override { return true; }
virtual ssize_t write(FileDescription&, const u8*, ssize_t) override { return 0; }
virtual bool can_write(FileDescription&) const override { return true; }
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 11:58:59 +03:00
private:
virtual const char* class_name() const override;
PartitionTable: Initial GPT Support, Adding Block Limit Also added a script to handle creation of GPT partitioned disk (with GRUB config file). Block limit will be used to disallow potential access to other partitions.
2019-10-07 03:12:37 +03:00
DiskPartition(DiskDevice&, unsigned block_offset, unsigned block_limit);
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 11:58:59 +03:00
AK: Rename RetainPtr => RefPtr and Retained => NonnullRefPtr.
2019-06-21 19:37:47 +03:00
NonnullRefPtr<DiskDevice> m_device;
Kernel: Rename offset parameter of OffsetDiskDevice to block_offset
2019-06-02 12:29:17 +03:00
unsigned m_block_offset;
PartitionTable: Initial GPT Support, Adding Block Limit Also added a script to handle creation of GPT partitioned disk (with GRUB config file). Block limit will be used to disallow potential access to other partitions.
2019-10-07 03:12:37 +03:00
unsigned m_block_limit;
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 11:58:59 +03:00
};
Reference in New Issue Copy Permalink