Messages in this thread | | | Date | Wed, 7 Aug 2002 12:41:53 +0200 | From | Andi Kleen <> | Subject | 64bit clean drivers was Re: Linux 2.4.20-pre1 |
| |
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
- 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/
| |