Skip to contentSkip to conversation

Depmod errors on 2.6.17.4/2.6.18-rc1/2.6.18-rc1-mm1

PATCH New Matt Reuther 5 participants 26 messages Jul 10, 2006 – Jul 12, 2006

Subsystems (4)
USB Sound Framebuffer layer Backlight class/subsystem
lore
Share & tools
lore

Matt Reuther

author
#0 lore raw

The following errors show up on 'make modules_install' for the 2.6.18-rc1-mm1 kernel. The snd-miro ones have actually been there since at least 2.6.17.4, and they show up in 2.6.18-rc1 as well.

INSTALL sound/usb/snd-usb-audio.ko
INSTALL sound/usb/snd-usb-lib.ko
INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.18-rc1-mm1; fi
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_create
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_pcm
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_timer
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_mixer
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/fs/reiser4/reiser4.ko needs unknown symbol generic_file_read
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_unregister_client
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_register_client

My config is attached.

Matt

#1 lore raw
Quoted 9 lines · Matt Reuther

The following errors show up on 'make modules_install' for the 2.6.18-rc1-mm1 kernel. The snd-miro ones have actually been there since at least 2.6.17.4, and they show up in 2.6.18-rc1 as well.

WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_unregister_client
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_register_client

CONFIG_FB=n, CONFIG_BACKLIGHT_CLASS_DEVICE=m should not be possible in 2.6.18-rc1-mm1 and 2.6.18-rc1. Can you run kconfig again?

Tony

author
#2 lore raw

Quoting "Antonino A. Daplas" <[email protected]>:

Quoted 11 lines
Quoted 9 lines · Matt Reuther

The following errors show up on 'make modules_install' for the 2.6.18-rc1-mm1 kernel. The snd-miro ones have actually been there since at least 2.6.17.4, and they show up in 2.6.18-rc1 as well.

WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_unregister_client
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_register_client

Quoted 4 lines

CONFIG_FB=n, CONFIG_BACKLIGHT_CLASS_DEVICE=m should not be possible in 2.6.18-rc1-mm1 and 2.6.18-rc1. Can you run kconfig again?

Tony

I am not at the computer right now, but I will try later.

Here is how I got config-2.6.18-rc1-mm1. I copied this config from 2.6.18-rc1, which I had created with 'make menuconfig'. I ran 'make oldconfig' on the config-2.6.18-rc1 and answered the new questions to generate config-2.6.18-rc1-mm1. I compiled it from there. Does 'make oldconfig' not work properly anymore?

Matt

#3 lore raw
Quoted 22 lines · Matt Reuther

Quoting "Antonino A. Daplas" <[email protected]>:

Quoted 15 lines
Quoted 6 lines · Matt Reuther

The following errors show up on 'make modules_install' for the 2.6.18-rc1-mm1
kernel. The snd-miro ones have actually been there since at least 2.6.17.4,
and they show up in 2.6.18-rc1 as well.

Quoted 7 lines

WARNING:
/lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_unregister_client
WARNING:
/lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_register_client

Quoted 4 lines

CONFIG_FB=n, CONFIG_BACKLIGHT_CLASS_DEVICE=m should not be possible in 2.6.18-rc1-mm1 and 2.6.18-rc1. Can you run kconfig again?

Tony

Quoted 7 lines

I am not at the computer right now, but I will try later.

Here is how I got config-2.6.18-rc1-mm1. I copied this config from 2.6.18-rc1, which I had created with 'make menuconfig'. I ran 'make oldconfig' on the config-2.6.18-rc1 and answered the new questions to generate config-2.6.18-rc1-mm1. I compiled it from there. Does 'make oldconfig' not work properly anymore?

I really don't know. I have received several bug reports where the main cause was that a kconfig option changed after upgrading kernels.

I tested with make menuconfig, and it's not possible to set lcd/backlight options if CONFIG_FB is not set.

Tony

author
#4 lore raw
Quoted 16 lines · Antonino A. Daplas
Quoted 7 lines · Matt Reuther

Quoting "Antonino A. Daplas" <[email protected]>:

Quoted 5 lines

CONFIG_FB=n, CONFIG_BACKLIGHT_CLASS_DEVICE=m should not be possible in 2.6.18-rc1-mm1 and 2.6.18-rc1. Can you run kconfig again?

Tony

Quoted 7 lines

I am not at the computer right now, but I will try later.

Here is how I got config-2.6.18-rc1-mm1. I copied this config from 2.6.18-rc1, which I had created with 'make menuconfig'. I ran 'make oldconfig' on the config-2.6.18-rc1 and answered the new questions to generate config-2.6.18-rc1-mm1. I compiled it from there. Does 'make oldconfig' not work properly anymore?

