how to coordinate ioctl and block I/O requests in a block device driver

how to coordinate ioctl and block I/O requests in a block device driver

Post by Tilman Schmi » Sat, 06 Aug 1994 00:22:09



I am writing a block device driver with a raw (character device)
interface just as described in any book on Unix device driver
programming.  But unlike the examples in these books (and *like*
most real-life disk drivers), mine also has to do ioctls through
its raw device.  A couple of months ago I posted a question how
to coordinate, in this context the execution of ioctl requests
and of block read/write requests.

Meanwhile, I hit upon the source of a "real" disk driver which
solved the problem as follows:

In the ioctl function, it just stores its arguments in static
variables.  It then queues, through a call to the strategy routine,
a private static buf structure which exists for this sole purpose,
and finally does an iowait() on this buf.  Of course it makes sure
that any further ioctl calls are put to sleep until this special
buf is free again.

The start routine checks, for each buf it dequeues, whether its
address is that of this special buf.  If so, it executes the ioctl
function from the stored arguments and then calls iodone() on the
buf normally, waking up the process that called the ioctl function.

It seems to work, but I am not quite comfortable with it yet.
Is this how it is normally done?  Do you see any flaws in this
scheme?  Could iowait() and iodone() expect something in the buf
structure that the fake buf doesn't have, or do something to it
that will cause problems if the buf isn't a real one created by the
kernel or by physio()?  Could it create a problem that b_bcount is
zero if the ioctl function hasn't any data to transfer?  I once
noticed that iomap() panics if called for a buf with b_bcount==0,
which at the time seemed like an excessive reaction to me; but
iowait() and iodone() don't seem to mind.

Any comments welcome.

aTdHvAaNnKcSe
Tilman

--
Tilman Schmidt                              Phone:  +49 221 8299 275
Sema Group Deutschland GmbH                 Fax:    +49 221 8299 266

 
 
 

1. Non blocking socket blocks; says 'read would block' ?

Hi all,

I have three sockets in server which I am reading in a continuous loop,
so don't want to wait on any one. I have designated them as 'non blocking'
but when run the server exits on the very first read() and says 'would
block'. (Is it the same as 'EWOULDBLOCK' mentioned in R. Steven's book ?)
I don't want that I should get any error msg and exit, in fact the
whole purpose of nonblocking is that if something is available, read it
else proceed in the loop and come back to read next time.
The client (sender) is sending msgs on all three sockets. The sockets
are conn_oriented. I am using SunOS 4.1. The small code part is below:

int emer_s, env_s, sens_s;            /* socket fds */
//----------- making sockets nonblocking ******
if ((res=fcntl(emer_s,F_SETFL,FNDELAY)) < 0)
        {
          perror("fcntl res = -1");
          exit(1);
        }
if ((res=fcntl(env_s,F_SETFL,FNDELAY)) < 0)
        {
          perror("fcntl res = -1");
          exit(1);
        }
if ((res=fcntl(sens_s,F_SETFL,FNDELAY)) < 0)
        {
          perror("fcntl res = -1");
          exit(1);
        }

for(; ;)
   {

      if ((cc=read(emer_s,(char*)&gen_struct,size)) < size)
        {
        perror("read error");
          exit(1);
        }
......... do something
      if ((cc=read(env_s,(char*)&gen_struct,size)) < size)
        {
         perror("read error");
          exit(1);
        }
        ......... do something
      if ((cc=read(sens_s,(char*)&gen_struct,size)) < size)
        {
          perror("read error");
          exit(1);
        }
        ......... do something

   }

Any help is appreciated.

hashmi

--
-----
Atiqullah Hashmi                    
UTA (Univ. of Texas at Arlington)  

2. Linux and IDE CDRW drive

3. Block device invalidate cached blocks

4. USB

5. Does TRU-64 support devices with block sizes > 512 bytes/block ?

6. Linux DVD players and region codes

7. ioctl calls and block devices

8. recommended afio flags for scsi disk & tape?

9. drivers/block/block.o: In function `rd_blkdev_pagecache_IO' and `rd_make_request': undefined reference to `bio_size'

10. Blocking I/O with ioctl() to network driver do not work !!!

11. About the request queue of block device

12. Block devices, writing when inside a read request

13. 2.4.14: drivers/block/block.o: undefined reference to `deactivate_page'