NetBSD Problem Report #7933

Received: (qmail 5832 invoked from network); 6 Jul 1999 16:54:42 -0000
Message-Id: <19990706165441.68790143@jekyll.piermont.com>
Date: Tue,  6 Jul 1999 12:54:41 -0400 (EDT)
From: perry@piermont.com
Reply-To: perry@piermont.com
To: gnats-bugs@gnats.netbsd.org
Subject: brk/sbrk are strangely implemented
X-Send-Pr-Version: 3.95

>Number:         7933
>Category:       kern
>Synopsis:       brk/sbrk are strangely implemented
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 06 10:05:00 +0000 1999
>Closed-Date:    
>Last-Modified:  Tue May 13 13:35:01 +0000 2008
>Originator:     Perry E. Metzger
>Release:        NetBSD-current
>Organization:
Perry Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you."
>Environment:

System: NetBSD jekyll.piermont.com 1.4 NetBSD 1.4 (JEKYLL) #0: Mon May 3 09:58:15 EDT 1999 perry@jekyll.piermont.com:/usr/src/sys/arch/i386/compile/JEKYLL i386


>Description:

brk(2) and sbrk(2) are in section 2. However, they are implemented as
machine language stubs to sys_break in userland. They aren't section 2 
at all!

OTOH, sys_break isn't really sys_break -- it is an alias for
sys_obreak which is presumably supposed to be obsolete.

Furthermore, we find wacko crud in our kernel, like a definition for
sys_sbrk in syscalls.master (!?!!) which is unused by userland, and a
sys_sbrk() function is defined in uvm_mmap.c (although all it does is
return ENOSYS).

This all smacks of some sort of conversion that was started by someone 
and never finished. I'm not sure what direction it was being taken in, 
but it obviously ought to be cleaned up so that this stuff looks like
all our other system calls and is done cleanly.

By the way, at the same time, we should fix our standards conformance
on this call (problem described in another PR.)

>How-To-Repeat:

observe the problem via:

man sbrk
more /usr/src/sys/uvm/uvm_mmap.c
more /usr/src/sys/kern/syscalls.master
etc., etc.

>Fix:

"I am only an egg."
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed
State-Changed-By: ad@NetBSD.org
State-Changed-When: Tue, 13 May 2008 13:24:55 +0000
State-Changed-Why:
They are system calls, with a miniscule difference in the wrapper.


State-Changed-From-To: closed->open
State-Changed-By: perry@NetBSD.org
State-Changed-When: Tue, 13 May 2008 13:30:58 +0000
State-Changed-Why:
The issues are still there


From: "Perry E. Metzger" <perry@piermont.com>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
	 ad@NetBSD.org
Subject: Re: kern/7933 (brk/sbrk are strangely implemented)
Date: Tue, 13 May 2008 09:32:00 -0400

 I've reopened this. There are some legitimate issues here in terms of
 cruft that was clearly left there following a conversion at some point
 in the past. Closing the PR is not appropriate.

 Perry

 ad@NetBSD.org writes:
 > Synopsis: brk/sbrk are strangely implemented
 >
 > State-Changed-From-To: open->closed
 > State-Changed-By: ad@NetBSD.org
 > State-Changed-When: Tue, 13 May 2008 13:24:55 +0000
 > State-Changed-Why:
 > They are system calls, with a miniscule difference in the wrapper.

 -- 
 Perry E. Metzger		perry@piermont.com

>Unformatted:

Home	PR Database Search