Quoted 7 lines

I really don't know. I have received several bug reports where the main cause was that a kconfig option changed after upgrading kernels.

I tested with make menuconfig, and it's not possible to set lcd/backlight options if CONFIG_FB is not set.

Tony

I ran 'make menuconfig' and I got the same warnings. Perhaps CONFIG_FB needs to be part of the 'selects' line for any option that selects the backlight support. I think the USB Apple Cinema display support, which I set as modular, might have selected backlight. I don't need framebuffer support, so I have that shut off. Here are the depmod warnings once again:

INSTALL sound/usb/snd-usb-audio.ko
INSTALL sound/usb/snd-usb-lib.ko
INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.18-rc1-mm1; fi
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_create
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_pcm
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_timer
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_mixer
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/fs/reiser4/reiser4.ko needs unknown symbol generic_file_read
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_unregister_client
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_register_client

I ran make menuconfig with the config file I sent before. The new config is attached.

Matt

#5 lore raw

PATCH 1/1 appledisplay/backlight (Depmod errors on 2.6.17.4/2.6.18-rc1/2.6.18-rc1-mm1)

Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines

CONFIG_FB=n, CONFIG_BACKLIGHT_CLASS_DEVICE=m should not be possible in 2.6.18-rc1-mm1 and 2.6.18-rc1. Can you run kconfig again?

Tony

I tested with make menuconfig, and it's not possible to set lcd/backlight options if CONFIG_FB is not set.

Tony, it is possiblle when the USB APPLEDISPLAY option is set and it selects backlight options without regard for FB.

Quoted 4 lines

WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_unregister_client
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_register_client

This patch fixes it for me. Is it the right thing to do?
---

From: Randy Dunlap <[email protected]>

appledisplay calls fb_register_client() so needs to depend on FB.

Signed-off-by Randy Dunlap <[email protected]>
---
 drivers/usb/misc/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/misc/Kconfig +1 -1
@@ -163,7 +163,7 @@ config USB_IDMOUSE
 
 config USB_APPLEDISPLAY
 	tristate "Apple Cinema Display support"
-	depends on USB
+	depends on USB && FB
 	select BACKLIGHT_LCD_SUPPORT
 	select BACKLIGHT_CLASS_DEVICE
 	help
#6 lore raw

PATCH 1/1 backlight: lcd: Remove dependency from the framebuffer layer

The backlight and lcd layer should be independent from the framebuffer layer. It can use the services offered by the framebuffer, but its absence should not prevent the backlight/lcd layer from functioning.

Signed-off-by Antonino Daplas <[email protected]>

---

Quoted 10 lines · Randy.Dunlap
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines

CONFIG_FB=n, CONFIG_BACKLIGHT_CLASS_DEVICE=m should not be possible in 2.6.18-rc1-mm1 and 2.6.18-rc1. Can you run kconfig again?

Tony

I tested with make menuconfig, and it's not possible to set lcd/backlight options if CONFIG_FB is not set.

Tony, it is possiblle when the USB APPLEDISPLAY option is set and it selects backlight options without regard for FB.

Quoted 6 lines
Quoted 4 lines

WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_unregister_client
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/drivers/video/backlight/backlight.ko needs unknown symbol fb_register_client

This patch fixes it for me. Is it the right thing to do?

In this case, yes. But I think the better solution is to eliminate framebuffer dependency.

Tony

 drivers/video/Kconfig               |    2 -
 drivers/video/backlight/Kconfig     |    4 +-
 drivers/video/backlight/backlight.c |   85 ++++++++++++++++++++++-------------
 drivers/video/backlight/lcd.c       |   76 +++++++++++++++++++------------
 4 files changed, 103 insertions(+), 64 deletions(-)
drivers/video/Kconfig +1 -1
index c51a54b..9d9d02a 100644
@@ -1622,7 +1622,7 @@ if FB || SGI_NEWPORT_CONSOLE
 	source "drivers/video/logo/Kconfig"
 endif
 
-if FB && SYSFS
+if SYSFS
 	source "drivers/video/backlight/Kconfig"
 endif
drivers/video/backlight/Kconfig +2 -2
index 022f9d3..02f1529 100644
@@ -10,7 +10,7 @@ menuconfig BACKLIGHT_LCD_SUPPORT
 
 config BACKLIGHT_CLASS_DEVICE
         tristate "Lowlevel Backlight controls"
-	depends on BACKLIGHT_LCD_SUPPORT && FB
+	depends on BACKLIGHT_LCD_SUPPORT
 	default m
 	help
 	  This framework adds support for low-level control of the LCD

