Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!hplabs!hpda!hpisod1!hpcllla!hpesoc1!hpindda!daver
From: daver@hpindda.HP.COM (Dave Richards)
Newsgroups: comp.os.minix
Subject: Re: what does brk do on segmented architectures?
Message-ID: <3580005@hpindda.HP.COM>
Date: Wed, 7-Oct-87 02:40:33 EDT
Article-I.D.: hpindda.3580005
Posted: Wed Oct  7 02:40:33 1987
Date-Received: Sat, 10-Oct-87 10:13:08 EDT
References: <94@rocksvax.UUCP>
Organization: Hewlett Packard, Cupertino
Lines: 15

After looking at the alternatives, you may come to the same conclusion
I did about brk()/sbrk(); don't implement them.  It's tempting to work
around the architecture.  The example mentioned previously that Xenix
uses is the way I'd do it if I absolutely had to, it's relatively
elegant and straightforward.

However, malloc(3) and it's siblings tend to be the biggest user of
the system calls anyway.  Why not, like MVS, implement these routines
in the kernel.  It saves you (kernel maintainer) the embarrassment of
supporting a less-than-elegant interface, and allows you to place
the free and allocated memory lists in kernel space so that poor Joe
User doesn't step on these lists and hurt himself too badlu.  I have
considered doing exactly this, and it seems quite reasonable.

	Dave Richards at HP Information Networks Division