[BusyBox] choice for reserving buffers

[Manuel Novoa III]

Vladimir,

I wasn't advocating any particular method.  I was listing advantages and
disadvantages to each approach.  No one else seemed to have done so.

On Fri, 26 Jan 2001, Vladimir N. Oleynik wrote:
> Manuel Novoa III wrote:
> > 1) the kernel does lazy allocation of memory (MMU)
> >    a) stack mem (coded or alloca)-- limited space, but is this really
> > a problem?
> 
> "Segmentaion faults" - bad detector this problem. ;)

Let me be more specific.  Is this really a problem for busybox?  For any applet
that isn't heavily recursive, I would say no.  You're deciding either to put
things in BSS or on the stack.  I haven't built a full busybox recently, but
surely you are talking about less than 100k.  If you've got an MMU, this
shouldn't be a problem.  When was the last time you saw a seg fault from stack
overflow that wasn't a compiler bug?

> > Each instance gets a new stack and, since we have an MMU, that stack
> > is probably more than large enough for our needs.  In this case,
> > do we really have a risk of exhausting stack mem in busybox?
> 
> The utility will not be started at all if not memory for BSS though
> certainly it and will not be selected at once will suffice. 
> Other business, that further we have buffers addresses, and with the
> stack we only shall try to make it without indication of success and
> with increase of a size of the code (this too memory), 
> as addresses not constants.

But if you don't have an MMU there are situations where you would be able
to run a lot of the applets because you don't need as large a BSS to be
allocated.  And as far as code size being memory too, yes but 1) it is shared
among the applets unlike the BSS and 2) it might even be running out of ROM.
 
> > b) BSS mem -- Not actually allocated until needed.  Depending on
> > mapping of variables in mem, max possible wastage is 2*(page size)-2
> > for each data structure.
> 
> It is any random generator, instead of structures. :)

I was just trying to make the point that an object a few bytes larger than a
page size could result in 3 pages being allocated.

> Each utility place the structures sequentially in memory, and
> for kernel this not interesting.

Actually, this isn't necessarily true.  ld has the option of grouping
data objects in BSS based on their size, putting objects of like sizes together.

> > c) malloc'd mem -- Not actually allocated until needed.  
> > Some overhead for malloc data structures and for each allocation.
> > Could be more or less wastage then BSS.  The app has a chance 
> > to deal with the situation if malloc fails.
> 
> Your (c) argument with MMU is not necessary, in this case 
> naturally will win BSS.
> Result size usage memory ~equivalet.  

This is a boundary case certainly.

> If require dynamic memory - please use malloc, alloca
> function is machine dependent.

I wasn't advocating the use of alloca.  But it is a valid option in many
situations.  If you're using gcc, then (my understanding) it is a simple stack
adjustment.  Besides, it is used already in busybox.  See insmod.c and
uudecode.c.

> and trivail buff[const_size] - faults if memory exhausting not
> detected in program.

I'm also not talking about a recursive function that rips a large chunk of
memory from the stack each time.  If you're writing for a small system with no
MMU, you ought to know how big the stack size is and you should the
requirements of your code.  If you have a stack overflow, that is a BUG.

Also, as mentioned in a follow-up post, if you're on a system with no MMU, you
are already "paying" for the stack... it is allocated.  Why throw something in
BSS or malloc it and require the system to allocate more memory to your app?

> > 2) the kernel does not do lazy allocation (no MMU)
> 
> I seem already have convinced Larry to make correct preprocessor`s
> macros.  

I apologize if I misunderstood your previous posts.  But you seemed (to me) to
be saying that BSS allocation was better... always... period.  I was just trying
to point out that this isn't necessarily true when you don't have an MMU.

Manuel