architectures with their own "config PCMCIA"

architectures with their own "config PCMCIA"

[Adrian Bunk]

The following architetures have their own "config PCMCIA" instead of 
including drivers/pcmcia/Kconfig (in 2.6.8-rc3-mm1):
- m68k
- s390
- sparc
- sparc64

Is there any good reason for this, or would a patch to change these 
architectures to include drivers/pcmcia/Kconfig be OK?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: architectures with their own "config PCMCIA"

[Christoph Hellwig]

On Sat, Aug 07, 2004 at 07:01:22PM +0200, Adrian Bunk wrote:
> The following architetures have their own "config PCMCIA" instead of 
> including drivers/pcmcia/Kconfig (in 2.6.8-rc3-mm1):
> - m68k
> - s390
> - sparc
> - sparc64
> 
> Is there any good reason for this, or would a patch to change these 
> architectures to include drivers/pcmcia/Kconfig be OK?

What about switching them to use drivers/Kconfig instead?

Re: architectures with their own "config PCMCIA"

[Adrian Bunk]

On Sat, Aug 07, 2004 at 06:10:51PM +0100, Christoph Hellwig wrote:
> On Sat, Aug 07, 2004 at 07:01:22PM +0200, Adrian Bunk wrote:
> > The following architetures have their own "config PCMCIA" instead of 
> > including drivers/pcmcia/Kconfig (in 2.6.8-rc3-mm1):
> > - m68k
> > - s390
> > - sparc
> > - sparc64
> > 
> > Is there any good reason for this, or would a patch to change these 
> > architectures to include drivers/pcmcia/Kconfig be OK?
> 
> What about switching them to use drivers/Kconfig instead?

drivers/Kconfig doesn't source drivers/pcmcia/Kconfig (and m68k 
already uses drivers/Kconfig).


But after a second look, I begin to understand a bit more:
Most of the architectures in question even have help text for the PCMCIA 
option, but the option itself isn't asked.

IOW: It's impossible to enable them.

Is there eny reason for such options that are never visible nor enabled, 
or could they be removed?


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: architectures with their own "config PCMCIA"

[Arnd Bergmann]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

> On Sat, Aug 07, 2004 at 06:10:51PM +0100, Christoph Hellwig wrote:
> > What about switching them to use drivers/Kconfig instead?

I'd prefer not to switch s390 to use drivers/Kconfig unless someone
volunteers to clean up all included Kconfig files by adding proper
'depends on PCI' etc. flags. Otherwise too many broken options are
offered.

On Samstag, 7. August 2004 19:25, Adrian Bunk wrote:
> Is there eny reason for such options that are never visible nor enabled,  
> or could they be removed?

Yes, the reason is that some other options depend on them. We added the
PCMCIA option to arch/s390/Kconfig to stop kbuild from asking about
some drivers that won't work anyway.

E.g. drivers/scsi/pcmcia starts with

menu "PCMCIA SCSI adapter support"
	depends on SCSI!=n && PCMCIA!=n && MODULES

which evaluate to true if the PCMCIA option is not known. Changing
that to

menu "PCMCIA SCSI adapter support"
	depends on SCSI && PCMCIA && MODULES

solves this in a different way, but I'm not 100% sure if it still has
the same meaning.

	Arnd <><

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: architectures with their own "config PCMCIA"

[Geert Uytterhoeven]

On Sat, 7 Aug 2004, Arnd Bergmann wrote:
> > On Sat, Aug 07, 2004 at 06:10:51PM +0100, Christoph Hellwig wrote:
> > > What about switching them to use drivers/Kconfig instead?
>
> I'd prefer not to switch s390 to use drivers/Kconfig unless someone
> volunteers to clean up all included Kconfig files by adding proper
> 'depends on PCI' etc. flags. Otherwise too many broken options are
> offered.

I've been `fixing up' many of them lately. Please give it a try.
Anyway, probably all additional clean ups you do for s390 are useful for m68k
as well ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: architectures with their own "config PCMCIA"

[Arnd Bergmann]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Samstag, 7. August 2004 22:36, Geert Uytterhoeven wrote:
> I've been `fixing up' many of them lately. Please give it a try.
> Anyway, probably all additional clean ups you do for s390 are useful for m68k
> as well ;-)

Yes, most devices drivers that rely on ISA or PCI attachment now
appear to be gone.

However, I just tried and found that out of the 23 driver submenus, only
"Generic Driver Options", "Block devices", "SCSI device support",
"Multi-device support", "Networking support" and "Character devices"
make any sense at all. All others depend on some hardware that has
never been attached to an s390 box. 

