64bit clean drivers was Re: Linux 2.4.20-pre1

[Andi Kleen]

On Wed, Aug 07, 2002 at 12:50:43PM +0100, Alan Cox wrote:
> On Wed, 2002-08-07 at 11:01, Andi Kleen wrote:
> > Can you explain this further. How else do you propose to get rid of 
> > unmaintained-and-absolutely-hopeless-on-64bit drivers in the configuration? 
> > I definitely do not want to get bug reports about these not working on x86-64.
> 
> I don't want a tree where every driver has seventeen lines of if IBM and
> not 64bit || parisc || x86 || !x86_64 || ia64) && (!wednesdayafternoon)
> 
> Its *unmaintainable*.

I don't see why it is unmaintainable. What is so bad with these ifs? 
64bit cleanness is just another dependency, nothing magic and fundamentally
hard.

I admit it is a bit ugly to hardcode CONFIG_X86_64 here, I would actually
prefer an generic CONFIG_64BIT

At least for i386 it should make no difference at all.

If you object to the ifdefs I can turn it into 
dep_tristate  ... $CONFIG_X86_32 (or CONFIG_I386 and add this)

(unfortunately there is no dep_tristate ... !$CONFIG_64BIT) 
Alternatively CONFIG_NO_64BIT to work around this issue.

> 
> The sparc64 people don't do it, the mips people don't do it, the ia64
> people don't do it, wtf should you get to fill config.in with crap

The main reason I'm doing this is that unlike IA64,alpha,mips (sorry no
offense to these ports) x86-64 is aimed at the mass market. I will
not invoke the A..T... word, but having a configuration where a good
chunk of the drivers do not work is just not acceptable for x86-64 where
even non kernel hackers will likely recompile the kernels. I tried
to fix it for some of the drivers but some are obviously hopeless without
major work.

> The _ISA stuff makes sense, thats sensible, but the rest - when people
> moan we tell em to fix the drivers.

I don't think it is very nice. Some of these actually compile, just with
thousands of warnings, but will oops very quickly likely after first load.
I prefer to disable them. That is much nicer to the user.

-Andi