On Tue, Sep 16, 2003 at 09:27:53PM +0200, Kronos wrote:

Hi,
this is a new version of the new framebuffer_alloc API. It is based on the
feedback I had (thanks to Russel King).

framebuffer_alloc  is unchanged,  driver  specific  release callback  is
gone. struct fb_info won't go away until we drop the refcount with a new
function. I think that framebuffer_free can  be misleading as it doesn't
free anything, so I named it framebuffer_release.

Just a quick question about this. I didn't really follow this thread,
but it seem to me that you are implementing a sort of reference counting
memory allocation, or something such.

If so, it has been proven that exploratory garbage collection is more
effective than reference-sounting in normal programming, even in
imperative languages like C. I don't know if these results will apply as
well in this case which handles framebuffer memory (or perhaps also the
texture memory the DRI framework uses ?). I think the disadvantage of
not being able to handle circular structure is of no moment, as i doubt
circular structures will be implemtented in framebuffer memory.

Anyway have you at least looked a bit at the possibility of using an
exploratory garbage collection in this case, as well as designing a
framework which can be shared between not only the fbdevs but also the
other framebuffer using stuff (dri, X, etc.).

Disclaimer: i am by no means an expert of memory allocation or garbage
collection, altough my main programming language is ocaml, so what i say
hear may well be nonsense or something. Please excuse me if this is the
case.

Friendly,

Sven Luther



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf