Going into week 5, I started with a code-complete but very much incorrect implementation of the TDI_SEND and TDI_RECEIVE IRQ handlers. My TCP_CONTEXT data structure and the existing ADDRESS_FILE data structure both did not contain a way to keep track of pending IRQs, so I had no way of keeping track of outstanding pending IRQs and what connection contexts they were supposed to be associated with. Without a clear scheme for keeping track of the information, IRP pointers invariably got lost.
This week I worked on AHCI IO Request Processing and FIS programming part. I implemented IO Queue, Slot distribution mechanism for AHCI requests. Updated Github's PR for next round of code review.Next I will be working on port programming i.e. telling the controller about the slots that I've allotted for IO request.
Very soon we will have a running AHCI device driver :D
Mid-term evaluations opened up yesterday, and naturally I've been super-busy this week, making sure I've earned my keep! ;)
TO LEARN HOW TO SWIM, YOU NEED TO GET INTO THE WATER.
At the start of the week I was debugging the system crash on ROS's usbhub unload in Win2k3. I spent a lot of time asking questions and discussing topics related to WDM with my mentor Thfabba. He kind of kickstarted me, giving small tasks and then analyzing with me the results. During that sessions I have gathered many new tips related debugging and also started feeling much more confidently working with WDM.
This week, I started off chasing down how to handle TDI sending a new IRQ to create a connection context immediately after a connection has been accepted on the server end. At first, I thought it was for socket multiplexing. As I talked more with Art and looked more into the lwIP source code, I realized that this is an attempt by TDI to support backlogging. As such, this was not something I had to actively handle since lwIP has full backlogging support.