RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-26 00:17:46 +00:00
Code Issues Activity Actions

Kernel/Storage: Add LUN address to each StorageDevice

Browse source 
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.
This commit is contained in:
Liav A 2022-04-22 18:52:20 +03:00 • committed by Andreas Kling
parent b49af59b4a
commit 4744ccbff0
13 changed files with 76 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

19
Kernel/Storage/StorageDevice.h
View file

@ -45,6 +45,20 @@ public:
NVMe,
};
// Note: The most reliable way to address this device from userspace interfaces,
// such as SysFS, is to have one way to enumerate everything in the eyes of userspace.
// Therefore, SCSI LUN (logical unit number) addressing seem to be the most generic way to do this.
// For example, on a legacy ATA instance, one might connect an harddrive to the second IDE controller,
// to the Primary channel as a slave device, which translates to LUN 1:0:1.
// On NVMe, for example, connecting a second PCIe NVMe storage device as a sole NVMe namespace translates
// to LUN 1:0:0.
// TODO: LUNs are also useful also when specifying the boot drive on boot. Consider doing that.
struct LUNAddress {
u32 controller_id;
u32 target_id;
u32 disk_id;
};
public:
virtual u64 max_addressable_block() const { return m_max_addressable_block; }
@ -62,6 +76,8 @@ public:
void add_partition(NonnullRefPtr<DiskPartition> disk_partition) { MUST(m_partitions.try_append(disk_partition)); }
LUNAddress const& logical_unit_number_address() const { return m_logical_unit_number_address; }
virtual CommandSet command_set() const = 0;
StringView interface_type_to_string_view() const;
@ -71,7 +87,7 @@ public:
virtual ErrorOr<void> ioctl(OpenFileDescription&, unsigned request, Userspace<void*> arg) final;
protected:
StorageDevice(MajorNumber, MinorNumber, size_t, u64, NonnullOwnPtr<KString>);
StorageDevice(LUNAddress, MajorNumber, MinorNumber, size_t, u64, NonnullOwnPtr<KString>);
// ^DiskDevice
virtual StringView class_name() const override;
@ -82,6 +98,7 @@ private:
// FIXME: Remove this method after figuring out another scheme for naming.
NonnullOwnPtr<KString> m_early_storage_device_name;
LUNAddress const m_logical_unit_number_address;
u64 m_max_addressable_block { 0 };
size_t m_blocks_per_page { 0 };
};