[BusyBox] Re: busybox digest, Vol 1 #258 - 3 msgs

[Tomi Ollila]

Tuesday Jan 23 13:26:17 -0700 2001 Mark Whitley <markw at lineo.com> wrote:
> On Wed, Jan 24, 2001 at 08:43:30AM +1300, Alex King wrote:
> > 
> > I was just wondering, is the bss actually pulled into memory?  Appart
> > from page table overhead, this should only use memory if the applications
> > actually touch the bss, ie it should be pulled in in 4k pages as
> > needed?
> 
> This was addressed before, but here's the scoop:
> 
> Taken from FOLDOC: (http://www.foldoc.org)
> 
> 	Block Started by Symbol
> 
> 	(BSS) The uninitialised data segment produced by Unix linkers. The
> 	other segments are the "text" segment which contains the program
> 	code and the "data" segment contains initialised data. Objects in
> 	the bss segment have only a name and a size but no value.

> 
> Hence, the BSS does not exist on the disk, per se, except as a name and a
> size. The value reported from the 'size' command to show the size of the BSS
> is the run-time size, not the disk size. The gain from eliminating big static
> buffers is that much less memory is used at run-time, at the cost of a
> slightly larger size on disk. I consider this to be an overall win.

But, isn't it so that is system is demand paging... and bss UNinitialized,
that memory is not used during run time if it is not touched (as Alex King
wrote).
If the system is not demand paging, and there is big BSS, that memory would
be used always during run time, were applets using it or not. On the other
hand, if system is not demand paging, the stack may have limited size (and
the memory gain goes to setting stack big enough?).

I have the following idea:

In the structured applet list that is used to find the applet being run,
2 additional fields are added:

1) A `resuid' flag: If this is set (and busybox is suid root), The process
uid is set to the same as real user id (ideas how to change to
suid-some-other-user?) .

2) Amount of memory allocated for the applet, pointer `buffer' is set to 
point to this memory area: If there is one centralized allocation done
(when possible) this reduces the code size. Dynamically allocating from
the heap is probably the most portable way to get system working. The
applets can then lay a structure on top of the allocated memory to get
their data structures working best. 

This second field could also be a pointer to a function which tells the
size of memory needed (and NULL if none needed). Then the loader code
doesn't need to know all fancy structures which sizeof's are used to this
purpose; code `int foo_memory() { return sizeof Foo; }' probably make some
6 to 14 bytes to additional memory requirements...

Now, if we could get to the level on indirection (or lack thereof) that is
needed when there is static buffer, compared to one extra pointer reference...

> 
> 
> Mark Whitley
> markw at lineo.com


Tomi Ollila