Extensible Driver Interface
Extensible Driver Interface
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
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
v3.3 Spec (not the newest, but the latest I can get from SF.net): http://sourceforge.net/project/download ... r=optusnet
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?
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?
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?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?
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
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,
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
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.JamesM wrote: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?
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
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.
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.Brendan wrote: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.JamesM wrote: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?
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
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 ..
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.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.