All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Early malloc() summary
Date: Thu, 16 Aug 2012 16:52:01 +0200	[thread overview]
Message-ID: <201208161652.01179.marex@denx.de> (raw)
In-Reply-To: <502CD8B3.4070104@gmail.com>

Dear Graeme Russ,

> Hi Marek,
> 
> On 08/15/2012 12:00 AM, Marek Vasut wrote:
> > Dear Graeme Russ,
> > 
> >> Hi Marek,
> >> 
> >> On Tue, Aug 14, 2012 at 10:37 PM, Marek Vasut <marex@denx.de> wrote:
> >>> Dear Tomas Hlavacek,
> >>> 
> >>>> Hello Marek,
> >>>> 
> >>>> On Sun, Aug 12, 2012 at 1:16 AM, Marek Vasut <marex@denx.de> wrote:
> >>>>> So ... we should aim for firing up the real mallocator as soon as
> >>>>> possible and maybe implement discontigmem (sparsemem) into it, so we
> >>>>> don't have to bother with relocating pointers maybe?
> >>>>> 
> >>>>> The only problem I see is platforms where the memory disappears.
> >>>> 
> >>>> I doubt that on ARM for instance you can set off real mallocator that
> >>>> early without completely rewriting it.
> >>> 
> >>> Esp. on ARM, I won't see much of a problem. You usually have some small
> >>> SRAM where such allocator could run.
> >>> 
> >>>> The idea of having one complex
> >>>> mallocator working in the same manner in board_init_f and board_init_r
> >>>> stages, being able to operate on all platforms using their nifty
> >>>> memory-management/model features
> >>> 
> >>> Do you need them? You usually need only a piece of RW memory.
> >>> 
> >>>> and being seamless to users is really
> >>>> tempting. But do we need/want to introduce such deep rewrites?
> >>> 
> >>> Deep rewrites? You'd only need to implement sparsemem into it, which
> >>> might be list of RW memory areas instead of one memory area.
> >> 
> >> OK, stop right there (please) - This gets into a highly architecturally
> >> specific implementations of malloc. Let's not go there OK :)
> > 
> > Not really, today you give the mallocator one slab of memory on which it
> > operates ... making it so it'd operate on a list of such slabs shouldn't
> > be _that_ hard.
> 
> When you start throwing around "discontigmem", "sparsemem" and "nifty
> memory-management/model features" you are talking architecture specifics

In uboot, not so much ... in uboot it'd be just a matter of making one memory 
are that's currently available to malloc() into list of memory areas and that's 
all. Not specific at all


Best regards,
Marek Vasut

  reply	other threads:[~2012-08-16 14:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-09  0:55 [U-Boot] Early malloc() summary Graeme Russ
2012-08-09 12:48 ` Wolfgang Denk
2012-08-11 23:16   ` Marek Vasut
2012-08-14  8:11     ` Tomas Hlavacek
2012-08-14 12:37       ` Marek Vasut
2012-08-14 13:08         ` Albert ARIBAUD
2012-08-14 14:40           ` Marek Vasut
2012-08-14 13:54         ` Graeme Russ
2012-08-14 14:00           ` Marek Vasut
2012-08-16 11:25             ` Graeme Russ
2012-08-16 14:52               ` Marek Vasut [this message]
2012-08-16 23:05                 ` Graeme Russ
2012-08-14 23:56           ` Marek Vasut
2012-08-16 11:39             ` Graeme Russ
2012-08-15 12:00           ` Tomas Hlavacek
2012-08-16 11:56             ` Graeme Russ
2012-08-16 14:50               ` Marek Vasut
2012-08-16 23:03                 ` Graeme Russ
2012-08-16 23:32                   ` Marek Vasut
2012-08-16 23:50                     ` Graeme Russ
2012-08-17  0:34                       ` Marek Vasut
2012-08-17  1:15                         ` Graeme Russ
2012-08-19 13:21                           ` Tomas Hlavacek
2012-08-19 23:47                             ` Graeme Russ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201208161652.01179.marex@denx.de \
    --to=marek.vasut@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.