RFC: let x86_64 no longer define X86

RFC: let x86_64 no longer define X86

[Adrian Bunk]

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

Re: RFC: let x86_64 no longer define X86

[Nick Piggin]

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)

Re: RFC: let x86_64 no longer define X86

[Adrian Bunk]

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

Re: [discuss] RFC: let x86_64 no longer define X86

[Paul Menage]

On Fri, 19 Nov 2004 01:51:17 +0100, Adrian Bunk <bunk@stusta.de> 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

Re: [discuss] RFC: let x86_64 no longer define X86

[Adrian Bunk]

On Thu, Nov 18, 2004 at 05:31:14PM -0800, Paul Menage wrote:
> On Fri, 19 Nov 2004 01:51:17 +0100, Adrian Bunk <bunk@stusta.de> 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

Re: [discuss] RFC: let x86_64 no longer define X86

[Andi Kleen]

> 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

Re: [discuss] RFC: let x86_64 no longer define X86

[Adrian Bunk]

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

Re: RFC: let x86_64 no longer define X86

[Andi Kleen]

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

Re: RFC: let x86_64 no longer define X86

[Jeff Garzik]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Andi Kleen]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[David Woodhouse]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Andi Kleen]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[David Woodhouse]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Andi Kleen]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Jeff Garzik]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Andi Kleen]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Jeff Garzik]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Adrian Bunk]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[linux-os]

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.

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Jeff Garzik]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Raul Miller]

> 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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Adrian Bunk]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[David Woodhouse]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Adrian Bunk]

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

Re: [discuss] Re: RFC: let x86_64 no longer define X86

[Andi Kleen]

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

Re: RFC: let x86_64 no longer define X86

[Takashi Iwai]

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

Re: RFC: let x86_64 no longer define X86

[Paul Mackerras]

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.