@@ -26,7 +26,7 @@ config BACKLIGHT_DEVICE
 
 config LCD_CLASS_DEVICE
         tristate "Lowlevel LCD controls"
-	depends on BACKLIGHT_LCD_SUPPORT && FB
+	depends on BACKLIGHT_LCD_SUPPORT
 	default m
 	help
 	  This framework adds support for low-level control of LCD.
drivers/video/backlight/backlight.c +53 -32

109 lines not on this page · raw message

drivers/video/backlight/lcd.c +47 -29

101 lines not on this page · raw message

#7 lore raw

PATCH 1/1 backlight: lcd: Remove dependency from the framebuffer layer

In reply to Randy.Dunlap

The backlight and layer should be independent from the framebuffer layer. It can use the services offered by the framebuffer, but its absence should not prevent the backlight/lcd layer from functioning.

Signed-off-by Antonino Daplas <[email protected]>

---

Oops, the previous patch has extraneous characters. Use this instead.

Tony

 drivers/video/Kconfig               |    2 -
 drivers/video/backlight/Kconfig     |    4 +-
 drivers/video/backlight/backlight.c |   85 ++++++++++++++++++++++-------------
 drivers/video/backlight/lcd.c       |   76 +++++++++++++++++++------------
 4 files changed, 103 insertions(+), 64 deletions(-)
drivers/video/Kconfig +1 -1
index c51a54b..9d9d02a 100644
@@ -1622,7 +1622,7 @@ if FB || SGI_NEWPORT_CONSOLE
 	source "drivers/video/logo/Kconfig"
 endif
 
-if FB && SYSFS
+if SYSFS
 	source "drivers/video/backlight/Kconfig"
 endif
drivers/video/backlight/Kconfig +2 -2
index 022f9d3..02f1529 100644
@@ -10,7 +10,7 @@ menuconfig BACKLIGHT_LCD_SUPPORT
 
 config BACKLIGHT_CLASS_DEVICE
         tristate "Lowlevel Backlight controls"
-	depends on BACKLIGHT_LCD_SUPPORT && FB
+	depends on BACKLIGHT_LCD_SUPPORT
 	default m
 	help
 	  This framework adds support for low-level control of the LCD

@@ -26,7 +26,7 @@ config BACKLIGHT_DEVICE
 
 config LCD_CLASS_DEVICE
         tristate "Lowlevel LCD controls"
-	depends on BACKLIGHT_LCD_SUPPORT && FB
+	depends on BACKLIGHT_LCD_SUPPORT
 	default m
 	help
 	  This framework adds support for low-level control of LCD.
drivers/video/backlight/backlight.c +53 -32

109 lines not on this page · raw message

drivers/video/backlight/lcd.c +47 -29

101 lines not on this page · raw message

#8 lore raw

Re: [PATCH] backlight: lcd: Remove dependency from the framebuffer layer

drivers/video/backlight/backlight.c #include <linux/ctype.h> · line 19

Quoted 2 lines · On Tue, 11 Jul 2006 15:04:08 +0800 "Antonino A. Daplas" <[email protected]>…
drivers/video/backlight/backlight.c +2 -0
+#if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \
+			   defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))

Peeking at CONFIG_FB_MODULE like this is considered sinful.

<tries to remember why>

Because someone might build a CONFIG_FB=n, CONFIG_FB_MODULE=n kernel, then later build the fbdev module for that kernel only to find that the backlight driver doesn't know that the fbdev module is available.

Or something like that. It's pretty contrived, and I really doubt that anyone's going to try to cobble together a kernel like that.

Or maybe there's a better reason...

#9 lore raw

Re: [PATCH] backlight: lcd: Remove dependency from the framebuffer layer

Quoted 10 lines · Andrew Morton

drivers/video/backlight/backlight.c #include <linux/ctype.h> · line 19

Quoted 2 lines · On Tue, 11 Jul 2006 15:04:08 +0800 "Antonino A. Daplas" <[email protected]>…
drivers/video/backlight/backlight.c +2 -0
+#if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \
+			   defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))

Peeking at CONFIG_FB_MODULE like this is considered sinful.

<tries to remember why>

Quoted 8 lines

Because someone might build a CONFIG_FB=n, CONFIG_FB_MODULE=n kernel, then later build the fbdev module for that kernel only to find that the backlight driver doesn't know that the fbdev module is available.

Or something like that. It's pretty contrived, and I really doubt that anyone's going to try to cobble together a kernel like that.

Or maybe there's a better reason...

