martyl@rocksvax.UUCP (10/02/87)
What should brk do on a segmented architecutre (like the 80286) without a linear address space. If a process wants to change its memory allocation, what should break do across segment boundaries (I'm really looking for a means to malloc/free memory blocks rather than just change a pointer to the top of the processes virtual address space -- I don't see how this works on 286 machines). Or would it be more meaningful to do something along the lines of the Sys V shared memory stuff where a process could allocate additional regions as additional private memory blocks). Then the process would be reasponsible for its own memory management by mallocing/freeing blocks as needed. I suppose brk could be implemented across multiple segments, but some standard set of conventions would have to exist between the operating system and the client programs. Any ideas? What do other 286 Unixes implement? (I don't have access to any real 286 unixes yet). marty leisner xerox corp ARPA: leisner.henr@xerox.com UUCP: martyl@rocksvax.uucp -- marty leisner xerox corp leisner.henr@xerox.com martyl@rocksvax.uucp
dricej@drilex.UUCP (Craig Jackson) (10/05/87)
'brk' and 'sbrk' are two Unix system calls which are very difficult to
implement on many systems. They assume a linear address space used linearly.
Most systems which don't have both these characteristics either kluge around
them or don't implement them at all. For example, I believe that some
Apollo implementations just reserved some memory for 'brk', and when you
something else in the address space, that was all. (I don't know if their
current version does this; not relevant.)
For non-linear address spaces, such as Zilogs or Intels, generally there is
no simple 'sbrk' or 'brk', except in the degenerate memory models. Generally
there is one 'brk' per segment, and a call which sets it.
--
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX: cjacksonjdr+@andrew.cmu.edu (Jeff Rosenfeld) (10/06/87)
> For non-linear address spaces, such as Zilogs or Intels, generally there is > no simple 'sbrk' or 'brk', except in the degenerate memory models. > Generally > there is one 'brk' per segment, and a call which sets it. On the 80286 under Xenix 286, there are reasonable versions of brk and sbrk. Using a small data memory model (one 64K segment), they work just like they should. Using a large data memory model (multiple 64K segments), the brk limit is set or incremented as though the far pointer were a pointer in a linear address space except that only valid segment selectors are allowed and the selectors are in numerical order. In this way, you can sbrk() more than 64K in which case more than one segment will be allocated to you and the selectors for those segments will be incremented by 8 (a magic number related to the meanings of bits in a selector) for each segment beyond the one referenced by the return value from sbrk(). Since a segment must be full (its limit must be 64K) before another is allocated, there need be only one brk for the whole program. This does not imply that contiguous physical memory is allocated; only that the segments allocated do not overlap in physmem. It is also possible to allocate segments about which brk doesn't know, but using that facility invalidates brk's operation. The only serious problem (from a user's perspective) with implementing brk() and sbrk() on a segmented architecture is that your pointers are not perfectly linear and so subtraction of pointers whose selectors are different might be an undefined operation.
daver@hpindda.HP.COM (Dave Richards) (10/07/87)
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