Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!tness7!tness1!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Disk corrupt - task held
Keywords: guru to the maximum frustrastion
Message-ID: <2108@sugar.UUCP>
Date: 12 Jun 88 14:21:12 GMT
References: <1657@vaxb.calgary.UUCP> <3932@cbmvax.UUCP>
Distribution: na
Organization: Sugar Land UNIX - Houston, TX
Lines: 91

In article ... maloff@calgary.UUCP (Sheldon Maloff) writes:
> I've just moved this thread over to .tech rather than cross post, since
> it seems technical enough.

> In article <3932@cbmvax.UUCP>, steveb@cbmvax.UUCP (Steve Beats) writes:
> > In article ... maloff@calgary.UUCP (Sheldon Maloff) writes:
> > >	Disk Corrupt - Task Held
> > >	Finish ALL Disk Activity
> > >	etc.

> > >I go straight into a guru of this form

> > >	8700000B.265F48F1

> > >So I look up in my handy Amiga-Guru book on what this means and I find
> > >out we have a fatal error in the dos library, specifically key out of
> > >range.

> > Yeah, I know!  This should really be considered an 'A' bug (one which should
> > be fixed before release) but it hasn't been.

Damn straight.

> > The current version of FFS has the same code...

Are you planning on fixing this? Soon I hope?

> > I could go on for ages about how difficult it is to trap errors like
> > that, and then exit gracefully.

But you've already trapped the error when you go to the guru.

> > Exactly what do you do when the data coming off disk are bad ?

Return an error code, and let the program clean up. You feel like going over
problems in the file system again? We could get into things like bad block
handling and baroque directories, too.

Hey, I have an idea! How about an alternate file system for Amy: the UFS (UNIX
style file system). Have it emulate Examine and ExNext for compatibility, but
provide Berkeley-style directory-reading entry points for speed. Take advantage
of the last 16 or so years of AT&Ts and Berkeley's work. Yeh.

As an aside: I've been re-reading Bach's book and thinking about running UNIX
tasks under AmigaDOS. You know, I think it would be dead-easy [*]. You'd need an
MMU, but you'd turn the MMU off whenever you left UNIX mode (interrupt while
in UNIX task, system call). The MMU overhead would be about zip with just one
task (since you wouldn't ever be switching UNIX contexts). To AmigaDOS the UNIX
task would look like another Amy task, but with traps to gracefully kill it if
it gets out of bounds.

You'd have to modify the Exec, some. Not that much. Just provide an entry point
whereby a task requests the MMU, and a few entry points to track what the task
does with the MMU. Then whenever it goes into that task it'll set the MMU up
the way it was when that task left it. If the task had turned it off (say, it
was in a system call) then it leaves it off.

You could boot up with the UFS, so Amy tasks wouldn't know. AmigaDOS and any
AmigaDOS tasks would look like a real-time kernel to UNIX. Of course if you
got a guru, you'd be dead, but UNIX tasks wouldn't guru.

And with the MMU support, you could even write AmigaDOS tasks with appropriate
traps. Turn the MMU on and off whenever you want to deal with MEMF_PUBLIC. Not
totally safe, but better than nothing...

NewExamine(lock, fib)
BPTR lock;
struct FileInfoBlock *fib;
{
	struct FileInfoBlock *real_fib;

	MMU(0);
	if(!(real_fib = AllocMem(sizeof *fib, MEMF_PUBLIC))) {
		return 0;
	}
	if(!(Examine(lock, real_fib))) {
		FreeMem(real_fib, sizeof *fib);
		return 0;
	}
	*fib = *real_fib;
	FreeMem(real_fib, sizeof *fib);
	MMU(1);
	return 1;
}
----------
[*] Dead-easy is a relative term, here. Compared to supporting AmigaDOS under
UNIX it would be.
-- 
-- Peter da Silva      `-_-'      ...!hoptoad!academ!uhnix1!sugar!peter
-- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter
-- Disclaimer: These may be the official opinions of Hackercorp.