That is only a limitation of the C/C++ language. So, yes, it means declaring such things using C structs is not a great solution. But if it is desirable to have this info in an ELF section, we can achieve that in other ways, for example by declaring the data directly in an assembler sourcefile, or by using some other tool to generate a .o with the layout we want inside.
And even with separate string literals in a C struct, I think we could get something usable with a few macros.
But at that point, indeed we have to ask ourselves: what benefit do we get from putting this info inside the ELF files, compared to xattrs or even BResource?
The design of this part of the operating system is getting vastly over complicated
At first boot with fresh install
Query mother board and cpu serial cache those and create a hdd cached file for storage of hardware information. Put it in the bootsector and have the kernel read it at boot up.
Probe bus, get devices and device list. Cache that
Create kernel driver loading logic , is cache file present yes/no, if yes load cache file, if no probe all busses and match drivers. Store bus map in cached file
Add a few checks for basic hardware changes cpu motherboard chipset etc serial number to trigger cache refresh in case install os portable . In fact have a scan default for portable installs isa good idea anyways.
Simplify the design. It’s hardware it’s not that smart and most people aren’t booting portable thumb drives on multiple systems. That’s definitely a outside use case.
By moving the bus cache or even the bus probe logic into a stored file in the boot sector the kernel reads at boot you could make that extensible for fdt and other non x86 hardware.
Also a checksum of ram CPU serial motherboard serial could be used to trigger a cache refresh. Post boot at desktop, have the system rerun a full bus scan to verify hardware config.
That is not a particularly good design, though. You only need to change one piece of hardware, and the whole thing breaks down. That reminds me of Windows 95, to be honest.
Iterating over the existing busses is nothing you can skip. You will always need to do that, and it’s usually also not really that slow to justify caching it at all. However, it may make sense to cache the information which driver feels responsible for a particular piece of hardware, to not have to iterate over all drivers. But even then, drivers can change without the operating system being in charge, so it’s always best if the actual driver discovery phase is as fast as possible, so that caching is not necessary.
But on the other topic: if you cannot properly subclass C++ code, but need to have pure virtuals or everything in kernel, what would we actually gain by using a C++ interface? Having the ability to subclass devices would be a huge argument for having a C++ interface, like a SCSI bus driver that brings its own classes to the table. If that isn’t possible, it may complicate things more than it does any good IMO.
I’m also a big fan of being able to put audio drivers into an audio directory, and only query them for their support when there actually is an audio device.
Better type safety. The current module_info struct with function pointers makes it somewhat easy to put methods in the wrong order or forget one, and then it can be quite difficult to understand what the problem is. This is of course even worse if the parent class changes. With (modern) C++, we can use the ‘override’ keyword in subclasses to make sure the subclass is doing what it intends to do.
Similarity with other parts of the code. Everyone already knows how to subclass a C++ class. Related to that, self-documentation: you can read the .h defining the class and the function prototypes, and get a good idea of what it does. Doing the same with a struct full of function pointers isn’t that easy. With a class I can document the process of writing a driver in one sentence: “To create a driver, you subclass the Driver class and implement the Read, Write, Open, Close and Ioctl methods defined in there”. I do not need to get into more details about how to set up a driver/module structure, and so on.
On the other hand, it is a big change compared to what we used to do, and it will be C++ “but-not-quite” due to the limitations, so it still isn’t that simple. For me it is difficult to say how the improvements and downsides balance out.
How about something in the line of a file with pci-id ↔ drivername pairs ? That could be updated alongside the system, or manually when the person adds a driver ?
What if user install 3rd-party driver? Who will update hardware-driver matching list file? Installer? User itself manually? It sounds fragile because list can become inconsistent after improper user editing or broken installers and can cause system to become unbootable.
Idea is basically the same as this file, but without linking into executable.
I thought more like a binary file, not something text that the user would edit himself. An installer, or Preferences applet for “Add New Hardware” would update the file when a new 3rd driver ( do we have those ? ) would be added.
The point I mean is to avoid having to read pieces from every driver file every boot. But I also believe the solution proposed by collins a few posts ago wouldn´t work
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.
) would be added.
