Subject: kern/7933: brk/sbrk are strangely implemented
To: None <gnats-bugs@gnats.netbsd.org>
From: None <perry@piermont.com>
List: netbsd-bugs
Date: 07/06/1999 10:23:42
>Number: 7933
>Category: kern
>Synopsis: brk/sbrk are strangely implemented
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: kern-bug-people (Kernel Bug People)
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Tue Jul 6 10:05:00 1999
>Last-Modified:
>Originator: Perry E. Metzger
>Organization:
Perry Metzger perry@piermont.com
--
"Ask not what your country can force other people to do for you."
>Release: NetBSD-current
>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."
>Audit-Trail:
>Unformatted: