Peter Samuelson wrote:
>
> (BTW, the format is great - I can use 'M-x compile' and 'M-x
> next-error' and Emacs pulls up files and lines for me.)
This is not a coincidence.
> CONFIG_SCSI should be defined earlier, like in the "Block Devices"
> menu. Then again, 'sg' is not a block device so this isn't strictly
> correct. Perhaps a "kernel subsystems" submenu under "general setup",
> or even as a toplevel menu.
Sounds like a good idea. You could put CONFIG_SERIAL and CONFIG_PCMCIA
in there too.
> CONFIG_INPUT - arch/{alpha,mips,mips64}/config.in are broken. There's
> a comment in other arch/*/config.in files to the effect that
> drivers/input/Config.in must come before drivers/usb/input/Config.in.
> These 3 explicitly do the opposite.
There are many broken things about the arch toplevel config.ins, mostly
due to them starting life as copy-n-paste jobs from arch/i386/config.in
and then slowly diverging. A brief sampling from my bugs list...
* CONFIG_KERNEL_ELF
Defined in arch/ppc/config.in as "define_bool CONFIG_KERNEL_ELF y".
Specified in a large number of ppc defconfigs.
Not used anywhere in the source.
Appears to be an obsolete artifact.
CONFIG_ELF_KERNEL
Defined in arch/mips/config.in as "define_bool CONFIG_ELF_KERNEL y".
Specified in a large number of mips defconfigs.
Not used anywhere in the source.
Appears to be an obsolete artifact.
* arch/ia64/config.in has this:
if [ "$CONFIG_DEVFS_FS" = "y" ]; then
bool ' Enable DEVFS Debug Code' CONFIG_DEVFS_DEBUG n
fi
but why!?!? Not only does this have a bogus third argument as
if it were dep_bool, but it defines a symbol already defined
over in fs/Config.in, which is *included* from this config.in.
* Most architectures have two global menus "General setup", one from
their own arch/foo/config.in, one from init/Config.in.
* One of these two correctly describes the device(s) it supports:
arch/m68k/config.in: dep_tristate 'A2091 WD33C93A support' CONFIG_A2091_SCSI $CONFIG_SCSI
drivers/scsi/Config.in: dep_tristate 'A2091/A590 WD33C93A support' CONFIG_A2091_SCSI $CONFIG_SCSI
* What's the story with CONFIG_ALPHA_EV56? It's defined as a symbol
three times in arch/alpha/config.in with different banners:
bool 'EV56 CPU (speed >= 333MHz)?' CONFIG_ALPHA_EV56
bool 'EV56 CPU (speed >= 366MHz)?' CONFIG_ALPHA_EV56
bool 'EV56 CPU (speed >= 400MHz)?' CONFIG_ALPHA_EV56
* WTF?!? arch/cris/drivers/bluetooth/Makefile has an install: target
which actually hacks Config.in and Makefile in other directories!?!?!
* There's a fair bit of confusion between the architectures about
CONFIG_BINFMT_ELF{,32}...
ARCH C_B_ELF C_B_ELF32
---- ------- ---------
alpha 1
arm 1
cris 1
i386 1
ia64 1
m68k 1
mips64 2 4
mips 3
parisc 1
ppc64 2 5
ppc 3
s390 1
s390x 1 6
sh 1
sparc64 2 5
sparc 1
x86_64 1
1='Kernel support for ELF binaries'
2='Kernel support for 64-bit ELF binaries'
3=define_bool
4=define_bool,unset
5='Kernel support for 32-bit ELF binaries'
6='Kernel support for 31 bit ELF binaries'
Note that the interpretation of CONFIG_BINFMT_ELF appears to be
"support for largest-ELF" but some 64 bit platforms present this
to the user as explicitly "64-bit" while other 64 bit platforms
don't seem to care. The 32-bit platforms just pretend there's
no such thing as 64-bits.
> CONFIG_SOUND_GAMEPORT - defined in drivers/input/gameport/, used only
> in sound/oss/. I'm not sure what's going on here
I couldn't figure out CONFIG_SOUND_GAMEPORT or CONFIG_INPUT_GAMEPORT either.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
[Greg Banks]
[I wrote]
> > (BTW, the format is great - I can use 'M-x compile' and 'M-x
> > next-error' and Emacs pulls up files and lines for me.)
>
> This is not a coincidence.
Indeed not - if you hadn't already used that format I would have
munged it. Grew up on gcc, so this is my favorite error message
format. Yours too, I guess. (:
> > CONFIG_SCSI should be defined earlier, like in the "Block Devices"
> > menu. Then again, 'sg' is not a block device so this isn't strictly
> > correct. Perhaps a "kernel subsystems" submenu under "general setup",
> > or even as a toplevel menu.
>
> Sounds like a good idea. You could put CONFIG_SERIAL and CONFIG_PCMCIA
> in there too.
CONFIG_SERIAL and CONFIG_PCMCIA didn't generate any noise, though.
Minimum necessary change and all that. It's easy enough to add later,
if desired.
Here's a start. It looks a little hacky but it does fix real issues.
I decided to combine "general setup", "module config" and "major
subsystems" - the latter needs to come after modules but really
belongs with general setup. Eh?
I think the first patch belongs on trivial@rustcorp - what's the
protocol there, just an email cc? Attach or inline? etc.
Peter
Here's another one - this should fix the forward dependency between
CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
into the "Multimedia" menu - where I think it belongs anyway.
The big loser here is ARM - it no longer suppresses the sound card
question for the appropriate boards. But it's just one question, so I
didn't sweat it too much.
On Tue, 13 Aug 2002, Peter Samuelson wrote:
> Here's another one - this should fix the forward dependency between
> CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
> into the "Multimedia" menu - where I think it belongs anyway.
Hmmh, makes sense to me, but there will probably be people complaining
"sound config has disappeared for me" ;)
> The big loser here is ARM - it no longer suppresses the sound card
> question for the appropriate boards. But it's just one question, so I
> didn't sweat it too much.
Well, I think that's okay, but you should check back with _rmk_.
What I like about that patch is that it actually removes duplicated code.
I think that's exactly where this effort should start. For example, the
SCSI patch didn't do this, though AFAICS it would be nicely possible to
unconditionally source drivers/scsi/Config.in and then have the if in
there.
These are trivial changes, and they make it easier to see what's happening
in the patches which actually change behavior. Taking that a step further,
this should also be a nice opportunity to introduce drivers/Config.in and
remove even more duplication from arch/$ARCH/config.in. It comes of the
cost of testing for the architecture, since e.g. s390 does not want to
include most of drivers/*, but that means we'd actually collect this
knowledge at a centralized place.
Introducing drivers/Config.in could be done nicely piecemeal as well,
without any change in behavior which is always good. It would also provide
a possibility to not lose the ARM knowledge.
I think it's basically just a question of taste if you prefer to initial
global subsystem question in drivers/Config.in or
drivers/<subsys>/Config.in.
drivers/isdn/Config.in starts with
mainmenu_option next_comment
comment 'ISDN subsystem'
if [ "$CONFIG_NET" != "n" ]; then
bool 'ISDN support' CONFIG_ISDN_BOOL
if [ "$CONFIG_ISDN_BOOL" = "y" ]; then
mainmenu_option next_comment
since I did not like having that duplicated in each arch/*/config.in. It
also makes sense in the "have as much information as possible about a
subsystem located in one place (drivers/<subsys>)". By the way, if you do
these kind of changes, also check Config.help, you may be able to remove
duplicated entries there as well ;)
The drawbacks of that solution as opposed to having the above in
drivers/Config.in and ending with source "drivers/isdn/Config.in" are:
o We need to source all the Config.in files even when the subsys gets
disabled, since we cannot know that beforehand
o The trivial patches moving statements like the above into the
subsys/Config.in means that all of that file should be indented, which
makes the patches look really large, even though they change very
little.
I have no strong opinion either way, but I'd certainly like
a drivers/Config.in.
Oh, what I don't like about your patches: You don't include them inline,
so I cannot easily (R)eply to them and have them quoted ;)
--Kai
[I wrote]
> > Here's another one - this should fix the forward dependency
> > between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the
> > sound config into the "Multimedia" menu - where I think it belongs
> > anyway.
[Kai Germaschewski]
> Hmmh, makes sense to me, but there will probably be people
> complaining "sound config has disappeared for me" ;)
You are probably right. I still think it's the right thing to do. (:
I do *not* like the recent proliferation of toplevel menu entries.
> Well, I think that's okay, but you should check back with _rmk_.
True. The trouble with this sort of work is that you *have* to touch
all the architectures, and sometimes change the behavior somewhat.
That can mean stepping on toes now and then.
> What I like about that patch is that it actually removes duplicated
> code. I think that's exactly where this effort should start. For
> example, the SCSI patch didn't do this, though AFAICS it would be
> nicely possible to unconditionally source drivers/scsi/Config.in and
> then have the if in there.
I thought about that - but didn't want to re-indent the whole file. I
hate doing that. (:
Also, there's a *reason* every arch has a separate config.in file -
for maximum flexibility without putting lots of ifdefs in common code.
To a certain extent I agree with you and I wish it were possible to
eliminate the arch/*/config.in entirely, but it's not. ESR tried it
with CML2 and was slapped down by Linus himself, as I recall.
I don't want my humble efforts to end up the same way CML2 did. For
that reason I'm trying very hard to make only small, incremental,
obvious changes. Perhaps I'm a bit *too* timid.
> It comes of the cost of testing for the architecture, since
> e.g. s390 does not want to include most of drivers/*, but that means
> we'd actually collect this knowledge at a centralized place.
What we need is an easy way to check for any arch. CONFIG_ARCH_S390
is the right idea (though s390x sets it as well, not sure if that's
good or bad). Then again, such checks polluting the common code is
exactly what the current system (with all its cut/paste code in
arch/*/config.in) is supposed to prevent. Perhaps The Powers That Be
like the status quo.
> Introducing drivers/Config.in could be done nicely piecemeal as
> well, without any change in behavior which is always good. It would
> also provide a possibility to not lose the ARM knowledge.
Hmmmm ... I didn't see any clean way to keep the arm test. Thinking
about it some more, I suppose one could do
if [ "$CONFIG_ARM" = "y" ]; then
if [ ... ]; then
tristate CONFIG_SOUND
fi
else
tristate CONFIG_SOUND
fi
It's still not pretty, but should work. I think I'll put that in
drivers/media/Config.in.
> By the way, if you do these kind of changes, also check Config.help,
> you may be able to remove duplicated entries there as well ;)
I'd been avoiding Config.help - I was afraid if I looked in it I would
find entries I would have to move from one dir to another. (:
> I have no strong opinion either way, but I'd certainly like a
> drivers/Config.in.
Agreed.
> Oh, what I don't like about your patches: You don't include them
> inline, so I cannot easily (R)eply to them and have them quoted ;)
Sorry about that - I agree. I only attached patches when I had more
than one for a single mail, and then I forgot to switch back. Must
recompile self with -finline-patches....
Peter
Kai Germaschewski wrote:
>
> On Tue, 13 Aug 2002, Peter Samuelson wrote:
>
> I think that's exactly where this effort should start. For example, the
> SCSI patch didn't do this, though AFAICS it would be nicely possible to
> unconditionally source drivers/scsi/Config.in and then have the if in
> there.
I like that idea.
> this should also be a nice opportunity to introduce drivers/Config.in and
> remove even more duplication from arch/$ARCH/config.in. It comes of the
> cost of testing for the architecture, since e.g. s390 does not want to
> include most of drivers/*, but that means we'd actually collect this
> knowledge at a centralized place.
<gentle-irony>Oh no the dreaded unified arch tree!</gentle-irony>
Seriously, I think this is perhaps a bit brave in the short term.
> o The trivial patches moving statements like the above into the
> subsys/Config.in means that all of that file should be indented, which
> makes the patches look really large, even though they change very
> little.
I wouldn't be too worried about indentation, it's quite loosely followed
already. In fact better to do one patch that does the move and a second
larger but provably-trivial patch that fixes up the indentation.
> I have no strong opinion either way, but I'd certainly like
> a drivers/Config.in.
I think it's a great idea whose time has not yet come.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
Peter Samuelson wrote:
>
> Here's another one - this should fix the forward dependency between
> CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
> into the "Multimedia" menu - where I think it belongs anyway.
>
> [...]
> -if [ "$CONFIG_ARCH_ACORN" = "y" -o \
> - "$CONFIG_ARCH_CLPS7500" = "y" -o \
> - "$CONFIG_ARCH_TBOX" = "y" -o \
> - "$CONFIG_ARCH_SHARK" = "y" -o \
> - "$CONFIG_ARCH_SA1100" = "y" -o \
> - "$CONFIG_PCI" = "y" ]; then
> - mainmenu_option next_comment
> - comment 'Sound'
> -
> - tristate 'Sound card support' CONFIG_SOUND
> - if [ "$CONFIG_SOUND" != "n" ]; then
> - source sound/Config.in
> - fi
> - endmenu
> -fi
> -
> [...]
> -if [ "$CONFIG_DECSTATION" != "y" ]; then
> - mainmenu_option next_comment
> - comment 'Sound'
> -
> - tristate 'Sound card support' CONFIG_SOUND
> - if [ "$CONFIG_SOUND" != "n" ]; then
> - source sound/Config.in
> - fi
> - endmenu
> -fi
> -
> [...]
> +tristate 'Sound card support' CONFIG_SOUND
> +if [ "$CONFIG_SOUND" != "n" ]; then
> + source sound/Config.in
> + source sound/oss/dmasound/Config.in
> +fi
> +
> tristate 'Video For Linux' CONFIG_VIDEO_DEV
> if [ "$CONFIG_VIDEO_DEV" != "n" ]; then
> source drivers/media/video/Config.in
Perhaps you might want to be careful about losing existing behaviour.
This patch makes the following improvements:
--- s-2.5.31-sam2.txt Wed Aug 14 15:56:09 2002
+++ s-2.5.31-sam3.txt Wed Aug 14 16:24:25 2002
@@ -279,3 +279,3 @@
1 CONFIG_PCI_NAMES
-329 undeclared-symbol
+328 undeclared-symbol
76 CONFIG_OBSOLETE
@@ -294,4 +294,4 @@
11 CONFIG_SA
- 4 CONFIG_ARCH_TBOX
3 CONFIG_ARCH_FTVPCI
+ 3 CONFIG_ARCH_TBOX
2 CONFIG_ARCH_NEXUSPCI
@@ -314,3 +314,3 @@
1 CONFIG_PROC_FS
-134 forward-reference
+123 forward-reference
43 CONFIG_PROC_FS
@@ -321,3 +321,2 @@
11 CONFIG_ISDN_DRV_EICON_OLD
- 11 CONFIG_SOUND_ACI_MIXER
6 CONFIG_PCI
@@ -330,6 +329,5 @@
1 CONFIG_ZORRO
-34 forward-dependancy
+23 forward-dependancy
11 CONFIG_ISDN_CAPI
11 CONFIG_PROC_FS
- 11 CONFIG_SOUND_ACI_MIXER
1 CONFIG_BLK_DEV_SD
@@ -394,2 +392,2 @@
10 different-compound-type
-3055 total
+3032 total
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
On Tue, Aug 13, 2002 at 11:35:58PM -0500, Peter Samuelson wrote:
> The big loser here is ARM - it no longer suppresses the sound card
> question for the appropriate boards. But it's just one question, so I
> didn't sweat it too much.
I'd be tempted to drop that set of tests, and just rely on the per-driver
stuff, where its sane to do so. There's no way we can special case all
the drivers out there for each machine type in the generic config files.
That is the route to madness.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Wednesday 14 August 2002 07:49, Peter Samuelson wrote:
> [Kai Germaschewski]
> > It comes of the cost of testing for the architecture, since
> > e.g. s390 does not want to include most of drivers/*, but that means
> > we'd actually collect this knowledge at a centralized place.
>
> What we need is an easy way to check for any arch. CONFIG_ARCH_S390
> is the right idea (though s390x sets it as well, not sure if that's
> good or bad).
It's not logical, but it tends to help because it's what's meant most
of the time. I don't know a single place in the kernel where you want
to test for (CONFIG_ARCH_S390 && !CONFIG_ARCH_S390X).
Rather than making everything depend on CONFIG_ARCH_THIS && CONFIG_ARCH_THAT,
I'd prefer if every driver depended on its bus type. With the new driver
model, every driver has a clearly defined bus type and driver class,
so it would be logical to have that driver option exactly when these two
are enabled. Of course, that probably means a huge amount of work but it
helps avoid problems when a new architecture is added or an existing one
gets a new bus.
E.g., s390 used to have no support for SCSI, but with the zfcp driver
we enable drivers/scsi/Config.in, so now we get a lot of questions about
drivers that won't work. Enclosing the drivers in "CONFIG_ARCH_s390" != "y"
does help us, but it would still be wrong to do that for a Sparc kernel
that supports some of the PCI cards but not the ISA ones.
Arnd <><
On Wed, Aug 14, 2002 at 12:56:27PM +0200, Arnd Bergmann wrote:
> It's not logical, but it tends to help because it's what's meant most
> of the time. I don't know a single place in the kernel where you want
> to test for (CONFIG_ARCH_S390 && !CONFIG_ARCH_S390X).
BTW, ho much differences are between arch/s390 and arch/s390x? Is there
any chance it could use the same #ifdef __LP64__ trick parisc uses for
its 32 and 64bit versions? so far every file I've looked at was duplicated
exactly in s390 and s390x.
On Wednesday 14 August 2002 14:20, Christoph Hellwig wrote:
> On Wed, Aug 14, 2002 at 12:56:27PM +0200, Arnd Bergmann wrote:
> > It's not logical, but it tends to help because it's what's meant most
> > of the time. I don't know a single place in the kernel where you want
> > to test for (CONFIG_ARCH_S390 && !CONFIG_ARCH_S390X).
>
> BTW, ho much differences are between arch/s390 and arch/s390x? Is there
> any chance it could use the same #ifdef __LP64__ trick parisc uses for
> its 32 and 64bit versions? so far every file I've looked at was duplicated
> exactly in s390 and s390x.
The biggest differences are that s390 has an fpu emulation while s390x has
emulation for s390 binaries. These are not an issue -- just an ifdef for
the files. The other problem is that the assembly opcodes are different
-- 64 bit instructions have a 'g' in the opcode so you need two versions
of each .S file and #ifdefs for each inline asm.
The remaining differences are stuff that depends on sizeof(void*) and some
more backwards compatible system calls for s390, the diff -u between these
is ~300kb out of 500kb of the common .c files. I'd expect this to become
at least 50 #ifdefs plus some moved files (e.g. s390x/kernel/ptrace.c ->
s390/kernel/ptrace64.c) and an audit of all places where the difference
is nonobvious.
I also had the idea to unify the two (actually have tried a few months ago
but did not bring it to a clean end), but was not really sure if it was a
good one. Do you think it is worth the effort of merging the existing code
and changing all the documentation referring to arch/s390x?
We do indeed want to merge include/asm-s390 include/asm-s390x, which would
help building a compiler that supports both on s390x, but nobody has
worked on that recently -- I had done this for ~2.5.8 but it soon got
outdated.
Arnd <><
On Wed, Aug 14, 2002 at 07:21:58PM +0200, Arnd Bergmann wrote:
> I also had the idea to unify the two (actually have tried a few months ago
> but did not bring it to a clean end), but was not really sure if it was a
> good one. Do you think it is worth the effort of merging the existing code
I think it's worth the effort. Especially if IBM wants to keep the 32 (31)bit
port alife long-term. Having two codebases that are mostly the same doesn't
sound like a good idea for fix propagation to me.
> and changing all the documentation referring to arch/s390x?
How much documentation outside the kernel tree knows about it?
> We do indeed want to merge include/asm-s390 include/asm-s390x, which would
> help building a compiler that supports both on s390x,
I think it's a good idea but don't understand the compiler depency. Why
do you need asm-s390 and asm-s390x to be the same to have an compiler that
works for 32bit and 64bit mode? Today e.g. the sparc and x86 compilers
can support both modes with very different kernel headers.
I don't see how you want to make the s390x port refer to include/asm-s390
easily when ARCH is still s390x..
On Wed, Aug 14, 2002 at 11:18:13PM +0200, Arnd Bergmann wrote:
> Ok. So what happens there if a user space program e.g. does #include
> <asm/page.h>? Where does that go instead of /usr/include/asm/page.h?
First: Userspace including asm/* headers is BROKEN. But as we have lots
of broken userspace we still to have to support that for some time. The
solution is to have a wrapper that includes either asm-<b> or asm-<a>
depending on some cpp symbol. Look at redhat's old kernel rpms for an
example.
On Wednesday 14 August 2002 20:16, Christoph Hellwig wrote:
> > and changing all the documentation referring to arch/s390x?
>
> How much documentation outside the kernel tree knows about it?
There are some books about Linux on s390/zSeries that are supposed
to be kept up to date with each of our "code drops" that happen
about twice a year. There probably isn't that much reference
to "s390x" since that's not an official IBM marketing term, but
still they'd have to be audited. OTOH, there are other far bigger
documentation changes for 2.6, so having only one architecture might
actually save some duplicated work even for the documentation.
> > We do indeed want to merge include/asm-s390 include/asm-s390x, which
> > would help building a compiler that supports both on s390x,
>
> I think it's a good idea but don't understand the compiler depency. Why
> do you need asm-s390 and asm-s390x to be the same to have an compiler that
> works for 32bit and 64bit mode? Today e.g. the sparc and x86 compilers
> can support both modes with very different kernel headers.
Ok. So what happens there if a user space program e.g. does #include
<asm/page.h>? Where does that go instead of /usr/include/asm/page.h?
Arnd <><
On Wednesday 14 August 2002 21:22, Christoph Hellwig wrote:
> On Wed, Aug 14, 2002 at 11:18:13PM +0200, Arnd Bergmann wrote:
> > Ok. So what happens there if a user space program e.g. does #include
> > <asm/page.h>? Where does that go instead of /usr/include/asm/page.h?
>
> First: Userspace including asm/* headers is BROKEN. But as we have lots
> of broken userspace we still to have to support that for some time. The
And since in particular glibc is still part of this brokenness, every
sufficiently large user space program accesses them in some way...
> solution is to have a wrapper that includes either asm-<b> or asm-<a>
> depending on some cpp symbol. Look at redhat's old kernel rpms for an
> example.
ok, so it does not work with the default kernel headers copied to
/usr/include but some extra tweaking. Making the two include/asm-*/ trees
identical is just another way of getting to the same result.
Arnd <><