lkml.org 
[lkml]   [2002]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [patch] i386 "General Options" - begone [take 2]
Date
> From: Dave Jones [mailto:davej@suse.de] 

> On Tue, Jun 04, 2002 at 02:58:35PM -0700, Grover, Andrew wrote:
> > So, let's assume in the very near future it becomes
> possible to compile a
> > kernel without MPS or $PIR support. Where should those
> config options go?
> Why do they need to be options ? They should be implied if
> CONFIG_ACPI=n
> Otherwise we could build a kernel without any PCI IRQ routing, MPS
> discovery etc.. I can't see the benefit of making this stuff compile
> time optional other than to save a few bytes (and there are
> much better
> places to start attacking to save space than this).

One reason is for code cleanliness. Linux's internal data structures for irq
routing and MPS stuff on i386 were not designed to handle the possibility of
multiple ways of getting this info. ACPI init gets in there and does its
thing, but it could be better architected. Making the legacy config options
removable is one way to ensure the kernel has things properly modularized
wrt this, and yes, I think someday (maybe not soon) someone *will* want to
leave out MPS support.

> Can you confirm that you're not advocating a "ACPI or Legacy"
> approach ?
> I think you're aware of the dragons that lie that way, but I
> want to be
> sure my suspicions are unfounded.

All I can say is using just *part* of ACPI will cause some machine,
somewhere, to not work. I want to avoid scenarios where that happens. If
there are issues with that, can we discuss them asap, perhaps now?

Regards -- Andy
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:26    [W:0.032 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site