Re: Re: [RFC] Video Mode Handling

[Andrew Morton <akpm@osdl.org>]

Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Sun, 8 Aug 2004, Andrew Morton wrote:
> > "Antonino A. Daplas" <adaplas@hotpop.com> wrote:
> > > Most fbdev developers are proposing to bring back the per-display var
> > >  structures to ease the difficulty of video mode handling.  This proposal
> > >  is countered by a few (notably James) in that it severely increases the
> > >  memory footprint of the kernel.
> >
> > Surprised.
> >
> > By how much does this increase the kernel's memory footprint?
> 
> Indeed, you need a full mode database per driver.

Sorry, that's way outside my area of knowledge ;)

> > And how much simpler would the code be if we were to bring back the
> > per-display var structures?
> >
> > IOW: what's the tradeoff here?
> 
>   - per-display var:
>       - increase memory footprint by
>         MAX_NR_CONSOLES.*sizeof(struct var_screen_info)

I see no var_screen_info.  sizeof(struct screen_info) is 56 bytes, and
there are 63 of them.  This is a negligible amount of memory!

>       + simpler code
>       + 100% compatible with 2.4
> 
>   - private modedb:
>       - increase memory footprint by full mode database per driver.
>       - more complex (and larger) code
>       - subtle differences with 2.4, because not the whole var is saved
>         (BTW, which fields do you want to save, and which not, so I can
> 	 evaluate the impact on some drivers?)

Well gee.  If we're talking about 3k, or even 10k or 30k, let's go with the
simplest code?


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com