[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] sleep() and wake() in device drivers



 Hi, Jonathan

On Sat, 1 Jul 2000, Jonathan Oddie wrote:

> Hello,
> 
> I am writing a "device driver" so as to be able to access the modem and printer
> ports from MacMiNT. I think I have this mostly figured out, except for one 
> thin; I want to use asynchronous execution for reading and writing (as 
> synchronous execution can lock up the whole machine), but this means that
> unless the device was opened with O_NDELAY flag, I have to put the calling
> process to sleep and wake it again upon completion of the IO. I know that
> sleep() and wake() from the kerinfo struct are used for this, but I couldn't
> quite figure out from the source how they are used. My best guess is something
> like this:
> long busy;
> 
> busy = 1;
> /* here would go Toolbox call to do the actual IO, with a pointer to a 
> 	completion routine that sets busy = 0 */
> sleep(IO_Q,&busy);
> 
> So do I need the wake() call at all, or is it simply enough for the IO
> completion routine (called when it has actually finished) to set busy = 0? I'm
> a bit confused...

 No, you've got it wrong :) the call is like this; sleep(queue,cond). That
is, put the current process to sleep on the given queue, waiting for
'cond' to happend.

 So, after putting a process (or many) to sleep with , for example,
sleep(IO_Q,&busy), you will wake all processes sleeping on the IO queue,
waiting for 'cond' &busy with wake(IO_Q,&busy). You can look at the second
parameter (the &busy parameter) as some kind of ID by which you can select
what to wake on the given queue. The use of address in most xdd's is to
make sure a unique condition (or sleep ID, as I like to look at it), so
that other wake calls don't accidentally wake other processes too. The
contents at &busy makes no difference at all...

> 
> Thanks for any help,
> Jonathan
> 
> p.s. I'm still trying to set up the gcc cross-compiler... it *does* build the
> actual xgcc binary, but then dies when trying to reconfigure itself to build
> `libio'... I'll keep trying though
> 
> 
> 

Regards,

 Odd Skancke - ozk@atari.org - http://assemsoft.atari.org