So this merge window was somewhat rocky in the sense that there was a lot of arguments about it, but at the same time I at least personally think that from a technical angle, we had somewhat less scary stuff going on than has been almost the rule lately. Lots of changes, but nothing that really feels all that fragile to me. Famous last words. I expect that the x86 PAT support (which has been long in the making) has the potential to have some issues, but the obvious problems were hashed out long ago, and while the merge window already showed one bug, that one was fairly benign and quickly fixed. As usual, the bulk of the changes are to drivers (roughly 40% of the diffs, and that's with rename detection - with renames shown as delete/create events it was pretty exactly half of the diff). The network driver updates were about half of that (again, that's not unusual, and is mostly indicative of the fact that there's a metric buttload of networking drivers out there). Arch updates were another 20%, still leaving a fair amount of stuff spread out all over (that said, the "dirstat" with rename detection is a bit flaky - if files get renamed across directories, the accounting is obviously not very meaningful - so take the numbers as a guideline rather than anything else). Among the randon stuff, filesystems (ext4, gfs2, ocfs2 and xfs stand out), and networking (with the generic 802.11 layer being a big part of it, so I guess that should counts as partly driver-related). Of course, sometimes the small patches is what is more noticeable (especially if they introduce bugs ;). The VM doesn't really show up very big in diffstat, but there were a fair number of cleanups there. Another feature that is notable not for its size, but because people have tried to get me to merge it for some long is kgdb support. Which really turned out pretty small and clean, once people started putting their effort into making it so. So go out and test it. The diffstat and short...
Hi...
I have installed this kernel, and it behaves a bit strange.
If I launch a movie under totem, it plays nicely (no HD, just 512x384).
If then I start deluge with some torrents downloading, the video begins to
loose frames and jump, like loosing 1 or 2 frames per second.
There is not much bandwidth used, just 15-20 Kb.
I have tried the same copying a kernel source tree and the video plays fine.
So can it be something network related, os network+io to disk ?
No group scheduling, 1000Hz, fully preemptive kernel.
If you smell something and need my .config I will post it.
TIA
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--could you try latest -git (head v2.6.26-rc1-110-ga153063 or later).
There's scheduler interactivity fixes in it: in particular the
fair-sleepers latency bug was finally tracked down and fixed via
v2.6.26-rc1-66-ga992241 ("sched: fix normalized sleeper").
In v2.6.25 we didnt find that bug in time - see v2.6.25-rc9-1-ge2df9e0
('revert "sched: fix fair sleepers"').
Ingo
--Hi, probably related to the Alistair John Strachan media build breakage report: make[1]: Entering directory `/usr/src/linux-2.6.26-rc1' CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CHK include/linux/compile.h LDS arch/x86/kernel/acpi/realmode/wakeup.lds LD arch/x86/kernel/acpi/realmode/wakeup.elf OBJCOPY arch/x86/kernel/acpi/realmode/wakeup.bin AS arch/x86/kernel/acpi/wakeup_rm.o LD arch/x86/kernel/acpi/built-in.o LD arch/x86/kernel/built-in.o LD drivers/built-in.o ld: drivers/media/built-in.o: No such file: No such file or directory make[2]: *** [drivers/built-in.o] Error 1 make[1]: *** [drivers] Error 2 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/usr/src/linux-2.6.26-rc1' make: *** [debian/stamp-build-kernel] Error 2 Command exited with non-zero status 2 This is output during repeated runs of CONCURRENCY_LEVEL=2 time make-kpkg kernel_image (error happened during original run as well, of course) # ls drivers/media/ common/ dvb/ Kconfig Makefile radio/ video/ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc1 # Mon May 5 01:20:32 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_DEFCONFIG_LIST="arch/x86/configs/i386_defconfig" # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not...
i reported and fixed that bug a week ago, see the "drivers/media build fix for modular builds" patch on lkml. currently i've got 20 build fixes in my queue that are not yet upstream as of today's -git - see them below. Some of them are integrated into subsystem trees already and they are all in the process of being reviewed and accepted or redone differently by their respective maintainers. Ingo -------> Subject: video: STKWEBCAM fixes From: Ingo Molnar <mingo@elte.hu> Date: Tue Apr 29 15:11:29 CEST 2008 x86.git randconfig testing found these build bugs in -git: drivers/media/video/stk-webcam.c: In function 'stk_create_sysfs_files': drivers/media/video/stk-webcam.c:340: error: implicit declaration of function 'video_device_create_file' drivers/media/video/stk-webcam.c: In function 'stk_remove_sysfs_files': [...] drivers/media/video/stk-webcam.c: In function 'v4l_stk_mmap': drivers/media/video/stk-webcam.c:846: error: 'VM_WRITE' undeclared (first use in this function) [...] config at: http://redhat.com/~mingo/misc/config-Tue_Apr_29_15_00_47_CEST_2008.bad the reason was a missing include file, and a dependency on a deprecated (but still in use) VIDEO_V4L1_COMPAT API. Signed-off-by: Ingo Molnar <mingo@elte.hu> --- drivers/media/video/Kconfig | 1 + drivers/media/video/stk-webcam.c | 1 + 2 files changed, 2 insertions(+) Index: linux/drivers/media/video/Kconfig =================================================================== --- linux.orig/drivers/media/video/Kconfig +++ linux/drivers/media/video/Kconfig @@ -883,6 +883,7 @@ config USB_ZR364XX config USB_STKWEBCAM tristate "USB Syntek DC1125 Camera support" depends on VIDEO_V4L2 && EXPERIMENTAL + select VIDEO_V4L1_COMPAT ---help--- Say Y here if you want to use this type of camera. Supported devices are typically found in some Asus laptops, Index: linux/drivers/media/video/stk-webcam.c ==================================================...
This was discovered in linux-next and a patch posted on March 28 ...
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: [patch] nsc-ircc: wrap PNP probe code in #ifdef CONFIG_PNP
Date: Fri, 28 Mar 2008 10:54:43 -0600
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, Samuel Ortiz <samuel@sortiz.org>,
As was this:
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: Andrew Morton <akpm@linux-foundation.org>
Subject: [patch] smsc-ircc2: wrap PNP probe code in #ifdef CONFIG_PNP
Date: Fri, 28 Mar 2008 10:53:06 -0600
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, Samuel Ortiz <samuel@sortiz.org>,
irda-users@lists.sourceforge.net, linux-next@vger.kernel.org
I (and I assume Andrew) have been carrying them since then but noone took
them up. I guess (as Andrew pointed out to me) I should have pushed them.
--=20
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/hm, i do searches on lkml before posting patches but i cannot do searches on _every_ mailing list where patches might show up. There's just 30 hours in a day ;-) perhaps linux-next should propagate all add-on fix patches it is carrying against subsystem trees if they are still relevant to -git, once the subsystem tree goes to -git, and re-post them to lkml in that case, to avoid duplicative work? Once it's on lkml i think most yeah. Ingo --
Hi Ingo, --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <sfr@canb.auug.org.au> So what should I do now? I have Ingo's IRDA PNP fixes in my net-2.6 tree and that's already publicly visible, so I'd need to add revert changesets if people want me to remove it. --
Hi Dave, On Mon, 05 May 2008 16:55:01 -0700 (PDT) David Miller <davem@davemloft.net>= Do nothing. I was just making a point about patches getting lost/ignored. I have dropped my copies from linux-next today. At least the fixes are now in a tree headed for Linus, soon. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <sfr@canb.auug.org.au> Great, thanks. --
On Mon, 05 May 2008 23:56:54 -0700 (PDT) David Miller <davem@davemloft.net>= Except, of course, make sure that those patches go to Linus. :-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
i have no problem with the revert - Bjorn Helgaas found and fixed the buglet first. Ingo --
Uncharted territory here. As we discussed last week, I won't carry these patches because they're already upstream. It turns out that "upstream" in this case is linux-next itself, which is an unexpected place for patches to be mastered. So I suggest that Stephen send patches such as this into Linus sooner rather than later. Because nobody else will. Well. They _might_. In this case Len could merge the patch in which case Stephen would drop it and the fix would dawdle around in the acpi tree for a while. Ho hum, hopefully this isn't a common case. Often Linus or I will just do a maintainer bypass on things like this, but my ability to do that is now much reduced because a) I can't merge the patch and b) when I _do_ try to do that, it's "huh, we already fixed it". So... I hereby appoint Stephen random-build-fix-monkey. --
On Mon, 5 May 2008 17:16:57 -0700 Andrew Morton <akpm@linux-foundation.org>= This is an uncommon case because normally I would just revert the patch/tree that caused the problem. In this case, the problem didn't show up until after the linux-tree had been released so when the fix patches turned up the next day I added them in the hope that someone else would pick them up soon i.e. before they were needed in Linus' tree. I Rats! :-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Hi Ingo, Thanks for your good work! I got several of your patches, and applied them on my tree. Not sure if I got all ;) Due to May, 1st Holyday, I took some days to rest. I'm returning today. My intention is to double check what I've missed, clean-up my inbox, review the patches I've received and prepare a pull request with the bug fixes I Yes, some of your patches could use a different approach. For example, the stkwebcam patch can be re-done without forcing suport to the legacy V4L1 API. In fact, I've already did a patch with this approach just before the Holyday. Not sure if I've already merged it somewhere. I'll take a look and reply with the approach I took, for review. Cheers, -- Cheers, Mauro Carvalho Chehab http://linuxtv.org mchehab@infradead.org --
i'm tracking these fixes (and a ton of other fixes) because it's needed by our tests, so will let you know if there's anything missing after the next video push+pull. Have a good second look at the Kconfig patches i did - Kconfig dependencies are a maze to figure out and debugging and sorting those out is not particularly straightforward to someone like me who just wants to do a hit-and-run fix. Ingo --
even with my full stack of fixes this fails with missing symbols: http://redhat.com/~mingo/misc/config-Wed_May__7_01_58_56_CEST_2008.bad so please check this config too, whether your fixes covers that case as well. Ingo --
Just 800. We have already been past that: git shortlog v2.6.24..v2.6.25-rc1 | grep -Pv '^( |$)' | wc -l 918 --
x86.git testing found the following build failure on v2.6.26-rc1:
In file included from include/linux/kobject.h:22,
from include/linux/module.h:17,
from include/linux/crypto.h:22,
from arch/x86/kernel/asm-offsets_32.c:8,
from arch/x86/kernel/asm-offsets.c:3:
include/linux/sysfs.h:201: error: redefinition of 'sysfs_update_group'
include/linux/sysfs.h:195: error: previous definition of 'sysfs_update_group' was here
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
with the following config:
http://redhat.com/~mingo/misc/config-Sun_May__4_07_09_30_CEST_2008.bad
the reason for the build failure is the duplicate definition of the
sysfs_update_group() inline function in include/linux/sysfs.h.
The duplication was a merge error: it was added via -mm by commit
v2.6.25-7262-g2850699, "sysfs: sysfs_update_group stub for
CONFIG_SYSFS=n" a day before v2.6.26-rc1, but a day before that the same
commit was already merged upstream via the sysfs tree, with commit
v2.6.25-7211-g1cbfb7a.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
include/linux/sysfs.h | 6 ------
1 file changed, 6 deletions(-)
Index: linux/include/linux/sysfs.h
===================================================================
--- linux.orig/include/linux/sysfs.h
+++ linux/include/linux/sysfs.h
@@ -196,12 +196,6 @@ static inline int sysfs_update_group(str
return 0;
}
-static inline int sysfs_update_group(struct kobject *kobj,
- const struct attribute_group *grp)
-{
- return 0;
-}
-
static inline void sysfs_remove_group(struct kobject *kobj,
const struct attribute_group *grp)
{
--drivers/built-in.o: In function `xc2028_get_reg': tuner-xc2028.c:(.text+0x6b613): undefined reference to `i2c_transfer' drivers/built-in.o: In function `load_firmware': tuner-xc2028.c:(.text+0x6bf90): undefined reference to `i2c_transfer' drivers/built-in.o: In function `generic_set_freq': tuner-xc2028.c:(.text+0x6cdff): undefined reference to `i2c_transfer' tuner-xc2028.c:(.text+0x6ce65): undefined reference to `i2c_transfer' tuner-xc2028.c:(.text+0x6ceea): undefined reference to `i2c_transfer' drivers/built-in.o:tuner-xc2028.c:(.text+0x6cf61): more undefined references to `i2c_transfer' follow drivers/built-in.o: In function `simple_set_params': tuner-simple.c:(.text+0x6e425): undefined reference to `i2c_clients_command' tuner-simple.c:(.text+0x6e454): undefined reference to `i2c_transfer' tuner-simple.c:(.text+0x6e75b): undefined reference to `i2c_transfer' tuner-simple.c:(.text+0x6e7c0): undefined reference to `i2c_transfer' tuner-simple.c:(.text+0x6e9f6): undefined reference to `i2c_clients_command' tuner-simple.c:(.text+0x6ea7e): undefined reference to `i2c_transfer' tuner-simple.c:(.text+0x6eb6c): undefined reference to `i2c_transfer' tuner-simple.c:(.text+0x6ec0a): undefined reference to `i2c_transfer' tuner-simple.c:(.text+0x6ecee): undefined reference to `i2c_transfer' drivers/built-in.o: In function `simple_tuner_attach': (.text+0x6efcc): undefined reference to `i2c_transfer' drivers/built-in.o:tuner-simple.c:(.text+0x6f387): more undefined references to `i2c_transfer' follow drivers/built-in.o: In function `v4l2_i2c_drv_detach_legacy': tuner-core.c:(.text+0x7d191): undefined reference to `i2c_detach_client' drivers/built-in.o: In function `v4l2_i2c_drv_probe_legacy': tuner-core.c:(.text+0x7d1e7): undefined reference to `i2c_probe' drivers/built-in.o: In function `v4l2_i2c_drv_attach_legacy': tuner-core.c:(.text+0x7d20d): undefined reference to `v4l2_i2c_attach' drivers/built-in.o: In function `set_type': tuner-core.c:(.text+0x7d98a): undefined reference to `i2c_maste...
Amazingly, even if I say Y to this option and disable all tuners, it still tries (and fails) to compile this file. What is pulling in this tuner-core dependency? drivers/built-in.o: In function `v4l2_i2c_drv_detach_legacy': tuner-core.c:(.text+0x72ba9): undefined reference to `i2c_detach_client' drivers/built-in.o: In function `v4l2_i2c_drv_probe_legacy': tuner-core.c:(.text+0x72bff): undefined reference to `i2c_probe' drivers/built-in.o: In function `v4l2_i2c_drv_attach_legacy': tuner-core.c:(.text+0x72c25): undefined reference to `v4l2_i2c_attach' drivers/built-in.o: In function `set_type': tuner-core.c:(.text+0x738f8): undefined reference to `i2c_master_send' tuner-core.c:(.text+0x73935): undefined reference to `i2c_master_send' drivers/built-in.o: In function `tuner_probe': tuner-core.c:(.text+0x741c3): undefined reference to `i2c_master_recv' drivers/built-in.o: In function `v4l2_i2c_drv_init': tuner-core.c:(.init.text+0x6191): undefined reference to `i2c_register_driver' tuner-core.c:(.init.text+0x61e9): undefined reference to `i2c_register_driver' tuner-core.c:(.init.text+0x61fb): undefined reference to `i2c_del_driver' drivers/built-in.o: In function `v4l2_i2c_drv_cleanup': tuner-core.c:(.exit.text+0x44a): undefined reference to `i2c_del_driver' tuner-core.c:(.exit.text+0x456): undefined reference to `i2c_del_driver' Find config attached. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK.
What if you change CONFIG_MEDIA_TUNER to a 'n' Robin --
This isn't a menu-visible option. Your hint does explain why it turns itself
on, however:
config MEDIA_TUNER
tristate
default DVB_CORE || VIDEO_DEV
depends on DVB_CORE || VIDEO_DEV
I have DVB_CORE=n and VIDEO_DEV=y. VIDEO_DEV is:
config VIDEO_DEV
tristate "Video For Linux"
So if you enable Video For Linux, the tuner-core is automatically built, even
if no tuners are selected? Surely that's wrong..
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
--That is probably correct. Video For Linux is used for capturing video streams. The fact that you can get this invalid config to fail to build should be reported to the v4l folks and let them fix it up. VIDEO FOR LINUX P: Mauro Carvalho Chehab M: mchehab@infradead.org M: v4l-dvb-maintainer@linuxtv.org L: video4linux-list@redhat.com W: http://linuxtv.org T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git S: Maintained Thanks, Robin --
Alistair,
Sorry for not answering earlier, I got some days off (I still didn't read
Yes, this is correct, if you select a board that supports tuner (for
example, bttv, or cx88).
The error is that most tuners are dependent of I2C. The right fix seems to
do this:
config MEDIA_TUNER
tristate
default (DVB_CORE || VIDEO_DEV) && I2C
--
Cheers,
Mauro Carvalho Chehab
http://linuxtv.org
mchehab@infradead.org
--This still seems imperfect -- if I have I2C=y and VIDEO_DEV=y, but DVB_CORE=n (and no board types selected), it'll still build at least some of the tuner code into the V4L core. This is still true even if I set MEDIA_TUNER_CUSTOMIZE=y and set all of the tuners to 'n'. I'd assumed that this was an artefact of the complex Kconfig logic here, and was not intentional. Thanks for fixing the compile issue though, I've confirmed that it works. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. --
On Tue, 6 May 2008 09:02:25 +0100 I agree. the Kconfig logic for V4L/DVB is complex. It tries to address two different issues: - an easy board selection for the end-user (just selecting CX88 should allow his board to work); - an advanced selection for embedded set-top-boxes, where you can select just what you really need. Due to that, there are several "select" clauses, that don't consider the "depends on". So, it is very easy to break it, unfortunately. Also, since 2.6.24, all tuner modules are shared by analog and digital support (there are two different, independent API's and core utilities for analog and for digital). We need to redesign Kconfig/Makefile's to simplify the logic and remove the hidden dependencies. Cheers, Mauro --
No, it is not easy to break, it /is/ broken. But it is /trivial/ to fix. If A selects B, you have to copy all of B's dependencies to A or select these dependencies by A. So it's totally simple to do it right. The only nuisance is that you always have to update B's dependencies and selections whenever A's dependencies are changed. Furthermore: If you are worried that people don't figure out how to switch on support for board XYZ because it has several dependencies which may hide CONFIG_XYZ, there is a very simple trick. comment "XYZ cards need ABC" depends on ABC=n config XYZ tristate "XYZ cards" depends on ABC This way you avoid "select ABC", but still see how to get XYZ support while ABC is off. See for example drivers/ieee1394/Kconfig for an application of this comment trick. -- Stefan Richter -=====-==--- -=-= --==- http://arcgraph.de/sr/ --
On Tue, 06 May 2008 16:34:27 +0200
This is easy to maintain, if you have just a few selects, but this is not the
case of V4L drivers. Look some examples:
IVTV driver:
config VIDEO_IVTV
tristate "Conexant cx23416/cx23415 MPEG encoder/decoder support"
depends on VIDEO_V4L1 && VIDEO_V4L2 && PCI && I2C && EXPERIMENTAL
select I2C_ALGOBIT
select FW_LOADER
select VIDEO_IR
select MEDIA_TUNER
select VIDEO_TVEEPROM
select VIDEO_CX2341X
select VIDEO_CX25840
select VIDEO_MSP3400
select VIDEO_SAA711X
select VIDEO_SAA717X
select VIDEO_SAA7127
select VIDEO_TVAUDIO
select VIDEO_CS53L32A
select VIDEO_M52790
select VIDEO_WM8775
select VIDEO_WM8739
select VIDEO_VP27SMPX
select VIDEO_UPD64031A
select VIDEO_UPD64083
config VIDEO_FB_IVTV
tristate "Conexant cx23415 framebuffer support"
depends on VIDEO_IVTV && FB && EXPERIMENTAL
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
(btw, on above, IVTV is missing INPUT)
This is Cx88 driver:
config VIDEO_CX88
tristate "Conexant 2388x (bt878 successor) support"
depends on VIDEO_DEV && PCI && I2C && INPUT
select I2C_ALGOBIT
select FW_LOADER
select VIDEO_BTCX
select VIDEOBUF_DMA_SG
select MEDIA_TUNER
select VIDEO_TVEEPROM
select VIDEO_IR
select VIDEO_WM8775 if VIDEO_HELPER_CHIPS_AUTO
config VIDEO_CX88_ALSA
tristate "Conexant 2388x DMA audio support"
depends on VIDEO_CX88 && SND && EXPERIMENTAL
select SND_PCM
config VIDEO_CX88_BLACKBIRD
tristate "Blackbird MPEG encoder support (cx2388x + cx23416)"
depends on VIDEO_CX88
select VIDEO_CX2341X
config VIDEO_CX88_DVB
tristate "DVB...Shouldn't layers actually untangle dependencies, i.e. concentrate dependencies? A "high-level driver" does not depend on "low-level drivers" and the low-level drivers' dependencies anymore. It only depends on a "core driver" and on foreign subsystem APIs. And yes, the core driver may very well provide some functionality which not all of the high-level drivers need, or not all of the low-level drivers are able to support. (All theoretical since I have no idea of what kinds of modules of functionality you have/need and whether it really can be simpler organized.) -- Stefan Richter -=====-==--- -=-= --==- http://arcgraph.de/sr/ --
On Tue, 06 May 2008 21:44:36 +0200 This is the way it is designed. For example, if you have a em28xx device with msp3400 and tvp5150 and another em28xx device with saa7113. If you remove the select's for MSP3400, TVP5150 and SAA7113, at, em28xx, the module will compile without problems. The only issue is that you won't be able to see any images (due to the lack of tvp5150 or saa7113 analog TV demoduler) or listen to the audio, if the device needs msp3400 to decode audio. So, you'll just spend kernelspace for a completely useless driver ;) Ok, let's consider a scenario where there are 3 options, for each of the above. Now, the user will need to open the USB stick, without breaking anything, to identify what chips it have inside the internal i2c bus, before compiling the kernel. Also, since V4L/DVB has more than 230 drivers (most of them are those I2C helper drivers), the number of items for the user to understand and select will be huge. It is much better for the user to just select EM28XX and let the Kconfig do the hard work of selecting what low-level driver applies for em28xx-based devices. This causes lots of select, being very hard to maintain. The better would be to have a select-like clause that could check the dependencies automatically. Another alternative would be some sort of script (checkpatch.pl?) that would check if all selected dependencies are ok. Cheers, Mauro --
Ah, now I understand. You use "select" to enable options which aren't actually a build requirement for the selecting option. Another example where "select" is used to fill a gap left by limitations regarding what can be presented in the "make ...config" UIs. If you use "select" this way, well, then you have to cope with the implications. Another workaround for this UI limitation: config VIDEO_EM28XX tristate "Empia EM2800/2820/2840 USB video capture support" depends on WHATEVER_BUILD_REQUIREMENT_IS_LEFT select MAYBE_ANOTHER_BUILD_REQUIREMENT help ... comment "Empia EM28xx devices may require Philips SAA7113/4/5 video decoders" depends on VIDEO_EM28XX && VIDEO_SAA711X=n comment "Empia EM28xx devices may require Texas Instruments TVP5150 video decoder" depends on VIDEO_EM28XX && VIDEO_TVP5150=n Still awkward, but now you don't have to copy VIDEO_SAA711X's and VIDEO_TVP5150's dependencies to VIDEO_EM28XX anymore. Or another idea: Copy _all_ dependencies of drivers which can be selected by "...if VIDEO_HELPER_CHIPS_AUTO" to VIDEO_HELPER_CHIPS_AUTO. Of course all these issues go away as soon as somebody has implemented "select" with recursive dependency check. -- Stefan Richter -=====-==--- -=-= --==- http://arcgraph.de/sr/ --
PS: I believe the canonical way to express _runtime_ dependencies in Kconfig (in contrast to build dependencies) is not "select", but "help". -- Stefan Richter -=====-==--- -=-= --=== http://arcgraph.de/sr/ --
On Tue, 06 May 2008 22:47:20 +0200 Yes. That's why there are so many selects. Just a few of them are really to This seems Interesting, but probably not very effective, since it would produce a large amount of "warnings". However, we may use something like this: comment "WARNING: Empia EM28xx devices require a video decoder" I actually did this for tuners, on this changeset (still not at mainstream): Yes. Cheers, Mauro --
Yes... Except that it is very dangerous to /move/ dependencies, as you are apparently doing in that patch. When you use "select" somewhere, you should generally /copy/ dependencies. Although something like config VIRTUAL_META_OPTION depends on REAL_DEPENDENCY config THE_REAL_THING depends on VIRTUAL_META_OPTION does work if THE_REAL_THING actually depends on REAL_DEPENDENCY, it is safer if this dependency stays there, i.e. config THE_REAL_THING depends on REAL_DEPENDECY or config THE_REAL_THING depends on REAL_DEPENDENCY && VIRTUAL_META_OPTION or whatever, or equivalent constructs involving "if"..."endif". (I presume that for example MEDIA_TUNER_TDA827X does indeed have a build dependency on DVB_CORE && I2C.) Or in other words: Since MEDIA_TUNER selects a bunch of options which itself have build dependencies, you /must/ duplicate all of their dependencies to MEDIA_TUNER. Well, actually you don't use plain "select", you use "select ... if !MEDIA_TUNER_CUSTOMIZE". So if you can ensure by other means that those 2nd level dependencies are guaranteed to be fulfilled whenever MEDIA_TUNER_CUSTOMIZE=n, then you don't need to duplicate the 2nd level dependencies into MEDIA_TUNER. That's the same what I meant in my comment on VIDEO_HELPER_CHIPS_AUTO: Those options which "select" video decoders generally /must/ contain duplicates of the dependency statements of the decoders which they select. Except, since you don't use plain "select" there but actually "select ... if VIDEO_HELPER_CHIPS_AUTO", you can alternatively put the duplicates of the dependency statements to VIDEO_HELPER_CHIPS_AUTO. -- Stefan Richter -=====-==--- -=-= --=== http://arcgraph.de/sr/ --
On Wed, 07 May 2008 01:36:09 +0200 No, the dependency of this file is currently wrong. In the case of those tuners, all have the same dependencies: DVB or V4L and I2C. That's the reason why I've removed the individual dependencies. Yet, two drivers need a select (xc3028 and xc5000 needs to select FW_LOADER - so, only those two drivers are also dependent of HOTPLUG). Cheers, Mauro --
Which I just wrote is dangerous. It is easy to get wrong, and it is not
maintainable.
Here is what I would do:
config TUNER_1
tristate "Tuner 1"
depends on ACTUAL_DEP1_OF_T1 && ACTUAL_DEP2_OF_T1
config TUNER_2
tristate "Tuner 2"
depends on ACTUAL_DEP1_OF_T2 && ACTUAL_DEP2_OF_T2
select ACTUAL_DEP3_OF_T2
In this example, ACTUAL_DEP3_OF_T2 does not have further dependencies
itself.
And if you believe that Kconfig should assist with runtime dependencies
too, not just build-time dependencies, and you believe that the "help"
and "comment" directives are insufficient for that, then add
meta-options like this:
config META_TUNER_A
tristate "Meta-tuner A"
select TUNER_1
depends on ACTUAL_DEP1_OF_T1 && ACTUAL_DEP2_OF_T1 # for TUNER_1
select TUNER_2
depends on ACTUAL_DEP1_OF_T2 && ACTUAL_DEP2_OF_T2 # for TUNER_2
select ACTUAL_DEP3_OF_T2 # for TUNER_2
help
Adds support for cards which contain tuner 1 and/or tuner 2.
So, like I said before, I recommend:
- If an option has an actual build requirement, state it explicitly
by "depends on" (or alternatively "select") directly at this option.
Alternatively, enclose this option or a block of options which
have identical dependencies in an "if"/ "endif" block, conditional
on this common dependency.
- Whenever you use "select", *copy* all dependencies of option A to
option B if B selects A.
Alternatively, replace "select" by "select ... if C" and *copy*
all dependencies of option A to option C.
This is because the Kconfig files (1.) must correctly state all build
dependencies and (2.) must be maintainable.
If you "select" a lot, you will have of course a lot of dependencies to
copy. That's the nature of "select". You can't get around that. Not
as long as there is no "select" which recursively checks and maybe
selects dependencies of dependencies.
--
Stefan Richter
-=====-==--- -=-= -=---
[ message continues ]Switch A and B in the last sentence. :-) -- Stefan Richter -=====-==--- -=-= --==- http://arcgraph.de/sr/ --
a) He's already on CC b) No config I have posted was invalid c) There are two (possibly three) entirely separate issues You've got the wrong end of the stick here. I'm not saying V4L isn't required for MEDIA_TUNER, but MEDIA_TUNER should not be a dependency of V4L and so should NOT be unconditionally enabled. The first issue is obviously the build error, which can be resolved by adding a dep on I2C to MEDIA_TUNER, but given the recent churn there I'll leave that to Mauro. The second issue is the fact that the MEDIA_TUNER option is transparent and not user selectable, building code that is probably not required in some kernel configurations (tuner code depends on V4L, but surely not the other way around.. MEDIA_TUNER should be able to be n when VIDEO_DEV is y). The final issue is more of a matter of personal taste, which refers to the MEDIA_TUNER_CUSTOMIZE option, something that I think should be inverted and turned into a menu like most other device driver sections. So rather than MEDIA_TUNER_CUSTOMIZE, why not just have MEDIA_TUNER be visible to the user, and if Y, let them select tuners, and if N, no tuners are built. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. --
| Manu Abraham | PCIE |
| Jared Hulbert | [PATCH 00/10] AXFS: Advanced XIP filesystem |
| Pardo | Re: pthread_create() slow for many threads; also time to revisit 64b context switc... |
| Tomasz Chmielewski | Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS |
git: | |
| Thomas Glanzmann | fatal: serious inflate inconsistency |
| Jeff Garzik | Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits) |
| Andy Parkins | Re: git-fetch and unannotated tags |
| Yossi Leybovich | corrupt object on git-gc |
| Richard Stallman | Real men don't attack straw men |
| Bertram Scharpf | First install: Grub doesn't find partitions |
| Unix Fan | Chatting with developers? Is it soo 1996? |
| Joel Wiramu Pauling | Re: Suggested PF Setup when using BitTorrent? |
| Vegard Nossum | Re: [bug, netconsole, SLUB] BUG skbuff_head_cache: Poison overwritten |
| Jarek Poplawski | Re: NMI lockup, 2.6.26 release |
| Tomas Winkler | [PATCH] iwlwifi: RS small compile warnings without CONFIG_IWLWIFI_DEBUG |
| Simon Horman | Re: [PATCH] sendfile() and UDP socket |
