RFC: disallow modular framebuffers

RFC: disallow modular framebuffers

[Adrian Bunk]

Hi,

while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and 
FB_SAVAGE_ACCEL=m are currently broken) I asked myself:

Do modular framebuffers really make sense?

OK, distributions like to make everything modular, but all the 
framebuffer drivers I've looked at parse driver specific options in 
their *_setup function only in the non-modular case.

And most framebuffer drivers contain a module_exit function.
Is there really any case where this is both reasonable and working?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: disallow modular framebuffers

[Jeff Garzik]

Adrian Bunk wrote:
> Hi,
> 
> while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and 
> FB_SAVAGE_ACCEL=m are currently broken) I asked myself:
> 
> Do modular framebuffers really make sense?
> 
> OK, distributions like to make everything modular, but all the 
> framebuffer drivers I've looked at parse driver specific options in 
> their *_setup function only in the non-modular case.
> 
> And most framebuffer drivers contain a module_exit function.
> Is there really any case where this is both reasonable and working?


It depends on the driver's level of hardware support, and the likely 
configuration of the hardware at boot time.

It is a case-by-case basis.

	Jeff

Re: RFC: disallow modular framebuffers

[Jon Smirl]

The on-going work to support XGL is going to change the significance
of modular framebuffers. Right now there is no real need to load
framebuffers on X86. In the future XGL is probably going to require
that the framebuffer be loaded. When XGL initially starts being
distributed people are not going to have framebuffer loaded so modular
framebuffer will let you load it on demand. From then on, in the XGL
case, if framebuffers weren't modular Redhat would have to compile all
75 of them into their distro kernel.

I don't think the framebuffer codebase has received the same level of
inspection that a lot of the other kernel code has. This is probably
because all X86 users can currently avoid loading them due to VGA
compatibility.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Re: RFC: disallow modular framebuffers

[James Simmons]

> I don't think the framebuffer codebase has received the same level of
> inspection that a lot of the other kernel code has. This is probably
> because all X86 users can currently avoid loading them due to VGA
> compatibility.

Actaully it has recieved inspection but we don't have the man power to 
clean up the system. It will always lag because of this :-( 

Re: [Linux-fbdev-devel] RFC: disallow modular framebuffers

[Antonino A. Daplas]

On Tuesday 01 March 2005 10:41, Adrian Bunk wrote:
> Hi,
>
> while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and
> FB_SAVAGE_ACCEL=m are currently broken) I asked myself:
>
> Do modular framebuffers really make sense?
>
> OK, distributions like to make everything modular, but all the
> framebuffer drivers I've looked at parse driver specific options in
> their *_setup function only in the non-modular case.
>
> And most framebuffer drivers contain a module_exit function.
> Is there really any case where this is both reasonable and working?

Only a few drivers are capable of being unloaded with the possiblity of
restoring the vga console (i810fb and rivafb), when CONFIG_FBCON = n.

If CONFIG_FBCON=y, it's not possible to unload the module unless 2 drivers
are loaded at the same time. One driver can be mapped to the console, so the
other can be unloaded.  Although not important from the user's POV, it is
quite helpful when debugging/developing drivers.

Currently fbcon cannot be unloaded, it will freeze the system.

Tony

Re: RFC: disallow modular framebuffers

[Antonino A. Daplas]

On Tuesday 01 March 2005 10:41, Adrian Bunk wrote:
> Hi,
>
> while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and
> FB_SAVAGE_ACCEL=m are currently broken) I asked myself:

BTW, what's the problem with the above?

Tony

Re: RFC: disallow modular framebuffers

[Adrian Bunk]

On Tue, Mar 01, 2005 at 09:15:27PM +0800, Antonino A. Daplas wrote:
> On Tuesday 01 March 2005 10:41, Adrian Bunk wrote:
> > Hi,
> >
> > while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and
> > FB_SAVAGE_ACCEL=m are currently broken) I asked myself:
> 
> BTW, what's the problem with the above?

  #if defined(CONFIG_FB_SAVAGE_ACCEL)

doesn't work with FB_SAVAGE_ACCEL=m, and

  #if defined(CONFIG_FB_SAVAGE_ACCEL) || defined(CONFIG_FB_SAVAGE_ACCEL_MODULE)

would break with FB_SAVAGE=y and FB_SAVAGE_ACCEL=m.


Is there any reason for these being three modules?
It seems the best solution would be to make this one module composed of 
up to three object files?


> Tony

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: disallow modular framebuffers

