RFC: disallow modular framebuffers
Adrian Bunk
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jeff Garzik
> 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
Jon Smirl
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
jons...@gmail.com
Antonino A. Daplas
> 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
Antonino A. Daplas
>
> 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
Jesse Barnes
> 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
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 :-(
David Vrabel
>
> 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/
Paul Mundt
> Do modular framebuffers really make sense?
>
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.
Jon Smirl
> 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
jons...@gmail.com
Adrian Bunk
> 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
-
Antonino A. Daplas
> 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
Antonino A. Daplas
> 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.
>
> - 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.
Adrian Bunk
>...
> > 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
-