Re: framebuffer_{alloc,release}

[Kronos <kronos@kronoz.cjb.net>]

Il Wed, Sep 17, 2003 at 10:52:57AM +0200, Sven Luther ha scritto: 
> 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.

We are talking about controlling  lifetime of framebuffer info structure
(struct fb_info). This  structure contains a description  of framebuffer
(current  mode, timings,  color  map, etc.). We  want  to register  this
structure with the driver core so  that drivers can export whatever they
want using sysfs.

> 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 ?).

Framebuffer memory  (ie. the  place where  we draw)  is the  video board
memory,  we just  map it  upon  load and  unmap it  on exit. AFAIK  only
virtual framebuffer uses vmalloc() for its framebuffer memory.

Luca
-- 
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
Se il  destino di un uomo  e` annegare, anneghera` anche  in un bicchier
d'acqua.
Proverbio yddish


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