I'd like to send a patch after 2.6.10 that removes the following from
arch/x86_64/Kconfig:
config X86
bool
default y
Additionally, I'll also check all current X86 uses to prevent breakages.
Why?
X86 is _the_ symbol to identify the i386 architecture, but the x86_64
port hijacked it. Kernel-wise, x86_64 is mostly simply a new port like
e.g. ia64.
Where is the problem?
To say "X86", you currently have to write "(X86 && !X86_64)" in the
Kconfig file. This is not intuitive.
Why is e.g. CONFIG_LBD available on x86_64 and even enabled in
defconfig?
Isn't this an incompatible change?
Yes it is.
But according to the current development model, such changes are allowed
in 2.6 .
And if you want to support both older and more recent kernels, the
following dependencies will be correct both before and after this
change:
- (X86 && !X86_64)
- (X86 && X86_64)
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:
> And if you want to support both older and more recent kernels, the
> following dependencies will be correct both before and after this
> change:
> - (X86 && !X86_64)
> - (X86 && X86_64)
>
This last one surely can't be correct before *and* afterwards. But even in
the current system, it is a pretty perverse thing to check for. I guess you
meant:
(X86 || X86_64)
On Fri, Nov 19, 2004 at 12:14:06PM +1100, Nick Piggin wrote:
> Adrian Bunk wrote:
>
> >And if you want to support both older and more recent kernels, the
> >following dependencies will be correct both before and after this
> >change:
> >- (X86 && !X86_64)
> >- (X86 && X86_64)
> >
>
> This last one surely can't be correct before *and* afterwards. But even in
> the current system, it is a pretty perverse thing to check for. I guess you
> meant:
>
> (X86 || X86_64)
Yes, thanks for the correcting my typo.
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 Fri, 19 Nov 2004 01:51:17 +0100, Adrian Bunk <[email protected]> wrote:
> I'd like to send a patch after 2.6.10 that removes the following from
> arch/x86_64/Kconfig:
>
> config X86
> bool
> default y
>
> Additionally, I'll also check all current X86 uses to prevent breakages.
>
Or, you could define an X86_32 config symbol in i386. This seems a
little more backward compatible, and means that you can continue to
just test X86 for the rather large set of code that works fine on both
32-bit and 64-bit.
I guess it depends on whether you think there are more places in the
generic code that the two architectures share code, vs places that are
32-bit only.
Paul
On Fri, Nov 19, 2004 at 01:51:17AM +0100, Adrian Bunk wrote:
> I'd like to send a patch after 2.6.10 that removes the following from
> arch/x86_64/Kconfig:
>
> config X86
> bool
> default y
I'm against this. Please don't do this.
-Andi
Andi Kleen wrote:
> On Fri, Nov 19, 2004 at 01:51:17AM +0100, Adrian Bunk wrote:
>
>>I'd like to send a patch after 2.6.10 that removes the following from
>>arch/x86_64/Kconfig:
>>
>> config X86
>> bool
>> default y
>
>
> I'm against this. Please don't do this.
An explanation would be nice.
Jeff
On Fri, Nov 19, 2004 at 05:21:22AM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> >On Fri, Nov 19, 2004 at 01:51:17AM +0100, Adrian Bunk wrote:
> >
> >>I'd like to send a patch after 2.6.10 that removes the following from
> >>arch/x86_64/Kconfig:
> >>
> >> config X86
> >> bool
> >> default y
> >
> >
> >I'm against this. Please don't do this.
>
> An explanation would be nice.
Basically what Paul Menage said. There is a lot of common code,
and you would end up writing X86 && X86_64 more often than
X86 && !X86_64.
In addition such a change is quite intrusive and I don't
think it's a good idea to do right now because it'll very
likely introduce bugs.
If someone really thinks the X86 && !X86_64 is too ugly
(I personally don't think it is because it says clearly
what the matter is) then adding an additional X86_32 would be the right
thing to do.
-Andi
At Fri, 19 Nov 2004 01:51:17 +0100,
Adrian Bunk wrote:
>
> I'd like to send a patch after 2.6.10 that removes the following from
> arch/x86_64/Kconfig:
>
> config X86
> bool
> default y
>
> Additionally, I'll also check all current X86 uses to prevent breakages.
>
>
> Why?
>
> X86 is _the_ symbol to identify the i386 architecture, but the x86_64
> port hijacked it. Kernel-wise, x86_64 is mostly simply a new port like
> e.g. ia64.
If we do this for x86-64, shouldn't we do the same for ppc64 and sh64,
too? (only sparc64 seems not defining 32bit config.)
Takashi
On Fri, 2004-11-19 at 11:34 +0100, Andi Kleen wrote:
> Basically what Paul Menage said. There is a lot of common code,
> and you would end up writing X86 && X86_64 more often than
> X86 && !X86_64.
(assuming you meant the first to be X86 || X86_64)
Can you show some examples? We don't have this for any other
architecture.
--
dwmw2
On Fri, Nov 19, 2004 at 11:28:20AM +0000, David Woodhouse wrote:
> Can you show some examples? We don't have this for any other
> architecture.
Just grep for any use of X86 in Kconfig.
-Andi
On Fri, 2004-11-19 at 12:55 +0100, Andi Kleen wrote:
> On Fri, Nov 19, 2004 at 11:28:20AM +0000, David Woodhouse wrote:
> > Can you show some examples? We don't have this for any other
> > architecture.
>
> Just grep for any use of X86 in Kconfig.
OK, I'll pick the first I find...
config ATP
tristate "AT-LAN-TEC/RealTek pocket adapter support"
depends on NET_POCKET && ISA && X86
Why is that OK on x86_64 but not Alpha? Why isn't the use of X86 a bug
in that case?
--
dwmw2
On Fri, Nov 19, 2004 at 11:34:19AM +0100, Andi Kleen wrote:
>...
> In addition such a change is quite intrusive and I don't
> think it's a good idea to do right now because it'll very
> likely introduce bugs.
>...
I's say it will fix some bugs and make some future bugs less likely.
The CONFIG_LBD example in my initial mail is an example for such a bug.
> -Andi
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 Fri, Nov 19, 2004 at 01:05:23PM +0100, Adrian Bunk wrote:
> On Fri, Nov 19, 2004 at 11:34:19AM +0100, Andi Kleen wrote:
> >...
> > In addition such a change is quite intrusive and I don't
> > think it's a good idea to do right now because it'll very
> > likely introduce bugs.
> >...
>
> I's say it will fix some bugs and make some future bugs less likely.
I doubt it (and so far I did most of these changes)
-Andi
Andi Kleen wrote:
> I don't know details about the driver, but it's not enabled on x86-64
> because x86-64 doesn't have ISA set.
which I disagree with. CONFIG_ISA should include southbridge devices
behind a PCI<->ISA bridge. There is zero value to a more stricter
"there is a physical ISA bus in this machine" definition.
Jeff
On Fri, Nov 19, 2004 at 07:12:46AM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> >I don't know details about the driver, but it's not enabled on x86-64
> >because x86-64 doesn't have ISA set.
>
>
> which I disagree with. CONFIG_ISA should include southbridge devices
> behind a PCI<->ISA bridge. There is zero value to a more stricter
> "there is a physical ISA bus in this machine" definition.
There is. It gets rid of many tens of drivers that are not and will never
be 64bit clean and have a snowball in hell chances to work on x86-64.
In theory you could invent a new ISA_SLOT or ISA_BROKEN config for them,
but since ISA does the job quite well for near everybody except
for one or two corner cases I don't see any sense in changing it.
-Andi
On Fri, Nov 19, 2004 at 11:50:50AM +0000, David Woodhouse wrote:
> On Fri, 2004-11-19 at 12:55 +0100, Andi Kleen wrote:
> > On Fri, Nov 19, 2004 at 11:28:20AM +0000, David Woodhouse wrote:
> > > Can you show some examples? We don't have this for any other
> > > architecture.
> >
> > Just grep for any use of X86 in Kconfig.
>
> OK, I'll pick the first I find...
>
> config ATP
> tristate "AT-LAN-TEC/RealTek pocket adapter support"
> depends on NET_POCKET && ISA && X86
>
> Why is that OK on x86_64 but not Alpha? Why isn't the use of X86 a bug
> in that case?
I don't know details about the driver, but it's not enabled on x86-64
because x86-64 doesn't have ISA set.
-Andi
On Thu, Nov 18, 2004 at 05:31:14PM -0800, Paul Menage wrote:
> On Fri, 19 Nov 2004 01:51:17 +0100, Adrian Bunk <[email protected]> wrote:
> > I'd like to send a patch after 2.6.10 that removes the following from
> > arch/x86_64/Kconfig:
> >
> > config X86
> > bool
> > default y
> >
> > Additionally, I'll also check all current X86 uses to prevent breakages.
>
> Or, you could define an X86_32 config symbol in i386. This seems a
> little more backward compatible, and means that you can continue to
> just test X86 for the rather large set of code that works fine on both
> 32-bit and 64-bit.
>
> I guess it depends on whether you think there are more places in the
> generic code that the two architectures share code, vs places that are
> 32-bit only.
We are not talking about thousands of places.
We are talking about less than hundred places.
And many people do currently get it wrong like with CONFIG_LBD.
The most important improvement would be to prevent such bugs and to have
the X86_64 dependency explicitely stated.
The #ifdef CONFIG_X86 in init/main.c is an example where it currently
takes some time to understand whether it's correct or a bug.
X86_32 would be a solution, but it would IMHO also create confusion
since i386 and ia64 also have some things in common (e.g. ACPI support).
The cleanest thing is simply, to state X86_64 dependencies explicitely.
> Paul
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
Andi Kleen wrote:
> On Fri, Nov 19, 2004 at 07:12:46AM -0500, Jeff Garzik wrote:
>
>>Andi Kleen wrote:
>>
>>>I don't know details about the driver, but it's not enabled on x86-64
>>>because x86-64 doesn't have ISA set.
>>
>>
>>which I disagree with. CONFIG_ISA should include southbridge devices
>>behind a PCI<->ISA bridge. There is zero value to a more stricter
>>"there is a physical ISA bus in this machine" definition.
>
>
> There is. It gets rid of many tens of drivers that are not and will never
> be 64bit clean and have a snowball in hell chances to work on x86-64.
>
> In theory you could invent a new ISA_SLOT or ISA_BROKEN config for them,
> but since ISA does the job quite well for near everybody except
> for one or two corner cases I don't see any sense in changing it.
The traditional legacy ISA devices -- floppy, serial, parallel, mouse,
keyboard, IDE -- are still around. Yet now we need to invent a new name
to classify ISA devices that have been with us for 20 years?
CONFIG_ISA_BROKEN is more appropriate than pretending devices we've
called ISA since the 1980's do not imply/depend on CONFIG_ISA.
Jeff
> The most important improvement would be to prevent such bugs and to have
> the X86_64 dependency explicitely stated.
This would just end up with me having to hunt through all the drivers
all the time and enabling drivers that need to be enabled on x86-64 too.
It's much easier to disable the few drivers that are broken with !X86_64.
Again please don't do it. It will just cause more work long term.
-Andi
On Fri, Nov 19, 2004 at 07:37:33AM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> >On Fri, Nov 19, 2004 at 07:12:46AM -0500, Jeff Garzik wrote:
> >
> >>Andi Kleen wrote:
> >>
> >>>I don't know details about the driver, but it's not enabled on x86-64
> >>>because x86-64 doesn't have ISA set.
> >>
> >>
> >>which I disagree with. CONFIG_ISA should include southbridge devices
> >>behind a PCI<->ISA bridge. There is zero value to a more stricter
> >>"there is a physical ISA bus in this machine" definition.
> >
> >
> >There is. It gets rid of many tens of drivers that are not and will never
> >be 64bit clean and have a snowball in hell chances to work on x86-64.
> >
> >In theory you could invent a new ISA_SLOT or ISA_BROKEN config for them,
> >but since ISA does the job quite well for near everybody except
> >for one or two corner cases I don't see any sense in changing it.
>
> The traditional legacy ISA devices -- floppy, serial, parallel, mouse,
> keyboard, IDE -- are still around. Yet now we need to invent a new name
> to classify ISA devices that have been with us for 20 years?
>
> CONFIG_ISA_BROKEN is more appropriate than pretending devices we've
> called ISA since the 1980's do not imply/depend on CONFIG_ISA.
Silly question:
Why CONFIG_ISA_BROKEN?
A new CONFIG_ISA_SLOT might solve such cases, and otherwise the case
Andi described would be perfectly covered by !CONFIG_64BIT .
> Jeff
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 Fri, 19 Nov 2004, Jeff Garzik wrote:
> Andi Kleen wrote:
>> On Fri, Nov 19, 2004 at 07:12:46AM -0500, Jeff Garzik wrote:
>>
>>> Andi Kleen wrote:
>>>
>>>> I don't know details about the driver, but it's not enabled on x86-64
>>>> because x86-64 doesn't have ISA set.
>>>
>>>
>>> which I disagree with. CONFIG_ISA should include southbridge devices
>>> behind a PCI<->ISA bridge. There is zero value to a more stricter "there
>>> is a physical ISA bus in this machine" definition.
>>
>>
>> There is. It gets rid of many tens of drivers that are not and will never
>> be 64bit clean and have a snowball in hell chances to work on x86-64.
>>
>> In theory you could invent a new ISA_SLOT or ISA_BROKEN config for them,
>> but since ISA does the job quite well for near everybody except
>> for one or two corner cases I don't see any sense in changing it.
>
> The traditional legacy ISA devices -- floppy, serial, parallel, mouse,
> keyboard, IDE -- are still around. Yet now we need to invent a new name to
> classify ISA devices that have been with us for 20 years?
>
> CONFIG_ISA_BROKEN is more appropriate than pretending devices we've called
> ISA since the 1980's do not imply/depend on CONFIG_ISA.
>
> Jeff
>
Why CONFIG_ISA_BROKEN. That implies (states) that its broken and
it's not. All modern ix86's have such a bus, even though it
doesn't go out to some connectors anymore. Just leave the 20-year-old
local bus, then called ISA, alone. ISA means:
Industry Standard Architecture
It __is__! Don't muck with it.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by John Ashcroft.
98.36% of all statistics are fiction.
linux-os wrote:
> Why CONFIG_ISA_BROKEN. That implies (states) that its broken and
The name is appropriate because the drivers in question _are_ broken.
Jeff
On Fri, Nov 19, 2004 at 01:40:55PM +0100, Andi Kleen wrote:
> > The most important improvement would be to prevent such bugs and to have
> > the X86_64 dependency explicitely stated.
>
> This would just end up with me having to hunt through all the drivers
> all the time and enabling drivers that need to be enabled on x86-64 too.
>
> It's much easier to disable the few drivers that are broken with !X86_64.
>...
The issue you describe only occurs when a new dependency on X86 is
added. It is not a problem for the common case that a driver is portable
and therefore available on all architectures.
If the driver also works on X86_64, adding a " || X86_64" is trivial.
In the worst case, a new driver is not available on X86_64 until this is
added to the dependencies.
But the current setup might cause real bugs.
If one new user of CONFIG_LBD wouldn't additionally (and not strictly
required) check BITS_PER_LONG, it might currently have unwanted effects
on X86_64. Explicite annotations with X86_64 if it works on this
architecture would prevent such bugs.
> -Andi
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
> linux-os wrote:
> > Why CONFIG_ISA_BROKEN. That implies (states) that its broken and
On Fri, Nov 19, 2004 at 08:04:57AM -0500, Jeff Garzik wrote:
> The name is appropriate because the drivers in question _are_ broken.
On some architectures -- this is a porting issue, and not a clean binary
distinction.
ASSUMES_32_BIT or some other "32 bit" name would probably better capture
this particular issue.
Even better might be to get the compiler to catch the most obvious
mistakes and use #define decorations to override the compiler's
determination (you'd need two of these, because the compiler can get
this wrong in two different ways).
--
Raul
On Fri, 2004-11-19 at 13:05 +0100, Andi Kleen wrote:
> I don't know details about the driver, but it's not enabled on x86-64
> because x86-64 doesn't have ISA set.
That looks bogus actually -- I think it should only depend on the
existence of parport_pc style hardware. CONFIG_ISA is definitely a
digression. But still, either way the example is wrong. It shouldn't be
limited to X86 and X86_64.
I still haven't found good examples of cases where X86 is used and we
would want to change that to X86 || X86_64. Could this be one?
config HW_RANDOM
tristate "Intel/AMD/VIA HW Random Number Generator support"
depends on (X86 || IA64) && PCI
...or this?
config FTAPE
tristate "Ftape (QIC-80/Travan) support"
depends on BROKEN_ON_SMP && (ALPHA || X86)
I also see some which already have it:
config NVRAM
tristate "/dev/nvram support"
depends on ATARI || X86 || X86_64 || ARM || GENERIC_NVRAM
config HANGCHECK_TIMER
tristate "Hangcheck timer"
depends on X86_64 || X86
And some which seem to be wrong because they want only X86 not X86_64:
config SONYPI
tristate "Sony Vaio Programmable I/O Control Device support (EXPERIMENTAL)"
depends on EXPERIMENTAL && X86 && PCI && INPUT && !64BIT
config MWAVE
tristate "ACP Modem (Mwave) support"
depends on X86
select SERIAL_8250
Using X86 to include X86_64 is bizarre and inconsistent, and it's
already leading to errors in Kconfig. Let's fix it.
--
dwmw2
On Fri, Nov 19, 2004 at 01:19:10PM +0100, Andi Kleen wrote:
> On Fri, Nov 19, 2004 at 07:12:46AM -0500, Jeff Garzik wrote:
> > Andi Kleen wrote:
> > >I don't know details about the driver, but it's not enabled on x86-64
> > >because x86-64 doesn't have ISA set.
> >
> >
> > which I disagree with. CONFIG_ISA should include southbridge devices
> > behind a PCI<->ISA bridge. There is zero value to a more stricter
> > "there is a physical ISA bus in this machine" definition.
>
> There is. It gets rid of many tens of drivers that are not and will never
> be 64bit clean and have a snowball in hell chances to work on x86-64.
>...
If this was correctly annotated with (!64BIT || BROKEN), such a broken
driver wasn't offered on Alpha, too.
> -Andi
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
Takashi Iwai writes:
> If we do this for x86-64, shouldn't we do the same for ppc64 and sh64,
> too? (only sparc64 seems not defining 32bit config.)
Both ppc32 and ppc64 define CONFIG_PPC already.
Paul.