OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:45 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject:
PostPosted: Tue Mar 25, 2008 5:10 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
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

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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 25, 2008 6:14 am 
Offline
Member
Member

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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 25, 2008 9:02 am 
Offline
Member
Member
User avatar

Joined: Fri Aug 03, 2007 6:03 am
Posts: 536
Location: Cambridge, UK
Im liking the path idea, that uses the PCI vendor etc.

But what about non-PCI devices?

_________________
~ Lukem95 [ Cake ]
Release: 0.08b
Image


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 25, 2008 1:19 pm 
Offline
Member
Member
User avatar

Joined: Wed Feb 07, 2007 1:45 pm
Posts: 1401
Location: Eugene, OR, US
There is no perfect solution. :wink:

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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 25, 2008 2:08 pm 
Offline
Member
Member
User avatar

Joined: Fri Aug 03, 2007 6:03 am
Posts: 536
Location: Cambridge, UK
Brendans suggestion does indeed look like a good'un :)

_________________
~ Lukem95 [ Cake ]
Release: 0.08b
Image


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 25, 2008 6:14 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
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

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 27, 2008 7:52 am 
Offline
Member
Member
User avatar

Joined: Fri Aug 03, 2007 6:03 am
Posts: 536
Location: Cambridge, UK
And im sure databases exist with these, we could provide a link from the EDI site.

this sounds good :)

_________________
~ Lukem95 [ Cake ]
Release: 0.08b
Image


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 02, 2008 9:07 am 
Offline
Member
Member

Joined: Thu Oct 21, 2004 11:00 pm
Posts: 248
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?

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!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 02, 2008 10:24 pm 
Offline
Member
Member
User avatar

Joined: Wed Feb 07, 2007 1:45 pm
Posts: 1401
Location: Eugene, OR, US
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. :(


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 1:30 am 
Offline
Member
Member
User avatar

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

_________________
Horizon - a framework and language for SAS-OS development
Project 'Pedigree'
Practical x86 OSDev tutorials


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 7:51 am 
Offline
Member
Member
User avatar

Joined: Wed Feb 07, 2007 1:45 pm
Posts: 1401
Location: Eugene, OR, US
@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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 10:36 pm 
Offline
Member
Member

Joined: Thu Oct 21, 2004 11:00 pm
Posts: 248
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.


Top
 Profile  
 
 Post subject: Re:
PostPosted: Mon Jul 28, 2008 4:40 pm 
Offline
Member
Member

Joined: Wed Oct 18, 2006 3:29 pm
Posts: 202
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.

Quote:
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


Top
 Profile  
 
 Post subject: Re: Extensible Driver Interface
PostPosted: Sun Apr 19, 2009 7:22 pm 
Offline
Member
Member
User avatar

Joined: Thu Dec 21, 2006 3:03 am
Posts: 1029
Location: Hobart, Australia
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?

_________________
My Personal Blog | My Software Company - Loop Foundry | My Github Page


Top
 Profile  
 
 Post subject: Re: Extensible Driver Interface
PostPosted: Sun Apr 19, 2009 7:53 pm 
Offline
Member
Member

Joined: Thu Jul 07, 2005 11:00 pm
Posts: 1546
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....

_________________
My new NEW blag


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 29 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group