Re: 2.2/2.4/2.6 VMs: do malloc() ever return NULL?

["Ihar 'Philips' Filipau" <filia@softhome.net>]

Richard B. Johnson wrote:
> 
> Here is a dynamic allocation scheme that doesn't fail with
> the usual, i.e., less that 1/2 megabyte temporary storage. It
> also automatically frees the RAM it's allocated.
> 
> int function(void *what, size_t len)
> {
>     char tmp[len];
>     ;;;;;
>     return 0;
> }
> 

    You want to say that space is always allocated?
    And how can you make graceful error handling if there is no memory left?
    malloc() has return value, mlock() has return value. So there is at 
least room for error handling. But in your case if you will by mistake 
will run second instance of application - what will happend? I suppose 
crash or welcome oom_killer. Both not nice.

> 
> If you need really large buffers and have only a single
> thread, you can still allocate memory at compile-time, i.e.,
> 
> char scratch[0x10000000];
> 

   I was thinking about this - it has a lot of adavantages and one very 
big disadvantage: you need to recompile app to scale system, you cannot 
make this a command line/configuration parameter.

> 
>>   Embedded? with swap?!?
>>   What you have smoken?! - take me to your dealer!-)))
>>
> 
> Absolutely. A RAM-Disk on non-paged RAM. It allows individual
> tasks to keep track of a valuable resource with minimum
> overhead. It would be nicer if there was a "get free pages"
> function call but you can make a driver for a virtual device
> that returns such information. Then you don't need the
> RAM disk to keep track of virtual memory
> 

   A-ha. A la mtd/rw flash.
   Intersting idea.

   Let's say: I'm working on embedded system - but it is less embedded 
than other embedded systems ;-)

   Thanks for your advices in any way - probably something can be used 
in future.

-- 
Ihar 'Philips' Filipau  / with best regards from Saarbruecken.
--                                                           _ _ _
  Because the kernel depends on it existing. "init"          |_|*|_|
  literally _is_ special from a kernel standpoint,           |_|_|*|
  because its' the "reaper of zombies" (and, may I add,      |*|*|*|
  that would be a great name for a rock band).
                                 -- Linus Torvalds