IA64_GENERIC shouldn't select other stuff.
select'ing ACPI without select'ing PCI had broken ACPI in the past (the
current workaround is that ACPI select's PCI).
Select'ing NUMA means that the illegal configuration NUMA=y, FLATMEM=y
is possible.
The generic setting might be required in some places, but select'ing
some options like NUMA while not select'ing some other similar
important options like PCI doesn't make much sense.
Signed-off-by: Adrian Bunk <[email protected]>
--- linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig.old 2006-02-07 23:07:29.000000000 +0100
+++ linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig 2006-02-07 23:07:55.000000000 +0100
@@ -72,9 +72,6 @@
config IA64_GENERIC
bool "generic"
- select ACPI
- select NUMA
- select ACPI_NUMA
help
This selects the system type of your hardware. A "generic" kernel
will run on any supported IA-64 system. However, if you configure
Adrian Bunk (on Tue, 7 Feb 2006 23:11:57 +0100) wrote:
>IA64_GENERIC shouldn't select other stuff.
>
>select'ing ACPI without select'ing PCI had broken ACPI in the past (the
>current workaround is that ACPI select's PCI).
>
>Select'ing NUMA means that the illegal configuration NUMA=y, FLATMEM=y
>is possible.
>
>The generic setting might be required in some places, but select'ing
>some options like NUMA while not select'ing some other similar
>important options like PCI doesn't make much sense.
>
>
>Signed-off-by: Adrian Bunk <[email protected]>
>
>--- linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig.old 2006-02-07 23:07:29.000000000 +0100
>+++ linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig 2006-02-07 23:07:55.000000000 +0100
>@@ -72,9 +72,6 @@
>
> config IA64_GENERIC
> bool "generic"
>- select ACPI
>- select NUMA
>- select ACPI_NUMA
> help
> This selects the system type of your hardware. A "generic" kernel
> will run on any supported IA-64 system. However, if you configure
>
A generic IA64 kernel requires (at least) the ACPI and NUMA options in
order to run on all the IA64 platforms out there. Omitting those
options and relying on the user to set them by hand is going to cause
more problems.
If anything, there should be more options being set as a side effect of
selecting IA64_GENERIC, including ARCH_DISCONTIGMEM_ENABLE,
ARCH_SPARSEMEM_ENABLE, PCI and even SMP.
On Wed, Feb 08, 2006 at 09:37:11AM +1100, Keith Owens wrote:
> A generic IA64 kernel requires (at least) the ACPI and NUMA options in
> order to run on all the IA64 platforms out there. Omitting those
> options and relying on the user to set them by hand is going to cause
> more problems.
I'm not sure about that. If the user selects a specific type of machine,
ACPI doesn't get selected for them -- even when it's needed to boot.
It's certainly inconsistent and should be fixed one way or the other.
On Tue, Feb 07, 2006 at 03:43:44PM -0700, Matthew Wilcox wrote:
> On Wed, Feb 08, 2006 at 09:37:11AM +1100, Keith Owens wrote:
> > A generic IA64 kernel requires (at least) the ACPI and NUMA options in
> > order to run on all the IA64 platforms out there. Omitting those
> > options and relying on the user to set them by hand is going to cause
> > more problems.
>
> I'm not sure about that. If the user selects a specific type of machine,
> ACPI doesn't get selected for them -- even when it's needed to boot.
> It's certainly inconsistent and should be fixed one way or the other.
And PCI is never selected for him with IA64_GENERIC.
I see the point for a catch-all option for processor-specific stuff, but
it can't be a replacement for allyesconfig.
AFAIR your defconfig was intended for the "runs everywhere" case (with
the exception that in this case the bug that CONFIG_ITANIUM is not set
is still unfixed - would you accept a patch to fix this?).
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
> AFAIR your defconfig was intended for the "runs everywhere" case (with
> the exception that in this case the bug that CONFIG_ITANIUM is not set
> is still unfixed - would you accept a patch to fix this?).
Only die-hard early adopters are still using CONFIG_ITANIUM systems, and
they have the knowledge to turn this option on. So no, I'm not looking
for a patch to add this to defconfig.
-Tony
Adrian Bunk wrote on Tuesday, February 07, 2006 3:17 PM
> IOW, you want the patch below?
>
No, I really don't think so.
> --- linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig.old
> +++ linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig
> @@ -132,10 +134,11 @@
> This choice is safe for all IA-64 systems, but may not perform
> optimally on systems with, say, Itanium 2 or newer processors.
>
> config MCKINLEY
> bool "Itanium 2"
> + depends on IA64_GENERIC=n
> help
> Select this to configure for an Itanium 2 (McKinley) processor.
>
> endchoice
>
This hunk does not make any logical sense. Select generic system type
does not mean Itanium processor is the only choice I can have. What's
wrong with having an option that works just fine right now?
- Ken
On Wed, Feb 08, 2006 at 09:37:11AM +1100, Keith Owens wrote:
>
> A generic IA64 kernel requires (at least) the ACPI and NUMA options in
> order to run on all the IA64 platforms out there. Omitting those
> options and relying on the user to set them by hand is going to cause
> more problems.
>
> If anything, there should be more options being set as a side effect of
> selecting IA64_GENERIC, including ARCH_DISCONTIGMEM_ENABLE,
> ARCH_SPARSEMEM_ENABLE, PCI and even SMP.
IOW, you want the patch below?
Not that I'm a big fan of this approach, but if it should be done this
way, it should be done right.
cu
Adrian
<-- snip -->
Let IA64_GENERIC select more stuff (as wanted by the ia64 developers).
Signed-off-by: Adrian Bunk <[email protected]>
--- linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig.old 2006-02-07 23:07:29.000000000 +0100
+++ linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig 2006-02-08 00:13:58.000000000 +0100
@@ -73,10 +73,12 @@
config IA64_GENERIC
bool "generic"
select ACPI
select NUMA
select ACPI_NUMA
+ select PCI
+ select SMP
help
This selects the system type of your hardware. A "generic" kernel
will run on any supported IA-64 system. However, if you configure
a kernel for your specific system, it will be faster and smaller.
@@ -132,10 +134,11 @@
This choice is safe for all IA-64 systems, but may not perform
optimally on systems with, say, Itanium 2 or newer processors.
config MCKINLEY
bool "Itanium 2"
+ depends on IA64_GENERIC=n
help
Select this to configure for an Itanium 2 (McKinley) processor.
endchoice
@@ -318,11 +321,11 @@
for architectures which are either NUMA (Non-Uniform Memory Access)
or have huge holes in the physical address space for other reasons.
See <file:Documentation/vm/numa> for more.
config ARCH_FLATMEM_ENABLE
- def_bool y
+ def_bool y if IA64_GENERIC=n
config ARCH_SPARSEMEM_ENABLE
def_bool y
depends on ARCH_DISCONTIGMEM_ENABLE
On Tue, Feb 07, 2006 at 04:52:59PM -0800, Chen, Kenneth W wrote:
> Adrian Bunk wrote on Tuesday, February 07, 2006 3:17 PM
> > IOW, you want the patch below?
> >
>
> No, I really don't think so.
>
>
> > --- linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig.old
> > +++ linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig
> > @@ -132,10 +134,11 @@
> > This choice is safe for all IA-64 systems, but may not perform
> > optimally on systems with, say, Itanium 2 or newer processors.
> >
> > config MCKINLEY
> > bool "Itanium 2"
> > + depends on IA64_GENERIC=n
> > help
> > Select this to configure for an Itanium 2 (McKinley) processor.
> >
> > endchoice
> >
>
> This hunk does not make any logical sense. Select generic system type
> does not mean Itanium processor is the only choice I can have. What's
> wrong with having an option that works just fine right now?
You could ask the same question for NUMA:
Select generic system type does not mean NUMA systems are only choice I
can have. What's wrong with having an option that works just fine?
Keith said IA64_GENERIC should select all the options required in order
to run on all the IA64 platforms out there.
This is what my patch does.
> - Ken
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
Adrian Bunk wrote on Tuesday, February 07, 2006 5:20 PM
> You could ask the same question for NUMA:
> Select generic system type does not mean NUMA systems are only choice I
> can have. What's wrong with having an option that works just fine?
Please read more ia64 arch specific code ...
CONFIG_IA64_GENERIC is a platform type choice, you can have platform
type of DIG, HPZX1, SGI SN2, or all of the above. DIG platform depends
on ACPI, thus need ACPI on. SGI altix is a numa box, thus, need NUMA
on. NEC, Fujitsu build numa machines with ACPI SRAT table, thus, need
ACPI_NUMA on. When you build a kernel to boot on all platforms, you
have no choice but to turn on all of the above. Processor type and SMP
is different from platform type. It does not have any dependency on
platform type. They are orthogonal choice.
> Keith said IA64_GENERIC should select all the options required in
> order to run on all the IA64 platforms out there.
^^^^^^^^^^^^^^
> This is what my patch does.
You patch does more than what you described and is wrong. Selecting
platform type should not be tied into selecting SMP nor should it tied
with processor type, nor should it tied with ARCH_FLATMEM_ENABLE. All
of them are orthogonal and independent.
Theoretically and maybe academically interesting, I should be able to
build a kernel that boots on all UP platforms, with your patch, that
is not possible.
- Ken
On Tue, Feb 07, 2006 at 05:40:13PM -0800, Chen, Kenneth W wrote:
> Adrian Bunk wrote on Tuesday, February 07, 2006 5:20 PM
> > You could ask the same question for NUMA:
> > Select generic system type does not mean NUMA systems are only choice I
> > can have. What's wrong with having an option that works just fine?
>
> Please read more ia64 arch specific code ...
>
> CONFIG_IA64_GENERIC is a platform type choice, you can have platform
> type of DIG, HPZX1, SGI SN2, or all of the above. DIG platform depends
> on ACPI, thus need ACPI on. SGI altix is a numa box, thus, need NUMA
> on. NEC, Fujitsu build numa machines with ACPI SRAT table, thus, need
> ACPI_NUMA on. When you build a kernel to boot on all platforms, you
> have no choice but to turn on all of the above. Processor type and SMP
> is different from platform type. It does not have any dependency on
> platform type. They are orthogonal choice.
This is interesting, considering that e.g. IA64_SGI_SN2=y, NUMA=n or
IA64_DIG=y, ACPI=n are currently allowed configurations.
> > Keith said IA64_GENERIC should select all the options required in
> > order to run on all the IA64 platforms out there.
> ^^^^^^^^^^^^^^
> > This is what my patch does.
>
> You patch does more than what you described and is wrong. Selecting
> platform type should not be tied into selecting SMP nor should it tied
This was what Keith wanted.
It seems everyone thinks I am wrong, but when I'm implementing what one
person suggests, other people say that what I am doing is wrong.
> with processor type, nor should it tied with ARCH_FLATMEM_ENABLE. All
> of them are orthogonal and independent.
1. NUMA on ia64 currently depends on !FLATMEM.
2. IA64_GENERIC currently select's NUMA.
3. You say IA64_GENERIC should not be tied with ARCH_FLATMEM_ENABLE.
It's impossible to fulfill all three of them.
My initial approach to fix them was to remove the select's from
IA64_GENERIC, therefore removing 2., but this patch was not accepted.
This patch adds more select's to IA64_GENERIC, therefore removing 3.,
but you disagree with it.
The last choice it to remove the dependency of NUMA on !FLATMEM... ;-)
> Theoretically and maybe academically interesting, I should be able to
> build a kernel that boots on all UP platforms, with your patch, that
> is not possible.
Theoretically and maybe academically interesting, I should be able to
build a kernel that boots on all non-NUMA platforms, currently, that is
not possible.
> - Ken
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
Adrian Bunk wrote on Tuesday, February 07, 2006 6:09 PM
> > CONFIG_IA64_GENERIC is a platform type choice, you can have platform
> > type of DIG, HPZX1, SGI SN2, or all of the above. DIG platform depends
> > on ACPI, thus need ACPI on. SGI altix is a numa box, thus, need NUMA
> > on. NEC, Fujitsu build numa machines with ACPI SRAT table, thus, need
> > ACPI_NUMA on. When you build a kernel to boot on all platforms, you
> > have no choice but to turn on all of the above. Processor type and SMP
> > is different from platform type. It does not have any dependency on
> > platform type. They are orthogonal choice.
>
> This is interesting, considering that e.g. IA64_SGI_SN2=y, NUMA=n or
> IA64_DIG=y, ACPI=n are currently allowed configurations.
Right, that is what Matthew Wilcox said in earlier thread.
> > > Keith said IA64_GENERIC should select all the options required in
> > > order to run on all the IA64 platforms out there.
> > ^^^^^^^^^^^^^^
> > > This is what my patch does.
> >
> > You patch does more than what you described and is wrong. Selecting
> > platform type should not be tied into selecting SMP nor should it tied
>
> This was what Keith wanted.
>
> It seems everyone thinks I am wrong, but when I'm implementing what one
> person suggests, other people say that what I am doing is wrong.
You have to digest what people say and *understand* why they said what they
say. Checking earlier thread, Keith did not say "select CONFIG_ITANIUM
for generic ia64 platforms".
> > Theoretically and maybe academically interesting, I should be able to
> > build a kernel that boots on all UP platforms, with your patch, that
> > is not possible.
>
> Theoretically and maybe academically interesting, I should be able to
> build a kernel that boots on all non-NUMA platforms, currently, that is
> not possible.
This is going too far and very childish in my opinion. I'm going to shut
up.
- Ken
On Tue, Feb 07, 2006 at 06:17:47PM -0800, Chen, Kenneth W wrote:
> Adrian Bunk wrote on Tuesday, February 07, 2006 6:09 PM
> > > CONFIG_IA64_GENERIC is a platform type choice, you can have platform
> > > type of DIG, HPZX1, SGI SN2, or all of the above. DIG platform depends
> > > on ACPI, thus need ACPI on. SGI altix is a numa box, thus, need NUMA
> > > on. NEC, Fujitsu build numa machines with ACPI SRAT table, thus, need
> > > ACPI_NUMA on. When you build a kernel to boot on all platforms, you
> > > have no choice but to turn on all of the above. Processor type and SMP
> > > is different from platform type. It does not have any dependency on
> > > platform type. They are orthogonal choice.
> >
> > This is interesting, considering that e.g. IA64_SGI_SN2=y, NUMA=n or
> > IA64_DIG=y, ACPI=n are currently allowed configurations.
>
> Right, that is what Matthew Wilcox said in earlier thread.
>
>
> > > > Keith said IA64_GENERIC should select all the options required in
> > > > order to run on all the IA64 platforms out there.
> > > ^^^^^^^^^^^^^^
> > > > This is what my patch does.
> > >
> > > You patch does more than what you described and is wrong. Selecting
> > > platform type should not be tied into selecting SMP nor should it tied
> >
> > This was what Keith wanted.
> >
> > It seems everyone thinks I am wrong, but when I'm implementing what one
> > person suggests, other people say that what I am doing is wrong.
>
> You have to digest what people say and *understand* why they said what they
> say. Checking earlier thread, Keith did not say "select CONFIG_ITANIUM
> for generic ia64 platforms".
>...
Keith suggested that IA64_GENERIC should select SMP, and this is what
you disagreed with.
And I'm still interested in your suggestion for the
IA64_GENERIC<->NUMA<->FLATMEM dependencies.
> - Ken
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
"Chen, Kenneth W" (on Tue, 7 Feb 2006 17:40:13 -0800) wrote:
>Adrian Bunk wrote on Tuesday, February 07, 2006 5:20 PM
>> You could ask the same question for NUMA:
>> Select generic system type does not mean NUMA systems are only choice I
>> can have. What's wrong with having an option that works just fine?
>
>Please read more ia64 arch specific code ...
>
>CONFIG_IA64_GENERIC is a platform type choice, you can have platform
>type of DIG, HPZX1, SGI SN2, or all of the above. DIG platform depends
>on ACPI, thus need ACPI on. SGI altix is a numa box, thus, need NUMA
>on. NEC, Fujitsu build numa machines with ACPI SRAT table, thus, need
>ACPI_NUMA on. When you build a kernel to boot on all platforms, you
>have no choice but to turn on all of the above. Processor type and SMP
>is different from platform type. It does not have any dependency on
>platform type. They are orthogonal choice.
>
>
>> Keith said IA64_GENERIC should select all the options required in
>> order to run on all the IA64 platforms out there.
> ^^^^^^^^^^^^^^
>> This is what my patch does.
>
>You patch does more than what you described and is wrong. Selecting
>platform type should not be tied into selecting SMP nor should it tied
>with processor type, nor should it tied with ARCH_FLATMEM_ENABLE. All
>of them are orthogonal and independent.
Blame me for the SMP bit. I have a dim, distant memory that Intel
required all IA64 boxes to be SMP, but I could be wrong. Also it is
almost pointless to do a generic build which pulls in NUMA etc.,
without also including SMP.
On Wed, Feb 08, 2006 at 01:48:10PM +1100, Keith Owens wrote:
> Blame me for the SMP bit. I have a dim, distant memory that Intel
> required all IA64 boxes to be SMP, but I could be wrong. Also it is
The HP zx2000 is a single socket workstation, and you can buy other HP
workstations/servers with only one socket occupied.
Keith Owens wrote on Tuesday, February 07, 2006 6:48 PM
> >You patch does more than what you described and is wrong. Selecting
> >platform type should not be tied into selecting SMP nor should it tied
> >with processor type, nor should it tied with ARCH_FLATMEM_ENABLE. All
> >of them are orthogonal and independent.
>
> Blame me for the SMP bit. I have a dim, distant memory that Intel
> required all IA64 boxes to be SMP, but I could be wrong. Also it is
> almost pointless to do a generic build which pulls in NUMA etc.,
> without also including SMP.
I'm not disagreeing with the SMP bit. In my very first reply, I
disagree with the hunk that disable CONFIG_MCKINLEY for CONFIG_IA64_GENERIC.
People tends to mix the terminology, CONFIG_IA64_GENERIC is a
platform type choice, it is a sub-requirement for building a
kernel that boots everywhere. People keeps on promoting the
config option.
- Ken
Excerpt from earlier email:
> --- linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig.old
> +++ linux-2.6.16-rc1-mm5-ia64/arch/ia64/Kconfig
> @@ -132,10 +134,11 @@
> This choice is safe for all IA-64 systems, but may not perform
> optimally on systems with, say, Itanium 2 or newer processors.
>
> config MCKINLEY
> bool "Itanium 2"
> + depends on IA64_GENERIC=n
> help
> Select this to configure for an Itanium 2 (McKinley) processor.
>
> endchoice
>
This hunk does not make any logical sense. Select generic system type
does not mean Itanium processor is the only choice I can have. What's
wrong with having an option that works just fine right now?
On Tue, Feb 07, 2006 at 06:58:42PM -0800, Chen, Kenneth W wrote:
>...
> > >You patch does more than what you described and is wrong. Selecting
> > >platform type should not be tied into selecting SMP nor should it tied
>...
> I'm not disagreeing with the SMP bit. In my very first reply, I
>...
It might be related to the fact that I'm not a native English speaker,
but for me this reads as if you contradict yourself, and I have
therefore problems understanding your emails.
> - Ken
>...
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
> > > >You patch does more than what you described and is wrong. Selecting
> > > >platform type should not be tied into selecting SMP nor should it tied
> >...
> > I'm not disagreeing with the SMP bit. In my very first reply, I
> >...
>
> It might be related to the fact that I'm not a native English speaker,
> but for me this reads as if you contradict yourself, and I have
> therefore problems understanding your emails.
Yeah, I've been flip-flopping on CONFIG_SMP. I just don't have strong
opinion one way or the other. Having said that, I don't think we should
mix the CONFIG_IA64_GENERIC, which is defined to select platform type
with smp/processor type etc.
But for the bit that this thread started, which disables CONFIG_MCKINLEY
for CONFIG_IA64_GENERIC, it is totally wrong and is the "over my dead
body" type of thing.
- Ken
On Tue, Feb 07, 2006 at 09:52:09PM -0800, Chen, Kenneth W wrote:
> > > > >You patch does more than what you described and is wrong. Selecting
> > > > >platform type should not be tied into selecting SMP nor should it tied
> > >...
> > > I'm not disagreeing with the SMP bit. In my very first reply, I
> > >...
> >
> > It might be related to the fact that I'm not a native English speaker,
> > but for me this reads as if you contradict yourself, and I have
> > therefore problems understanding your emails.
>
> Yeah, I've been flip-flopping on CONFIG_SMP. I just don't have strong
> opinion one way or the other. Having said that, I don't think we should
> mix the CONFIG_IA64_GENERIC, which is defined to select platform type
> with smp/processor type etc.
>
> But for the bit that this thread started, which disables CONFIG_MCKINLEY
> for CONFIG_IA64_GENERIC, it is totally wrong and is the "over my dead
> body" type of thing.
My initial patch that started this thread was to remove all select's
from CONFIG_IA64_GENERIC.
Is this OK for you?
> - Ken
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
>>>>> "Adrian" == Adrian Bunk <[email protected]> writes:
Adrian> On Tue, Feb 07, 2006 at 09:52:09PM -0800, Chen, Kenneth W
Adrian> wrote:
>> But for the bit that this thread started, which disables
>> CONFIG_MCKINLEY for CONFIG_IA64_GENERIC, it is totally wrong and is
>> the "over my dead body" type of thing.
Adrian> My initial patch that started this thread was to remove all
Adrian> select's from CONFIG_IA64_GENERIC.
Adrian> Is this OK for you?
Adrian,
Not really, it helps a bit by selecting some things we know we need
for all GENERIC builds. True we can't make it bullet proof, but whats
there is better than removing it.
Jes
Adrian> Is this OK for you?
Jes> Not really, it helps a bit by selecting some things we know we need
Jes> for all GENERIC builds. True we can't make it bullet proof, but whats
Jes> there is better than removing it.
Which I think sums up why this is so contentious. There is no right answer
here as the purpose of the GENERIC entry is rather vague and has been
interpreted differently by different people. Mostly it is a convenience
entry that auto-selects a bunch of other config options, but there isn't
a single answer to what it should select, as different people have different
goals, so what might be convenient for one person would be a pain for
someone else.
The current set looks close ... perhaps PCI should be added as it isn't
likely to inconvenience anyone, but SMP is a lot further into murky territory
(some distributors like to use a UP kernel for installation ... so they
want a "generic" kernel, but don't need to worry about SMP ... there are few
places where SMP would be advantageous during install).
-Tony
On Wed, 2006-02-08 at 10:35 -0800, Luck, Tony wrote:
> The current set looks close ... perhaps PCI should be added as it isn't
> likely to inconvenience anyone, but SMP is a lot further into murky territory
Seems like maybe PCI was removed so that it was possible to configure
a generic kernel to boot on the simulator... I could imagine not having
PCI might have some degree of usefulness when using a ramdisk. Isn't
this what the defconfigs are for?
Alex
--
Alex Williamson HP Linux & Open Source Lab
Alex Williamson wrote:
> On Wed, 2006-02-08 at 10:35 -0800, Luck, Tony wrote:
>
>
>>The current set looks close ... perhaps PCI should be added as it isn't
>>likely to inconvenience anyone, but SMP is a lot further into murky territory
>
>
> Seems like maybe PCI was removed so that it was possible to configure
> a generic kernel to boot on the simulator... I could imagine not having
> PCI might have some degree of usefulness when using a ramdisk. Isn't
> this what the defconfigs are for?
Hi Alex,
That could explain it, but the question is whether one would want to
boot a generic kernel when running on a simulator. After all then every
cycle does count ;)
Anyway I think we're down nit picking in details. My vote is for
preserving status quo.
Cheers,
Jes
> That could explain it, but the question is whether one would want to
> boot a generic kernel when running on a simulator. After all then every
> cycle does count ;)
You might if you wanted to use the simulator to debug a problem that
only showed up in a generic kernel.
-Tony
Jes Sorensen wrote on Wednesday, February 08, 2006 11:24 AM
> > Seems like maybe PCI was removed so that it was possible to configure
> > a generic kernel to boot on the simulator... I could imagine not having
> > PCI might have some degree of usefulness when using a ramdisk. Isn't
> > this what the defconfigs are for?
> > That could explain it, but the question is whether one would want to
>
> boot a generic kernel when running on a simulator. After all then every
> cycle does count ;)
CONFIG_IA64_GENERIC select CONFIG_ACPI, and CONFIG_ACPI select CONFIG_PCI,
This whole thread is silly since the beginning and it is a moot point for
all of previous discussions. What are we talking about exactly??
- Ken
On Wed, Feb 08, 2006 at 11:55:58AM -0800, Chen, Kenneth W wrote:
> CONFIG_IA64_GENERIC select CONFIG_ACPI, and CONFIG_ACPI select CONFIG_PCI,
> This whole thread is silly since the beginning and it is a moot point for
> all of previous discussions. What are we talking about exactly??
I think the problem is that ia64 is abusing the 'select' feature.
Select is a reverse dependency. It should be used to turn things on
which are required for this option to work. Right now, the generic
config uses it to turn on things which people think you probably want
if you're building a generic kernel.
IMO, the select statements should be deleted. They make it impossible to
build a generic kernel without ACPI or NUMA. While both are ubiquitous
in ia64 implementations, they really aren't mandatory.
On Wed, Feb 08, 2006 at 08:38:57AM -0500, Jes Sorensen wrote:
> >>>>> "Adrian" == Adrian Bunk <[email protected]> writes:
>
> Adrian> On Tue, Feb 07, 2006 at 09:52:09PM -0800, Chen, Kenneth W
> Adrian> wrote:
> >> But for the bit that this thread started, which disables
> >> CONFIG_MCKINLEY for CONFIG_IA64_GENERIC, it is totally wrong and is
> >> the "over my dead body" type of thing.
>
> Adrian> My initial patch that started this thread was to remove all
> Adrian> select's from CONFIG_IA64_GENERIC.
>
> Adrian> Is this OK for you?
>
> Adrian,
>
> Not really, it helps a bit by selecting some things we know we need
> for all GENERIC builds. True we can't make it bullet proof, but whats
> there is better than removing it.
Like the bug of allowing the illegal configuration NUMA=y, FLATMEM=y?
> Jes
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
Matthew Wilcox wrote on Wednesday, February 08, 2006 1:24 PM
> On Wed, Feb 08, 2006 at 11:55:58AM -0800, Chen, Kenneth W wrote:
> > CONFIG_IA64_GENERIC select CONFIG_ACPI, and CONFIG_ACPI select CONFIG_PCI,
> > This whole thread is silly since the beginning and it is a moot point for
> > all of previous discussions. What are we talking about exactly??
>
> I think the problem is that ia64 is abusing the 'select' feature.
> Select is a reverse dependency. It should be used to turn things on
> which are required for this option to work. Right now, the generic
> config uses it to turn on things which people think you probably want
> if you're building a generic kernel.
>
> IMO, the select statements should be deleted. They make it impossible to
> build a generic kernel without ACPI or NUMA. While both are ubiquitous
> in ia64 implementations, they really aren't mandatory.
Things are mangled so badly that you can't even compile a generic kernel
after deselecting ACPI.
Adrian Bunk wrote on Wednesday, February 08, 2006 1:38 PM
> > Not really, it helps a bit by selecting some things we know we need
> > for all GENERIC builds. True we can't make it bullet proof, but whats
> > there is better than removing it.
>
> Like the bug of allowing the illegal configuration NUMA=y, FLATMEM=y?
You can't even compile a kernel with that combination ...
Just about every arch except ia64 turns off ARCH_FLATMEM_ENABLE if NUMA=y.
ia64 can just do the same thing. Instead of mucking around with select,
fix the bug at its source. The real culprit is in mm/Kconfig, it shouldn't
enable ARCH_FLATMEM_ENABLE if NUMA=y.
Fix ARCH_FLATMEM_ENABLE dependency in ia64 arch.
Signed-off-by: Ken Chen <[email protected]>
--- ./arch/ia64/Kconfig.orig 2006-02-08 14:57:40.597354431 -0800
+++ ./arch/ia64/Kconfig 2006-02-08 15:04:15.552427718 -0800
@@ -298,7 +298,8 @@ config ARCH_DISCONTIGMEM_ENABLE
See <file:Documentation/vm/numa> for more.
config ARCH_FLATMEM_ENABLE
- def_bool y
+ depends on !NUMA
+ def_bool y if !NUMA
config ARCH_SPARSEMEM_ENABLE
def_bool y
Drifting a little (perhaps). "make allnoconfig" produces
a config that doesn't compile. Lots or warnings during compile
about implicit declaration of ia64_pfn_valid. Then link errors
for vmem_map and ia64_pfn_valid.
What's the right thing to do about this? It's been broken for a
long time (definitely since SPARSE support was added, perhaps longer).
-Tony
On Wed, Feb 08, 2006 at 02:24:51PM -0800, Chen, Kenneth W wrote:
> Adrian Bunk wrote on Wednesday, February 08, 2006 1:38 PM
> > > Not really, it helps a bit by selecting some things we know we need
> > > for all GENERIC builds. True we can't make it bullet proof, but whats
> > > there is better than removing it.
> >
> > Like the bug of allowing the illegal configuration NUMA=y, FLATMEM=y?
>
>
> You can't even compile a kernel with that combination ...
> Just about every arch except ia64 turns off ARCH_FLATMEM_ENABLE if NUMA=y.
> ia64 can just do the same thing. Instead of mucking around with select,
> fix the bug at its source. The real culprit is in mm/Kconfig, it shouldn't
> enable ARCH_FLATMEM_ENABLE if NUMA=y.
No, the bug is exactly the part of arch/ia64/Kconfig you are patching,
because mm/Kconfig simply relies on architectures setting the right
dependencies for ARCH_FLATMEM_ENABLE.
> Fix ARCH_FLATMEM_ENABLE dependency in ia64 arch.
>
> Signed-off-by: Ken Chen <[email protected]>
>
> --- ./arch/ia64/Kconfig.orig 2006-02-08 14:57:40.597354431 -0800
> +++ ./arch/ia64/Kconfig 2006-02-08 15:04:15.552427718 -0800
> @@ -298,7 +298,8 @@ config ARCH_DISCONTIGMEM_ENABLE
> See <file:Documentation/vm/numa> for more.
>
> config ARCH_FLATMEM_ENABLE
> - def_bool y
> + depends on !NUMA
> + def_bool y if !NUMA
>...
Only one of the two NUMA dependencies is required.
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
>>>>> "Adrian" == Adrian Bunk <[email protected]> writes:
Adrian> On Wed, Feb 08, 2006 at 08:38:57AM -0500, Jes Sorensen wrote:
>> Not really, it helps a bit by selecting some things we know we need
>> for all GENERIC builds. True we can't make it bullet proof, but
>> whats there is better than removing it.
Adrian> Like the bug of allowing the illegal configuration NUMA=y,
Adrian> FLATMEM=y?
Adrian,
There's other reasons why this is a moot exercise anyway, allyesconfig
doesn't link on ia64 due to the size of the object exceeding the reach
of the relative link relocs. Not much you can do about that.
Here's a patch that will make it all build until it tries to link. It
includes a simplified version of Ken's patch. Now can we please
dismiss this issue once and for all and go back to getting real work
done?
Tony, would you apply at least the part of this touching
arch/ia64/Kconfig if you do not fancy taking it all, please.
Thanks,
Jes
Various fixes to help allyesconfig on ia64:
- ARCH_FLATMEM_ENABLE is incompatible with NUMA
- atm code tries to include kernel headers to decide upon byteorder
without allowing for said header file to include other files
- HP100 driver cannot be compiled on systems without ISA support in it's
current state.
- Add check_signature() to include/asm-ia64/io.h
- Include vmalloc.h in mixart_hwdep.c which uses vmalloc
Signed-off-by: Jes Sorensen <[email protected]>
----
arch/ia64/Kconfig | 1 +
drivers/atm/Makefile | 2 +-
drivers/net/Kconfig | 2 +-
include/asm-ia64/io.h | 15 +++++++++++++++
sound/pci/mixart/mixart_hwdep.c | 1 +
5 files changed, 19 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/ia64/Kconfig
===================================================================
--- linux-2.6.orig/arch/ia64/Kconfig
+++ linux-2.6/arch/ia64/Kconfig
@@ -297,6 +297,7 @@
See <file:Documentation/vm/numa> for more.
config ARCH_FLATMEM_ENABLE
+ depends on !NUMA
def_bool y
config ARCH_SPARSEMEM_ENABLE
Index: linux-2.6/drivers/atm/Makefile
===================================================================
--- linux-2.6.orig/drivers/atm/Makefile
+++ linux-2.6/drivers/atm/Makefile
@@ -41,7 +41,7 @@
# guess the target endianess to choose the right PCA-200E firmware image
ifeq ($(CONFIG_ATM_FORE200E_PCA_DEFAULT_FW),y)
byteorder.h := include$(if $(patsubst $(srctree),,$(objtree)),2)/asm/byteorder.h
- CONFIG_ATM_FORE200E_PCA_FW := $(obj)/pca200e$(if $(shell $(CC) -E -dM $(byteorder.h) | grep ' __LITTLE_ENDIAN '),.bin,_ecd.bin2)
+ CONFIG_ATM_FORE200E_PCA_FW := $(obj)/pca200e$(if $(shell $(CC) -I$(srctree)/include -E -dM $(byteorder.h) | grep ' __LITTLE_ENDIAN '),.bin,_ecd.bin2)
endif
endif
Index: linux-2.6/drivers/net/Kconfig
===================================================================
--- linux-2.6.orig/drivers/net/Kconfig
+++ linux-2.6/drivers/net/Kconfig
@@ -946,7 +946,7 @@
config HP100
tristate "HP 10/100VG PCLAN (ISA, EISA, PCI) support"
- depends on NET_ETHERNET && (ISA || EISA || PCI)
+ depends on NET_ETHERNET && ISA || EISA
help
If you have a network (Ethernet) card of this type, say Y and read
the Ethernet-HOWTO, available from
Index: linux-2.6/include/asm-ia64/io.h
===================================================================
--- linux-2.6.orig/include/asm-ia64/io.h
+++ linux-2.6/include/asm-ia64/io.h
@@ -435,6 +435,21 @@
#define ioremap_nocache(o,s) ioremap(o,s)
+static inline int
+check_signature(void __iomem *io_addr, const unsigned char *signature,
+ int length)
+{
+ int retval = 0;
+ do {
+ if (readb(io_addr) != *signature++)
+ goto out;
+ io_addr++;
+ } while (--length);
+ retval = 1;
+ out:
+ return retval;
+}
+
# ifdef __KERNEL__
/*
Index: linux-2.6/sound/pci/mixart/mixart_hwdep.c
===================================================================
--- linux-2.6.orig/sound/pci/mixart/mixart_hwdep.c
+++ linux-2.6/sound/pci/mixart/mixart_hwdep.c
@@ -24,6 +24,7 @@
#include <linux/interrupt.h>
#include <linux/pci.h>
#include <linux/firmware.h>
+#include <linux/vmalloc.h>
#include <asm/io.h>
#include <sound/core.h>
#include "mixart.h"
On Thu, Feb 09, 2006 at 07:53:11AM -0500, Jes Sorensen wrote:
> There's other reasons why this is a moot exercise anyway, allyesconfig
> doesn't link on ia64 due to the size of the object exceeding the reach
> of the relative link relocs. Not much you can do about that.
That'd be a toolchain problem then ... need to insert stubs.
> - HP100 driver cannot be compiled on systems without ISA support in it's
> current state.
I have it enabled on parisc without ISA or EISA. More details, please.
> config HP100
> tristate "HP 10/100VG PCLAN (ISA, EISA, PCI) support"
> - depends on NET_ETHERNET && (ISA || EISA || PCI)
> + depends on NET_ETHERNET && ISA || EISA
> help
Also I think this is wrong. Doesn't the precedence make this evaluate
as (NET_ETHERNET && ISA) || EISA ?
>>>>> "Matthew" == Matthew Wilcox <[email protected]> writes:
Matthew> On Thu, Feb 09, 2006 at 07:53:11AM -0500, Jes Sorensen wrote:
>> There's other reasons why this is a moot exercise anyway,
>> allyesconfig doesn't link on ia64 due to the size of the object
>> exceeding the reach of the relative link relocs. Not much you can
>> do about that.
Matthew> That'd be a toolchain problem then ... need to insert stubs.
True, but I think there's a special flag people need to use when
linking large userland apps. No idea if it could work for the kernel
in this case.
>> - HP100 driver cannot be compiled on systems without ISA support in
>> it's current state.
Matthew> I have it enabled on parisc without ISA or EISA. More
Matthew> details, please.
Generous use of isa_memcpy_toio, isa_readb etc. Those functions ought
not be visible in a config where ISA is disabled. Anybody who cares
enough about this could easily fix the HP100 driver to deal with it,
but it would require some reorganization of the code.
>> config HP100 tristate "HP 10/100VG PCLAN (ISA, EISA, PCI) support"
>> - depends on NET_ETHERNET && (ISA || EISA || PCI) + depends on
>> NET_ETHERNET && ISA || EISA help
Matthew> Also I think this is wrong. Doesn't the precedence make this
Matthew> evaluate as (NET_ETHERNET && ISA) || EISA ?
Thats me being stupid, the parenthesis should have stayed.
Updated patch attached.
Cheers,
Jes
Various fixes to help allyesconfig on ia64:
- ARCH_FLATMEM_ENABLE is incompatible with NUMA
- atm code tries to include kernel headers to decide upon byteorder
without allowing for said header file to include other files
- HP100 driver cannot be compiled on systems without ISA support in it's
current state.
- Add check_signature() to include/asm-ia64/io.h
- Include vmalloc.h in mixart_hwdep.c which uses vmalloc
Signed-off-by: Jes Sorensen <[email protected]>
----
arch/ia64/Kconfig | 1 +
drivers/atm/Makefile | 2 +-
drivers/net/Kconfig | 2 +-
include/asm-ia64/io.h | 15 +++++++++++++++
sound/pci/mixart/mixart_hwdep.c | 1 +
5 files changed, 19 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/ia64/Kconfig
===================================================================
--- linux-2.6.orig/arch/ia64/Kconfig
+++ linux-2.6/arch/ia64/Kconfig
@@ -297,6 +297,7 @@
See <file:Documentation/vm/numa> for more.
config ARCH_FLATMEM_ENABLE
+ depends on !NUMA
def_bool y
config ARCH_SPARSEMEM_ENABLE
Index: linux-2.6/drivers/atm/Makefile
===================================================================
--- linux-2.6.orig/drivers/atm/Makefile
+++ linux-2.6/drivers/atm/Makefile
@@ -41,7 +41,7 @@
# guess the target endianess to choose the right PCA-200E firmware image
ifeq ($(CONFIG_ATM_FORE200E_PCA_DEFAULT_FW),y)
byteorder.h := include$(if $(patsubst $(srctree),,$(objtree)),2)/asm/byteorder.h
- CONFIG_ATM_FORE200E_PCA_FW := $(obj)/pca200e$(if $(shell $(CC) -E -dM $(byteorder.h) | grep ' __LITTLE_ENDIAN '),.bin,_ecd.bin2)
+ CONFIG_ATM_FORE200E_PCA_FW := $(obj)/pca200e$(if $(shell $(CC) -I$(srctree)/include -E -dM $(byteorder.h) | grep ' __LITTLE_ENDIAN '),.bin,_ecd.bin2)
endif
endif
Index: linux-2.6/drivers/net/Kconfig
===================================================================
--- linux-2.6.orig/drivers/net/Kconfig
+++ linux-2.6/drivers/net/Kconfig
@@ -946,7 +946,7 @@
config HP100
tristate "HP 10/100VG PCLAN (ISA, EISA, PCI) support"
- depends on NET_ETHERNET && (ISA || EISA || PCI)
+ depends on NET_ETHERNET && (ISA || EISA)
help
If you have a network (Ethernet) card of this type, say Y and read
the Ethernet-HOWTO, available from
Index: linux-2.6/include/asm-ia64/io.h
===================================================================
--- linux-2.6.orig/include/asm-ia64/io.h
+++ linux-2.6/include/asm-ia64/io.h
@@ -435,6 +435,21 @@
#define ioremap_nocache(o,s) ioremap(o,s)
+static inline int
+check_signature(void __iomem *io_addr, const unsigned char *signature,
+ int length)
+{
+ int retval = 0;
+ do {
+ if (readb(io_addr) != *signature++)
+ goto out;
+ io_addr++;
+ } while (--length);
+ retval = 1;
+ out:
+ return retval;
+}
+
# ifdef __KERNEL__
/*
Index: linux-2.6/sound/pci/mixart/mixart_hwdep.c
===================================================================
--- linux-2.6.orig/sound/pci/mixart/mixart_hwdep.c
+++ linux-2.6/sound/pci/mixart/mixart_hwdep.c
@@ -24,6 +24,7 @@
#include <linux/interrupt.h>
#include <linux/pci.h>
#include <linux/firmware.h>
+#include <linux/vmalloc.h>
#include <asm/io.h>
#include <sound/core.h>
#include "mixart.h"
On Thu, Feb 09, 2006 at 08:26:58AM -0500, Jes Sorensen wrote:
> >>>>> "Matthew" == Matthew Wilcox <[email protected]> writes:
>...
> >> - HP100 driver cannot be compiled on systems without ISA support in
> >> it's current state.
>
> Matthew> I have it enabled on parisc without ISA or EISA. More
> Matthew> details, please.
>
> Generous use of isa_memcpy_toio, isa_readb etc. Those functions ought
> not be visible in a config where ISA is disabled. Anybody who cares
> enough about this could easily fix the HP100 driver to deal with it,
> but it would require some reorganization of the code.
>...
A patch is already available:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
2.6.16-rc2/2.6.16-rc2-mm1/broken-out/
remove-isa-legacy-functions-drivers-net-hp100c.patch
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
>>>>> "Adrian" == Adrian Bunk <[email protected]> writes:
Adrian> A patch is already available:
Adrian> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
Adrian> 2.6.16-rc2/2.6.16-rc2-mm1/broken-out/
Adrian> remove-isa-legacy-functions-drivers-net-hp100c.patch
No problem, Al's patch looks a better solution than mine. So lets
ignore that part of my patch.
Tony is it ok for you to just ignore that part of the patch and apply
the rest? If not I can send you an updated patch.
Thanks,
Jes