On Wed, Jun 4, 2008 at 10:12 PM, Jeffrey Hsu <[EMAIL PROTECTED]> wrote: > > I am sending this mail , however to find out more > > details. I could be digging through the code as well but if some of > > you out there already know what exists it would be great to understand > > a little more so that i can dig in the right places. > > You should break this up into several steps: > 1. existing code cleanup > a. define new external APIs for the rest of the kernel to use > 2. define internal I/O scheduler API > a. factor out the existing 1-way elevator scan code > 3. implement anticipatory I/O scheduler > > (I suggest you use a source code control tool like Mercurial patch > queue facility to help you manage your code changes.) > > I did 1 and 2 a while ago. This code compiled and worked as of Nov last year. > You're welcome to use this as a base for your project.
Awesome! It is a bit difficult for me to come up with 1 and 2 pretty fast- when I have to consider that all drivers must use the api for I/O. In my case I was planning on getting nata drivers use the api first and then try to get the others to switch , and this is like pasta to me since I have to first get nata routing through the api correctly and then get the others working right making sure nata still works fine etc etc While this is of immense help, I'd like to know where in the kernel tree must I apply the patch .I examined the indices of the patch and assume I apply it in the sys directory? Currently I am using the 1.13 development version- I'll try out your code base on it. thanks a lot! nirmal > > Jeffrey >