We could of course build some subsystems like MTD, ISDN or FB, but
there is still little point without any low-level drivers.

	Arnd <><

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: architectures with their own "config PCMCIA"

[Christoph Hellwig]

On Sat, Aug 07, 2004 at 11:41:17PM +0200, Arnd Bergmann wrote:
> However, I just tried and found that out of the 23 driver submenus, only
> "Generic Driver Options", "Block devices", "SCSI device support",
> "Multi-device support", "Networking support" and "Character devices"
> make any sense at all. All others depend on some hardware that has
> never been attached to an s390 box. 
> 
> We could of course build some subsystems like MTD, ISDN or FB, but
> there is still little point without any low-level drivers.

That gives this type of code additional build coverage, which is a good
thing.  Just allow it in the menues, no need to add it to your defconfigs :)

Re: architectures with their own "config PCMCIA"

[Adrian Bunk]

On Sat, Aug 07, 2004 at 08:12:56PM +0200, Arnd Bergmann wrote:
>...
> On Samstag, 7. August 2004 19:25, Adrian Bunk wrote:
> > Is there eny reason for such options that are never visible nor enabled,  
> > or could they be removed?
> 
> Yes, the reason is that some other options depend on them. We added the
> PCMCIA option to arch/s390/Kconfig to stop kbuild from asking about
> some drivers that won't work anyway.
> 
> E.g. drivers/scsi/pcmcia starts with
> 
> menu "PCMCIA SCSI adapter support"
> 	depends on SCSI!=n && PCMCIA!=n && MODULES
> 
> which evaluate to true if the PCMCIA option is not known. Changing
> that to
> 
> menu "PCMCIA SCSI adapter support"
> 	depends on SCSI && PCMCIA && MODULES
> 
> solves this in a different way, but I'm not 100% sure if it still has
> the same meaning.

Roman, is it intentional that PCMCIA!=n is true if there's no PCMCIA 
option, or is it simply a bug?

> 	Arnd <><

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: architectures with their own "config PCMCIA"

[Sam Ravnborg]

On Wed, Aug 11, 2004 at 10:17:25PM +0200, Adrian Bunk wrote:
> On Sat, Aug 07, 2004 at 08:12:56PM +0200, Arnd Bergmann wrote:
> >...
> > On Samstag, 7. August 2004 19:25, Adrian Bunk wrote:
> > > Is there eny reason for such options that are never visible nor enabled,  
> > > or could they be removed?
> > 
> > Yes, the reason is that some other options depend on them. We added the
> > PCMCIA option to arch/s390/Kconfig to stop kbuild from asking about
> > some drivers that won't work anyway.
> > 
> > E.g. drivers/scsi/pcmcia starts with
> > 
> > menu "PCMCIA SCSI adapter support"
> > 	depends on SCSI!=n && PCMCIA!=n && MODULES
> > 
> > which evaluate to true if the PCMCIA option is not known. Changing
> > that to
> > 
> > menu "PCMCIA SCSI adapter support"
> > 	depends on SCSI && PCMCIA && MODULES
> > 
> > solves this in a different way, but I'm not 100% sure if it still has
> > the same meaning.
> 
> Roman, is it intentional that PCMCIA!=n is true if there's no PCMCIA 
> option, or is it simply a bug?

Roman, a related Q.
Why not error out, or at least warn when encountering an unknow
symbol in a 'depends on' statement?

I took a quick look, but did not initially see how to actually implemnt it.
Considering something in the bottom of menu_finalize()?

	Sam

Re: architectures with their own "config PCMCIA"

[Adrian Bunk]

On Wed, Aug 11, 2004 at 11:40:32PM +0200, Sam Ravnborg wrote:
> 
> Roman, a related Q.
> Why not error out, or at least warn when encountering an unknow
> symbol in a 'depends on' statement?
>...

That doesn't sound like a good idea, consider e.g.:

config BAGETLANCE
        tristate "Baget AMD LANCE support"
        depends on NET_ETHERNET && BAGET_MIPS


> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: architectures with their own "config PCMCIA"

[Roman Zippel]

Hi,

On Thu, 12 Aug 2004, Adrian Bunk wrote:

> > Roman, a related Q.
> > Why not error out, or at least warn when encountering an unknow
> > symbol in a 'depends on' statement?
> >...
> 
> That doesn't sound like a good idea, consider e.g.:
> 
> config BAGETLANCE
>         tristate "Baget AMD LANCE support"
>         depends on NET_ETHERNET && BAGET_MIPS

