[SOLVED] How to handle I/O inside I/O ?

[wichtounet]

Hi,

After a long time, I've come back to my OS and having fun again. I've realised that I was doing something pretty stupid. And this wasted a lot of time and made me quit the last time and now I realize that it's indeed a simple problem, but I don't find a good solution.

I't s a multitasking system, fully preemptive. I have some log routines that write into a log file.

1. One log is done when a process is blocked
2. The log routine is writing to a file
3. File writing is going VFS -> FS -> ATA
4. Inside my ATA driver I use semaphores to a) lock the driver for exclusive access b) wait for an IRQ on the controllers
5. If the semaphore has to wait, it'll block the current process and reschedule. This causes 1. to happen again

At this point, it's pretty clear that I have a big problem It'll block on the first semaphore for exclusive access and be blocked for ever. If I make the mutex reentrant, this won't solve the issue since then I still thave the problem that It'll compete against himself for a resource.

What is a good solution for handling I/O ? Having a queue of I/O requests and then a kernel process that will go through them ? Or is there another solution ?

Thanks

[mariuszp]

why do you want to write to the log that a semaphore has blocked?

[wichtounet]

why do you want to write to the log that a semaphore has blocked?

Because I'm still debugging the multitasking part of my system and I'd like to have some process flow information.

[Kevin]

Sometimes, the right tool for debugging is a kprintf() which doesn't do anything complicated but goes directly to the screen and/or serial console.

[onlyonemac]

So far I'm avoiding situations like this by ensuring that all driver operations are atomic, therefore drivers are stateless and don't need locking.

Although I'm expecting this to be a performance bottleneck later on, so I might need to change this.

[wichtounet]

Sometimes, the right tool for debugging is a kprintf() which doesn't do anything complicated but goes directly to the screen and/or serial console.

For now, I've worked it out with logging by Qemu serial port or Bochs E9 hack (I don't know how I worked without this before).

So far I'm avoiding situations like this by ensuring that all driver operations are atomic, therefore drivers are stateless and don't need locking.

Although I'm expecting this to be a performance bottleneck later on, so I might need to change this.

Makes sense to me But you have to think of that from the beginning.

Anyway, my question was not very clear, but at least with Qemu/Bochs debugging, I solved my issues for the time being.

Thanks