All of lore.kernel.org
 help / color / mirror / Atom feed
From: CJ <cj@cjcj.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Asynchronous io
Date: Thu, 12 Apr 2001 08:40:15 -0700	[thread overview]
Message-ID: <3AD5CC5F.69D3BAEC@cjcj.com> (raw)

//Linux really needs a clean basis for asynchronous and 
//unbuffered i/o libraries.  Something like the fork/thread
//clone(), but to replace select() and aio_* polling.  This 
//might be a start. And it is just a file and very like a
//pipe or socket.

//Suppose we add /dev/qio with 64 byte sectors as follows: 

struct qio{            //64 byte i/o request
    u16 flags;          //0.0 request block variant, SEEK_SET...
    u16 verb;           //0.2 open,close,read,mmap,sync,write,
                        //    ioctl
                        //    mallocIO&read,write&freeIO,
                        //    mallocIO,freeIO
                        //    autothread might be an ioctl()
    u16 errno;          //0.4 per request status
    u16 completehow;    //0.6 queue,AST,pipe,SIGIO,SIGIO||delete ok
    u64 offset;         //1 
    u32 length;         //2.0 bytes requested
    u32 timeout;        //2.4 im ms or us?
    u32 transferred;    //3.0 bytes
    u32 qiohandle;      //3.4 for cancell or polling
    void* handle;       //4 (open & close might write)
    void* buffer;       //5
    void* callback;     //6 optimize special cases w/ completehow
    void* callparam;    //7 
};                      //all fields are read xor write

//Writing to the device would schedule i/o, reading would reap
//completions.  Bad writes would give the byte offset to the 
//rejected sector field if detected synchronously.  Multiple 
//sector writes would be truncated on the first bad sector.
//Accepted writes would be buffered in the kernel.

//Each open creates a new queue, each write is read in the
//same queue.  Any number of threads can read or write a queue.

//some cases might be simplified by kernel processed completions, 
//such as VMS AST emulation, or putting results in a pipe. Hence
//completehow, which might use callback and callparam.

//timeout?  
//canceling i/o?  
//Sun aio emulation?  
//VMS qio emulation?  
//MS IOCP emulation?
//malloc()&free() safe across threads?
//Should O_DIRECT would error unless properly aligned etc.

             reply	other threads:[~2001-04-12 15:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-12 15:40 CJ [this message]
2001-04-12 16:22 ` Asynchronous io Bart Trojanowski
  -- strict thread matches above, loose matches on Subject: below --
2001-04-13  8:45 Asynchronous IO Dan Maas
2001-04-14  2:00 ` Christopher Smith
2001-04-19 18:19 ` Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3AD5CC5F.69D3BAEC@cjcj.com \
    --to=cj@cjcj.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.