That's the simplest method I can think of to prevent impossible combinations such as CONFIG_FB=m, CONFIG_BACKLIGHT_CLASS_DEVICE=y without having to use 'depend' or 'select' in Kconfig, or God forbid, inter_module_get().

I should have added a comment that I also don't like the hackishness of this method.

Thinking about this a little more carefully now, how about we just statically link the fb notification?

I'll see if I can send an update for that.

Tony

#10 lore raw

PATCH 1/1 fbdev: Statically link the framebuffer notification functions

In reply to Andrew Morton

The backlight and lcd subsystems can be notified by the framebuffer layer of blanking events. However, these subsystems, as a whole, can function independently from the framebuffer layer. But in order to enable to the lcd and backlight subsystems, the framebuffer has to be compiled also, effectively sucking in a huge amount of unneeded code. Besides, the dependency is introducing a lot of compilation problems.

To prevent these, separate out the framebuffer notification mechanism from the framebuffer layer and permanently link it to the kernel.

Signed-off-by Antonino Daplas <[email protected]>

---

Quoted 9 lines · Andrew Morton

Because someone might build a CONFIG_FB=n, CONFIG_FB_MODULE=n kernel, then later build the fbdev module for that kernel only to find that the backlight driver doesn't know that the fbdev module is available.

Or something like that. It's pretty contrived, and I really doubt that anyone's going to try to cobble together a kernel like that.

Or maybe there's a better reason...

Andrew,

Here's the patch as promised. The changelog should say it all. Statically linking the notification mechanism is not that expensive as the code is very small. Also, future subsystems that requires fb notification need not play dependency games.

I prefer this over the previous patch. If you do apply this, you have to revert backlight-lcd-remove-dependency-from-the-framebuffer-layer.patch. This patch leaves the code in the backlight directory untouched.

Tony

 drivers/video/Makefile          |    1 +
 drivers/video/backlight/Kconfig |    4 +--
 drivers/video/fb_notify.c       |   46 +++++++++++++++++++++++++++++++++
 drivers/video/fbmem.c           |   54 ++++++++-------------------------------
 include/linux/fb.h              |    2 +
 5 files changed, 61 insertions(+), 46 deletions(-)
drivers/video/Makefile +1 -0
index 6283d01..be7f1c9 100644
@@ -4,6 +4,7 @@ # Rewritten to use lists instead of if-s
 
 # Each configuration option enables a list of files.
 
+obj-y                             += fb_notify.o
 obj-$(CONFIG_FB)                  += fb.o
 fb-y                              := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
                                      modedb.o fbcvt.o
drivers/video/backlight/Kconfig +2 -2
index 022f9d3..02f1529 100644
@@ -10,7 +10,7 @@ menuconfig BACKLIGHT_LCD_SUPPORT
 
 config BACKLIGHT_CLASS_DEVICE
         tristate "Lowlevel Backlight controls"
-	depends on BACKLIGHT_LCD_SUPPORT && FB
+	depends on BACKLIGHT_LCD_SUPPORT
 	default m
 	help
 	  This framework adds support for low-level control of the LCD

@@ -26,7 +26,7 @@ config BACKLIGHT_DEVICE
 
 config LCD_CLASS_DEVICE
         tristate "Lowlevel LCD controls"
-	depends on BACKLIGHT_LCD_SUPPORT && FB
+	depends on BACKLIGHT_LCD_SUPPORT
 	default m
 	help
 	  This framework adds support for low-level control of LCD.
drivers/video/fb_notify.c new file +46 -0

46 lines not on this page · raw message

drivers/video/fbmem.c +11 -43

127 lines not on this page · raw message

