OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Apr 19, 2024 2:02 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: [SOLVED] How to handle I/O inside I/O ?
PostPosted: Sat Jul 02, 2016 7:47 am 
Offline
Member
Member
User avatar

Joined: Fri Nov 01, 2013 4:05 pm
Posts: 90
Location: Fribourg, Switzerland
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 :P 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

_________________
Thor Operating System: C++ 64 bits OS: https://github.com/wichtounet/thor-os
Good osdeving!


Last edited by wichtounet on Mon Jul 04, 2016 2:21 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: How to handle I/O inside I/O ?
PostPosted: Sat Jul 02, 2016 9:24 am 
Offline
Member
Member

Joined: Sat Oct 16, 2010 3:38 pm
Posts: 587
why do you want to write to the log that a semaphore has blocked?


Top
 Profile  
 
 Post subject: Re: How to handle I/O inside I/O ?
PostPosted: Sat Jul 02, 2016 9:29 am 
Offline
Member
Member
User avatar

Joined: Fri Nov 01, 2013 4:05 pm
Posts: 90
Location: Fribourg, Switzerland
mariuszp wrote:
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.

_________________
Thor Operating System: C++ 64 bits OS: https://github.com/wichtounet/thor-os
Good osdeving!


Top
 Profile  
 
 Post subject: Re: How to handle I/O inside I/O ?
PostPosted: Sat Jul 02, 2016 10:11 am 
Offline
Member
Member

Joined: Sun Feb 01, 2009 6:11 am
Posts: 1070
Location: Germany
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. :)

_________________
Developer of tyndur - community OS of Lowlevel (German)


Top
 Profile  
 
 Post subject: Re: How to handle I/O inside I/O ?
PostPosted: Sat Jul 02, 2016 10:56 am 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1146
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.

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: How to handle I/O inside I/O ?
PostPosted: Mon Jul 04, 2016 2:20 am 
Offline
Member
Member
User avatar

Joined: Fri Nov 01, 2013 4:05 pm
Posts: 90
Location: Fribourg, Switzerland
Kevin wrote:
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).

onlyonemac wrote:
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

_________________
Thor Operating System: C++ 64 bits OS: https://github.com/wichtounet/thor-os
Good osdeving!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 56 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group