SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Fri, 2 Jan 2004 19:46:44 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com > , "osFree@yahoogroups.com" <osFree@yahoogroups.com >
Subject:	SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Frank Griffin writes:
"...But none of this is germane to the point I made. The specs
for hardware designed since 1980 are not written in SL/I, and
many of the earlier ones simply aren't correct or complete in
describing the behavior of the hardware. Nothing that you
derive from incorrect specifications will be correct, whether
SL/I generates the code or the code is written by some
drooling lycanthrope of a VB programmer with electrodes in
his ears. ..."

Frank,

Happy New Year. No, you were not the target. Yes, I'm
actually submitting this response to two mailing lists. I have
repeated myself so many times in so many places that when I
don't have to chew my tobacco twice I relish the opportunity.
This particular thread topic is one under consideration in the
SCOUG Programming SIG as part of our effort to determine
how we can best use our people resources to support open
source development for OS/2.

Everyone of your points is correct. Neither SL/I nor logic
programming can compensate for incorrect or incomplete
specifications. I wouldn't pretend or claim otherwise.

However incorrectly manufacturers hardware differs from
their claims doesn't alter the fact that you must be able to
write correct specifications for how they actually work.
Otherwise no one could write the code in any programming
language from machine level on up. Any code for any
motherboard written for Linux is specifiable in SL/I or PL/I or
any number of other programming languages.

It is also true that that we must pair the motherboard,
whatever its internal logic, with the software to do valid
testing. We have a similar problem when an machine
instruction in practice differs from its spec. We have to make,
to modify, the software to match the hardware. We have to
do it with the machine instructions themselves specifiable.

In every case we have to validate that we have a match
through testing. Hopefully we do exhaustive testing to have a
complete record of what occurs when, what input produces
what output. A standard IPO model.

Given that you can arrive at the correct specs, overcoming
any misinformation from the manufacturer, they will suffice
for anyone in writing any kernel of any operating system.
Furthermore if you have these specs along with those
representing the instruction set of the associated processor,
you can optimize the code for this hardware/processor
combination, eliminating the need to consider any other.

Whatever exists in Linux of use to us is there for the taking.
Otherwise I've failed somehow to grasp the point of open
source. That it's done means I don't have to redo it, i.e. the
process of discovery, only rewrite it.

Basically we are in agreement on all your points. We differ
only (and there only slightly) on which path to proceed from
there.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 02 | January | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.