Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty
From: scotty@l5comp.UUCP (Scott Turner)
Newsgroups: comp.sys.amiga
Subject: Re: Re: Wishlist for 1.3 Executive.
Message-ID: <301@l5comp.UUCP>
Date: Thu, 23-Jul-87 18:13:37 EDT
Article-I.D.: l5comp.301
Posted: Thu Jul 23 18:13:37 1987
Date-Received: Sat, 25-Jul-87 16:40:49 EDT
References: <8707220001.AA01966@cogsci.berkeley.edu>
Reply-To: scotty@l5comp.UUCP (Scott Turner)
Organization: L5 Computing, Edmonds, WA
Lines: 138
Summary: Thoughts on shutdown command.

In article <8707220001.AA01966@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes:
>I agree!!!  Anything hanging off that sequence is vulnerable to corruption,
>anything it does is suspect.  I said that I was not debating the merits of
>the idea itself, but rather poiting out how it could be done.  If I was
The fact that you were discussing "how to" is what raised my concern. Someone
might say "Gee that sounds neat lets do it!" without understanding any flip
side issues.

>god-of-all-things there would be Ctrl-Amiga-Amiga and Ctrl-Amiga-Amiga-Alt.
>One would be "safe" and flush all buffers.  One would be dirty for use
>in emergencies.  A workbench menu item could verify things with the user, give
What I think is needed is a shutdown command. One for the CLI and a menu item
for the Workbench. Having it as a Ctrl-Amiga-Amiga-Alt (or whatever key
sequence you wish to use) could lead people to try the safe reboot in places
where things are really screwed up. ie if you don't have a working CLI or
workbench to run a shutdown from then it might be a real good idea to not
try flushing anything out to disk. :) Remember, no MMU means wild code can
wack ANYTHING including data about to get flushed.

>people want a "official" shutdown, turning the machine off seems crude
>and dangerous to them.  If they have a harddisk, I agree with them.
Even with just a floppy system it's dangerous to just power off. Hackers are
smart enough to know to wait 2-3 seconds for the auto-flush before doing
anything drastic but most of John Q Public isn't. And the golden rule "Don't
do nothin with the red drive light on" isn't a good rule either. I've seen
the light go out and then the auto-flush kick in and it come back on 2-3
seconds after it went out.

Hard disks just have it rougher. As an aside, it sure would be neat if the
Amiga knew the difference between a floppy and a harddisk. My hard disk gets
motor off commands all the time! For a system that's so flexible I don't
seem to be able to say "I'll take the periodic flush calls, but please hold
the motor offs, they give me gas." ;) But then again the whole motor on/off
thing was a MAJOR kludge to begin with.

>Also I'd define some keys to selectivly disable parts of the auto-config
>process.  Press CTRL-F1 and restrict yourself to 256K of CHIP ram.  If
>CTRL-F3 is held down then $C00000 memory is not sized, etc.  More thought
>is needed as to the keystrokes, but the idea has merit.
What is needed is better software. I don't see why the C-A folks should put
time into this to benifit those who wish to use defective software. My skyfox
no longer works with my memory expanded system. I don't blame C-A or expect
THEM to fix it, I blame EA. Software that doesn't allocate ram correctly is
just plain BROKE, it hits the trash can around here.

>Terminology... Terminology.  There are a number of things on the Amiga that
>have multiple names and a number of things that share a common name.  YOU ARE
Terminology is important though in this forum. Tons of people read it from
different backgrouds and Amiga experience levels. If those of us that DO know
the difference between device drivers and device handlers don't keep it
straight how can we expect those that DON'T know the difference to get it
straight? I know the difference and you know the difference which is what
concerned me about your statement. The thought "Maybe Bryce forgot about
handler caching" ran through my mind.

>What the validator does is unimportant.  Even if the file is left open, and
>this bitmap is marked as pending... no sweat.
Obviously you haven't spent alot of time waiting for the validator to run its
course. On a 20 meg hard disk it's like watching glaciers form. Sure there's
no permanent data loss, but it's still a royal pain plus VERY alarming to
those who don't know what the hell is going on. Witness recent messages here.