This is less a problem, as here it's clear that you want a boolean result, 
but something like "FOO=n" is really a string compare and FOO could be of 
any type (that 99% of all symbols are boolean/tristate symbols doesn't 
really help).

bye, Roman

Re: architectures with their own "config PCMCIA"

[Adrian Bunk]

On Thu, Aug 12, 2004 at 10:59:25AM +0200, Roman Zippel wrote:
> Hi,
> 
> On Thu, 12 Aug 2004, Adrian Bunk wrote:
> 
> > > Roman, a related Q.
> > > Why not error out, or at least warn when encountering an unknow
> > > symbol in a 'depends on' statement?
> > >...
> > 
> > That doesn't sound like a good idea, consider e.g.:
> > 
> > config BAGETLANCE
> >         tristate "Baget AMD LANCE support"
> >         depends on NET_ETHERNET && BAGET_MIPS
> 
> This is less a problem, as here it's clear that you want a boolean result, 
> but something like "FOO=n" is really a string compare and FOO could be of 
> any type (that 99% of all symbols are boolean/tristate symbols doesn't 
> really help).

Wouldn't it be better to require a string or hex to always be quoted  
like "somestring"?

This way y/m/n would always have a non-string type.

> bye, Roman

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: architectures with their own "config PCMCIA"

[Roman Zippel]

Hi,

On Sat, 14 Aug 2004, Adrian Bunk wrote:

> > This is less a problem, as here it's clear that you want a boolean result, 
> > but something like "FOO=n" is really a string compare and FOO could be of 
> > any type (that 99% of all symbols are boolean/tristate symbols doesn't 
> > really help).
> 
> Wouldn't it be better to require a string or hex to always be quoted  
> like "somestring"?

What about normal numbers? I don't think requiring quotes everywhere for 
this is a good idea.

bye, Roman

Re: architectures with their own "config PCMCIA"

[Geert Uytterhoeven]

On Sun, 15 Aug 2004, Roman Zippel wrote:
> On Sat, 14 Aug 2004, Adrian Bunk wrote:
> > > This is less a problem, as here it's clear that you want a boolean result,
> > > but something like "FOO=n" is really a string compare and FOO could be of
> > > any type (that 99% of all symbols are boolean/tristate symbols doesn't
> > > really help).
> >
> > Wouldn't it be better to require a string or hex to always be quoted
> > like "somestring"?
>
> What about normal numbers? I don't think requiring quotes everywhere for
> this is a good idea.

And numbers (both decimal and hex) can easily be distinguished from y, n, and m
anyway.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: architectures with their own "config PCMCIA"

[Adrian Bunk]

On Sun, Aug 15, 2004 at 09:37:30PM +0200, Geert Uytterhoeven wrote:
> On Sun, 15 Aug 2004, Roman Zippel wrote:
> > On Sat, 14 Aug 2004, Adrian Bunk wrote:
> > > > This is less a problem, as here it's clear that you want a boolean result,
> > > > but something like "FOO=n" is really a string compare and FOO could be of
> > > > any type (that 99% of all symbols are boolean/tristate symbols doesn't
> > > > really help).
> > >
> > > Wouldn't it be better to require a string or hex to always be quoted
> > > like "somestring"?
> >
> > What about normal numbers? I don't think requiring quotes everywhere for
> > this is a good idea.
> 
> And numbers (both decimal and hex) can easily be distinguished from y, n, and m
> anyway.

Sounds reasonable.

This leaves strings.

Could you point me to one single place in the kernel where a string 
constant is used in the dependencies of another symbol?
If it's that rare, requiring quotes shouuldn't be that much of a burden.

I see six places where quotes are used for y/n/m, but they should be 
trivial to fix.

> Gr{oetje,eeting}s,
> 
> 						Geert

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: architectures with their own "config PCMCIA"

[Roman Zippel]

Hi,

On Sun, 15 Aug 2004, Geert Uytterhoeven wrote:

> > What about normal numbers? I don't think requiring quotes everywhere for
> > this is a good idea.
> 
> And numbers (both decimal and hex) can easily be distinguished from y, n, and m
> anyway.

I did consider this at some point, but I didn't want to add further 
special cases. Every symbol has a tristate and a string value and so you 
can compare pretty much everything with everything else. Splitting the 
string value further into other types isn't worth the trouble. The problem 
at hand is easy enough to solve by adding a type declaration.

bye, Roman

Re: architectures with their own "config PCMCIA"

[Adrian Bunk]

On Mon, Aug 16, 2004 at 01:01:35AM +0200, Roman Zippel wrote:

