PL5 in progress ...

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

>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.

I can't say anything about the legitimacy of your method; that's
Eric's department.  I can say how I'd like to see this handled, since
I've given it a little bit of thought but haven't sent any of them to
the list until now, since I haven't done any MiNT filesystem work and
figured there'd be obvious problems with it.  Feel free to rip this
idea apart...

What we need is a new system call, Fsync().  By default, this will
point to an empty list of sync handlers.

In the kerinfo structure, filesystems should then get a pointer to a
routine which will install a sync handler for it.  Minixfs and any
other fs can call this routine once at startup.

The advantage of this method is that it will mean only one update
daemon will be needed, to call Fsync() repeatedly, no matter how many
filesystems are installed.

>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.

My guess would be that the daemon would get some slices whenever the
GEM program entered the Bios/Xbios/Gemdos (more uneducated guesses
here...)  which are the only times it would really matter.  I guess it
would be unfortunate if the sequence went: gem program makes Gemdos
call, context switch to update daemon occurs, daemon does Fsync()
[nothing happens since Gemdos calls hasn't done anything yet], context
switch back to gem program's Gemdos call occurs, gemdos call
completes, gem program continues and hogs the system again, preventing
the update daemon from forcing the sync.  I'll leave it to the real
gurus to figure out if this is the case.

Cheers,
entropy