As a side note, I think that C-A should have the validator at least print a
message saying something like "Validating disk XXXX", followed by the
infamous "This may take a few minutes". :-) I hope this can be slid into
1.3, the current non-talkative validator does seem to be alarming people.

>What is important is that what has already been written, but is sitting is
>cache, is flushed.  Care needs to be taken that the DEVICE (exec device such
>as trackdisk.device) has completed writing, turned off the drive, and is
>generally ready for doomesday.  Catching it in the middle of a cache update
I think this whole topic falls into another one of those nitty gritty details
that the C-A crowd has yet to deal with. It took Apple a while to figure out
the details on this feature for the Mac family as well. The problem I see is
that the hooks were there from day one to shutdown a Mac, but I don't see
some of the crucial hooks in the Amiga. Otherwise I'd craft a shutdown
program. Having a Mac here on a daily basis has infected me with the desire
to have a real shutdown rather than risk my patience at 03:00. It's very
comforting to know that if I yank restart or shutdown on the Mac everything
will get flushed/shutdown A-OK.

>If there was a better programmers definition of ALL the dos packets, there would
>be a better chance that you could cause a HANDLER to do the right_stuff before
>a forced powerdown.  ACTION_FLUSH is documented, but whats that ACTION_DIE
>packet meant for anyway?  Even "nothing" would be reassuring to those of
>use writing handlers.
Nothing is what the ram disk does for ACTION_DIE. The best dox I have on
dog packets was gleaned from ripping ram-handler apart. But even it doesn't
handle some packets that I know the disk handler handles (Like add cache).
This has been one of things I've been curious about under the new
developer's program. No one replied to my query regarding the new program
so I can still only guess.  But it seems that they get the same dox that
we've always gotten. And sure you can save a few bux on hardware but with
Amiga dealers as scarce as they are doesn't it make sense to prop the local
ones up? Given the choice of buying my goodies from C-A or my local dealer
I'd pick my local dealer. They're nice folks and I'd like to see them stay
in the business, even if only so they can sell my commercial products. :)
And when it comes to time for service it sure feels good to be able to say
"YES!" when they ask if you bought the machine from them. Every dealer I
know has a "They bought it here" program in their service departments. If
two machines need the last disk drive in stock, the machine bought from that
store is going to get it over a developer machine bought from C-A.

I think C-A's current program of not documenting the COMPLETE set of ACTION
packets is going to just cause more trouble down stream. People are already
starting to write more and more handlers. I'm about to write a HUGE
handler, Arthur a whole new file system, and as these handlers start
catching on it'll be damn hard for C-A to pop up and say "Well now we're
going to document those packets and by the way you've all be using them the
wrong way!"

>Note to scott on scottdisk.device.  You mentioned bad documentation...
>well what better documentation than source code, and that's in the Rom Kernal
>Manual.  Or perhaphs your troubles related to trackdisk-type devices?? 
>Otherwise the sample source works just fine with a little tweaking and
>not much adding...
The RKM's driver is missing tons of stuff for those that wish to do a disk
driver. It's also missing crucial code concepts for those that wish to do
serial or parallel devices. It's great if all you want is yet another ram
disk.

Also, people like to say source code is great dox. It just isn't so. Working
source code just shows you how to make something work as it does. It very often
doesn't tell you how to make tweak A or tweak B or don't do this because the
machine will vaporize. "DEMO SOURCE" is even worse because it doesn't even
work. You always have that nagging doubt in the back of your mind, when your
code based on the demo code doesn't work, as to wether it's your code or the
code in the demo that's screwed.

Source code is to documentation as pictures are to a text book. PERIOD. A
picture in a text book is not entirely useless without text to describe it
but it's not nearly as useful. Same goes for source code and documentation.

Scott Turner
-- 
UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make
UUCP-auto: scotty@l5comp.UUCP    | sure I don't run up a vet bill.
GEnie: JST			 | "The bombs drop in 5 minutes" R. Reagan
		Disclaimer? I own L5 Computing. Isn't that enough?