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
```
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.
"Endpoint Address" refers to "[t]he combination of an endpoint number
and an endpoint direction on a USB device."
(USB 2.0 Specification, Chapter 2)
The USB::Pipe m_endpoint_address member doesn't have the direction part,
so rename it and all variables/functions associated with it
appropriately.
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>
Previously USB::Pipe would just try to poorly maintain copies of some
of the relevant properties of USB::Device. (address & speed)
Now it just holds a reference to it's owning device and can query them
when needed.
At any one given time, there can be an abitrary number of USB drivers in
the system. The way driver mapping works (i.e, a device is inserted, and
a potentially matching driver is probed) requires us to have
instantiated driver objects _before_ a device is inserted. This leaves
us with a slight "chicken and egg" problem. We cannot call the probe
function before the driver is initialised, but we need to know _what_
driver to initialise.
This section is designed to store pointers to functions that are called
during the last stage of the early `_init` sequence in the Kernel. The
accompanying macro in `USBDriver` emits a symbol, based on the driver
name, into this table that is then automatically called.
This way, we enforce a "common" driver model; driver developers are not
only required to write their driver and inherit from `USB::Driver`, but
are also required to have a free floating init function that registers
their driver with the USB Core.
