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
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
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
[email protected]
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
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
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
> 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 :-(
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/
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.
On Wed, 2 Mar 2005 14:17:44 +0200, Paul Mundt <[email protected]> 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
[email protected]
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
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
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
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
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(-)
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 -- [email protected]
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
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
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