64bit clean drivers was Re: Linux 2.4.20-pre1

From: Andi Kleen (ak@suse.de)
Date: Wed Aug 07 2002 - 05:41:53 EST

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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:35 EST