We have a system that is automatic now and already works. Why would we go back 30 years to the way it worked in Windows 95? You know, the OS we all laughed about because BeOS had no such problems. Just plug and play.
If that’s the direction we are headed, asking users to do some manual interevention everytime they want to install a driver, I’d much prefer we don’t touch anything and keep what we have now.
But, fortunately, I think none of the people currently working on this are headed that direction
Usb devices are peripheral, and should be polled on a regular interrupt, say 5 second intervals. In fact voard level hardware and usb external devices need different handling.
I’d break device management into 4 category’s and make it extensible.
Bios/uefi class
Pci/pcie
Chipset
External peripheral usb etc.
They all have different behaviors and needs, there’s no reason to jam it all into 1 big giant do everything spaghetti monster.
You can cache the first 3, those don’t chabge frequently, and set up a trugger for rescan when hardware that expected doesn’t attach. If else compare, clean simple easy, maintainable
How would you handle people who boot Haiku off an USB drive? This is not peripheral at all.
Why would the type of bus be such a distinction? Many laptops have USB touchpad and keyboards, and even storage for the cheapest ones, that are not removable at all.
What about USB4 and Thunderbolt? They are just PCI with a USB shaped connector.
What about the docking station on my laptop, which is a PCI express bus on its own, with several devices connected to it?
The real world of computer hardware does not match with these simplifications.
Usb is a dynamic system asset, much like a network, in fact USB has more in common with a tcpip network or can bus than the , static hardware elsewhere in the machine.
To counter your other point, the kernel and drivers are loaded into a static spot in the ram at boot, unless you’re aware of someone hot plugging motherboards, cpu, etc in a running system, motherboard static assets are not going to vary in a running environment.
There is a serious conceptual misalignment here.
USB is a special type if dynamic hardware, it should be handled more like a network, which it’s behavior minics, because it’s actually a 9nboard serial com network.
Forcing device management to work for both static and dynamic assests , when they have dramatically desperate modes of operating, is not a good idea and will make for a very overly complicated control scheme full of strange rules.
As Pulkomandy just stated, Haiku on a USB drive… well then the CPU and all the other stuff are now the thing that changes… it has to be automatic every boot. Frankly I dont’ think its that big of a deal unless you are scaling to 1000s of CPUs and buses where Linux does see enumeration speed become a problem.
Windows has been scorned by IT professionals for decades because of its poor device reconfiguration.
When talking about PCs and UEFI systems and even ARM/RISC-V systems… there is no reason for all devices to not be dynamic. Neither is it a good idea to design into a corner, systems with pluggable CPUS/RAM/HDD/ what have you do exist either cold plug or hotplug alike. Definitely GPU hotplug has become a common thing in the past couple years.
This looks like MS DOS or Windows 95 way of thinking where you need to reboot every time hardware configuration is changed. Today nearly every device can be hot plugged and I see no reason to make separate handling of hot-pluggable and not hot-pluggable devices. It will only complicate things. Reading compatible info from all driver add-ons every boot will be fast enough (< 0.1 sec) on every hardware suitable to Haiku.
that’s not even remotely close to the suggestion I am making. Secondly most hardware if you hot plug it " not usb" will cause the mother board to have issues. This is a non issue, and it’s a non existent outside of server racks. Also that’s not even remotely close to MS dos or window 95 which did not dynamically handle drivers at all and required a driver to be load, and store and then assigned by IRQ number. might want to read the old 386x specs. You had to MANUALLY assign the IRQ at the BIOS, mind you I am almost 50 and I was using those system when they were new.
There is absolutely no practical use case where a PC operating system will EVER need to hot plug anything but USB and other CAN network like devices on a serial bus of some form. Most motherboard do not support it to begin with. Haiku is not a SERVER rack operating system and does not require SERVER rack accommodation.
Have you even heard about USB 4/Thunderbolt? It is actually hot-pluggable PCIe device that use USB type C physical connector. It can be used to connect NVMe SSDs or external GPUs for example. So it need OS support for hot-pluggable PCI devices such as PCI BAR resource reassignment.
New microSD Express memory card standard also directly use PCIe bus.
Agreed, mostly you assigned IRQ/DMA with jumpers. The bios was
for onboard things, when they existed ( usually from 486 and up ) : serial and parallel ports, joystick, IDE.
Things like network cards, sound cards, modems, etc, had either jumpers or software utilities to set them. Some were fixed on some irq/dma, and would be inconvenient if the computer had another card with the same exigences.
That is just nonsense, SATA is perfectly hot-plug capable and there are enough desktop computers that expose SATA ports to the outer casing to connect drives.
(add tp that the obvious thundervolt case mentioned above. Or firewire or displayport or…)
I know that it’s generally a good idea to reduce duplication of effort/code, but is there any reason
to not have a one-time probe at boot for certain kinds of USB peripherals? Some devices definitely fall into a class where you’d expect it to be plugged in once and not removed.
Obviously, we still need Haiku to handle hot-plugging, but I think it’s probably okay to not worry about hotplug events that occur while the system is booting up as long as that is intentional and clearly documented behavior.
E.g.
keyboard
mouse
boot devices (hard drive, cd drive flash drive – mass storage)
printers
maybe also:
sound devices (speakers, microphone)
network devices (ethernet, wifi)
That is just nonsense, SATA is perfectly hot-plug capable and there are enough desktop computers that expose SATA ports to the outer casing to connect drives.
(add tp that the obvious thundervolt case mentioned above. Or firewire or displayport or…)
I think it’s probably safe to assume that USB is the use case of most immediate concern.
While SATA/eSATA is a thing, I believe it is rather uncommon for most end users to be hotplugging SATA devices. I would love to see Haiku support FireWire (FW) but I can’t see that it’s a real priority given that new computers haven’t come with it built-in for a long time and most devices are legacy products at this point.
DisplayPort seems like it would fall under detecting the monitors/displays that are attached and would be a similar concern as VGA or HDMI displays being connected after the system is booted up.
There are no reason to permanently save information about connected devices because discovering devices on each boot is fast enough. Adding permanent connected hardware information will only complicate things and increase a chance of various failures, but it will not save more than 0.1 seconds of boot time. Effort is not worth.
I wasn’t talking about permanently saved information, just proposing that there could be a single probe for connected USB devices at boot and no hot-plug detection at all until the system is completely up and running.
What problem are you trying to solve by disabling hot-plugging until “system is completely up and running”? Hot-plug events are usually zero-cost when it are not triggering. For USB for example hot-plug events can be detected using interrupts without any polling and this is how already my Device Manager v2 works.
I do not know the current state of the new device_manager.
My main interrest is for Intel GPUs. They offer the following functions:
multiple monitors (eDP, DisplayPort, HDMI, DSI), up to 4
multiple displays on a single DisplayPort connection (MST)
audio via DisplayPort and HDMI
Hot Plug Detection on Displayport and HDMI
Video capture
Video Codecs
While displays and audio outputs are plug and play, video capture and codec utilisation are not.
I think we should make sure those functions can be supported by the new device_manager.
@X512 I want to help you with the documentation and tests, I think it is very important for newcomers like myself to have a good guidance when developing a driver.
So, I’ve come across another thing that needs to be taken into account in a new API design (though it shouldn’t be too difficult to do so):
devfs mode types and permissions
Right now, devfs publishes all files as S_IFCHR. But this means that TTYs, /dev/random, etc. which are really S_IFIFO (that is, unseekable) aren’t detected and managed as such. Furthermore there isn’t any way to specify what permissions published devices should have.
