The default template argument is only used in one place, and it
looks like it was probably just an oversight. The rest of the Kernel
code all uses u8 as the type. So lets make that the default and remove
the unused template argument, as there doesn't seem to be a reason to
allow the size to be customizable.
This commit moves the KResult and KResultOr objects to Kernel/API to
signify that they may now be freely used by userspace code at points
where a syscall-related error result is to be expected. It also exposes
KResult and KResultOr to the global namespace to make it nicer to use
for userspace code.
According to the VirtIO 1.0 specification:
"Non-transitional devices SHOULD have a PCI Device ID in the range
0x1040 to 0x107f. Non-transitional devices SHOULD have a PCI Revision ID
of 1 or higher. Non-transitional devices SHOULD have a PCI Subsystem
Device ID of 0x40 or higher."
It also says that:
"Transitional devices MUST have a PCI Revision ID of 0. Transitional
devices MUST have the PCI Subsystem Device ID matching the Virtio
Device ID, as indicated in section 5. Transitional devices MUST have the
Transitional PCI Device ID in the range 0x1000 to 0x103f."
So, for legacy devices, we know that revision ID in the PCI header won't
be 1, so we probe for PCI_SUBSYSTEM_ID value.
Instead of using the subsystem device ID, we can probe the DEVICE_ID
value directly in case it's not a legacy device.
This should cover all possibilities for identifying VirtIO devices, both
per the specification of 0.9.5, and future revisions from 1.0 onwards.
This ensures we safely handle interrupts (which can call virtual
functions), so they don't happen in the constructor - this pattern can
lead to a crash, if we are still in the constructor context because
not all methods are available for usage (some are pure virtual,
so it's possible to call __cxa_pure_virtual).
Also, under some conditions like adding a PCI device via PCI-passthrough
mechanism in QEMU, it became exposed to the eye that the code asserts on
RNG::handle_device_config_change(). That device has no configuration but
if the hypervisor still misbehaves and tries to configure it, we should
simply return false to indicate nothing happened.
Like with the ProcFS, description data can change at anytime, so it's
wise to ensure that when the userland reads from an Inode, data is
consistent unless the userland indicated it wants to refresh the data
(by seeking to offset 0, or re-attaching the Inode).
Otherwise, if the data changes in the middle of the reading, it can
cause silent corruption in output which can lead to random crashes.
And also try_create<T> => try_make_ref_counted<T>.
A global "create" was a bit much. The new name matches make<T> better,
which we've used for making single-owner objects since forever.
This leads to a bad pattern where anyone could create an RNG or a
Console object. Instead, let's just use the common pattern of a static
method to instantiate a new object and return it wrapped by a
NonnullRefPtr.
Before of this change, many specific classes to VirtIO were in the
Kernel namespace, which polluted it.
Everything should be more organized now, but there's still room for
improvement later.
This class member was used only to determine the device type when
printing messages to the debug log. Instead, remove this class member,
and add a quick way to find the device type according to how the VirtIO
specification says to do that.
This simplifies construction of VirtIODevices a bit, because now the
constructor doesn't need to ask for a String identified with the device
type.
This class as a CharacterDevice really was not useful, because you
couldn't even read from it.
Also, the random number generator interface should be the /dev/random,
so any other interface to get random numbers is generally not a good
idea.
Instead, let's keep this functionality as an entropy source for random
numbers generation, but without exposing a device node.
We now expose the `USBDevice`'s address in the SysFS object. This means
that device addresses are no longer determined by the name of the file
in the `/bus/usb/` directory. This was an incorrect way of determining
device address, as a standard PC can have multiple USB controllers
(and hence multiple buses) that can have overlapping device IDs.
Now that the old PCI::Device was removed, we can complete the PCI
changes by making the PCI::DeviceController to be named PCI::Device.
Really the entire purpose and the distinction between the two was about
interrupts, but since this is no longer a problem, just rename it to
simplify things further.
I created this class a long time ago just to be able to quickly make a
PCI device to also represent an interrupt handler (because PCI devices
have this capability for most devices).
Then after a while I introduced the PCI::DeviceController, which is
really almost the same thing (a PCI device class that has Address member
in it), but is not tied to interrupts so it can have no interrupts, or
spawn interrupt handlers however it wants to seems fit.
However I decided it's time to say goodbye for this class for
a couple of reasons:
1. It made a whole bunch of weird patterns where you had a PCI::Device
and a PCI::DeviceController being used in the topic of implementation,
where originally, they meant to be used mutually exclusively (you
can't and really don't want to use both).
2. We can really make all the classes that inherit from PCI::Device
to inherit from IRQHandler at this point. Later on, when we have MSI
interrupts support, we can go further and untie things even more.
3. It makes it possible to simplify the VirtIO implementation to a great
extent. While this commit almost doesn't change it, future changes
can untangle some complexity in the VirtIO code.
For UHCIController, E1000NetworkAdapter, NE2000NetworkAdapter,
RTL8139NetworkAdapter, RTL8168NetworkAdapter, E1000ENetworkAdapter we
are simply making them to inherit the IRQHandler. This makes some sense,
because the first 3 devices will never support anything besides IRQs.
For the last 2, they might have MSI support, so when we start to utilize
those, we might need to untie these classes from IRQHandler and spawn
IRQHandler(s) or MSIHandler(s) as needed.
The VirtIODevice class is also a case where we currently need to use
both PCI::DeviceController and IRQHandler classes as parents, but it
could also be untied from the latter.
The previous version of this was pretty bad and caused a lot of
odd behevaiour to occur. We now abstract a lot of the allocation
behind a `template`d pool class that handles all of the memory
allocation.
The number of UHCI related files is starting to expand to the point
where it's best if we move this into their own subdirectory. It'll
also make it easier to manage when we decide to add some more
controller types (whenever that may be)
There's no need for generated files in SysFS to tell you their precise
file size when you stat() them.
I noticed when profiling "find /" that we were spending a chunk of time
generating and throwing away SysFS content just so we could tell you
exactly how large it would be. :^)
This makes for nicer handling of errors compared to checking whether a
RefPtr is null. Additionally, this will give way to return different
types of errors in the future.
A hub can technically have up to 255 ports, given that bNbrPorts is a
u8 and the DeviceRemovable field is a VLA to support up to 255 ports.
Source: USB 2.0 Specification Section 11.23.2.1
That means this enum is not going to scale well in terms of size.
Replacing it with a raw u8 allows me to remove the two port assumption
and a cast.
Previously it would create a contiguous AVMO manually and pass it to
MM. This uses supervisor pages that quickly run out as they never get
returned and crash the system.
Instead, use allocate_kernel_region as we're only allocating a page so
it will be contiguous and will be returned when destroyed.
A potentially better solution would be to use a pool of transfers to
avoid all the allocations. This just prevents the system from crashing
within ~5 seconds from the continuous hub polling.
This is a bug that went unnoticed for a long time, so the exposed values
in SysFS PCI device directories were incorrect because the assigned PCI
address was simply the host bridge always.
Also, the bus typing should really be two hexadecimal digits and not 4
digits.
This patch removes KResult::operator int() and deals with the fallout.
This forces a lot of code to be more explicit in its handling of errors,
greatly improving readability.
This removes Pipes dependency on the UHCIController by introducing a
controller base class. This will be used to implement other controllers
such as OHCI.
Additionally, there can be multiple instances of a UHCI controller.
For example, multiple UHCI instances can be required for systems with
EHCI controllers. EHCI relies on using multiple of either UHCI or OHCI
controllers to drive USB 1.x devices.
This means UHCIController can no longer be a singleton. Multiple
instances of it can now be created and passed to the device and then to
the pipe.
To handle finding and creating these instances, USBManagement has been
introduced. It has the same pattern as the other management classes
such as NetworkManagement.
