where is the best place to put the drivers and call table?
I want the driver interface like this.
Level 1 : Low level device i/o (not visible to the user)
Level 2 : API (visisble to the user)
when using nasm, how do I tell the level 2 driver where the level 1 function is?
Driver Interface
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Driver Interface
i'm unsure about what you mean by "level 2 driver", but i assume you want something like this:
- ATA disks, ATAPI cdroms, SCSI/USB sticks etc. all offer a common "blockdevice" interface through a table of functions.
- On top of the "blockdevice" abstraction, you want to offer more elaborated abstraction such as filesystems (with more elaborated functions such as "read/write inode" or "read/write datablock #x in inode #n", which is _also_ made available through a table of functions.
So my guess would be that the kernel will have to
- allow drivers to register _instances_ of their table of functions with a _unique name_ identifying them (e.g. "disk.ide0.master" or "hda"). It will probably be interresting to have a pointer towards data together with those functions (e.g. disk geometry, disk identification, etc)
- allow drivers to enumerate instances that match a given interface (e.g. "what are all the blockdevice's" ?)
- allow drivers to retrieve the instance for a given name (e.g. "how do i communicate to "hda" ?)
- ATA disks, ATAPI cdroms, SCSI/USB sticks etc. all offer a common "blockdevice" interface through a table of functions.
- On top of the "blockdevice" abstraction, you want to offer more elaborated abstraction such as filesystems (with more elaborated functions such as "read/write inode" or "read/write datablock #x in inode #n", which is _also_ made available through a table of functions.
So my guess would be that the kernel will have to
- allow drivers to register _instances_ of their table of functions with a _unique name_ identifying them (e.g. "disk.ide0.master" or "hda"). It will probably be interresting to have a pointer towards data together with those functions (e.g. disk geometry, disk identification, etc)
- allow drivers to enumerate instances that match a given interface (e.g. "what are all the blockdevice's" ?)
- allow drivers to retrieve the instance for a given name (e.g. "how do i communicate to "hda" ?)