How are device drivers handled in Haiku? Are they installable/executable like .exe files, or do they follow the .nix method of residing within the kernel itself? I sincerely hope it’s the former, b/c that was the final straw that made me leave linux. After the kernel upgraded to 2.25.(something), several of my devices no longer worked “b/c they were too old”. I checked online and was told I would have to tweak/recompile the kernel itself–something I have very little inclination of doing. I reinstalled windows xp, downloaded all the device drivers for laptop and viola–instant happiness(except for the fact I was stuck w/ windows again. After windows ticked me off(yet again), I installed pc-bsd and patiently wait for the day I can use Haiku(provided the answer to my original question is favorable). Thanks.
Your question begins from a false assumption. Essentially as if you asked, “Are sheep water-breathing, like cows? Or do they fly through the air, like camels?”. So it would be much easier to offer an answer if you made it clear what you actually want to know.
In Linux the device drivers are usually separate modules which can be loaded into the kernel as necessary. You can arrange for modules to be included into the file containing the core kernel, but most systems don’t do this (embedded systems sometimes do and I suppose some ricer Gentoo types might). Instead usually the modules reside in ‘.ko’ files in the various subdirectories of the /lib/modules/ directory, for example you would have ahci.ko which is a driver for AHCI SATA controllers. Such modules are certainly “installable” in the sense you seem to mean.
When some new hardware is available on a modular system the Linux kernel provides the userspace information about the hardware, and if there’s a suitable driver it is loaded automatically and any appropriate action can be taken. For example, if I plug in an old PCMCIA WiFi card, it will be detected, the necessary driver is loaded and if I don’t have an Internet connection already it will try to scan for Wireless APs and offer a list to connect to.
Haiku works much the same way except that there’s no userspace mechanism to identify suitable drivers for new hardware. So every driver must either be kept loaded into RAM all the time, or reloaded for each new device that is connected.
It is possible for device drivers to be implemented as non-kernel executables, but none of the systems you’ve tried do that, to have all the device drivers outside the kernel requires a microkernel design, like QNX or GNU HURD. In practice it seems to be very difficult to achieve good performance this way, although QNX does better than most.
Installing drivers in Haiku is very simple - like Windows.
Later on, when they come out with package manager - you’ll be able to click on packages ( for programs or drivers ) & they’ll automatically install.
Right now, for any 3rd party video, audio or network drivers - you must unzip, then copy the driver to the right directory and create a symbolic link. ( everything takes less than 2 to 3 minutes to do ). Very, very easy. But, you’ll still require someone to create/port the drivers to Haiku.
Don’t expect Haiku out any time soon. Still hasn’t even hit Alpha. Could be awhile for R1 so you’ll just have to make due with BSD for awhile.
That is entirely incorrect. In Haiku a combination of the device manager and bus managers are responsible for detecting new devices and scanning for appropriate drivers. This is done intelligently though. And no, all drivers are not loaded into RAM all the time. They are in fact loaded/unloaded on demand as their device descriptors are opened. When a device is first detected, a suitable driver is chosen via probes, which then publishes an entry in the devfs and unloads again. If someone then asks to access a device that’s currently not in use by any app or server, the driver will be loaded on demand, and unloaded again when its ref count returns to 0.
It’s actually much simpler than in windows.
You don’t have to install anything (including 30MB of useless junk along with the 3KB driver file), if it’s supported, it just works.
On worst case you just have to unzip something (the zip itself wil contain the needed symlinks), but certainly not 30MB.
The problem with linux is not that it’s modular, it’s not more than windows.
It’s just that the modules do not follow a clean design. They just link to each other and the kernel and use whatever API is available on that precise kernel version.
Since the kernel API changes every now and then, each kernel version implies you must rebuild all modules because they might have become incompatible.
BeOS OTH, enforces a clean design of modules, because they can only link to the kernel itself, and use public APIs (that’s a bit less true on Haiku because we have the kernel sources). That was made necessary due to the kernel being closed. Sometimes not having sources can turn to an advantage. Also, modules can only call others through a clean versionned API, and must explicitely load each other, so they can gracefully fail if one isn’t found. On linux if you have a missing symbol it just won’t load and you’re on your own. Or worse, if you have all symbols but the version is wrong you’ll crash or corrupt data.
First of all, thank you all for your responses. I apologize if any part of my question is in error. I’m not a programmer, so everything I learn is from reading lots of forums. Everything I have heard so far sounds good to me, so I have no problem waiting until Haiku stable is out(despite the long time). I’ll even be willing to run the Betas–if I could manage to get them installed on my laptop. Thank you all again.
I think it would be great to have a microkernel mode in Haiku one would boot in to develop and especially test device drivers without the whole rebooting process and crashes due to memory allocation/overwriting of drivers in their development stage.
You can more or less do that already. The thing is split your driver in two:
- A very thin kernel mode driver (just to provide HW access, memory maps, etc.).
- A user mode library/add-on/application that does the rest.
If the thin kernel mode driver is properly written (I should learn to do that!) rebooting while developing them (for non “critical hardware” related drivers) is a thing of the past.
Another advantage: easier to debug.
Sounds great, still when you fiddle with HW access, memory maps, etc. you can easily crash your machine or is there not much to fiddle with in that area? I believe Rudolf the author of GeForce 3D drivers had to poke around the hw a lot, finding out what certain registers do, could one do that from userspace without crashing the OS?
An in-depth article about this would be great for devs IMHO.
[quote=nutela]Sounds great, still when you fiddle with HW access, memory maps, etc. you can easily crash your machine or is there not much to fiddle with in that area? I believe Rudolf the author of GeForce 3D drivers had to poke around the hw a lot, finding out what certain registers do, could one do that from userspace without crashing the OS?
An in-depth article about this would be great for devs IMHO.[/quote]
You won’t crash the kernel, but if you’re fiddling with the registers it’s still entirely possible to hard lock the box if you do something wrong, regardless of whether you’re in kernel or userspace, so honestly it isn’t really all that helpful in the bigger picture of things.
[quote=anevilyak]
That is entirely incorrect. In Haiku a combination of the device manager and bus managers are responsible for detecting new devices and scanning for appropriate drivers. This is done intelligently though.[/quote]
It’s done by trying every single driver. What’s “intelligent” about that ?
The probes are part of the driver. So to “choose” a driver the Haiku kernel loads every possible driver and runs its individual probe functions. For “hot plug” devices, the probe functions, and thus the driver, are permanently in RAM.
Driver defined “probe” functions were an excellent design choice for PCs with old-style ISA hardware, but for the past 15 years a better approach has been to directly enumerate hardware using unique identifiers. In Linux 2.6 these identifiers look like
pci:v00008086d00002668sv00001014sd000005B7bc04sc03i00
usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00
The Linux userspace can do whatever it likes with these identifiers, but most usually the module utilities match the identifier against a list of wildcard aliases for driver modules. Thus only the most appropriate driver (if any) is loaded. Drivers for hardware you don’t own remain on disk in case you buy new hardware some day, but they aren’t loaded into the kernel. Each driver module contains a list of its dependencies, a source version cookie and a list of wildcard aliases, as well as copyright information and a description - so it is self-contained. The source version cookies ensure that only a compatible driver can be loaded.
So for comparison - if we look at the Haiku probe mechanism there is chaos. Each driver author implements his own probing routine however he sees fit. So far Haiku really only supports a primitive “hot plug” for USB, other common buses are “probed” only when Haiku is rebooted or aren’t supported at all. So we shall look at USB, and in that case the drivers are always kept in RAM because they register a callback function, and of course if the driver was unloaded the callback function would be invalid and the kernel would fault when trying to call it.
Interesting
The part where that’s no longer how it works? I suggest you actually look at how Haiku’s new device manager-based driver model works instead of constantly running your mouth and spreading FUD on the basis of the assumption that everything is identical to BeOS-land circa 8 years ago.
[quote=NoHaikuForMe]
So we shall look at USB, and in that case the drivers are always kept in RAM because they register a callback function, and of course if the driver was unloaded the callback function would be invalid and the kernel would fault when trying to call it.[/quote]
Nope, that’s simply not how it works. A USB driver registers itself with the USB stack when it loads the first time, giving it a list of support descriptors, describing what kind of device the driver is interested in (based on vendor, device, class, subclass, protocol ids). Then the driver installs the notify hooks and gets notified of any already connected device that matches the support descriptors. If no device is present the driver is unloaded uninstalling the hook again. When a device is plugged in later that matches any support descriptors, the driver will be reloaded based on the registered information where it then installs the notification hooks again and is notified of the present devices. So an unused driver is not kept loaded as you imply.
Right now “legacy” drivers represent a substantial portion, if not the majority, of Haiku’s drivers. Which isn’t such a surprise when you consider that even Haiku’s developers don’t seem to agree about whether the “new device manager-based driver model” is a step forward. Axel decided that the core “device manager” would actually only care about PCI, and further that it would internally enumerate the relationship between arbitrary PCI codes and device drivers. Yet another upside-down design decision.
And, even with the “new” model, drivers that don’t and couldn’t possibly work with your hardware will be probed. Today Haiku has relatively few drivers, and some of those don’t build or aren’t included because they don’t work, so this burden is hardly felt, but to get something that works “out of the box” on most people’s machines will require hundreds of drivers (a typical desktop Linux system has about six hundred kernel drivers).
[quote=mmlr]
Nope, that’s simply not how it works. A USB driver registers itself with the USB stack when it loads the first time, giving it a list of support descriptors, describing what kind of device the driver is interested in (based on vendor, device, class, subclass, protocol ids). Then the driver installs the notify hooks and gets notified of any already connected device that matches the support descriptors. If no device is present the driver is unloaded uninstalling the hook again. When a device is plugged in later that matches any support descriptors, the driver will be reloaded based on the registered information where it then installs the notification hooks again and is notified of the present devices. So an unused driver is not kept loaded as you imply.[/quote]
Yes I see, you’re right, I was misled by my first reading of this code. This is still a very roundabout way to achieve something that’s actually very simple.
“This is still a very roundabout way to achieve something that’s actually very simple.”
Did you commit anything?
Before we go down this flametastic direction… let’s remember that constructive criticism is still a form of communication 
But let’s make sure and keep it constructive.
On the other hand, this thread in the forums isn’t going to get as much attention as it would on the haiku-development mailing list. Perhaps if there’s a better way to do it - that’s the location to have this discussion if there’s any hope that the Haiku devs would change anything.