Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
4. Make the device manager convert the PCI vendor and device ID (or any other identifying information) into an ASCII string that's used as a device driver file name. For example, an Intel 82557 Fast Ethernet LAN Controller has "vendorID = 8086" and "device ID = 0x1226", so the device manager tries to start the device driver "sys/drv/pci/8086/1226.drv" (which may be a device driver, or may be a symlink to a generic device driver, or...). If the exact device driver isn't present in the file system the device manager could try a generic driver (e.g. check the PCI class codes).
Of course this is only a beginning - there's many additional features, etc that could be added.
For some of us it'd also cause problems: how to start a device driver from the filesystem before device drivers and filesystems are running, but my OS design avoids that problem...
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
For non-PCI things, there's EISA IDs for most things (the same EISA IDs are also used by "ISA Plug & Play" and ACPI, IIRC).
Unless the device supports Plug and Play you need to either manually detect the device (probing) or expect the user to provide details in some sort of configuration script (or both). If the user provides details in a configuration script then the user would need to know the correct EISA ID for the device, but this is no worse than needing to know the correct device driver name.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
cyr1x wrote:Maybe this could be abstracted away, i.e.
Driver: Hey is there any RTL8139?
Manager: Yep here you have your resource.
Or something like this.
Should be create a new Interface or one that's based upon EDI?
Hi, I'm the guy who originally created EDI. It's nice to see that somebody actually decided to pick up the work now that I lack the spare time for OSdeving any longer!
Anyway, my original idea for "here's your resource" stuff was that abstract resources be represented by classes that some driver registered with the EDI runtime. These wouldn't be standardized as a part of EDI; instead, driver/runtime developers are expected to invent these, implement them, and argue over which ones work better for themselves. That's the "extensible" bit, because I realized pretty early on that every OSdever really has their own way of doing things, and an API that succeeds will need to acquiesce to that.
Maybe if I ever get around to OSdeving again I'll help out with the implementation of the much-improved EDI you guys are building.
Unfortunately, my winzip errors out when it tries to open your tarball -- so I can't look at your spec without a big hassle of porting back and forth between OSes.
For convenience I've untarred the files and posted them at http://www.jamesmolloy.co.uk/edi .
Copyright to Eli Gottlieb (crazed123), of course.
I was also pondering on EDI on the bus into work. If we went with Brendan's idea, how would we implement fallback drivers? The example that springs to mind is "no hardware acceleration? use the vesa driver!" in the graphics card world.
Another useful thing would be to add to the API a way to probe IRQs - IRQ autodetection, like in linux.
Generally Eli's and Brendan's driver detection methods seem pretty mutually exclusive, so we'll have to pick one...
@JamesM -- thank you for going to that effort. I expect and hope that enough people will utilize that page to make your work wortwhile.
The spec seems entirely dedicated to drivers that talk directly to hardware. I am having trouble conceiving how to create a "virtual" driver using these methods -- ie. a caching subsystem, or a software mediated compression/decompression mechanism. Because of this, I am also having trouble fitting it into my (current) conception of multiple pipelined drivers -- since the EDI runtime does not seem to have any easy generic access to the output of an EDI driver.
A "primitive" driver that talks to hardware registers classes with the runtime that it supports. Other drivers can then access those classes themselves, just like they would built-in classes.
This means that if you want, say... a sound-mixer driver that acts like multiple sound cards to mix streams before sending them to the actual hardware, you would write a mixer driver that imports a "sound card" and exports its own "sound card" class or subclass. The OS would then use *that* "sound card" to provide sound drivers for applications.
Crazed123 wrote:A "primitive" driver that talks to hardware registers classes with the runtime that it supports. Other drivers can then access those classes themselves, just like they would built-in classes.
That was what I thought initially.
This means that if you want, say... a sound-mixer driver that acts like multiple sound cards to mix streams before sending them to the actual hardware, you would write a mixer driver that imports a "sound card" and exports its own "sound card" class or subclass. The OS would then use *that* "sound card" to provide sound drivers for applications.
I'm also thinking about a partition table driver that would present to the runtime the logical partitions.
For example, a kernel-land logical volume manager could expect it's driver_init_t() to be called with an array of the physical disks available in the system (having the block-oriented devices a set of standard methods). The low level "mapper" would then be called in order to scan the available disks for recognizable physical volumes.
