Hello everybody !
I'm just thinking about a request queue for my device drivers.
Maybe you can help me !
For example a fdd driver. If more tasks wants to read sectors
from the fdd, I have to queue these requests. So far so good.
But who cares about this queue ?
The user task ?
- That works .. but the user task that requested
the first action have to to the work for all other
tasks that have a request in the queue. That isn't fair !
A general kernel task ?
- Mhh.. One task looking in every queue: "Jobs for me ?"
A task for every driver that has a queue ?
- ?? Is that clever ??
What do you think is the best way ?
Greetings from dinslaken, germany !
Drivers, requests and queues
-
carbonBased
RE:Drivers, requests and queues
One method I might use:
The driver maintains the queue, containing:
what needs to loaded
where to start
where to end
current position
for what task
And the driver simply loops through it's queue, loading a chunk (depending on your file system, could be a sector, a cluster, a block, etc) for one task, and then a chunk from another, etc, etc. This way each task gets its data loaded at the same time as the others. Once a load is completely done (currentAddr = endingAddr) then the driver copies the data back to the task, and activates that task.
Another method:
Have a device reader for each task, but make sure after reading a chunk of data, that it relinquishes control of the device so another task can read it (again, so data is read simultaneously for each task).
Don't know which methods are best for this kinda thing, just thought I'd toss up a few examples.
Jeff
The driver maintains the queue, containing:
what needs to loaded
where to start
where to end
current position
for what task
And the driver simply loops through it's queue, loading a chunk (depending on your file system, could be a sector, a cluster, a block, etc) for one task, and then a chunk from another, etc, etc. This way each task gets its data loaded at the same time as the others. Once a load is completely done (currentAddr = endingAddr) then the driver copies the data back to the task, and activates that task.
Another method:
Have a device reader for each task, but make sure after reading a chunk of data, that it relinquishes control of the device so another task can read it (again, so data is read simultaneously for each task).
Don't know which methods are best for this kinda thing, just thought I'd toss up a few examples.
Jeff
-
AnotherNewOS
RE:Drivers, requests and queues
Thank you for your answer.
But I don't have understood it so far.
An applikation makes an syscall "read(....)".
In kernel-mode the kernel puts that request on the queue of the device.
The task is waiting now for the completed request.
But anybody must give the device driver cpu time for getting the request
and working on it. Who does that ?
Joerg
But I don't have understood it so far.
An applikation makes an syscall "read(....)".
In kernel-mode the kernel puts that request on the queue of the device.
The task is waiting now for the completed request.
But anybody must give the device driver cpu time for getting the request
and working on it. Who does that ?
Joerg
-
TheUbu
RE:Drivers, requests and queues
AnotherNewOS,
Hi there are a few ways inwhich you can about this. You can make something called a resource control process in which will monitor all resources so if you have say task a and task b and task b requests a read from your FDD it will check with the resource control process if the fdd is avail it will let it contrinue. Now when task a checks with the RCP (resource control process) it will be told that the device is not ready and it can sleep for a few quntums and try again or wait for a signal back.
You can also set up a MPI (message passing interface) and send say send a message to the fdd that you need x read and here is your buffer to dma into. And all these requests will be put into the drivers mailbox and it will handle them in order and when its finished it will reply when the task detects the reply in its mailbox it can process the returned data and then continue on its way.
Or if you are feeling really adventerous you can try and combine both ways to come up with a more fool proof way. IE send a message to the RCP which will then talk to the driver for you and then get back to you.
If you need some more information just let me know.
-Christopher
Hi there are a few ways inwhich you can about this. You can make something called a resource control process in which will monitor all resources so if you have say task a and task b and task b requests a read from your FDD it will check with the resource control process if the fdd is avail it will let it contrinue. Now when task a checks with the RCP (resource control process) it will be told that the device is not ready and it can sleep for a few quntums and try again or wait for a signal back.
You can also set up a MPI (message passing interface) and send say send a message to the fdd that you need x read and here is your buffer to dma into. And all these requests will be put into the drivers mailbox and it will handle them in order and when its finished it will reply when the task detects the reply in its mailbox it can process the returned data and then continue on its way.
Or if you are feeling really adventerous you can try and combine both ways to come up with a more fool proof way. IE send a message to the RCP which will then talk to the driver for you and then get back to you.
If you need some more information just let me know.
-Christopher