[lkml]   [2001]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: CML2 design philosophy heads-up
Alan Cox <>:
> 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="">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
More majordomo info at
Please read the FAQ at

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