Re: PL5 in progress ...

[Stephen Usher <steve@earth.ox.ac.uk>]

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

This is what Unix does, and as MiNT is mostly following Unix-like ideas and
Minixfs is also Unix-like I think this is the way to go.

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

Also, MiNT itself could call this every so often, just incase there's no
daemon running. MiNT would also call this when init exits. Maybe Fsync()
should have a partner, SFsync() ie Shutdown-filesystem-synchronise which
would let the filesystems do final synchronisation and possibly set a bit in
the header telling any future auto-fscking program that the filesystem need
not be checked at boot time, just as SunOS 4.1.[23] and SunOS 5.x does.

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

>From what I've observed, MiNT gets locked out of the system until an event
happens and the application is given control back, ie. GEM busy-waits within
a system call. This would have to have been fixed in MultiTOS GEM!

>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

Just my tu'pence worth.

Steve

-- 
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
Tel:- Oxford (0865) 282110 (UK) or +44 865 282110 (International).