On Fri, 18 May 2001 10:53:53 -0400,
"Eric S. Raymond" <email@example.com> wrote:
> (a) Back off the capability approach. That is, accept that
> people doing configuration are going to explicitly and
> exhaustively specify low-level hardware.
No, you loose one of the nicer features of CML2.
> (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.
As a specific case this needs doing anyway, to handle SCSI emulation
over IDE, irrespective of the board type. It needs mid layer but no
SCSI driver and can be done on a PC right now.
As a general question, I prefer selecting machine type foo to mean just
that, you get the devices supported by foo.
> (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.
In general this is the best option, if you create a non-standard
configuration for machine foo then it is your problem, not everybody
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/