OSDev.org

Hi,

cyr1x wrote:and of course much more ..

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

Brendan wrote: 4. Make the device manager convert the PCI vendor and device ID (or any other identifying information) into an ASCII string

Yes, but the driver should register itself on install or on first start, so you needn't update the whole thing if a new device is created.

Im liking the path idea, that uses the PCI vendor etc.

But what about non-PCI devices?

There is no perfect solution.

But Brendan's suggestion reduces the size of your global config file by 95%.

Brendans suggestion does indeed look like a good'un

Hi,

lukem95 wrote:But what about non-PCI devices?

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

And im sure databases exist with these, we could provide a link from the EDI site.

this sounds good

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.

Happy hacking!

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.

Hi bewing,

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...

Cheers,

James

@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.

Or something like that.

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.

JJ

Just doing a bit of thread necromancing here.

Has anybody done any more with the EDI spec? Has anybody written any drivers? Has anybody implemented it in their kernel, or has plans to do so?

JackScott wrote:Just doing a bit of thread necromancing here.

Has anybody done any more with the EDI spec? Has anybody written any drivers? Has anybody implemented it in their kernel, or has plans to do so?

I had considered it... but there seems to be no implementation reference and it seems to be dead.. so I don't think I'll implement anytime soon....