Return to BSD News archive
Xref: sserve comp.os.minix:22428 comp.os.386bsd.misc:563 comp.os.linux:46100 Newsgroups: comp.os.minix,comp.os.386bsd.misc,comp.os.linux Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!gatech!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Re: Choosing a Unix like OS for a pc Message-ID: <1993Jul1.215149.734@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <201f9p$kkv@klaava.Helsinki.FI> <203s5k$j9u@urmel.informatik.rwth-aachen.de> <20th87$q0q@dumbo.cc.utexas.edu> Date: Thu, 1 Jul 93 21:51:49 GMT Lines: 42 In article <20th87$q0q@dumbo.cc.utexas.edu> mcintosh@dumbo.cc.utexas.edu (aubrey mcintosh) writes: [ ... on Oberon ... ] >There are several ports from the original >"on the silicon" system which essentially replace the file system >with hooks to the underlying OS. Depending on the memory models >available to current '386 Minixen, it might be possible to have a >Minix/Oberon running very soon. > >I would be especially interested in hearing comments from old hands, >after reviewing Oberon, although it seems the other end of the >spectrum than Amoeba with one user, one process, one cpu. Mapping a user space rather than a kernel space implementation of a file system introduces some rather nasty synchronization issues that won't go away, even with a change notification mechanism in the kernel file system to call-back changes to the user process. The problem is file contention with other user processes (other than Oberon). The basic issue that is unresolvable is that you will always have a "cache" in user buffers used to do file system operations on the memory mapped file pages, and that this cache can never be guaranteed to be up to date with the data in the vnode buffers (aka the file) if "I/O" operations are not atomic across the entirety of the manipulation. There are only three potential soloutions: real time your Oberon process, write a user space SPL function, or push the Oberon I/O into the kernel, where the syscall interface will guarantee its atomicity. None of these soloutions is very practicable or the least bit pleasent. Anything other than this for *any* hosted OS is simply blue sky and a toy, since integrity of files is compromised for all instances where the hosting OS is running other applications at the same time on intersecting file sets (for example, a "directory folder window" will incorrectly reflect directory contents if changes are made using a process other than Oberon -- it will become an outdated snapshot). Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.