Re: [PATCH] fbdev updates.

[Russell King <rmk@arm.linux.org.uk>]

On Fri, Jul 05, 2002 at 10:14:12AM -0700, James Simmons wrote:
> > First, I detest the idea of "fix", "var", "par" and "info".  Specifically
> > the "par" crap. Intensely.
> 
>    Why? Should each driver have their own structs that are completely
> different then? In this case you would be better off doing something like
> newport_con.c.
> 
>     We pretty much have this today. Each driver has so much excess code
> because they want to create their own special structs. Lost of bloat for
> no reason! I will NOT put up with that anymore!!!! Sorry!

James, you're OTT here.  Look at what the structure contains.  You will
notice that it's very specific to the driver.  Drivers have the implicit
right to define what data they need to maintain their internal state;
the core has no right to define that.

If you're going to be this hard headed about this, YOU can take over
complete maintainence of ALL framebuffer drivers.  I'll direct ALL
problems to you to solve.

It's part of the deal.  Either you allow driver writers to cleanly code
the way they see fit, or you take over maintainence of those drivers.
You break it, you fix it.  What's it to be?

> > "par" and "info" should be combined IMO,
> > which my framebuffer drivers do.
> 
> No!!!! This is one of the reasons we have the mess we have!! Look at how
> much code that could be removed from the standard drivers into fbmem.c and
> fbcon.c.

sa1100fb was already cleaned up in the way YOU wanted to remove most of
the junk back in the 2.4 days.  I consider it to be extremely clean.  Or
used to be.  All that now remains in there has very little commonality
between the drivers.

When there is ONE and only ONE framebuffer device possible, it makes
sense to try to combine structures as much as possible, especially
when:

1. allocation of structures has overhead.
2. you can get some performance advantage from combining such structures.
3. you're running on an embedded platform and are trying not to waste
   ANY resources.

> > Secondly, I think you're completely confused above.  lccr0 and lccr3 have
> > nothing to do with some "generic struct fb_info".  They hold the base
> > register values for two of the SA1100 control registers.
> >
> > Thirdly, you didn't delete them.  You _moved_ them within the structure.
> > They therefore served zero functional purpose.
> 
> If you could send me a patch I would be happy.

Patch for what?  I _really_ don't understand your request here.

> > Fourthly, nothing but the sa1100fb driver has any business accessing the
> > elements around these two both before and after the move.
> 
> True which is why things like that go into par.

Then why are you trying to share the par between others (as you said in
a previous message)?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf