..
    Date: Mon, 29 Jun 1998 00:58:22 -0400 (EDT)
    From: Elliot Lee <sopwith_at_cuc.edu>
    ..
    To: linux-coda_at_TELEMANN.coda.cs.cmu.edu
    cc: sanm_at_corelcomputer.com
    Subject: Re: Coda Network Computer 
    In-Reply-To: <199806290152.VAA06841_at_chef.redhat.com>
    ..
    On Sun, 28 Jun 1998 djb_at_redhat.com wrote:
    
    > > 4) The next step is tackle booting.  The target here is to have a
    > >    system that can get to the point of starting to run
    > >    /coda/linuxroot/sbin/init as process ID 1.  Achieving this will be
    > >    a major milestone, even if the init process immediately gets
    > >    confused!
    > 
    > Maybe I'm missing something, but doesn't the Linux initrd facility
    > handle this?  Couldn't you put your startup stuff in an initrd image
    > and create your startup script as /linuxrc in the initrd?  I thought
    > that this kind of thing was the point of the initrd, but I've never
    > played with it enough to see if it can do what you need above...
    
    Is there a size limit on how much can be put into initrd image?
    
    venus is fairly big (6 megs unstripped here, probably at least a meg
    stripped, and that's dynamically linked to libstdc++ and all), and unless
    you use the "do BOOTP in the kernel" feature of 2.1.x, you'd need all the
    networking tools too. 
    
    For a completely diskless client, perhaps going the route of mounting root
    via NFS, and then using that to bootstrap things up into action. The only
    problem is, I don't know if coda will work on a diskless client with no
    place to put /usr/coda/venus.cache on :)
    ..

Elliot, Peter, Michael, (the mysterious) sanm_at_corelcomputer.com and
Fellow Codaphiles,
    We are constructing a multicomputer which will use the Linux<->Coda
kernel interface as its (network) filesystem interface.  Many of the good
features of Coda, mainly those features which are needed to support
disconnected operation and robust internal authentication, will not be
required by our system area network.  For this reason we are using neither
venus not vice but are rewriting our own cache manager and file server.  
Nevertheless, the Linux<->Coda kernel interface is (almost) exactly what
we need so we are keen to see it thrive.
    Though progress was slow at first -- we stumbled about for a while
before we found Coda -- on Friday evening last we booted our first
Coda-root-filesystem-based computer using a similar approach to that
described in Michael and Peter's mail to the list of earlier today.
However, rather than use the /dev loopback mount method we have patched
the Linux kernel Coda fs code to support fifos, char- and block-special
devices.  The first of these patches has been incorporated into the
current Coda source, the second Peter says will be included later this
week.
    We load an initrd from the network (via the EtherBoot 4.0 package,
currently on a diskette but often stored on a boot ROM).
It (re)initialises the network interface, runs mkfs on the local cache
filesystem partition, sets up a swap partition, starts the local
(Venus-like) cache manager (which immediately connects to a remote
file server), mounts the Coda(-like) filesystem on a subdirectory of the
initrd and then chdir()s and chroot()s into it, exec()ing /sbin/init
as it goes.  (RAM disks have a default maximum size of 4MB but this can
be increased via an explicit parameter.)

    The remote filesystem is pretty much a standard Linux root filesystem
(actually a Slackware distribution).

    For now our file server supports just one client and the system is
fragile and not particularly fast, but we have passed an interesting
milestone.   In view of the recent mail on this list, now is probably
as good a time as any to put our heads up.

Cheers,
Bruce Janson, Basser Department of              Email:  bruce_at_cs.usyd.edu.au
Computer Science, Madsen Building (F09),        Phone:  +61-2-9351-3423/4
University of Sydney, N.S.W., 2006, AUSTRALIA   Fax:    +61-2-9351-3838