OSDev.org

Thread for discussion on the EDI interface-in-the-making.

No spam please.

Yayyak or someone else - if you have a link to the current spec please link it.

EDIT: Here. http://sourceforge.net/project/showfile ... _id=148100

Cheers.

James

Original Topic for EDI: http://www.osdev.org/phpBB2/viewtopic.php?t=637

v3.3 Spec (not the newest, but the latest I can get from SF.net): http://sourceforge.net/project/download ... r=optusnet

He also put the 3.4 spec on SF, but never linked it. You can get it via the link I posted.

It looks like a fairly good start, but the sample driver code is messy and not very aesthetically pleasing.

I think that should be of some importance in a interface.

Not bad. It seems that it is a well thought interface.
You're that this is a good start for an interface.

Could have PNP support. But this is an absolute bastard to implement as even MS can't get it right and has tons of code in Windows.

OK, I've now had a look at this and I like it immensely!

One thing I have thought of though, is querying the PCI bus (for example). On architectures such as MIPS and ARM, each board gets devices Mmapped at different addresses! We need some way of querying the runtime to find, for example, possible the PCI config space so a driver can work out exactly where its resources are located.

What do you think?

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?

The interesting thing here is that its usually the driver's job to detect its own devices. How does the manager know what an RTL8139 is? How does it know where it could be found? what responses it would give to ID queries?

Well i think a logical approach would be for the manager to query (for example) for the type of driver:

Kernel: Wants to file X on HD0

Manager: Detects HD0, gets appropriate HDD driver (ATA) and FS driver (FAT32)

Driver (HDD): Carrys out read operation

Driver (FS): Loads file into memory and returns address

Kernel: Recieves address and opens file

Hi,



For me, the Device Manager is responsible for managing devices, including scanning the PCI bus to see which resources each (CPL=3) device driver should be allowed to access (and possibly parsing a "config.sys" style file for legacy devices that don't support Plug&Play). Device drivers don't have access to anything they don't need access to. This includes I/O ports that aren't part of the device and all of PCI configuration space.

The Device Manager also knows which devices are present and only starts device drivers that are needed - there's no need to start a few thousand device drivers (where 99% of them find out their device isn't present anyway).


Cheers,

Brendan

so

kernel->loads driver manager->scans pci etc->loads drivers needed passing BAR etc->drivers configure device and wait for command ??

Yeah, that sounds sensible. Again though, the device manager would need some way of mapping, say, PCI identification strings with driver names, so it can load the correct driver.

As mentioned on a previous thread, I've offered to host the specification. It can be found online at: http://www.jamesmolloy.co.uk/edi

Enjoy!

There would be several possibilities:

1. Create a global gonfig file. The device manager starts all drivers in the file and the driver returns a string, ID, ... and checks if it is available.

2. Create a config file for every device driver, where the identifier is stored.

3. Create a new (or extend) executable format for drivers, where the identifier is stored. (The hardest solution and harder to make it portable)

and of course much more ..

This seems the best to me, with the change that it's the device manager's perogative to enumerate all drivers on the system - it doesn't matter *how* it does it as long as it is done.

yeah, i agree that the devices need to be enumerated before the drivers are loaded, otherwise it would be a huge waste of resources.

The config file could include the string identifier, or for example the PCI identifier, and from the the correct driver would be deduced