Extensible Driver Interface

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!
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Extensible Driver Interface

Post by JamesM »

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
User avatar
JackScott
Member
Member
Posts: 1031
Joined: Thu Dec 21, 2006 3:03 am
Location: Hobart, Australia
Contact:

Post by JackScott »

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
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

He also put the 3.4 spec on SF, but never linked it. You can get it via the link I posted.
User avatar
lukem95
Member
Member
Posts: 536
Joined: Fri Aug 03, 2007 6:03 am
Location: Cambridge, UK

Post by lukem95 »

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.
~ Lukem95 [ Cake ]
Release: 0.08b
Image
cyr1x
Member
Member
Posts: 207
Joined: Tue Aug 21, 2007 1:41 am
Location: Germany

Post by cyr1x »

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.
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

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?
cyr1x
Member
Member
Posts: 207
Joined: Tue Aug 21, 2007 1:41 am
Location: Germany

Post by cyr1x »

Maybe this could be abstracted away, i.e.

Driver: Hey is there any RTL8139?
Manager: Yep here you have your resource.
:lol:

Or something like this.

Should be create a new Interface or one that's based upon EDI?
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

cyr1x wrote:Maybe this could be abstracted away, i.e.

Driver: Hey is there any RTL8139?
Manager: Yep here you have your resource.
:lol:

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?
User avatar
lukem95
Member
Member
Posts: 536
Joined: Fri Aug 03, 2007 6:03 am
Location: Cambridge, UK

Post by lukem95 »

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
~ Lukem95 [ Cake ]
Release: 0.08b
Image
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Post by Brendan »

Hi,
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?
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
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.
User avatar
lukem95
Member
Member
Posts: 536
Joined: Fri Aug 03, 2007 6:03 am
Location: Cambridge, UK

Post by lukem95 »

so

kernel->loads driver manager->scans pci etc->loads drivers needed passing BAR etc->drivers configure device and wait for command ??
~ Lukem95 [ Cake ]
Release: 0.08b
Image
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

Brendan wrote:Hi,
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?
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
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!
cyr1x
Member
Member
Posts: 207
Joined: Tue Aug 21, 2007 1:41 am
Location: Germany

Post by cyr1x »

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 ..
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

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.
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.
User avatar
lukem95
Member
Member
Posts: 536
Joined: Fri Aug 03, 2007 6:03 am
Location: Cambridge, UK

Post by lukem95 »

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
~ Lukem95 [ Cake ]
Release: 0.08b
Image
Post Reply