Ah, since we're on the subject of Darwinian evolution, you might want to read up on the Darwin kernel's I/O Kit (used in Apple's Mac OS X), which serves not only as a general good example of a C++ object-oriented device driver framework, but also works the way you envisioned for hardware detection: each driver has a probe() method.Cjmovie wrote: Each module to have a fail-safe (as in 'wont hurt computer') feature named 'Detect', which will return a boolean true if it can prove the hardware it would control is their, a false if not.
What should be a module?
-
Arto
The I/O Kit
Re:What should be a module?
As always, reality can be a *****.
I know of at least one SCSI / NIC combination where the Linux driver scanning for the existence of the SCSI adapter causes the NIC to crash the whole system. (Advance 2940U2W and 3Com 905B.)
I know of at least one SCSI / NIC combination where the Linux driver scanning for the existence of the SCSI adapter causes the NIC to crash the whole system. (Advance 2940U2W and 3Com 905B.)
Every good solution is obvious once you've found it.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:What should be a module?
moreover, newer bus technologies such as PCI and USB have the option of scanning hardware to detect what's there. You could thus tell there's a USB keyboard available without even having proper driver for it, just with a generic USB bus driver.
Based on product/class/vendor/serial of what's present, you can then dig the list of available driver modules and load what's requested.
If i try to sum it up:
- you can have "boot-time drivers" packaged as a stuff that will be loaded in memory by your bootloader (GRUB can do it, for instance), which allows you to have fully modular FS/IO stuff without worrying about chickens and eggs (oh, and everyone knows dinosaurs were there first).
- you can have "microkernel setup program" that prepares the microkernel and a collection of "initial servers" ready to run in memory and *then* initiate microkernel operation, etc. which can help building lighter microkernels (esp. if module/servers loading is outsourced to a server aswell)
Based on product/class/vendor/serial of what's present, you can then dig the list of available driver modules and load what's requested.
If i try to sum it up:
- you can have "boot-time drivers" packaged as a stuff that will be loaded in memory by your bootloader (GRUB can do it, for instance), which allows you to have fully modular FS/IO stuff without worrying about chickens and eggs (oh, and everyone knows dinosaurs were there first).
- you can have "microkernel setup program" that prepares the microkernel and a collection of "initial servers" ready to run in memory and *then* initiate microkernel operation, etc. which can help building lighter microkernels (esp. if module/servers loading is outsourced to a server aswell)