Subject: Re: CVS commit: syssrc
To: Emmanuel Dreyfus <manu@netbsd.org>
From: Jason R Thorpe <thorpej@zembu.com>
List: source-changes
Date: 05/06/2001 13:06:59
On Sun, May 06, 2001 at 10:09:55PM +0300, Emmanuel Dreyfus wrote:

 > Modified Files:
 > 	syssrc/sys/compat/linux/common: linux_exec.c
 > 	syssrc/sys/compat/osf1: osf1_exec.c
 > 	syssrc/sys/compat/sunos: sunos_exec.c
 > 	syssrc/sys/compat/sunos32: sunos32_exec.c
 > 	syssrc/sys/kern: kern_exec.c
 > 	syssrc/sys/sys: proc.h
 > 
 > Log Message:
 > Added two flags to emulation packages:
 > 
 > EMUL_BSD_ASYNCIO_PIPE notes that the emulated binaries expect the original

This is wrong!  I said *specifically* that the sense of the flag should
be the other way, i.e. a flag to *disable* the BSD pipe async i/o semantics.

Please fix this!

 > BSD pipe behavior for asynchronous I/O, which is to fire SIGIO on read() and
 > write(). OSes without this flag do not expect any SIGIO to be fired on
 > read() and write() for pipes, even when async I/O was requested. As far as
 > we know, the OSes that need EMUL_BSD_ASYNCIO_PIPE are NetBSD, OSF/1 and
 > Darwin.
 > 
 > EMUL_NO_SIGIO_ON_READ notes that the emulated binaries that requested
 > asynchrnous I/O expect the reader process to be notified by a SIGIO, but
 > not the writer process. OSes without this flag expect the reader and the
 > writer to be notified when some data has arrived or when some data have been
 > read. As far as we know, the OSes that need EMUL_NO_SIGIO_ON_READ are Linux
 > and SunOS.
 > 
 > 
 > To generate a diff of this commit:
 > cvs rdiff -r1.48 -r1.49 syssrc/sys/compat/linux/common/linux_exec.c
 > cvs rdiff -r1.21 -r1.22 syssrc/sys/compat/osf1/osf1_exec.c
 > cvs rdiff -r1.29 -r1.30 syssrc/sys/compat/sunos/sunos_exec.c
 > cvs rdiff -r1.2 -r1.3 syssrc/sys/compat/sunos32/sunos32_exec.c
 > cvs rdiff -r1.138 -r1.139 syssrc/sys/kern/kern_exec.c
 > cvs rdiff -r1.126 -r1.127 syssrc/sys/sys/proc.h
 > 
 > Please note that diffs are not public domain; they are subject to the
 > copyright notices on the relevant files.
 > 

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>