include/linux/fb.h +1 -1
index 405f44e..4ad0673 100644
@@ -524,7 +524,7 @@ struct fb_event {
 
 extern int fb_register_client(struct notifier_block *nb);
 extern int fb_unregister_client(struct notifier_block *nb);
-
+extern int fb_notifier_call_chain(unsigned long val, void *v);
 /*
  * Pixmap structure definition
  *
#11 lore raw

PATCH 1/1 fbdev: Statically link the framebuffer notification functions

The backlight and lcd subsystems can be notified by the framebuffer layer of blanking events. However, these subsystems, as a whole, can function independently from the framebuffer layer. But in order to enable to the lcd and backlight subsystems, the framebuffer has to be compiled also, effectively sucking in a huge amount of unneeded code.

To prevent dependency problems, separate out the framebuffer notification mechanism from the framebuffer layer and permanently link it to the kernel.

Signed-off-by Antonino Daplas <[email protected]>

---

Another oops, forgot to remove the if FB in Kconfig.

Tony

 drivers/video/Kconfig           |    2 +
 drivers/video/Makefile          |    1 +
 drivers/video/backlight/Kconfig |    4 +--
 drivers/video/fb_notify.c       |   46 +++++++++++++++++++++++++++++++++
 drivers/video/fbmem.c           |   54 ++++++++-------------------------------
 include/linux/fb.h              |    2 +
 6 files changed, 62 insertions(+), 47 deletions(-)
drivers/video/Kconfig +1 -1
index c51a54b..9d9d02a 100644
@@ -1622,7 +1622,7 @@ if FB || SGI_NEWPORT_CONSOLE
 	source "drivers/video/logo/Kconfig"
 endif
 
-if FB && SYSFS
+if SYSFS
 	source "drivers/video/backlight/Kconfig"
 endif
drivers/video/Makefile +1 -0
index 6283d01..be7f1c9 100644
@@ -4,6 +4,7 @@ # Rewritten to use lists instead of if-s
 
 # Each configuration option enables a list of files.
 
+obj-y                             += fb_notify.o
 obj-$(CONFIG_FB)                  += fb.o
 fb-y                              := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
                                      modedb.o fbcvt.o
drivers/video/backlight/Kconfig +2 -2
index 022f9d3..02f1529 100644
@@ -10,7 +10,7 @@ menuconfig BACKLIGHT_LCD_SUPPORT
 
 config BACKLIGHT_CLASS_DEVICE
         tristate "Lowlevel Backlight controls"
-	depends on BACKLIGHT_LCD_SUPPORT && FB
+	depends on BACKLIGHT_LCD_SUPPORT
 	default m
 	help
 	  This framework adds support for low-level control of the LCD

@@ -26,7 +26,7 @@ config BACKLIGHT_DEVICE
 
 config LCD_CLASS_DEVICE
         tristate "Lowlevel LCD controls"
-	depends on BACKLIGHT_LCD_SUPPORT && FB
+	depends on BACKLIGHT_LCD_SUPPORT
 	default m
 	help
 	  This framework adds support for low-level control of LCD.
drivers/video/fb_notify.c new file +46 -0

46 lines not on this page · raw message

drivers/video/fbmem.c +11 -43

127 lines not on this page · raw message

include/linux/fb.h +1 -1
index 405f44e..4ad0673 100644
@@ -524,7 +524,7 @@ struct fb_event {
 
 extern int fb_register_client(struct notifier_block *nb);
 extern int fb_unregister_client(struct notifier_block *nb);
-
+extern int fb_notifier_call_chain(unsigned long val, void *v);
 /*
  * Pixmap structure definition
  *
#12 lore raw

Re: [PATCH] fbdev: Statically link the framebuffer notification functions

In reply to Antonino A. Daplas
Quoted 6 lines · Antonino A. Daplas

The backlight and lcd subsystems can be notified by the framebuffer layer of blanking events. However, these subsystems, as a whole, can function independently from the framebuffer layer. But in order to enable to the lcd and backlight subsystems, the framebuffer has to be compiled also, effectively sucking in a huge amount of unneeded code. Besides, the dependency is introducing a lot of compilation problems.

This code is effectively rebuilding a fb specific version of inter_module_get/put., something that was removed earlier.

Another solution would be to put this code into a tiny module and then have everyone depend on it.

Signature · 2 lines
Jon Smirl
[email protected]
#13 lore raw

Re: [PATCH] fbdev: Statically link the framebuffer notification functions

Quoted 10 lines · Jon Smirl
Quoted 8 lines · Antonino A. Daplas

The backlight and lcd subsystems can be notified by the framebuffer layer of blanking events. However, these subsystems, as a whole, can function independently from the framebuffer layer. But in order to enable to the lcd and backlight subsystems, the framebuffer has to be compiled also,
effectively sucking in a huge amount of unneeded code. Besides, the dependency
is introducing a lot of compilation problems.

Quoted 2 lines

This code is effectively rebuilding a fb specific version of inter_module_get/put., something that was removed earlier.

Huh? I don't see any semblance of inter_module_* or symbol_* in there. Read the patch again.

Tony

#14 lore raw

Re: [PATCH] fbdev: Statically link the framebuffer notification functions

Quoted 11 lines · Antonino A. Daplas
Quoted 10 lines · Jon Smirl
Quoted 8 lines · Antonino A. Daplas

The backlight and lcd subsystems can be notified by the framebuffer layer of blanking events. However, these subsystems, as a whole, can function independently from the framebuffer layer. But in order to enable to the lcd and backlight subsystems, the framebuffer has to be compiled also,
effectively sucking in a huge amount of unneeded code. Besides, the dependency
is introducing a lot of compilation problems.

Quoted 5 lines
Quoted 2 lines

This code is effectively rebuilding a fb specific version of inter_module_get/put., something that was removed earlier.

Huh? I don't see any semblance of inter_module_* or symbol_* in there. Read the patch again.

You are providing a fixed point to do a rendezvous between modules without refcount tracking. That's what inter_module did. The symbol is being passed implicitly via the entry point names.

Just wrap fb_notifier in a module and it will get tracked.

Quoted 5 lines

Tony

Signature · 2 lines
Jon Smirl
[email protected]
#15 lore raw

Re: [PATCH] fbdev: Statically link the framebuffer notification functions

Quoted 14 lines · Jon Smirl
Quoted 13 lines · Antonino A. Daplas
Quoted 2 lines · Jon Smirl
Quoted 1 line · Antonino A. Daplas

The backlight and lcd subsystems can be notified by the framebuffer

layer

Quoted 1 line
Quoted 1 line

of blanking events. However, these subsystems, as a whole, can

function

Quoted 7 lines
Quoted 6 lines

independently from the framebuffer layer. But in order to enable to the lcd and backlight subsystems, the framebuffer has to be compiled also,
effectively sucking in a huge amount of unneeded code. Besides, the dependency
is introducing a lot of compilation problems.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

This code is effectively rebuilding a fb specific version of inter_module_get/put., something that was removed earlier.

Huh? I don't see any semblance of inter_module_* or symbol_* in there. Read the patch again.

You are providing a fixed point to do a rendezvous between modules without refcount tracking. That's what inter_module did.

No, you're confused on inter_module. inter_module_* allows 2 or more modules to share data. The danger is that one module may disappear while the other is still accessing the data.

In this case, there is absolutely no data sharing. One module can safely unload without affecting the other. The only danger is that one might be in a midst of a calling the callout function while the other is unregistering its notifier block. But then the notifier chain already protects this from happening.

Quoted 4 lines

The symbol is
being passed implicitly via the entry point names.

Just wrap fb_notifier in a module and it will get tracked.

No, there's no need to do this. It just adds more complexity to the already complicated dependency.

Tony

#16 lore raw

Re: [PATCH] fbdev: Statically link the framebuffer notification functions

Quoted 28 lines · Antonino A. Daplas
Quoted 14 lines · Jon Smirl
Quoted 13 lines · Antonino A. Daplas
Quoted 2 lines · Jon Smirl
Quoted 1 line · Antonino A. Daplas

The backlight and lcd subsystems can be notified by the framebuffer

layer

Quoted 1 line
Quoted 1 line

of blanking events. However, these subsystems, as a whole, can

function

Quoted 7 lines
Quoted 6 lines

independently from the framebuffer layer. But in order to enable to the lcd and backlight subsystems, the framebuffer has to be compiled also,
effectively sucking in a huge amount of unneeded code. Besides, the dependency
is introducing a lot of compilation problems.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

This code is effectively rebuilding a fb specific version of inter_module_get/put., something that was removed earlier.

Huh? I don't see any semblance of inter_module_* or symbol_* in there. Read the patch again.

You are providing a fixed point to do a rendezvous between modules without refcount tracking. That's what inter_module did.

No, you're confused on inter_module. inter_module_* allows 2 or more modules to share data. The danger is that one module may disappear while the other is still accessing the data.

Quoted 5 lines

In this case, there is absolutely no data sharing. One module can safely unload without affecting the other. The only danger is that one might be in a midst of a calling the callout function while the other is unregistering its notifier block. But then the notifier chain already protects this from happening.

The code looks ok but this sure smells like inter_module_*. I guess inter_module had to deal with arbitrary users and this code is dealing with a fixed set of clients which makes it more manageable.

Have you considered making this a generic service and not fb specific?

Signature · 2 lines
Jon Smirl
[email protected]
#17 lore raw

Re: [PATCH] fbdev: Statically link the framebuffer notification functions

Quoted 30 lines · Jon Smirl
Quoted 29 lines · Antonino A. Daplas
Quoted 9 lines · Jon Smirl
Quoted 8 lines · Antonino A. Daplas
Quoted 2 lines · Jon Smirl
Quoted 1 line · Antonino A. Daplas

The backlight and lcd subsystems can be notified by the framebuffer

layer

Quoted 1 line
Quoted 1 line

of blanking events. However, these subsystems, as a whole, can

function

Quoted 2 lines
Quoted 2 lines

independently from the framebuffer layer. But in order to enable to the lcd and backlight subsystems, the framebuffer has to be

compiled

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

also,
effectively sucking in a huge amount of unneeded code. Besides, the dependency
is introducing a lot of compilation problems.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

This code is effectively rebuilding a fb specific version of inter_module_get/put., something that was removed earlier.

Huh? I don't see any semblance of inter_module_* or symbol_* in there. Read the patch again.

You are providing a fixed point to do a rendezvous between modules without refcount tracking. That's what inter_module did.

No, you're confused on inter_module. inter_module_* allows 2 or more modules to share data. The danger is that one module may disappear while the other is still accessing the data.

Quoted 7 lines
Quoted 5 lines

In this case, there is absolutely no data sharing. One module can safely unload without affecting the other. The only danger is that one might be in a midst of a calling the callout function while the other is unregistering its notifier block. But then the notifier chain already protects this from happening.

The code looks ok but this sure smells like inter_module_*.

I assure you, there is no smell of inter_module_* here. What scenario are you afraid of?

Quoted 6 lines

I guess
inter_module had to deal with arbitrary users and this code is dealing with a fixed set of clients which makes it more manageable.

Have you considered making this a generic service and not fb specific?

It's basically a wrapper to the notifier_call_chain, that's as generic as it can get. And yes, it's not fb_specific (meaning, there's no need for the client module to know fbdev internals), that's why the lcd and backlight subsystem can take advantage of it.

Tony

#18 lore raw

Re: [PATCH] fbdev: Statically link the framebuffer notification functions

Quoted 4 lines · Antonino A. Daplas
Quoted 1 line

The code looks ok but this sure smells like inter_module_*.

I assure you, there is no smell of inter_module_* here. What scenario are you afraid of?

Dangling references during the load/unload process. That was inter_module's problem.

Quoted 5 lines
Quoted 5 lines

I guess
inter_module had to deal with arbitrary users and this code is dealing with a fixed set of clients which makes it more manageable.

Quoted 7 lines
Quoted 2 lines

Have you considered making this a generic service and not fb specific?

It's basically a wrapper to the notifier_call_chain, that's as generic as it can get. And yes, it's not fb_specific (meaning, there's no need for the client module to know fbdev internals), that's why the lcd and backlight subsystem can take advantage of it.

The generic code could create notifier chains with a name. The modules would then use the name to attach. Now you don't need the fb_notifier code.

Signature · 2 lines
Jon Smirl
[email protected]
#19 lore raw

Re: [PATCH] fbdev: Statically link the framebuffer notification functions

Quoted 8 lines · Jon Smirl
Quoted 4 lines · Antonino A. Daplas
Quoted 1 line

The code looks ok but this sure smells like inter_module_*.

I assure you, there is no smell of inter_module_* here. What scenario are you afraid of?

Dangling references during the load/unload process. That was inter_module's problem.

That won't happen. If fbdev unloads, then the module that does the notification disappears, and the clients won't receive notifications. If the client is the one that unloads first, it unregisters its notifier block, and that's one less client for fbdev to notify (And fbdev doesn't know how many clients are there, that's internal to the notifier). And since registration, unregistration and the call to the callout function in the notifier block are protected by a semaphore (in the blocking type), the danger of unregistration while in the midst of a notification is removed.

Tony

#20 lore raw

PATCH 1/1 sound-miro unknown symbols (Depmod errors on 2.6.17.4/2.6.18-rc1/2.6.18-rc1-mm1)

In reply to Matt Reuther
Quoted 10 lines

WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_create
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_pcm
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_timer
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_mixer
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/fs/reiser4/reiser4.ko needs unknown symbol generic_file_read

Someone posted a patch for the reiser4 function-name conversion.

Here is a patch for the snd-miro driver references.

---
From: Randy Dunlap <[email protected]>

Fix undefined (missing) references in ISA MIRO sound driver.

Signed-off-by Randy Dunlap <[email protected]>
---
 sound/isa/cs423x/Makefile |    1 +
 1 file changed, 1 insertion(+)
sound/isa/cs423x/Makefile +1 -0
@@ -11,6 +11,7 @@ snd-cs4236-objs := cs4236.o
 
 # Toplevel Module Dependency
 obj-$(CONFIG_SND_AZT2320) += snd-cs4231-lib.o
+obj-$(CONFIG_SND_MIRO) += snd-cs4231-lib.o
 obj-$(CONFIG_SND_OPL3SA2) += snd-cs4231-lib.o
 obj-$(CONFIG_SND_CS4231) += snd-cs4231.o snd-cs4231-lib.o
 obj-$(CONFIG_SND_CS4232) += snd-cs4232.o snd-cs4231-lib.o
#21 lore raw
In reply to Matt Reuther
Quoted 20 lines · Matt Reuther
Quoted 19 lines · Antonino A. Daplas
Quoted 4 lines · Matt Reuther

Quoting "Antonino A. Daplas" <[email protected]>:

Quoted 3 lines

CONFIG_FB=n, CONFIG_BACKLIGHT_CLASS_DEVICE=m should not be possible in 2.6.18-rc1-mm1 and 2.6.18-rc1. Can you run kconfig again?

Quoted 8 lines
Quoted 1 line

Tony

I am not at the computer right now, but I will try later.

Here is how I got config-2.6.18-rc1-mm1. I copied this config from 2.6.18-rc1, which I had created with 'make menuconfig'. I ran 'make oldconfig' on the config-2.6.18-rc1 and answered the new questions to generate config-2.6.18-rc1-mm1. I compiled it from there. Does 'make oldconfig' not work properly anymore?

I really don't know. I have received several bug reports where the main cause was that a kconfig option changed after upgrading kernels.

I tested with make menuconfig, and it's not possible to set lcd/backlight options if CONFIG_FB is not set.

Quoted 7 lines
Quoted 1 line

Tony

I ran 'make menuconfig' and I got the same warnings. Perhaps CONFIG_FB needs to be part of the 'selects' line for any option that selects the backlight support. I think the USB Apple Cinema display support, which I set as modular, might have selected backlight. I don't need framebuffer support, so I have that shut off. Here are the depmod warnings once again:

Yes, that's the culprit. I've been thinking for some time to eliminate the framebuffer dependency from lcd/backlight. Can you try the patch I sent in another thread?

Tony

author
#22 lore raw
Quoted 10 lines · Antonino A. Daplas
Quoted 8 lines · Matt Reuther
Quoted 1 line · Antonino A. Daplas

Matt Reuther wrote:

I ran 'make menuconfig' and I got the same warnings. Perhaps CONFIG_FB needs to be part of the 'selects' line for any option that selects the backlight support. I think the USB Apple Cinema display support, which I set as modular, might have selected backlight. I don't need framebuffer support, so I have that shut off. Here are the depmod warnings once again:

Quoted 5 lines

Yes, that's the culprit. I've been thinking for some time to eliminate the framebuffer dependency from lcd/backlight. Can you try the patch I sent in another thread?

Tony

OK. I will give that a shot, probably this evening.

Shouldn't kconfig recursively figure out dependencies for stuff like this?

I turned on Apple Cinema support without turning on the framebuffer, but Cinema needed backlight, which needed framebuffer. I can see kconfig turning on backlight, but not checking to see what backlight needed.

There might be similar issues with snd-miro, which seems to want stuff in snd_cs4231, which I think I have shut off.

Thanks for your help. I try out your patch later on today, when I can get back to my computer.

Matt

#23 lore raw
Quoted 14 lines · Matt Reuther
Quoted 13 lines · Antonino A. Daplas
Quoted 8 lines · Matt Reuther
Quoted 1 line · Antonino A. Daplas

Matt Reuther wrote:

I ran 'make menuconfig' and I got the same warnings. Perhaps CONFIG_FB needs to be part of the 'selects' line for any option that selects the backlight support. I think the USB Apple Cinema display support, which I set as modular, might have selected backlight. I don't need framebuffer support, so I have that shut off. Here are the depmod warnings once again:

Yes, that's the culprit. I've been thinking for some time to eliminate the framebuffer dependency from lcd/backlight. Can you try the patch I sent in another thread?

Quoted 5 lines
Quoted 1 line

Tony

OK. I will give that a shot, probably this evening.

Shouldn't kconfig recursively figure out dependencies for stuff like this?

'select' doesn't. So does 'depends on'. Anyway, I consider it wasteful to also compile in fb when backlight/lcd is the only one needed. So try instead the other patch (Statically link the framebuffer notification functions).

Quoted 4 lines

I turned on Apple Cinema support without turning on the framebuffer, but Cinema needed backlight, which needed framebuffer. I can see kconfig turning on backlight, but not checking to see what backlight needed.

Yes, known problem with select.

Quoted 7 lines

There might be similar issues with snd-miro, which seems to want stuff in snd_cs4231, which I think I have shut off.

Thanks for your help. I try out your patch later on today, when I can get back to my computer.

Thanks for the report too.

Tony

author
#24 lore raw

The depmod problems are gone, except for the reiser4 warning about generic_file_read. I thought I had the right patch for that, too, but I guess not.

Thanks for all the help!
Matt