[Antonino A. Daplas]

On Friday 04 March 2005 00:56, Adrian Bunk wrote:
> On Tue, Mar 01, 2005 at 09:15:27PM +0800, Antonino A. Daplas wrote:
> > On Tuesday 01 March 2005 10:41, Adrian Bunk wrote:
> > > Hi,
> > >
> > > while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and
> > > FB_SAVAGE_ACCEL=m are currently broken) I asked myself:
> >
> > BTW, what's the problem with the above?
>
>   #if defined(CONFIG_FB_SAVAGE_ACCEL)
>
> doesn't work with FB_SAVAGE_ACCEL=m, and
>
>   #if defined(CONFIG_FB_SAVAGE_ACCEL) ||
> defined(CONFIG_FB_SAVAGE_ACCEL_MODULE)
>
> would break with FB_SAVAGE=y and FB_SAVAGE_ACCEL=m.
>

I see.

>
> Is there any reason for these being three modules?
> It seems the best solution would be to make this one module composed of
> up to three object files?

Yes.

Tony

Re: RFC: disallow modular framebuffers

[Adrian Bunk]

On Fri, Mar 04, 2005 at 03:50:42AM +0800, Antonino A. Daplas wrote:
>...
> > Is there any reason for these being three modules?
> > It seems the best solution would be to make this one module composed of
> > up to three object files?
> 
> Yes.

Two possible solutions:
- rename savagefb.c and link the three files into savagefb.o
- merge the other two files into savagefb.c

I'd slightly prefer the first choice, but I can send patches for 
whichever you prefer.

As a note, in both cases the EXPORT_SYMBOL's can be removed.

> Tony

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed



-------------------------------------------------------
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

Re: RFC: disallow modular framebuffers

[Antonino A. Daplas]

On Friday 04 March 2005 04:20, Adrian Bunk wrote:
> On Fri, Mar 04, 2005 at 03:50:42AM +0800, Antonino A. Daplas wrote:
> >...
> >
> > > Is there any reason for these being three modules?
> > > It seems the best solution would be to make this one module composed of
> > > up to three object files?
> >
> > Yes.
>
> Two possible solutions:
> - rename savagefb.c and link the three files into savagefb.o
> - merge the other two files into savagefb.c
>
> I'd slightly prefer the first choice, but I can send patches for
> whichever you prefer.

I also prefer the first one even if it results into a big patch because
of the rename.

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

[2.6 patch] make savagefb one module

[Adrian Bunk]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

This patch links all selected files under drivers/video/savagefb/ into 
one module.

This required a renaming of savagefb.c to savagefb_driver.c .

As a side effect, the EXPORT_SYMBOL's in this directory are no longer 
required.

---

Other names than savagefb_driver.c (e.g. savagefb_main.c) are easily 
possible - I do not claim being good at picking names...

Due to the size because of the renaming, this patch is attached gzipped.

 drivers/video/Kconfig                  |    4 
 drivers/video/savage/Makefile          |    8 
 drivers/video/savage/savagefb-i2c.c    |    3 
 drivers/video/savage/savagefb.c        | 2276 -------------------------
 drivers/video/savage/savagefb_accel.c  |    4 
 drivers/video/savage/savagefb_driver.c | 2276 +++++++++++++++++++++++++
 6 files changed, 2283 insertions(+), 2288 deletions(-)


