Date: Tue, 02 Dec 1997 07:02:32 +0000 From: "John S. Dyson" <dyson@FreeBSD.ORG> To: Terry Lambert <tlambert@primenet.com> Cc: "John S. Dyson" <toor@dyson.iquest.net>, current@FreeBSD.ORG Subject: Re: FYI: usage of new AIO calls Message-ID: <3483B288.DD0CD0E9@freebsd.org> References: <199712020621.XAA17318@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > The aio_* routines demanded by the lame-o POSIX "let's redefine the > universe in an incompatible way each Tuesday, and while we're at it, > let's ignore making the interface logically complete or correcting > out past mistakes so you still need crap like libc_r" can be nothing > more than wrappers. > Well, not only are the aio_* routines POSIX, but they are the standard UNIX (X/Open owns the branding for UNIX), and they also adopted the aio_* functions. I see nothing in the latest X/Open (UNIX) specs about aioread/aiowrite. The spec is now aio_read, aio_write. (They might really be in there somewhere in the deprecated section somewhere.) I really don't think that it is a good idea to chase history. I would expect that we could implement a compatibility aioread/aiowrite library or whatever, but those don't appear to exist in current (the latest) UNIX or POSIX docs. They most likely exist in legacy code, and on that basis, I can understand that they could be useful to implement -- but should be implemented only for that reason. If you make a bona-fide attempt at implementing the backwards compatible aioread/aiowrite and friends, and need additional kernel support, let me know. BTW, I also plan to implement pread/pwrite, but haven't decided to implement as a kernel call, or as a section (3) subroutine. (Those are less of an issue though.) So, the point that I am trying to make, is that I am implementing system calls or subroutines with the attempt of meeting *BOTH* POSIX and UNIX when applicable, and the aio_* routines do that. We am missing a minor amount of functionality in our implementation right now, but am too busy to do that right now. The code WILL be in 3.0, and will be in -current very soon. (aio_fsync, and some aio_cancel functionality). Likewise, my scaffolding for threads will support pthreads. Which version? Probably the most recent. (Hopefully, someone else will implement most of the threading package though.) We could support Solaris or Linux threads, but again (IMO), that should be in the form of a reverse or backwards compatibility package. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3483B288.DD0CD0E9>