ladybird/Kernel/Devices/Storage/StorageManagement.cpp

508 lines
20 KiB
C++
Raw Normal View History

/*
* Copyright (c) 2020-2022, Liav A. <liavalb@hotmail.co.il>
* Copyright (c) 2022, the SerenityOS developers.
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <AK/Platform.h>
#include <AK/Singleton.h>
#include <AK/StringView.h>
#include <AK/UUID.h>
2022-10-04 03:05:54 +03:00
#if ARCH(X86_64)
# include <Kernel/Arch/x86_64/ISABus/IDEController.h>
# include <Kernel/Arch/x86_64/PCI/IDELegacyModeController.h>
#endif
#if ARCH(AARCH64)
# include <Kernel/Arch/aarch64/RPi/SDHostController.h>
#endif
#include <Kernel/Boot/CommandLine.h>
Kernel/PCI: Simplify the entire subsystem A couple of things were changed: 1. Semantic changes - PCI segments are now called PCI domains, to better match what they are really. It's also the name that Linux gave, and it seems that Wikipedia also uses this name. We also remove PCI::ChangeableAddress, because it was used in the past but now it's no longer being used. 2. There are no WindowedMMIOAccess or MMIOAccess classes anymore, as they made a bunch of unnecessary complexity. Instead, Windowed access is removed entirely (this was tested, but never was benchmarked), so we are left with IO access and memory access options. The memory access option is essentially mapping the PCI bus (from the chosen PCI domain), to virtual memory as-is. This means that unless needed, at any time, there is only one PCI bus being mapped, and this is changed if access to another PCI bus in the same PCI domain is needed. For now, we don't support mapping of different PCI buses from different PCI domains at the same time, because basically it's still a non-issue for most machines out there. 2. OOM-safety is increased, especially when constructing the Access object. It means that we pre-allocating any needed resources, and we try to find PCI domains (if requested to initialize memory access) after we attempt to construct the Access object, so it's possible to fail at this point "gracefully". 3. All PCI API functions are now separated into a different header file, which means only "clients" of the PCI subsystem API will need to include that header file. 4. Functional changes - we only allow now to enumerate the bus after a hardware scan. This means that the old method "enumerate_hardware" is removed, so, when initializing an Access object, the initializing function must call rescan on it to force it to find devices. This makes it possible to fail rescan, and also to defer it after construction from both OOM-safety terms and hotplug capabilities.
2021-09-07 12:08:38 +03:00
#include <Kernel/Bus/PCI/API.h>
#include <Kernel/Bus/PCI/Access.h>
#include <Kernel/Bus/PCI/Controller/VolumeManagementDevice.h>
#include <Kernel/Devices/BlockDevice.h>
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
#include <Kernel/Devices/DeviceManagement.h>
#include <Kernel/Devices/Storage/ATA/AHCI/Controller.h>
#include <Kernel/Devices/Storage/ATA/GenericIDE/Controller.h>
#include <Kernel/Devices/Storage/NVMe/NVMeController.h>
#include <Kernel/Devices/Storage/SD/PCISDHostController.h>
#include <Kernel/Devices/Storage/SD/SDHostController.h>
#include <Kernel/Devices/Storage/StorageManagement.h>
#include <Kernel/FileSystem/Ext2FS/FileSystem.h>
#include <Kernel/FileSystem/VirtualFileSystem.h>
#include <Kernel/Library/Panic.h>
#include <LibPartition/EBRPartitionTable.h>
#include <LibPartition/GUIDPartitionTable.h>
#include <LibPartition/MBRPartitionTable.h>
namespace Kernel {
static Singleton<StorageManagement> s_the;
static Atomic<u32> s_storage_device_minor_number;
static Atomic<u32> s_partition_device_minor_number;
static Atomic<u32> s_controller_id;
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
static Atomic<u32> s_relative_ata_controller_id;
static Atomic<u32> s_relative_nvme_controller_id;
static Atomic<u32> s_relative_sd_controller_id;
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
static constexpr StringView partition_uuid_prefix = "PARTUUID:"sv;
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
static constexpr StringView partition_number_prefix = "part"sv;
static constexpr StringView block_device_prefix = "block"sv;
static constexpr StringView ata_device_prefix = "ata"sv;
static constexpr StringView nvme_device_prefix = "nvme"sv;
static constexpr StringView logical_unit_number_device_prefix = "lun"sv;
2023-03-25 00:11:39 +03:00
static constexpr StringView sd_device_prefix = "sd"sv;
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
UNMAP_AFTER_INIT StorageManagement::StorageManagement()
{
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
u32 StorageManagement::generate_relative_nvme_controller_id(Badge<NVMeController>)
{
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
auto controller_id = s_relative_nvme_controller_id.load();
s_relative_nvme_controller_id++;
return controller_id;
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
u32 StorageManagement::generate_relative_ata_controller_id(Badge<ATAController>)
{
auto controller_id = s_relative_ata_controller_id.load();
s_relative_ata_controller_id++;
return controller_id;
}
u32 StorageManagement::generate_relative_sd_controller_id(Badge<SDHostController>)
{
auto controller_id = s_relative_sd_controller_id.load();
s_relative_sd_controller_id++;
return controller_id;
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
void StorageManagement::remove_device(StorageDevice& device)
{
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
m_storage_devices.remove(device);
}
UNMAP_AFTER_INIT void StorageManagement::enumerate_pci_controllers(bool force_pio, bool nvme_poll)
{
VERIFY(m_controllers.is_empty());
if (!kernel_command_line().disable_physical_storage()) {
Kernel/PCI: Hold a reference to DeviceIdentifier in the Device class There are now 2 separate classes for almost the same object type: - EnumerableDeviceIdentifier, which is used in the enumeration code for all PCI host controller classes. This is allowed to be moved and copied, as it doesn't support ref-counting. - DeviceIdentifier, which inherits from EnumerableDeviceIdentifier. This class uses ref-counting, and is not allowed to be copied. It has a spinlock member in its structure to allow safely executing complicated IO sequences on a PCI device and its space configuration. There's a static method that allows a quick conversion from EnumerableDeviceIdentifier to DeviceIdentifier while creating a NonnullRefPtr out of it. The reason for doing this is for the sake of integrity and reliablity of the system in 2 places: - Ensure that "complicated" tasks that rely on manipulating PCI device registers are done in a safe manner. For example, determining a PCI BAR space size requires multiple read and writes to the same register, and if another CPU tries to do something else with our selected register, then the result will be a catastrophe. - Allow the PCI API to have a united form around a shared object which actually holds much more data than the PCI::Address structure. This is fundamental if we want to do certain types of optimizations, and be able to support more features of the PCI bus in the foreseeable future. This patch already has several implications: - All PCI::Device(s) hold a reference to a DeviceIdentifier structure being given originally from the PCI::Access singleton. This means that all instances of DeviceIdentifier structures are located in one place, and all references are pointing to that location. This ensures that locking the operation spinlock will take effect in all the appropriate places. - We no longer support adding PCI host controllers and then immediately allow for enumerating it with a lambda function. It was found that this method is extremely broken and too much complicated to work reliably with the new paradigm being introduced in this patch. This means that for Volume Management Devices (Intel VMD devices), we simply first enumerate the PCI bus for such devices in the storage code, and if we find a device, we attach it in the PCI::Access method which will scan for devices behind that bridge and will add new DeviceIdentifier(s) objects to its internal Vector. Afterwards, we just continue as usual with scanning for actual storage controllers, so we will find a corresponding NVMe controllers if there were any behind that VMD bridge.
2022-02-10 19:33:13 +03:00
// NOTE: Search for VMD devices before actually searching for storage controllers
// because the VMD device is only a bridge to such (NVMe) controllers.
MUST(PCI::enumerate([&](PCI::DeviceIdentifier const& device_identifier) -> void {
constexpr PCI::HardwareID vmd_device = { 0x8086, 0x9a0b };
if (device_identifier.hardware_id() == vmd_device) {
auto controller = PCI::VolumeManagementDevice::must_create(device_identifier);
MUST(PCI::Access::the().add_host_controller_and_scan_for_devices(move(controller)));
}
}));
auto const& handle_mass_storage_device = [&](PCI::DeviceIdentifier const& device_identifier) {
using SubclassID = PCI::MassStorage::SubclassID;
auto subclass_code = static_cast<SubclassID>(device_identifier.subclass_code().value());
#if ARCH(X86_64)
if (subclass_code == SubclassID::IDEController && kernel_command_line().is_ide_enabled()) {
if (auto ide_controller_or_error = PCIIDELegacyModeController::initialize(device_identifier, force_pio); !ide_controller_or_error.is_error())
m_controllers.append(ide_controller_or_error.release_value());
else
dmesgln("Unable to initialize IDE controller: {}", ide_controller_or_error.error());
}
#elif ARCH(AARCH64)
(void)force_pio;
TODO_AARCH64();
#else
# error Unknown architecture
#endif
if (subclass_code == SubclassID::SATAController
&& device_identifier.prog_if().value() == to_underlying(PCI::MassStorage::SATAProgIF::AHCI)) {
if (auto ahci_controller_or_error = AHCIController::initialize(device_identifier); !ahci_controller_or_error.is_error())
m_controllers.append(ahci_controller_or_error.value());
else
dmesgln("Unable to initialize AHCI controller: {}", ahci_controller_or_error.error());
}
if (subclass_code == SubclassID::NVMeController) {
auto controller = NVMeController::try_initialize(device_identifier, nvme_poll);
if (controller.is_error()) {
dmesgln("Unable to initialize NVMe controller: {}", controller.error());
} else {
m_controllers.append(controller.release_value());
}
}
};
auto const& handle_base_device = [&](PCI::DeviceIdentifier const& device_identifier) {
using SubclassID = PCI::Base::SubclassID;
auto subclass_code = static_cast<SubclassID>(device_identifier.subclass_code().value());
if (subclass_code == SubclassID::SDHostController) {
auto sdhc_or_error = PCISDHostController::try_initialize(device_identifier);
if (sdhc_or_error.is_error()) {
dmesgln("PCI: Failed to initialize SD Host Controller ({} - {}): {}", device_identifier.address(), device_identifier.hardware_id(), sdhc_or_error.error());
} else {
m_controllers.append(sdhc_or_error.release_value());
}
}
};
MUST(PCI::enumerate([&](PCI::DeviceIdentifier const& device_identifier) -> void {
auto class_code = device_identifier.class_code().value();
if (class_code == to_underlying(PCI::ClassID::MassStorage)) {
handle_mass_storage_device(device_identifier);
} else if (class_code == to_underlying(PCI::ClassID::Base)) {
handle_base_device(device_identifier);
}
}));
}
}
UNMAP_AFTER_INIT void StorageManagement::enumerate_storage_devices()
{
VERIFY(!m_controllers.is_empty());
for (auto& controller : m_controllers) {
for (size_t device_index = 0; device_index < controller->devices_count(); device_index++) {
auto device = controller->device(device_index);
if (device.is_null())
continue;
m_storage_devices.append(device.release_nonnull());
}
}
}
UNMAP_AFTER_INIT void StorageManagement::dump_storage_devices_and_partitions() const
{
dbgln("StorageManagement: Detected {} storage devices", m_storage_devices.size_slow());
for (auto const& storage_device : m_storage_devices) {
auto const& partitions = storage_device.partitions();
if (partitions.is_empty()) {
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
dbgln(" Device: block{}:{} (no partitions)", storage_device.major(), storage_device.minor());
} else {
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
dbgln(" Device: block{}:{} ({} partitions)", storage_device.major(), storage_device.minor(), partitions.size());
unsigned partition_number = 1;
for (auto const& partition : partitions) {
dbgln(" Partition: {}, block{}:{} (UUID {})", partition_number, partition->major(), partition->minor(), partition->metadata().unique_guid().to_string());
partition_number++;
}
}
}
}
UNMAP_AFTER_INIT ErrorOr<NonnullOwnPtr<Partition::PartitionTable>> StorageManagement::try_to_initialize_partition_table(StorageDevice& device) const
{
auto mbr_table_or_error = Partition::MBRPartitionTable::try_to_initialize(device);
if (!mbr_table_or_error.is_error())
return mbr_table_or_error.release_value();
auto ebr_table_or_error = Partition::EBRPartitionTable::try_to_initialize(device);
if (!ebr_table_or_error.is_error()) {
return ebr_table_or_error.release_value();
}
return TRY(Partition::GUIDPartitionTable::try_to_initialize(device));
}
UNMAP_AFTER_INIT void StorageManagement::enumerate_disk_partitions()
{
VERIFY(!m_storage_devices.is_empty());
for (auto& device : m_storage_devices) {
auto partition_table_or_error = try_to_initialize_partition_table(device);
if (partition_table_or_error.is_error())
continue;
auto partition_table = partition_table_or_error.release_value();
for (size_t partition_index = 0; partition_index < partition_table->partitions_count(); partition_index++) {
auto partition_metadata = partition_table->partition(partition_index);
if (!partition_metadata.has_value())
continue;
auto disk_partition = DiskPartition::create(device, generate_partition_minor_number(), partition_metadata.value());
device.add_partition(disk_partition);
}
}
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
UNMAP_AFTER_INIT Optional<unsigned> StorageManagement::extract_boot_device_partition_number_parameter(StringView device_prefix)
{
VERIFY(m_boot_argument.starts_with(device_prefix));
VERIFY(!m_boot_argument.starts_with(partition_uuid_prefix));
auto storage_device_relative_address_view = m_boot_argument.substring_view(device_prefix.length());
auto parameter_view = storage_device_relative_address_view.find_last_split_view(';');
if (parameter_view == storage_device_relative_address_view)
return {};
if (!parameter_view.starts_with(partition_number_prefix)) {
PANIC("StorageManagement: Invalid root boot parameter.");
}
auto parameter_number = parameter_view.substring_view(partition_number_prefix.length()).to_uint<unsigned>();
if (!parameter_number.has_value()) {
PANIC("StorageManagement: Invalid root boot parameter.");
}
return parameter_number.value();
}
UNMAP_AFTER_INIT Array<unsigned, 3> StorageManagement::extract_boot_device_address_parameters(StringView device_prefix)
{
VERIFY(!m_boot_argument.starts_with(partition_uuid_prefix));
Array<unsigned, 3> address_parameters;
auto parameters_view = m_boot_argument.substring_view(device_prefix.length()).find_first_split_view(';');
size_t parts_count = 0;
bool parse_failure = false;
parameters_view.for_each_split_view(':', SplitBehavior::Nothing, [&](StringView parameter_view) {
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
if (parse_failure)
return;
if (parts_count > 2)
return;
auto parameter_number = parameter_view.to_uint<unsigned>();
if (!parameter_number.has_value()) {
parse_failure = true;
return;
}
address_parameters[parts_count] = parameter_number.value();
parts_count++;
});
if (parts_count > 3) {
dbgln("StorageManagement: Detected {} parts in boot device parameter.", parts_count);
PANIC("StorageManagement: Invalid root boot parameter.");
}
if (parse_failure) {
PANIC("StorageManagement: Invalid root boot parameter.");
}
return address_parameters;
}
UNMAP_AFTER_INIT void StorageManagement::resolve_partition_from_boot_device_parameter(StorageDevice const& chosen_storage_device, StringView boot_device_prefix)
{
auto possible_partition_number = extract_boot_device_partition_number_parameter(boot_device_prefix);
if (!possible_partition_number.has_value())
return;
auto partition_number = possible_partition_number.value();
if (chosen_storage_device.partitions().size() <= partition_number)
PANIC("StorageManagement: Invalid partition number parameter.");
m_boot_block_device = chosen_storage_device.partitions()[partition_number];
}
UNMAP_AFTER_INIT void StorageManagement::determine_hardware_relative_boot_device(StringView relative_hardware_prefix, Function<bool(StorageDevice const&)> filter_device_callback)
{
VERIFY(m_boot_argument.starts_with(relative_hardware_prefix));
auto address_parameters = extract_boot_device_address_parameters(relative_hardware_prefix);
RefPtr<StorageDevice> chosen_storage_device;
for (auto& storage_device : m_storage_devices) {
if (!filter_device_callback(storage_device))
continue;
auto storage_device_lun = storage_device.logical_unit_number_address();
if (storage_device.parent_controller_hardware_relative_id() == address_parameters[0]
&& storage_device_lun.target_id == address_parameters[1]
&& storage_device_lun.disk_id == address_parameters[2]) {
m_boot_block_device = storage_device;
chosen_storage_device = storage_device;
break;
}
}
if (chosen_storage_device)
resolve_partition_from_boot_device_parameter(*chosen_storage_device, relative_hardware_prefix);
}
UNMAP_AFTER_INIT void StorageManagement::determine_ata_boot_device()
{
determine_hardware_relative_boot_device(ata_device_prefix, [](StorageDevice const& device) -> bool {
return device.command_set() == StorageDevice::CommandSet::ATA;
});
}
UNMAP_AFTER_INIT void StorageManagement::determine_nvme_boot_device()
{
determine_hardware_relative_boot_device(nvme_device_prefix, [](StorageDevice const& device) -> bool {
return device.command_set() == StorageDevice::CommandSet::NVMe;
});
}
2023-03-25 00:11:39 +03:00
UNMAP_AFTER_INIT void StorageManagement::determine_sd_boot_device()
{
determine_hardware_relative_boot_device(sd_device_prefix, [](StorageDevice const& device) -> bool {
return device.command_set() == StorageDevice::CommandSet::SD;
});
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
UNMAP_AFTER_INIT void StorageManagement::determine_block_boot_device()
{
VERIFY(m_boot_argument.starts_with(block_device_prefix));
auto parameters_view = extract_boot_device_address_parameters(block_device_prefix);
// Note: We simply fetch the corresponding BlockDevice with the major and minor parameters.
// We don't try to accept and resolve a partition number as it will make this code much more
// complicated. This rule is also explained in the boot_device_addressing(7) manual page.
LockRefPtr<Device> device = DeviceManagement::the().get_device(parameters_view[0], parameters_view[1]);
if (device && device->is_block_device())
m_boot_block_device = static_ptr_cast<BlockDevice>(device);
}
UNMAP_AFTER_INIT void StorageManagement::determine_boot_device_with_logical_unit_number()
{
VERIFY(m_boot_argument.starts_with(logical_unit_number_device_prefix));
auto address_parameters = extract_boot_device_address_parameters(logical_unit_number_device_prefix);
RefPtr<StorageDevice> chosen_storage_device;
for (auto& storage_device : m_storage_devices) {
auto storage_device_lun = storage_device.logical_unit_number_address();
if (storage_device_lun.controller_id == address_parameters[0]
&& storage_device_lun.target_id == address_parameters[1]
&& storage_device_lun.disk_id == address_parameters[2]) {
m_boot_block_device = storage_device;
chosen_storage_device = storage_device;
break;
}
}
if (chosen_storage_device)
resolve_partition_from_boot_device_parameter(*chosen_storage_device, logical_unit_number_device_prefix);
}
UNMAP_AFTER_INIT void StorageManagement::determine_boot_device()
{
VERIFY(!m_controllers.is_empty());
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
if (m_boot_argument.starts_with(block_device_prefix)) {
determine_block_boot_device();
return;
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
if (m_boot_argument.starts_with(partition_uuid_prefix)) {
determine_boot_device_with_partition_uuid();
return;
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
if (m_boot_argument.starts_with(logical_unit_number_device_prefix)) {
determine_boot_device_with_logical_unit_number();
return;
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
if (m_boot_argument.starts_with(ata_device_prefix)) {
determine_ata_boot_device();
return;
}
if (m_boot_argument.starts_with(nvme_device_prefix)) {
determine_nvme_boot_device();
return;
}
2023-03-25 00:11:39 +03:00
if (m_boot_argument.starts_with(sd_device_prefix)) {
determine_sd_boot_device();
return;
}
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
PANIC("StorageManagement: Invalid root boot parameter.");
}
UNMAP_AFTER_INIT void StorageManagement::determine_boot_device_with_partition_uuid()
{
VERIFY(!m_storage_devices.is_empty());
VERIFY(m_boot_argument.starts_with(partition_uuid_prefix));
auto partition_uuid = UUID(m_boot_argument.substring_view(partition_uuid_prefix.length()), UUID::Endianness::Mixed);
for (auto& storage_device : m_storage_devices) {
for (auto& partition : storage_device.partitions()) {
if (partition->metadata().unique_guid().is_zero())
continue;
if (partition->metadata().unique_guid() == partition_uuid) {
m_boot_block_device = partition;
break;
}
}
}
}
LockRefPtr<BlockDevice> StorageManagement::boot_block_device() const
{
return m_boot_block_device.strong_ref();
}
MajorNumber StorageManagement::storage_type_major_number()
{
return 3;
}
MinorNumber StorageManagement::generate_storage_minor_number()
{
return s_storage_device_minor_number.fetch_add(1);
}
MinorNumber StorageManagement::generate_partition_minor_number()
{
return s_partition_device_minor_number.fetch_add(1);
}
u32 StorageManagement::generate_controller_id()
{
return s_controller_id.fetch_add(1);
}
NonnullRefPtr<FileSystem> StorageManagement::root_filesystem() const
{
auto boot_device_description = boot_block_device();
if (!boot_device_description) {
dump_storage_devices_and_partitions();
PANIC("StorageManagement: Couldn't find a suitable device to boot from");
}
auto description_or_error = OpenFileDescription::try_create(boot_device_description.release_nonnull());
VERIFY(!description_or_error.is_error());
auto file_system = Ext2FS::try_create(description_or_error.release_value()).release_value();
if (auto result = file_system->initialize(); result.is_error()) {
dump_storage_devices_and_partitions();
PANIC("StorageManagement: Couldn't open root filesystem: {}", result.error());
}
return file_system;
}
UNMAP_AFTER_INIT void StorageManagement::initialize(StringView root_device, bool force_pio, bool poll)
{
VERIFY(s_storage_device_minor_number == 0);
m_boot_argument = root_device;
if (PCI::Access::is_disabled()) {
2022-10-04 03:05:54 +03:00
#if ARCH(X86_64)
// Note: If PCI is disabled, we assume that at least we have an ISA IDE controller
// to probe and use
auto isa_ide_controller = MUST(ISAIDEController::initialize());
m_controllers.append(isa_ide_controller);
#endif
} else {
enumerate_pci_controllers(force_pio, poll);
}
#if ARCH(AARCH64)
auto& rpi_sdhc = RPi::SDHostController::the();
if (auto maybe_error = rpi_sdhc.initialize(); maybe_error.is_error()) {
dmesgln("Unable to initialize RaspberryPi's SD Host Controller: {}", maybe_error.error());
} else {
m_controllers.append(rpi_sdhc);
}
#endif
enumerate_storage_devices();
enumerate_disk_partitions();
Kernel/Storage: Introduce new boot device addressing modes Before of this patch, we supported two methods to address a boot device: 1. Specifying root=/dev/hdXY, where X is a-z letter which corresponds to a boot device, and Y as number from 1 to 16, to indicate the partition number, which can be omitted to instruct the kernel to use a raw device rather than a partition on a raw device. 2. Specifying root=PARTUUID: with a GUID string of a GUID partition. In case of existing storage device with GPT partitions, this is most likely the safest option to ensure booting from persistent storage. While option 2 is more advanced and reliable, the first option has 2 caveats: 1. The string prefix "/dev/hd" doesn't mean anything beside a convention on Linux installations, that was taken into use in Serenity. In Serenity we don't mount DevTmpFS before we mount the boot device on /, so the kernel doesn't really access /dev anyway, so this convention is only a big misleading relic that can easily make the user to assume we access /dev early on boot. 2. This convention although resemble the simple linux convention, is quite limited in specifying a correct boot device across hardware setup changes, so option 2 was recommended to ensure the system is always bootable. With these caveats in mind, this commit tries to fix the problem with adding more addressing options as well as to remove the first option being mentioned above of addressing. To sum it up, there are 4 addressing options: 1. Hardware relative address - Each instance of StorageController is assigned with a index number relative to the type of hardware it handles which makes it possible to address storage devices with a prefix of the commandset ("ata" for ATA, "nvme" for NVMe, "ramdisk" for Plain memory), and then the number for the parent controller relative hardware index, another number LUN target_id, and a third number for LUN disk_id. 2. LUN address - Similar to the previous option, but instead we rely on the parent controller absolute index for the first number. 3. Block device major and minor numbers - by specifying the major and minor numbers, the kernel can simply try to get the corresponding block device and use it as the boot device. 4. GUID string, in the same fashion like before, so the user use the "PARTUUID:" string prefix and add the GUID of the GPT partition. For the new address modes 1 and 2, the user can choose to also specify a partition out of the selected boot device. To do that, the user needs to append the semicolon character and then add the string "partX" where X is to be changed for the partition number. We start counting from 0, and therefore the first partition number is 0 and not 1 in the kernel boot argument.
2022-08-05 20:32:26 +03:00
determine_boot_device();
if (m_boot_block_device.is_null()) {
dump_storage_devices_and_partitions();
PANIC("StorageManagement: boot device {} not found", m_boot_argument);
}
}
StorageManagement& StorageManagement::the()
{
return *s_the;
}
}