Re: [Geekos-devel] System calls

[David H. <da...@cs...>]

On Thu, Feb 21, 2002 at 02:54:05AM +0000, Vishal Soni wrote:
> I am planning to implement a MINIX like file system. But before starting 
> this I wanted to make certain points clear.

Great idea!

> Do we have a system call 
> interface ready or do we need to implement one?
> 
> If we dont have a system call interface i could look into it first because 
> i think it makes sense to implement a system call layer before implementing 
> a file system.

A rudimentary system call interface exists:
  kern/syscall.c
  user/libc/include/syscall.h
  user/libc/src/syscall.c

The system call number is passed in eax, parameters are
passed in other registers, return value is in eax.

There are copy_to_user() and copy_from_user() functions
to copy data to/from user space.  Right now they don't check that
the user buffer is valid, i.e. that it is actually in user
space, is readable or writable, and that the pages are present.
I'm planning on fixing them soon.

The real issue, of course, is that we need a user/kernel API
and we need to decide on how to implement it.  I would really like
suggestions on how to approach this.

In the virtual memory code, there is an abstraction called
memory_object, which is a collection of pages.  User processes
can map these into their VM space.  The "memory_object" has
a pointer to a "pager" which is a source and sink for data.
(If this sounds familiar, the ideas were all stolen from 4.4 BSD,
which took its VM system from Mach.)

I'd like the design of file I/O to use these memory_objects as
their file buffer cache, so that read() and write() system calls
are automatically coherent with memory-mapped file I/O.

Right now, I'm thinking the design would be something like the
following:

  - you implement a "disk pager", which implements the pager
    interface for IDE devices, using your IDE driver

  - the filesystem uses the disk pager to communicate with
    the hard drive

  - the filesystem handles requests to open and close files
    and directories residing it it

  - an instance of a file is represented by a "file pager",
    which handles the I/O, and a memory object, which caches
    the pages

Then a "file instance" object in the OS would have a reference to
the memory object, and would use it to read/write/seek/etc.

There are lots of unresolved issues here, such as

  - how does the filesystem store and cache metadata?

  - how do we implement semantics such as copy-on-write mappings?
    I think BSD uses stacks of memory objects for this.

  - When do we commit writes to the underlying file pager
    (to initiate real output to disk)?

  - How do we do page stealing?

  - If the number of references to a memory object drops to
    zero, we probably don't want to throw it away immediately,
    since it might be used again.  Whose responsibility is
    it to cache recently used persistent memory objects?

Thoughts?

-Dave