Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove cruft. Update to current reality.

This commit is contained in:
gdt 2007-04-08 13:50:51 +00:00
parent fc6776f366
commit 5fa91a46b1
3 changed files with 28 additions and 153 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
sys/coda/00READ
View File

@ -1,71 +0,0 @@
What needs to be done to port Coda to a different Architecture.
I. Fixes for the Coda applications
Coda is a package under net/coda_*; so it should be easy enough to
build. But there are a few specific files that need to be changed
first. Of course, setting it up and using it is harder.
1. coda/lib-src/mlwp/process.s
Coda coda/mlwp/ implements light weight user threads. The process.s
file contains stack switching code. It needs to be recoded for your
architecture. There is some old dead code in the file that you might
be able to resurrect for other platforms. At present, only the x86
case, ns32k case and arm32 case (and possibly linux sparc) work.
2. coda/coda-src/venus/fso_cfscalls2.cc
The Coda file system expands the strings @cputype and @sys in file
names in a platform specific way. In fso_cfscalls2.cc, under a
__NetBSD__ conditional, there is platform conditional that defines:
static char cputype []
static char systype []
Add the values for these strings under a conditional for your
architecture.
II. Fixes for the Coda kernel
The coda/ directory in the kernel is machine independent. The various
pieces of glue code, viz. conf/files, sys/vnode.h, are in place. You
do have a few platform changes:
1. src/sys/arch/xxx/conf/GENERIC or others
It would be best to take the few lines that define Coda and its communications
pseudo device from the x86 GENERIC and put them into your platform GENERIC.
They should look something like:
file-system CODA # Coda File System; also needs vcoda (below)
# a pseudo device needed for Coda # also needs CODA (above)
pseudo-device vcoda 4 # coda minicache <-> venus comm.
2. src/sys/arch/xxx/conf/majors.xxx
Coda needs a pseudodevice, vcoda, to communicate between the kernel and the
out of kernel client program, venus.
By way of example for the x86, you add:
device-major vcoda char 60 vcoda
to the majors file.
3. src/etc/xxx/MAKEDEV
Something like the code below should work; The chr device
that is appropriate for your platform should be used instead of 60.
cfs0)
name=cfs; unit=${i#cfs}; chr=60
rm -f $name$unit
mknod $name$unit c $chr $unit
chown root.wheel $name$unit
;;
We only support one device currently, but historically it is cfs0.
III. More?
There still may be a couple of other problems. If so, let us know.

70
sys/coda/README
View File

@ -1,60 +1,24 @@
Announcing the Availability of the
Coda Distributed
Filesystem
for
BSD Unix Systems
$NetBSD: README,v 1.3 2007/04/08 13:50:51 gdt Exp $
Coda is a distributed file system like NFS and AFS. It is
freely available, like NFS. But it functions much like AFS in being a
"stateful" file system. Coda and AFS cache files on your local
machine to improve performance. But Coda goes a step further than AFS
by letting you access the cached files when there is no available
network, viz. disconnected laptops and network outages. In Coda, both
the client and server are outside the kernel which makes them easier
to experiment with.
Coda is a distributed filesystem. It is derived from AFS, but
supports disconnected operation, both reading and writing. This
directory contains the interface between the VFS layer and a
user-space program ("venus") that implements the client part of Coda.
The interface is similar to puffs(9) in many respects.
To get more information on Coda, I would like to refer people to
http://www.coda.cs.cmu.edu
There is a wealth of documents, papers, and theses there. There is
also a good introduction to the Coda File System in
http://www.coda.cs.cmu.edu/ljpaper/lj.html
Coda servers do not need kernel support.
Coda was originally developed as an academic prototype/testbed. It is
being polished and rewritten where necessary. Coda is a work in
progress and does have bugs. It is, though, very usable. Our
interest is in making Coda available to as many people as possible and
to have Coda evolve and flourish.
For information on Coda, see
http://www.coda.cs.cmu.edu
The bulk of the Coda file system code supports the Coda client
program, the Coda server program and the utilities needed by both.
All these programs are unix programs and can run equally well on any
Unix platform. Our main development thrust is improving these
programs. There is a small part of Coda that deals with the kernel to
file system interface. This code is OS specific (but should not be
platform specific).
As of April 2007, Coda is not quite stable enough for demanding
production use, but is usable by those who are willing to deal with
problems. Help can be obtained via the list codalist@coda.cs.cmu.edu.
Coda is currently available for several OS's and platforms:
Freebsd-2.2.5: i386
Freebsd-2.2.6: i386
Freebsd -current: i386
linux 2.0: i386 & sparc
linux 2.1: i386 & sparc
NetBSD 1.3: i386
NetBSD -current: i386
The relevant sources, binaries, and docs can be found in
ftp://ftp.coda.cs.cmu.edu/pub/coda/
As of April 2007, pkgsrc/net/coda\* is old, and gdt recommends running
code from Coda's CVS.
We intend to come out with new Coda releases often, not daily. We
don't want to slight any OS/platform not mentioned above. We are just
limited in our resources as to what we can support internally. We
will be happy to integrate OpenBSD support as well as other OS
support. Also, adding platform support should be relatively easy and
we can discuss this. The only difficulty is that Coda has a light weight
process package. It does some manipulations in assembler which would
have to be redone for a different platform.
There are several mailing lists @coda.cs.cmu.edu that discuss coda:
coda-announce and linux-coda. We are going to revise linux-coda to be
OS neutral, since it is mainly Coda we want to discuss. We appreciate
comments, feedback, bug reports, bug fixes, enhancements, etc.
As of April 2007, the kernel code has not been tested on 64-bit
architectures. It runs on i386 and has previously been tested on
sparc.

40
sys/coda/TODO
View File

@ -1,37 +1,19 @@
$NetBSD: TODO,v 1.3 2006/04/04 13:20:39 gdt Exp $
$NetBSD: TODO,v 1.4 2007/04/08 13:50:51 gdt Exp $
1. coda_lookup locking
1. getcwd
coda_lookup does not follow the ISDOTDOT locking rules described in
sys/kern/vnode_if.src.
getcwd does not work.
2. getcwd
2. VOP_GETPAGES/PUTPAGES
getcwd does not work. (Fixing coda_lookup may fix this.)
Check behavior vs. specifications.
Resolve uvm_fault layering issue (see PR 28372).
3. LK_RETRY removal
3. check vnops correctness
Remove the use of LK_RETRY in coda_lookup, and check remaining uses
for correctness.
Check all vnops against their specifications.
4. coda_close cleanup
4. LK_RETRY removal
Understand, comment, and clean up '#ifdef hmm' in coda_close.
From 1998 (likely no longer correct):
Near term:
check cfs_vnodeops.c: re vrele/VOP_LOCK -> vget
cfs_create, remove, link mkdir, rmdir, symlink
cfs_vfsops.c: use vfsp vs 0
cp = makecfsnode(&ctlfid, vfsp, VCHR);
Medium term:
Add missing VFS methods.
Do performance profile.
Tune hash algorithm used in cfs_namecache.
Eventually:
Use standard queue macros.
Remove the use of LK_RETRY in most or all vn_lock calls.
(Defer this until other filesystems do not call LK_RETRY.)