if you punt in case C you should then have a mode where all dependancies
are ignored and all options are presented to the person ding the config.
This is FAR better then forcing them to hand-hack the config file.
possibly split the rules file into two parts.
part 1. absolute requirements (i.e. if you select a SCSI controller you
MUST select SCSI)
part 2. simplifications (i.e. if x86 and printer then x86_printer)
tehn have a mode where the part 2 rules are not evaluated to handle the
corner cases.
David Lang
On Fri, 18 May 2001, Eric S.
Raymond wrote:
> Date: Fri, 18 May 2001 10:53:53 -0400
> From: Eric S. Raymond <[EMAIL PROTECTED]>
> To: Alan Cox <[EMAIL PROTECTED]>
> Cc: Tom Rini <[EMAIL PROTECTED]>,
> Michael Meissner <[EMAIL PROTECTED]>,
> Keith Owens <[EMAIL PROTECTED]>, CML2 <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: CML2 design philosophy heads-up
>
> Alan Cox <[EMAIL PROTECTED]>:
> > I was under the impression the MVME had VME bus. So you can hang IDE off it
> > and other gunge. Its also a reference design so you may find MVME147 like
> > boards..
>
> Urk. Alan is right, I misinterpreted the original question. There is
> no on-board support for IDE or PCMCIA, but you could plug in an IDE
> daughterboard with an IDE drive or a PCMCIA slot. This would be a
> pretty damn perverse thing to do, however -- there are newer, less
> expensive, faster, and generally better SBCs that have IDE/ATAPI and
> PCMCIA built in. On top of that, VMEbus SBCs aren't normally used for
> consumer devices -- their market is basically industrial-control
> applications with a side of scientific instrumentation.
>
> That being the case, we do face a question of design
> philosophy, expressed as a policy question about how to design
> rulesets. Actually two questions:
>
> 1. When we have a platform symbol for a reference design like MVME147, do
> we stick to its spec sheet or consider it representative of all derivatives
> (which may have other facilities)?
>
> I know my answer to this one, which I will implement unless there's
> strong consensus otherwise. I go for explicitness. If we're going to
> support MVME147 derivatives and variants in the ruleset, they get
> their own platform symbols.
>
> 2. How much extra tsuris should we accept in order to handle
> perverse edge cases like this one? There are three ways we
> can cope:
>
> (a) Back off the capability approach. That is, accept that
> people doing configuration are going to explicitly and
> exhaustively specify low-level hardware.
>
> (b) Add complexity to the ruleset. Split SCSI into SCSI_MIDLEVEL and
> SCSI_DRIVERS capabilities, make sure SCSI_DRIVERS is implied
> whenever a SCSI card is configured, etc.
>
> (c) Decide not to support this case and document the fact in the
> rulesfile. If you're going put gunge on the VME bus that replaces
> the SBC's on-board facilities, you can hand-hack your own configs.
>
> I don't want to do (a); it conflicts with my design objective of
> simplifying configuration enough that Aunt Tillie can do it. I won't
> do that unless I see a strong consensus that it's the only Right Thing.
>
> The larger question in choosing between (b) and (c) is one of the usual ones
> in programming -- that is, generality vs. maintainability. Is it ever
> acceptable for the configuration system to deliberately punt an edge case
> like this one in order to keep from having a combinatorial-complexity
> explosion in the ruleset?
>
> I know what my sense of taste and proportion says. But I'm not going
> to impose my vision on everybody. If you have an opinion, I'd like
> to hear it.
> --
> <a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
>
> Whether the authorities be invaders or merely local tyrants, the
> effect of such [gun control] laws is to place the individual at the
> mercy of the state, unable to resist.
> -- Robert Anson Heinlein, 1949
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
