lkml.org 
[lkml]   [2001]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: CML2 design philosophy heads-up
    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 <esr@thyrsus.com>
    > To: Alan Cox <alan@lxorguk.ukuu.org.uk>
    > Cc: Tom Rini <trini@kernel.crashing.org>,
    > Michael Meissner <meissner@spectacle-pond.org>,
    > Keith Owens <kaos@ocs.com.au>, CML2 <linux-kernel@vger.kernel.org>,
    > kbuild-devel@lists.sourceforge.net
    > Subject: Re: CML2 design philosophy heads-up
    >
    > Alan Cox <alan@lxorguk.ukuu.org.uk>:
    > > 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 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/
    >
    -
    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 12:53    [W:4.037 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site