lkml.org 
[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Background to the argument about CML2 design philosophy
>1. The Mac derivations were half-right.  The MAC_SCC one is good but Macs
>can have either of two different SCSI controllers. I fixed that with help
>from Ray Knight, who maintains the 68K Mac port.

If I understand the "philosophy" correctly, it is still possible to specify
additional cards for those Macs which have PCI slots. If so, absolutely
fine - I can shove my Adaptec 19160 into my G4 and have it work just as
well as it currently does in my Athlon.

One caveat though - not all Macs have SCSI controllers, and not all that do
even have one of the two standard ones. The "Blue and White G3", the iMac,
the PowerBook G3 "Firewire" and later models on these lines all lack a
built-in SCSI controller, but many could have one added via PCI or CardBus
slots. The PowerBooks 5300 and 190 (and possibly others) use some
non-standard P.O.S. hanging off the NuBus, which even mkLinux doesn't know
how to drive. However, in these situations, disabling the extra drivers is
usually not critical unless you're running low on space somewhere. At that
point, you enable the "Are you insane?" module outlined below...

>3. The MVME derivations are correct *if* (and only if) you agree to ignore
>the possibility that somebody could want to ignore the onboard hardware,
>plug outboard disk or Ethernet cards into the VME-bus connector, and
>do something like running SCSI-over-ATAPI to the outboard device.
>(I missed these possibilities when I wrote the derivations.)

...and then someone else mentioned the possibility of f*x0r3d hardware. In
this case, I would say this *isn't* a kernel-configuration issue but one of
being able to disable the drivers for the malfunctioning hardware. If I
have a PCMCIA controller that reboots the machine as soon as the driver
tries to switch it on, I should be able to send a command-line parameter to
the kernel which tells it to switch it off *at run-time*. And iff I'm
running with hardware which is so f*x0r3d that that isn't enough, I'd
either fix the hardware or hack the config files. I don't see the problem.

I think the MVME derivations are *perfectly* sensible - if the reference
board and most (read: virtually all) derivatives have those features, turn
them on by all means. To satisfy some others, you might want to say "Hey,
these guys might want to *explicitly turn off* some of this stuff" - so
provide an option under "Are you insane?" which presents all the "derived"
symbols and allows the hackers to manually turn stuff off.

--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi@cyberspace.org (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----


-
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:0.085 / U:11.424 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site