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
450a2a0f9c
ladybird/Kernel/Devices/DiskPartition.h

59 lines
2.4 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 11:38:21 +03: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 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: Merge unnecessary DiskDevice class into BlockDevice
2020-02-08 04:17:26 +03:00
#include <Kernel/Devices/BlockDevice.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
Kernel: Move all code into the Kernel namespace
2020-02-16 03:27:42 +03:00
namespace Kernel {
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-08 04:17:26 +03: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 11:58:59 +03:00
public:
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-08 04:17:26 +03:00
static NonnullRefPtr<DiskPartition> create(BlockDevice&, 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_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
Kernel: Add explicit offset parameter to File::read etc
2020-04-10 12:44:42 +03:00
virtual ssize_t read(FileDescription&, size_t, u8*, ssize_t) override;
virtual bool can_read(const FileDescription&, size_t) const override;
virtual ssize_t write(FileDescription&, size_t, const u8*, ssize_t) override;
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 16:18:47 +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 11:58:59 +03:00
private:
virtual const char* class_name() const override;
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-08 04:17:26 +03:00
DiskPartition(BlockDevice&, 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
Kernel: Merge unnecessary DiskDevice class into BlockDevice
2020-02-08 04:17:26 +03:00
NonnullRefPtr<BlockDevice> 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
};
Kernel: Move all code into the Kernel namespace
2020-02-16 03:27:42 +03:00
}
Reference in New Issue Copy Permalink