For now we only support USB <3.0 devices, as we don't support streams.
We also don't leverage the benefits of UAS, as we pretend to have a
queue depth of 1, ie are single threaded.
To test this driver, you can use the following command:
```
SERENITY_BOOT_DRIVE=usb-uas Meta/serenity.sh run x86_64 Clang
```
Do this by:
- Removing more instances of `LockRefPtr` and `NonnullLockRefPtr`.
- Using better names of construction methods (i.e. `create` instead of
`try_create`).
- Only returning `NonnullRefPtr` on the `Device::try_create_device`
method.
- Removing a version of the `Device::try_create_device` method that
called `DeviceType::try_create(forward<Args>(args)...)`, which was
only used in a construction point in a VirtIO driver which now doesn't
need this anymore.
This change has many improvements:
- We don't use `LockRefPtr` to hold instances of many base devices as
with the DeviceManagement class. Instead, we have a saner pattern of
holding them in a `NonnullRefPtr<T> const`, in a small-text footprint
class definition in the `Device.cpp` file.
- The awkwardness of using `::the()` each time we need to get references
to mostly-static objects (like the Event queue) in runtime is now gone
in the migration to using the `Device` class.
- Acquiring a device feel more obvious because we use now the Device
class for this method. The method name is improved as well.
This will allow us to make send_scsi_command a member function. This is
necessary because we need to execute some SCSI commands
(with send_scsi_command) to get all arguments necessary for the
StorageDevice constructor.
This change should will likely also be necessary to support USB mass
storage devices with multiple LUNs.
This allows us to properly limit our block requests to the device's
capabilities, and choose more optimal block counts for I/O operations.
In theory, as Qemu only advertises a block limit above our current
internal block size limit of u16::max and does not advertise any optimal
transfer lengths.
This is apparently what bootloaders do before using a USB storage device
so we should likely do so as well, especially when no BIOS is present,
like on riscv.
Co-Authored-By: Sönke Holz <sholz8530@gmail.com>
