Re: [PATCH] arm Kconfig fixes

Re: [PATCH] arm Kconfig fixes

[Dave Jones]

On Sat, Aug 28, 2004 at 02:13:44AM +0000, Linux Kernel wrote:
 > ChangeSet 1.1892, 2004/08/27 19:13:44-07:00, viro@www.linux.org.uk
 > 
 > 	[PATCH] arm Kconfig fixes
 > 	
 > 	ARM dependency and makefile fixes (ACKed by rmk)
 > 	
 > diff -Nru a/drivers/char/agp/Kconfig b/drivers/char/agp/Kconfig
 > --- a/drivers/char/agp/Kconfig	2004-08-27 20:09:34 -07:00
 > +++ b/drivers/char/agp/Kconfig	2004-08-27 20:09:34 -07:00
 > @@ -1,5 +1,5 @@
 >  config AGP
 > -	tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU && !M68K
 > +	tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU && !M68K && !ARM
 >  	default y if GART_IOMMU
 >  	---help---
 >  	  AGP (Accelerated Graphics Port) is a bus system mainly used to

This has the opportunity to grow and grow and make things really ugly
in all the driver specific Kconfigs each time a new arch switches
over to use drivers/Kconfig.  Is this really any better than doing
this checking in drivers/Kconfig itself and keeping the subdir'd kconfig's
somewhat cleaner ?

Even if not,  I think I'd actually prefer a whitelist of drivers that *do*
support agpgart in the Kconfig, than the above which needs to be added to
all the time.  Something like if X86 && ALPHA && IA64 should cover it currently.
It just seems to me to be a lot more sensible than listing a bunch
of stuff which is completely irrelevant.

		Dave

Re: [PATCH] arm Kconfig fixes

[Christoph Hellwig]

On Sat, Aug 28, 2004 at 10:05:33PM +0100, Dave Jones wrote:
> Even if not,  I think I'd actually prefer a whitelist of drivers that *do*
> support agpgart in the Kconfig, than the above which needs to be added to
> all the time.  Something like if X86 && ALPHA && IA64 should cover it currently.

PPC

Re: [PATCH] arm Kconfig fixes

[Dave Jones]

On Sat, Aug 28, 2004 at 10:13:45PM +0100, Christoph Hellwig wrote:
 > On Sat, Aug 28, 2004 at 10:05:33PM +0100, Dave Jones wrote:
 > > Even if not,  I think I'd actually prefer a whitelist of drivers that *do*
 > > support agpgart in the Kconfig, than the above which needs to be added to
 > > all the time.  Something like if X86 && ALPHA && IA64 should cover it currently.
 > 
 > PPC

Bah, I *knew* I'd miss one. I even read the Kconfig twice after missing IA64.
I suck. I still stand by my claim that it would look better though.

		Dave

Re: [PATCH] arm Kconfig fixes

[Christoph Hellwig]

On Sat, Aug 28, 2004 at 10:17:17PM +0100, Dave Jones wrote:
> On Sat, Aug 28, 2004 at 10:13:45PM +0100, Christoph Hellwig wrote:
>  > On Sat, Aug 28, 2004 at 10:05:33PM +0100, Dave Jones wrote:
>  > > Even if not,  I think I'd actually prefer a whitelist of drivers that *do*
>  > > support agpgart in the Kconfig, than the above which needs to be added to
>  > > all the time.  Something like if X86 && ALPHA && IA64 should cover it currently.
>  > 
>  > PPC
> 
> Bah, I *knew* I'd miss one. I even read the Kconfig twice after missing IA64.
> I suck. I still stand by my claim that it would look better though.

Completely agreed on that one.  Negative depencies are a bad idea in general.

Re: [PATCH] arm Kconfig fixes

[viro]

On Sat, Aug 28, 2004 at 10:22:06PM +0100, Christoph Hellwig wrote:
> > Bah, I *knew* I'd miss one. I even read the Kconfig twice after missing IA64.
> > I suck. I still stand by my claim that it would look better though.
> 
> Completely agreed on that one.  Negative depencies are a bad idea in general.

ACK.

How about adding HAS_AGP into platform Kconfig and making that animal
dependent on it?

BTW, AFAICS a legitimate form of negative dependency is && (!FOO || BROKEN)
and it's common enough to consider adding a separate
	broken if <expression>
to config language.  It would be interpreted as && (!<expr> || BROKEN) added
to dependencies, but would document the situation better.

Re: [PATCH] arm Kconfig fixes

[Roman Zippel]

Hi,

On Sat, 28 Aug 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:

> BTW, AFAICS a legitimate form of negative dependency is && (!FOO || BROKEN)
> and it's common enough to consider adding a separate
> 	broken if <expression>
> to config language.  It would be interpreted as && (!<expr> || BROKEN) added
> to dependencies, but would document the situation better.

It looks ok, but the part I wouldn't like is to hardcode this into the 
parser, if someone comes up with a decent syntax to define this 
dynamically, it would be ok with me.

bye, Roman