[-- Attachment #2: patch-savagefb.gz --]
[-- Type: application/octet-stream, Size: 29047 bytes --]

Re: [Linux-fbdev-devel] [2.6 patch] make savagefb one module

[Geert Uytterhoeven]

On Fri, 4 Mar 2005, Adrian Bunk wrote:
> This patch links all selected files under drivers/video/savagefb/ into 
> one module.
> 
> This required a renaming of savagefb.c to savagefb_driver.c .
> 
> As a side effect, the EXPORT_SYMBOL's in this directory are no longer 
> required.
> 
> ---
> 
> Other names than savagefb_driver.c (e.g. savagefb_main.c) are easily 
> possible - I do not claim being good at picking names...

savagefb_core.c?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [2.6 patch] make savagefb one module

[Adrian Bunk]

On Fri, Mar 04, 2005 at 10:17:17AM +0100, Geert Uytterhoeven wrote:
> On Fri, 4 Mar 2005, Adrian Bunk wrote:
> > This patch links all selected files under drivers/video/savagefb/ into 
> > one module.
> > 
> > This required a renaming of savagefb.c to savagefb_driver.c .
> > 
> > As a side effect, the EXPORT_SYMBOL's in this directory are no longer 
> > required.
> > 
> > ---
> > 
> > Other names than savagefb_driver.c (e.g. savagefb_main.c) are easily 
> > possible - I do not claim being good at picking names...
> 
> savagefb_core.c?

Antonino, what's your opinion?

> Gr{oetje,eeting}s,
> 
> 						Geert

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed



-------------------------------------------------------
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

Re: [2.6 patch] make savagefb one module

[Antonino A. Daplas]

On Saturday 05 March 2005 09:12, Adrian Bunk wrote:
> On Fri, Mar 04, 2005 at 10:17:17AM +0100, Geert Uytterhoeven wrote:
> > On Fri, 4 Mar 2005, Adrian Bunk wrote:
> > > This patch links all selected files under drivers/video/savagefb/ into
> > > one module.
> > >
> > > This required a renaming of savagefb.c to savagefb_driver.c .
> > >
> > > As a side effect, the EXPORT_SYMBOL's in this directory are no longer
> > > required.
> > >
> > > ---
> > >
> > > Other names than savagefb_driver.c (e.g. savagefb_main.c) are easily
> > > possible - I do not claim being good at picking names...
> >
> > savagefb_core.c?
>
> Antonino, what's your opinion?

I'll take your patch as is.

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

Re: RFC: disallow modular framebuffers

[Jesse Barnes]

On Monday, February 28, 2005 6:41 pm, Adrian Bunk wrote:
> Hi,
>
> while looking how to fix modular FB_SAVAGE_* (both FB_SAVAGE_I2C=m and
> FB_SAVAGE_ACCEL=m are currently broken) I asked myself:
>
> Do modular framebuffers really make sense?
>
> OK, distributions like to make everything modular, but all the
> framebuffer drivers I've looked at parse driver specific options in
> their *_setup function only in the non-modular case.

That sounds like it should be fixed.

> And most framebuffer drivers contain a module_exit function.
> Is there really any case where this is both reasonable and working?

I'd like to see them stay modular if it's not too much trouble.  It makes 
things easier to debug and test, for one thing.  I also think setups with 
multiple framebuffers but w/o consoles on any of them are somewhat common, 
meaning the fb drivers can be easily loaded and unloaded if the fb devices 
aren't in use.

Jesse

Re: [Linux-fbdev-devel] RFC: disallow modular framebuffers

[David Vrabel]

Adrian Bunk wrote:
> 
> Do modular framebuffers really make sense?

Yes.  e.g., on embedded systems you may not use the display hardware
(and would therefore like to save a bit of memory) but it's convenient
to have only one build of the kernel/modules.

> OK, distributions like to make everything modular, but all the 
> framebuffer drivers I've looked at parse driver specific options in 
> their *_setup function only in the non-modular case.

Not the (new) Geode framebuffer driver -- it uses regular module
parameters for this very reason.

> And most framebuffer drivers contain a module_exit function.
> Is there really any case where this is both reasonable and working?

It's useful for testing if nothing else.  True, the Geode framebuffer
driver won't restore the mode on unload but since the software VGA
emulation on a Geode is less than perfect[*] I would expect people to
not use vgacon and thus there's nothing really to restore.

David Vrabel

[*] I never did work out what happened to the cursor...
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/

Re: RFC: disallow modular framebuffers

[Paul Mundt]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Tue, Mar 01, 2005 at 03:41:18AM +0100, Adrian Bunk wrote:
> Do modular framebuffers really make sense?
> 
Yes, at least these are quite common with embedded systems, quite often
without fbcon. It makes little sense to keep the driver constantly loaded
if the device is not being used as a console and is only seeing
occasional use.

It seems more sensible to just fix up the drivers that don't do this
right.. most of the broken drivers seem to be geared at x86 anyways where
people generally don't seem to care.

It may not make a lot of sense with distributions on x86, though it is
useful if you are doing driver development on a secondary device. This is
certainly a corner case though.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC: disallow modular framebuffers

[Jon Smirl]

On Wed, 2 Mar 2005 14:17:44 +0200, Paul Mundt <lethal@linux-sh.org> wrote:
> It seems more sensible to just fix up the drivers that don't do this
> right.. most of the broken drivers seem to be geared at x86 anyways where
> people generally don't seem to care.

X86 people don't care because they have VGA (with all of it's warts).
But that doesn't mean that VGA is a good thing. VGA lets X86 systems
run without needing framebuffer support.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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