Re: Resource management.

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

On Tuesday 22 February 2005 07:25, James Simmons wrote:
> > On Tuesday 22 February 2005 03:11, James Simmons wrote:
> > > Hi!
> > >
> > >    This is my first run at the resource management code. Comments are
> > > welcomed :-)
> >
> > Hi James,
> >
> > Where is this going to?  What I see are performance penalties.  For each
> > putcs and cursor, it has to call fb_find_resource() which walks the
> > linked list looking for a resource using strncmp().
> >
> > What's the goal here?
>
> 	So we don't end up with a struct fb_info constantly growing with struct
> fb_pixmaps. At present we have pixmap and sprite in struct fb_info. In the
> future we will have more. I need to create a pixmap for the framebuffer
> itself. This way we can have hooks for inbuf and outbuf to deal with
> issues of devices that have hardware restriction when writing to the
> framebuffer. The classic example is the Epson135X chipsets. You can only
> write/read 16 bits at a time with the framebuffer. Also in the future I
> plan to add DMA support. One approach to this is pci_pools. This would
> require multiple fb_pixmaps. One for each area for DMA you request. Of
> course we could have a static array of struct fb_pixmaps but there is no
> guarantee that the orders will be the same for each driver.
>
> Do you see any other solution to this then?

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. 

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.

Also, instead of storing the resource type as a string, why not use a
constant?

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