PL5 in progress ...

[shenson@nyx.cs.du.edu (Stephen Henson)]

Greetings,
	I'm in the process of coding pl5. One of the things that has been
suggested several times is the need for a sync() call. Minixfs currently does
a sync() after every sys call which really slows it down somewhat; anyone who
has tried minixfs without this WRITETHRU stuff will know there is a phenomenal
speedup when the cache is no longer shackled in this way.
	I've been a bit reluctant to remove all the WRITETHRU  stuff (and some
bits I missed: thanks Erling!) because it needs an asynchronous update daemon
and can leave the filesystem in a mess if the system crashes with a dirty cache.
Now I've done fsck I'm concentrating on the daemon.
	So I come to the points of this:

1. Using a method analagous to that used by tfork() I've managed to get minixfs
to spawn an update daemon as part of its initialisation (without needing a
separate program). Is this legitimate ? Particularly, I'm thinking about memory
protection since the new process ends up in user mode sharing the memory of
minix.xfs itself. I prefer this method rather than a separate program because
it's all self contained and can make use of some minixfs info not normally
available to a separate process.

2. Everything is fine when certain GEM stuff isn't running. When GEM stuff is
running the daemon hardly ever gets in. Presumably this is down to MiNT not
pre-empting GEM; does Multi-TOS fix this ? I suppose other users could always
have a small DA with an evnt_timer/Syield() loop in it.

Regards, Steve.