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...
[ message continues ]

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...
[ message continues ]

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

==================================================...
[ message continues ]

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...
[ message continues ]

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...
[ message continues ]

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 ]