From soda@sran230.sra.co.jp  Mon Jun  5 14:48:38 1995
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA11117
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 5 Jun 1995 14:48:37 -0700
Received: from sranhc.sra.co.jp by sraigw.sra.co.jp (8.6.12+2.4W/3.3W-2.1)
	id GAA05132; Tue, 6 Jun 1995 06:48:33 +0900
Received: from sran230.sra.co.jp by sranhc.sra.co.jp (5.67gw/6.4J.6-BXa)
	id AA16053; Tue, 6 Jun 95 06:47:46 +0900
Received: by sran230.sra.co.jp (4.2/6.4J.6-SJX)
	id AA05085; Tue, 6 Jun 95 06:48:15 JST
Message-Id: <9506052148.AA05085@sran230.sra.co.jp>
Date: Tue, 6 Jun 95 06:48:15 JST
From: Noriyuki Soda <soda@sra.co.jp>
Sender: soda@sran230.sra.co.jp
Reply-To: soda@sra.co.jp
To: FreeBSD-gnats-submit@freebsd.org
Cc: soda@sra.co.jp
Subject: 2.0.5-ALPHA should change msync(2) syscall number for compatibility
X-Send-Pr-Version: 3.2

>Number:         490
>Category:       kern
>Synopsis:       2.0.5-ALPHA should change msync(2) syscall number for compatibility
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    freebsd-bugs (FreeBSD bugs mailing list)
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun  5 14:50:03 1995
>Closed-Date:    Tue Jun 6 00:30:22 PDT 1995
>Last-Modified:
>Originator:     Noriyuki Soda
>Release:        FreeBSD 2.0-BUILT-19950527 i386
>Organization:
Software Research Associates, Inc., Japan
>Environment:

environment independent.

>Description:

msync(2) argument is changed from
	msync(addr, len)
to
	msync(addr, len, flags)
in 2.0.5-ALPHA.
So I think we should allocate new syscall number for new msync(2), and
reserve syscall 65 as omsync(2), for compatibility to old BSD binary.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: davidg 
State-Changed-When: Tue Jun 6 00:30:22 PDT 1995 
State-Changed-Why:  
Any application prior to 2.0.5A that used msync would have caued the 
machine to panic. Thus it can be safely assumed that no application 
is successfully being used with it. The third argument (flags) is also 
currently unimplemented and (almost) completely ignored. If an old 
application tries to use msync with only two arguments, the worst that 
will happen is that junk on the stack would be used as the third arg, 
and then the msync might fail because of an illegal combination of 
flags. Considering that the machine would likely crash if the msync() 
did succeed, this failure is actually a good thing. :-) 
The above combinations of factors was the reason for deciding not 
to allocate a new syscall number to msync(). This was a deliberate 
decision and not a bug. 
>Unformatted:


