9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9P, procedure calls, kernel, confusion. :(
Date: Tue,  5 Feb 2008 10:42:50 +0000	[thread overview]
Message-ID: <a169f3a83f79feb0b97b6f129c0bd7f9@terzarima.net> (raw)
In-Reply-To: <1b7f448f-8a38-4283-944b-07a9a08aa255@q39g2000hsf.googlegroups.com>

you can see the structures themselves in /sys/src/9/port/portdat.h

inside the kernel, the traditional integer file descriptor indexes an array of pointers to (possibly shared)
instances of the channel data structure, Chan, which contains the integer fid, an open mode, a current offset,
and most important a pointer (or an index into a table of pointers)
to the Dev structure for the device driver associated with the Chan.  each device driver implements its
own name space (ie, operations such as walk, dirread, stat) including the file i/o
operations (eg, open, read, write).  most drivers use a small library (/sys/src/9/port/dev.c)
to make implementing simple name spaces mainly a matter of defining a table
and some conventional calls for walk, stat, wstat, open, and dirread (which is handled as a special
case inside the device's read operation, not as a separate entry in Dev).

all open files have a Chan, but not all Chans correspond to open files (they can mark
current directories, or more interesting the current location in a walk of a name space).

inside the kernel, operations are done by
	Chan *c = p->fgrp->fd[fd];
	devtab[c->type]->walk(c, ...);
	devtab[c->type]->read(c, va, n, offset);
and so on.  fairly obvious stuff, really.

>Q. Does it mean that every RPC message essentially has to end up being implemented via that procedural interface?

one interesting driver (ie, one Dev) is the `mount driver' (/sys/src/9/port/devmnt.c).  its implementations
of walk, open, stat, read, write, etc build 9P messages representating the corresponding operations and
exchanges them on any given file descriptor (ie, Chan) using devtab[...]->write and devtab[...]->read
so it doesn't care what sort of file descriptor is used (pipe, network, ...).

(an alternative might be to use 9P messages throughout.)

>>>"A table in the kernel provides a list of entry points corresponding one to one with the 9P messages for each device."
>Q. Can I relate this 'table in the kernel' to the 'representation in a

it's the devtab[] that lists pointers to the Dev structures representing configured devices.


  reply	other threads:[~2008-02-05 10:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-05  9:56 Siddhant
2008-02-05 10:42 ` Charles Forsyth [this message]
2008-02-05 12:59 ` [9fans] " Siddhant
2008-02-05 16:41   ` Charles Forsyth
2008-02-05 16:35     ` erik quanstrom
2008-02-06  9:45     ` Siddhant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a169f3a83f79feb0b97b6f129c0bd7f9@terzarima.net \
    --to=forsyth@terzarima.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).