[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hfxt3woae.wl%tiwai@suse.de>
Date: Wed, 30 Apr 2008 13:54:49 +0200
From: Takashi Iwai <tiwai@...e.de>
To: David Miller <davem@...emloft.net>
Cc: mingo@...e.hu, mchehab@...radead.org, akpm@...ux-foundation.org,
linux-dvb-maintainer@...uxtv.org, video4linux-list@...hat.com,
linux-kernel@...r.kernel.org, efault@....de
Subject: Re: [patch, -git] media/video/sound build fix, TEA5761/TEA5767
At Wed, 30 Apr 2008 04:17:03 -0700 (PDT),
David Miller wrote:
>
> From: Takashi Iwai <tiwai@...e.de>
> Date: Wed, 30 Apr 2008 13:11:31 +0200
>
> > IMO, it's the reverse selection from sound to V4L that makes things
> > complicated. I believe it's better to fix it as a normal dependency.
> >
> > How about the patch below?
>
> The question that remains is what does this mean for users?
>
> How does a user, who wants to enable this 'sound' driver,
> learn that they must enable the v4l subsystem in order to
> do so?
>
> This is typically why select constructs are used, to not bother the
> user with such messy details.
Yes, from the usability POV, select is better.
> But like we see in this case, it can cause serious implementation
> problems if not used properly. :(
Indeed. The problem is that the select doesn't (can't?) resolve the
dependecy in a reverse way. For example, select VIDEO_V4L1 won't turn
on the dependent items such as VIDEO_DEV, VIDEO_V4L2_COMMON,
VIDEO_ALLOW_V4L1, so and so.
Thus, when another dependency is added to the selected target, it can
easily break the depdency chain like this case...
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists