2020-12-19 16:25:06 +03:00
|
|
|
/*
|
2022-04-25 19:54:06 +03:00
|
|
|
* Copyright (c) 2020-2022, Liav A. <liavalb@hotmail.co.il>
|
2022-02-09 21:33:39 +03:00
|
|
|
* Copyright (c) 2022, the SerenityOS developers.
|
2020-12-19 16:25:06 +03:00
|
|
|
*
|
2021-04-22 11:24:48 +03:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-12-19 16:25:06 +03:00
|
|
|
*/
|
|
|
|
|
2022-09-03 08:15:32 +03:00
|
|
|
#include <AK/Platform.h>
|
2021-08-27 08:08:43 +03:00
|
|
|
#include <AK/Singleton.h>
|
2021-10-03 01:11:01 +03:00
|
|
|
#include <AK/StringView.h>
|
2020-12-31 14:17:03 +03:00
|
|
|
#include <AK/UUID.h>
|
2022-10-04 03:05:54 +03:00
|
|
|
#if ARCH(X86_64)
|
2022-10-04 13:46:11 +03:00
|
|
|
# include <Kernel/Arch/x86_64/ISABus/IDEController.h>
|
|
|
|
# include <Kernel/Arch/x86_64/PCI/IDELegacyModeController.h>
|
2022-09-03 08:15:32 +03:00
|
|
|
#endif
|
2023-03-16 12:54:29 +03:00
|
|
|
#if ARCH(AARCH64)
|
|
|
|
# include <Kernel/Arch/aarch64/RPi/SDHostController.h>
|
|
|
|
#endif
|
2023-02-24 21:21:53 +03:00
|
|
|
#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>
|
2021-06-25 09:46:17 +03:00
|
|
|
#include <Kernel/Bus/PCI/Access.h>
|
2022-01-15 10:17:07 +03:00
|
|
|
#include <Kernel/Bus/PCI/Controller/VolumeManagementDevice.h>
|
2020-12-19 16:25:06 +03:00
|
|
|
#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>
|
2023-03-18 14:32:12 +03:00
|
|
|
#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>
|
2022-10-24 10:02:37 +03:00
|
|
|
#include <Kernel/FileSystem/Ext2FS/FileSystem.h>
|
2022-08-19 18:16:06 +03:00
|
|
|
#include <Kernel/FileSystem/VirtualFileSystem.h>
|
2023-02-24 21:10:59 +03:00
|
|
|
#include <Kernel/Library/Panic.h>
|
2022-03-02 04:01:52 +03:00
|
|
|
#include <LibPartition/EBRPartitionTable.h>
|
2022-03-02 04:21:35 +03:00
|
|
|
#include <LibPartition/GUIDPartitionTable.h>
|
2022-03-02 03:42:06 +03:00
|
|
|
#include <LibPartition/MBRPartitionTable.h>
|
2020-12-19 16:25:06 +03:00
|
|
|
|
|
|
|
namespace Kernel {
|
|
|
|
|
2021-08-27 08:08:43 +03:00
|
|
|
static Singleton<StorageManagement> s_the;
|
2022-07-23 11:15:35 +03:00
|
|
|
static Atomic<u32> s_storage_device_minor_number;
|
|
|
|
static Atomic<u32> s_partition_device_minor_number;
|
Kernel/Storage: Add LUN address to each StorageDevice
LUN address is essentially how people used to address SCSI devices back
in the day we had these devices more in use. However, SCSI was taken as
an abstraction layer for many Unix and Unix-like systems, so it still
common to see LUN addresses in use. In Serenity, we don't really provide
such abstraction layer, and therefore until now, we didn't use LUNs too.
However (again), this changes, as we want to let users to address their
devices under SysFS easily. LUNs make sense in that regard, because they
can be easily adapted to different interfaces besides SCSI.
For example, for legacy ATA hard drive being connected to the first IDE
controller which was enumerated on the PCI bus, and then to the primary
channel as slave device, the LUN address would be 0:0:1.
To make this happen, we add unique ID number to each StorageController,
which increments by 1 for each new instance of StorageController. Then,
we adapt the ATA and NVMe devices to use these numbers and generate LUN
in the construction time.
2022-04-22 18:52:20 +03:00
|
|
|
static Atomic<u32> s_controller_id;
|
2020-12-19 16:25:06 +03:00
|
|
|
|
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;
|
2023-03-16 12:54:29 +03:00
|
|
|
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
|
|
|
|
2022-01-25 21:29:34 +03:00
|
|
|
static constexpr StringView partition_uuid_prefix = "PARTUUID:"sv;
|
2021-10-03 01:11:01 +03:00
|
|
|
|
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
|
|
|
|
2021-08-27 08:08:43 +03:00
|
|
|
UNMAP_AFTER_INIT StorageManagement::StorageManagement()
|
2020-12-19 16:25:06 +03:00
|
|
|
{
|
2021-08-27 08:08:43 +03:00
|
|
|
}
|
|
|
|
|
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>)
|
2021-08-27 08:08:43 +03:00
|
|
|
{
|
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;
|
|
|
|
}
|
2023-03-16 12:54:29 +03:00
|
|
|
|
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;
|
2020-12-31 14:17:03 +03:00
|
|
|
}
|
|
|
|
|
2023-03-16 12:54:29 +03:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2023-08-31 17:46:55 +03:00
|
|
|
void StorageManagement::add_device(StorageDevice& device)
|
|
|
|
{
|
|
|
|
m_storage_devices.append(device);
|
|
|
|
// FIXME: Maybe handle this error in some way shape or form
|
|
|
|
(void)enumerate_device_partitions(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
|
|
|
void StorageManagement::remove_device(StorageDevice& device)
|
2020-12-31 14:17:03 +03:00
|
|
|
{
|
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);
|
2020-12-19 16:25:06 +03:00
|
|
|
}
|
|
|
|
|
2022-01-21 17:18:31 +03:00
|
|
|
UNMAP_AFTER_INIT void StorageManagement::enumerate_pci_controllers(bool force_pio, bool nvme_poll)
|
2020-12-26 17:53:30 +03:00
|
|
|
{
|
2021-08-27 08:08:43 +03:00
|
|
|
VERIFY(m_controllers.is_empty());
|
2022-01-03 14:39:33 +03:00
|
|
|
|
2021-04-08 21:18:48 +03:00
|
|
|
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)));
|
|
|
|
}
|
|
|
|
}));
|
2022-01-03 14:39:33 +03:00
|
|
|
|
2023-03-23 23:31:01 +03:00
|
|
|
auto const& handle_mass_storage_device = [&](PCI::DeviceIdentifier const& device_identifier) {
|
|
|
|
using SubclassID = PCI::MassStorage::SubclassID;
|
2022-01-03 14:39:33 +03:00
|
|
|
|
|
|
|
auto subclass_code = static_cast<SubclassID>(device_identifier.subclass_code().value());
|
2022-12-28 14:38:05 +03:00
|
|
|
#if ARCH(X86_64)
|
2022-01-03 14:39:33 +03:00
|
|
|
if (subclass_code == SubclassID::IDEController && kernel_command_line().is_ide_enabled()) {
|
2022-12-16 12:17:30 +03:00
|
|
|
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());
|
2022-01-03 14:39:33 +03:00
|
|
|
}
|
2022-10-25 19:44:54 +03:00
|
|
|
#elif ARCH(AARCH64)
|
|
|
|
(void)force_pio;
|
|
|
|
TODO_AARCH64();
|
2023-11-03 01:21:09 +03:00
|
|
|
#elif ARCH(RISCV64)
|
|
|
|
(void)force_pio;
|
|
|
|
if (subclass_code == SubclassID::IDEController && kernel_command_line().is_ide_enabled()) {
|
|
|
|
TODO_RISCV64();
|
|
|
|
}
|
2022-10-25 19:44:54 +03:00
|
|
|
#else
|
|
|
|
# error Unknown architecture
|
2022-09-03 16:23:44 +03:00
|
|
|
#endif
|
2022-01-03 14:39:33 +03:00
|
|
|
|
|
|
|
if (subclass_code == SubclassID::SATAController
|
2023-09-11 19:23:35 +03:00
|
|
|
&& device_identifier.prog_if() == PCI::MassStorage::SATAProgIF::AHCI) {
|
2023-03-14 16:13:50 +03:00
|
|
|
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());
|
2021-01-24 20:20:23 +03:00
|
|
|
}
|
2022-01-03 14:39:33 +03:00
|
|
|
if (subclass_code == SubclassID::NVMeController) {
|
2022-01-27 14:14:58 +03:00
|
|
|
auto controller = NVMeController::try_initialize(device_identifier, nvme_poll);
|
2021-12-16 18:07:54 +03:00
|
|
|
if (controller.is_error()) {
|
2022-01-03 14:39:33 +03:00
|
|
|
dmesgln("Unable to initialize NVMe controller: {}", controller.error());
|
2021-12-16 18:07:54 +03:00
|
|
|
} else {
|
|
|
|
m_controllers.append(controller.release_value());
|
|
|
|
}
|
|
|
|
}
|
2023-03-23 23:31:01 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
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 {
|
2023-09-11 17:01:01 +03:00
|
|
|
auto class_code = device_identifier.class_code();
|
|
|
|
if (class_code == PCI::ClassID::MassStorage) {
|
2023-03-23 23:31:01 +03:00
|
|
|
handle_mass_storage_device(device_identifier);
|
2023-09-11 17:01:01 +03:00
|
|
|
} else if (class_code == PCI::ClassID::Base) {
|
2023-03-23 23:31:01 +03:00
|
|
|
handle_base_device(device_identifier);
|
|
|
|
}
|
2022-02-04 20:48:13 +03:00
|
|
|
}));
|
2021-01-24 20:20:23 +03:00
|
|
|
}
|
2020-12-26 17:53:30 +03:00
|
|
|
}
|
|
|
|
|
2021-08-27 08:08:43 +03:00
|
|
|
UNMAP_AFTER_INIT void StorageManagement::enumerate_storage_devices()
|
2020-12-26 17:53:30 +03:00
|
|
|
{
|
2021-02-23 22:42:32 +03:00
|
|
|
VERIFY(!m_controllers.is_empty());
|
2020-12-26 17:53:30 +03:00
|
|
|
for (auto& controller : m_controllers) {
|
2023-03-06 19:56:28 +03:00
|
|
|
for (size_t device_index = 0; device_index < controller->devices_count(); device_index++) {
|
|
|
|
auto device = controller->device(device_index);
|
2020-12-26 17:53:30 +03:00
|
|
|
if (device.is_null())
|
|
|
|
continue;
|
2021-08-27 08:08:43 +03:00
|
|
|
m_storage_devices.append(device.release_nonnull());
|
2020-12-26 17:53:30 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-26 22:47:30 +03:00
|
|
|
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());
|
2022-01-26 22:47:30 +03:00
|
|
|
} 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());
|
2022-01-26 22:47:30 +03:00
|
|
|
unsigned partition_number = 1;
|
|
|
|
for (auto const& partition : partitions) {
|
2023-03-06 19:56:28 +03:00
|
|
|
dbgln(" Partition: {}, block{}:{} (UUID {})", partition_number, partition->major(), partition->minor(), partition->metadata().unique_guid().to_string());
|
2022-01-26 22:47:30 +03:00
|
|
|
partition_number++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-08-31 17:46:55 +03:00
|
|
|
ErrorOr<NonnullOwnPtr<Partition::PartitionTable>> StorageManagement::try_to_initialize_partition_table(StorageDevice& device) const
|
2020-12-26 17:53:30 +03:00
|
|
|
{
|
2022-03-02 03:42:06 +03:00
|
|
|
auto mbr_table_or_error = Partition::MBRPartitionTable::try_to_initialize(device);
|
2022-04-25 19:54:06 +03:00
|
|
|
if (!mbr_table_or_error.is_error())
|
|
|
|
return mbr_table_or_error.release_value();
|
2022-03-02 04:01:52 +03:00
|
|
|
auto ebr_table_or_error = Partition::EBRPartitionTable::try_to_initialize(device);
|
2022-04-25 19:54:06 +03:00
|
|
|
if (!ebr_table_or_error.is_error()) {
|
|
|
|
return ebr_table_or_error.release_value();
|
2020-12-26 17:53:30 +03:00
|
|
|
}
|
2022-03-02 04:21:35 +03:00
|
|
|
return TRY(Partition::GUIDPartitionTable::try_to_initialize(device));
|
2020-12-26 17:53:30 +03:00
|
|
|
}
|
|
|
|
|
2023-08-31 17:46:55 +03:00
|
|
|
ErrorOr<void> StorageManagement::enumerate_device_partitions(StorageDevice& device)
|
|
|
|
{
|
|
|
|
auto partition_table = TRY(try_to_initialize_partition_table(device));
|
|
|
|
for (auto partition_metadata : partition_table->partitions()) {
|
2023-06-30 08:59:58 +03:00
|
|
|
auto disk_partition = StorageDevicePartition::create(device, generate_partition_minor_number(), partition_metadata);
|
2023-08-31 17:46:55 +03:00
|
|
|
device.add_partition(disk_partition);
|
|
|
|
}
|
|
|
|
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
|
2022-01-03 13:58:38 +03:00
|
|
|
UNMAP_AFTER_INIT void StorageManagement::enumerate_disk_partitions()
|
2020-12-26 17:53:30 +03:00
|
|
|
{
|
|
|
|
for (auto& device : m_storage_devices) {
|
2023-08-31 17:46:55 +03:00
|
|
|
// FIXME: Maybe handle this error in some way shape or form
|
|
|
|
(void)enumerate_device_partitions(device);
|
2020-12-26 17:53:30 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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.");
|
|
|
|
}
|
|
|
|
|
2023-12-23 05:59:14 +03:00
|
|
|
auto parameter_number = parameter_view.substring_view(partition_number_prefix.length()).to_number<unsigned>();
|
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 (!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;
|
2022-10-22 16:38:21 +03:00
|
|
|
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;
|
2023-12-23 05:59:14 +03:00
|
|
|
auto parameter_number = parameter_view.to_number<unsigned>();
|
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 (!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.
|
2024-03-04 22:19:31 +03:00
|
|
|
auto device = DeviceManagement::the().get_device(parameters_view[0], parameters_view[1]);
|
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 (device && device->is_block_device())
|
2024-03-04 22:19:31 +03:00
|
|
|
m_boot_block_device = *static_ptr_cast<BlockDevice>(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
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2023-09-30 22:18:44 +03:00
|
|
|
UNMAP_AFTER_INIT bool StorageManagement::determine_boot_device(StringView boot_argument)
|
2020-12-19 16:25:06 +03:00
|
|
|
{
|
2021-02-23 22:42:32 +03:00
|
|
|
VERIFY(!m_controllers.is_empty());
|
2023-09-30 22:18:44 +03:00
|
|
|
m_boot_argument = boot_argument;
|
2021-11-27 10:10:10 +03:00
|
|
|
|
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();
|
2023-09-30 22:18:44 +03:00
|
|
|
return m_boot_block_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
|
|
|
}
|
2022-01-02 02:12:44 +03:00
|
|
|
|
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();
|
2023-09-30 22:18:44 +03:00
|
|
|
return m_boot_block_device;
|
2020-12-19 16:25:06 +03:00
|
|
|
}
|
|
|
|
|
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();
|
2023-09-30 22:18:44 +03:00
|
|
|
return m_boot_block_device;
|
2020-12-19 16:25:06 +03:00
|
|
|
}
|
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();
|
2023-09-30 22:18:44 +03:00
|
|
|
return m_boot_block_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
|
|
|
}
|
|
|
|
|
|
|
|
if (m_boot_argument.starts_with(nvme_device_prefix)) {
|
|
|
|
determine_nvme_boot_device();
|
2023-09-30 22:18:44 +03:00
|
|
|
return m_boot_block_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
|
|
|
}
|
2023-03-25 00:11:39 +03:00
|
|
|
|
|
|
|
if (m_boot_argument.starts_with(sd_device_prefix)) {
|
|
|
|
determine_sd_boot_device();
|
2023-09-30 22:18:44 +03:00
|
|
|
return m_boot_block_device;
|
2023-03-25 00:11:39 +03:00
|
|
|
}
|
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.");
|
2020-12-31 14:17:03 +03:00
|
|
|
}
|
|
|
|
|
2021-03-03 11:54:36 +03:00
|
|
|
UNMAP_AFTER_INIT void StorageManagement::determine_boot_device_with_partition_uuid()
|
2020-12-31 14:17:03 +03:00
|
|
|
{
|
2021-08-27 08:08:43 +03:00
|
|
|
VERIFY(!m_storage_devices.is_empty());
|
2021-10-03 01:11:01 +03:00
|
|
|
VERIFY(m_boot_argument.starts_with(partition_uuid_prefix));
|
2020-12-31 14:17:03 +03:00
|
|
|
|
2022-01-28 21:21:40 +03:00
|
|
|
auto partition_uuid = UUID(m_boot_argument.substring_view(partition_uuid_prefix.length()), UUID::Endianness::Mixed);
|
2020-12-31 14:17:03 +03:00
|
|
|
|
2021-08-27 08:08:43 +03:00
|
|
|
for (auto& storage_device : m_storage_devices) {
|
|
|
|
for (auto& partition : storage_device.partitions()) {
|
2023-03-06 19:56:28 +03:00
|
|
|
if (partition->metadata().unique_guid().is_zero())
|
2021-08-27 08:08:43 +03:00
|
|
|
continue;
|
2023-03-06 19:56:28 +03:00
|
|
|
if (partition->metadata().unique_guid() == partition_uuid) {
|
2021-08-27 08:08:43 +03:00
|
|
|
m_boot_block_device = partition;
|
|
|
|
break;
|
|
|
|
}
|
2020-12-31 14:17:03 +03:00
|
|
|
}
|
|
|
|
}
|
2020-12-19 16:25:06 +03:00
|
|
|
}
|
|
|
|
|
2022-08-19 21:53:40 +03:00
|
|
|
LockRefPtr<BlockDevice> StorageManagement::boot_block_device() const
|
2020-12-19 16:25:06 +03:00
|
|
|
{
|
2021-08-27 08:08:43 +03:00
|
|
|
return m_boot_block_device.strong_ref();
|
2020-12-26 17:53:30 +03:00
|
|
|
}
|
|
|
|
|
2021-12-23 21:08:18 +03:00
|
|
|
MajorNumber StorageManagement::storage_type_major_number()
|
2021-02-25 20:36:49 +03:00
|
|
|
{
|
|
|
|
return 3;
|
|
|
|
}
|
2021-12-23 21:08:18 +03:00
|
|
|
MinorNumber StorageManagement::generate_storage_minor_number()
|
2021-02-25 20:36:49 +03:00
|
|
|
{
|
2022-07-23 11:15:35 +03:00
|
|
|
return s_storage_device_minor_number.fetch_add(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
MinorNumber StorageManagement::generate_partition_minor_number()
|
|
|
|
{
|
|
|
|
return s_partition_device_minor_number.fetch_add(1);
|
2021-02-25 20:36:49 +03:00
|
|
|
}
|
|
|
|
|
Kernel/Storage: Add LUN address to each StorageDevice
LUN address is essentially how people used to address SCSI devices back
in the day we had these devices more in use. However, SCSI was taken as
an abstraction layer for many Unix and Unix-like systems, so it still
common to see LUN addresses in use. In Serenity, we don't really provide
such abstraction layer, and therefore until now, we didn't use LUNs too.
However (again), this changes, as we want to let users to address their
devices under SysFS easily. LUNs make sense in that regard, because they
can be easily adapted to different interfaces besides SCSI.
For example, for legacy ATA hard drive being connected to the first IDE
controller which was enumerated on the PCI bus, and then to the primary
channel as slave device, the LUN address would be 0:0:1.
To make this happen, we add unique ID number to each StorageController,
which increments by 1 for each new instance of StorageController. Then,
we adapt the ATA and NVMe devices to use these numbers and generate LUN
in the construction time.
2022-04-22 18:52:20 +03:00
|
|
|
u32 StorageManagement::generate_controller_id()
|
|
|
|
{
|
2022-08-11 21:23:26 +03:00
|
|
|
return s_controller_id.fetch_add(1);
|
Kernel/Storage: Add LUN address to each StorageDevice
LUN address is essentially how people used to address SCSI devices back
in the day we had these devices more in use. However, SCSI was taken as
an abstraction layer for many Unix and Unix-like systems, so it still
common to see LUN addresses in use. In Serenity, we don't really provide
such abstraction layer, and therefore until now, we didn't use LUNs too.
However (again), this changes, as we want to let users to address their
devices under SysFS easily. LUNs make sense in that regard, because they
can be easily adapted to different interfaces besides SCSI.
For example, for legacy ATA hard drive being connected to the first IDE
controller which was enumerated on the PCI bus, and then to the primary
channel as slave device, the LUN address would be 0:0:1.
To make this happen, we add unique ID number to each StorageController,
which increments by 1 for each new instance of StorageController. Then,
we adapt the ATA and NVMe devices to use these numbers and generate LUN
in the construction time.
2022-04-22 18:52:20 +03:00
|
|
|
}
|
|
|
|
|
2023-04-02 18:25:09 +03:00
|
|
|
NonnullRefPtr<FileSystem> StorageManagement::root_filesystem() const
|
2020-12-26 17:53:30 +03:00
|
|
|
{
|
2020-09-17 22:51:09 +03:00
|
|
|
auto boot_device_description = boot_block_device();
|
|
|
|
if (!boot_device_description) {
|
2022-01-26 22:47:30 +03:00
|
|
|
dump_storage_devices_and_partitions();
|
2021-02-14 11:30:31 +03:00
|
|
|
PANIC("StorageManagement: Couldn't find a suitable device to boot from");
|
2020-12-31 14:17:03 +03:00
|
|
|
}
|
2021-09-07 14:39:11 +03:00
|
|
|
auto description_or_error = OpenFileDescription::try_create(boot_device_description.release_nonnull());
|
2021-09-04 13:46:19 +03:00
|
|
|
VERIFY(!description_or_error.is_error());
|
|
|
|
|
2022-12-15 12:42:40 +03:00
|
|
|
Array<u8, PAGE_SIZE> mount_specific_data;
|
|
|
|
mount_specific_data.fill(0);
|
|
|
|
auto file_system = Ext2FS::try_create(description_or_error.release_value(), mount_specific_data.span()).release_value();
|
2021-09-04 13:46:19 +03:00
|
|
|
|
|
|
|
if (auto result = file_system->initialize(); result.is_error()) {
|
2022-01-26 22:47:30 +03:00
|
|
|
dump_storage_devices_and_partitions();
|
2021-11-08 02:51:39 +03:00
|
|
|
PANIC("StorageManagement: Couldn't open root filesystem: {}", result.error());
|
2020-12-19 16:25:06 +03:00
|
|
|
}
|
2021-09-04 13:46:19 +03:00
|
|
|
return file_system;
|
2020-12-19 16:25:06 +03:00
|
|
|
}
|
|
|
|
|
2023-09-30 22:18:44 +03:00
|
|
|
UNMAP_AFTER_INIT void StorageManagement::initialize(bool force_pio, bool poll)
|
2020-12-19 16:25:06 +03:00
|
|
|
{
|
2022-07-23 11:15:35 +03:00
|
|
|
VERIFY(s_storage_device_minor_number == 0);
|
2022-01-21 17:18:31 +03:00
|
|
|
if (PCI::Access::is_disabled()) {
|
2022-10-04 03:05:54 +03:00
|
|
|
#if ARCH(X86_64)
|
2022-01-21 17:18:31 +03:00
|
|
|
// Note: If PCI is disabled, we assume that at least we have an ISA IDE controller
|
|
|
|
// to probe and use
|
2022-12-16 11:04:42 +03:00
|
|
|
auto isa_ide_controller = MUST(ISAIDEController::initialize());
|
|
|
|
m_controllers.append(isa_ide_controller);
|
2022-09-03 08:15:32 +03:00
|
|
|
#endif
|
2022-01-21 17:18:31 +03:00
|
|
|
} else {
|
|
|
|
enumerate_pci_controllers(force_pio, poll);
|
|
|
|
}
|
2023-03-16 12:54:29 +03:00
|
|
|
|
|
|
|
#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
|
|
|
|
|
2021-08-27 08:08:43 +03:00
|
|
|
enumerate_storage_devices();
|
|
|
|
enumerate_disk_partitions();
|
2020-12-19 16:25:06 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
StorageManagement& StorageManagement::the()
|
|
|
|
{
|
|
|
|
return *s_the;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|