> Hi,

Hi Roman,

> On Sun, 15 Aug 2004, Geert Uytterhoeven wrote:
> 
> > > What about normal numbers? I don't think requiring quotes everywhere for
> > > this is a good idea.
> > 
> > And numbers (both decimal and hex) can easily be distinguished from y, n, and m
> > anyway.
> 
> I did consider this at some point, but I didn't want to add further 
> special cases. Every symbol has a tristate and a string value and so you 
> can compare pretty much everything with everything else. Splitting the 
> string value further into other types isn't worth the trouble. The problem 
> at hand is easy enough to solve by adding a type declaration.

if things stay as they are, we _really_ need warnings for !=n and 
rewrite the correct ones to (FOO=y || FOO=m).

> bye, Roman

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: architectures with their own "config PCMCIA"

[Roman Zippel]

Hi,

On Wed, 11 Aug 2004, Adrian Bunk wrote:

> Roman, is it intentional that PCMCIA!=n is true if there's no PCMCIA 
> option, or is it simply a bug?

Yes, undefined symbols have a (string) value of "" . Maybe it's time to 
add a warning for such comparisons...

bye, Roman

Re: architectures with their own "config PCMCIA"

[Adrian Bunk]

On Wed, Aug 11, 2004 at 11:45:21PM +0200, Roman Zippel wrote:

> Hi,

Hi Roman,

> On Wed, 11 Aug 2004, Adrian Bunk wrote:
> 
> > Roman, is it intentional that PCMCIA!=n is true if there's no PCMCIA 
> > option, or is it simply a bug?
> 
> Yes, undefined symbols have a (string) value of "" . Maybe it's time to 
> add a warning for such comparisons...

is there any strong reason why undefined symbols aren't equivalent to 
symbols with a value of "n"?

Many !=n seems to be bogus (especially ones from the automatic 
transition to the new Kconfig) and I'll audit them. But rewriting valid 
FOO!=n to (FOO=y || FOO=m) doesn't sound like an improvement.

> bye, Roman

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: architectures with their own "config PCMCIA"

[Randy.Dunlap]

On Thu, 12 Aug 2004 02:18:48 +0200 Adrian Bunk wrote:

| On Wed, Aug 11, 2004 at 11:45:21PM +0200, Roman Zippel wrote:
| 
| > Hi,
| 
| Hi Roman,
| 
| > On Wed, 11 Aug 2004, Adrian Bunk wrote:
| > 
| > > Roman, is it intentional that PCMCIA!=n is true if there's no PCMCIA 
| > > option, or is it simply a bug?
| > 
| > Yes, undefined symbols have a (string) value of "" . Maybe it's time to 
| > add a warning for such comparisons...
| 
| is there any strong reason why undefined symbols aren't equivalent to 
| symbols with a value of "n"?

I second that question...

| Many !=n seems to be bogus (especially ones from the automatic 
| transition to the new Kconfig) and I'll audit them. But rewriting valid 
| FOO!=n to (FOO=y || FOO=m) doesn't sound like an improvement.

Hm, I've thought that config selections were either boolean or
tristate.  This makes it sound like they could be quadstate (y/n/m/blank).

And the menu dependency doc in Documentation/kbuild/kconfig-language.txt
makes it sound (to me) like undefined values become 'n':

<quote>
Expressions are listed in decreasing order of precedence. 

(1) Convert the symbol into an expression. Boolean and tristate symbols
    are simply converted into the respective expression values. All
    other symbol types result in 'n'.
...
An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2
respectively for calculations). A menu entry becomes visible when it's
expression evaluates to 'm' or 'y'.
</quote>


--
~Randy

Re: architectures with their own "config PCMCIA"

[William Lee Irwin III]

On Sat, Aug 07, 2004 at 07:01:22PM +0200, Adrian Bunk wrote:
> The following architetures have their own "config PCMCIA" instead of 
> including drivers/pcmcia/Kconfig (in 2.6.8-rc3-mm1):
> - m68k
> - s390
> - sparc
> - sparc64
> Is there any good reason for this, or would a patch to change these 
> architectures to include drivers/pcmcia/Kconfig be OK?

I'd like to switch things over to drivers/Kconfig and/or
drivers/pcmcia/Kconfig. If the drivers are bust I'll just sweep them
when someone complains about the build being bust. One could
proactively find these with make allmodconfig and/or allyesconfig, but
I suspect that may be too large a set of drivers to digest all at once.
Or maybe not -- akpm does scale, after all.


-- wli