architectures with their own "config PCMCIA"

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

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

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.

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 <><

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 -- [email protected]

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

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 <><

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 :)

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

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

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

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

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

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

Hi,

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

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.

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

Hi,

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

bye, Roman

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 -- [email protected]

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

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.

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

Hi,

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

Hi Roman,

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

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

Hi,

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

bye, Roman

Hi Roman,

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.

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

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

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