Re: Resource management.

["Antonino A. Daplas" <adaplas@hotpop.com>]

On Friday 25 February 2005 03:57, James Simmons wrote:
> > If you intend to insist on doing this, this is my proposal:
> >
> > The linked list of resources per fb_info can be kept. However, instead
> > of doing an fb_find_resource() per call to putcs and cursor, this can
> > be done only once, during initialization of fbcon or set_con2fb_map.
> > This resource can then be stored in an fbcon-private area.
>
> I fixed this in my latest work. Alot of cleanups has happened. Still a few
> issues to work out.

Looks much better. And yes, I also see a few issues but is not your fault.

>
> > The advantage of this is that fbcon will only look for the resource that
> > it needs, ie "scratchpad" but not, for example, "overlay". Similarly,
> > a user video application can totally ignore "scratchpad" but will search
> > for "overlay".  Secondly, the performance penalty suffered by the your
> > initial patch will be eliminated. We also eliminate one or two more
> > fields in fb_info directly accessed by fbcon.
>
> I removed the scratch pad. We use the data reflecting the "drawable"
> properties.
>
> > Also, instead of storing the resource type as a string, why not use a
> > constant?
>
> We would run out very fast. 

With a u32?

> Plus we would need a index field in the case
> we have more than one of the same kind.

Then use a u32 for type, u32 for index.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click