Re: CML2 design philosophy heads-up

[David Lang]

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 <[e-mail]>
> To: Alan Cox <[e-mail]>
> Cc: Tom Rini <[e-mail]>,
>      Michael Meissner <[e-mail]>,
>      Keith Owens <[e-mail]>, CML2 <[e-mail]>,
>      [e-mail]
> Subject: Re: CML2 design philosophy heads-up
>
> Alan Cox <[e-mail]>:
> > 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 [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>