so far my list is as follows:
Code: Select all
inportb
outportb
inportw
outportw
inportl
outportl
map_memory (map an address into process's address space)
unmap_memory
hook_interrupt (IRQ handler)
unhook_interrupt
cli
stiDriver lib
Driver lib
I'm currently thinking about what functions my (userland, therefore ring3) drivers will need to access in order to work correctly. I'm going to have a protection mechanism so that only trusted drivers can use these functions (there isn't much point them being in ring3 really, but all my user programs are in ring3, so it's more consistant that way.
so far my list is as follows:
am i missing anything glaringly obvious?
so far my list is as follows:
Re: Driver lib
Pci config r/w? Pci probing? Also general port io permissions?
Why would you want to have direct access to cli/sti?
Why would you want to have direct access to cli/sti?
http://j-software.dk | JPasKernel - My Object Pascal kernel
Re: Driver lib
You may find out soon that you need more functions.
How about registering access to a I/O port from the OS first so that 2 drivers do not accidentally read or write to the same port?
cli/ sti could be replaced by critical sections,they have a count and can be nested.
Will your drivers not set or clear timeouts?
How about registering access to a I/O port from the OS first so that 2 drivers do not accidentally read or write to the same port?
cli/ sti could be replaced by critical sections,they have a count and can be nested.
Will your drivers not set or clear timeouts?
Re: Driver lib
i wasn't sure about cli/sti, but i think removing them would be safest.
i was going to pass the PCI information to the driver when it loads, however i have just realised that this may not be the best way to proceed. instead i think i'll implement a data structure with lots of generic information that can be passed, so it will work with PCI, ISA and any other standards (as well as drivers not using a BUS).
timouts will be dealt with seperatly, with the drivers using a standard system call (wait) and then the process being put to sleep for that length of time. i think this is the best way to deal with them, as it doesn't waste CPU time, and it's part of my C library anyway, so there would be little point rewriting the wrapper for drivers.
I/O port permissions is something i havn't thought about, i think a simple approach where the driver has to request the I/O port first, and release it as soon as it's done with it. theoretically there should only be one driver using each port, as they should be designed to cope with multiple devices, although if this is not the case i guess i could have a problem with deadlocks :S
i was going to pass the PCI information to the driver when it loads, however i have just realised that this may not be the best way to proceed. instead i think i'll implement a data structure with lots of generic information that can be passed, so it will work with PCI, ISA and any other standards (as well as drivers not using a BUS).
timouts will be dealt with seperatly, with the drivers using a standard system call (wait) and then the process being put to sleep for that length of time. i think this is the best way to deal with them, as it doesn't waste CPU time, and it's part of my C library anyway, so there would be little point rewriting the wrapper for drivers.
I/O port permissions is something i havn't thought about, i think a simple approach where the driver has to request the I/O port first, and release it as soon as it's done with it. theoretically there should only be one driver using each port, as they should be designed to cope with multiple devices, although if this is not the case i guess i could have a problem with deadlocks :S