ast@cs.vu.nl (Andy Tanenbaum) (06/12/90)
Here is the long awaited Amoeba driver for MINIX 1.5. First a bit of
introduction. Read the whole thing to see the relevance to MINIX.
Amoeba is a new operating system. It is a complete
operating system that runs on the bare hardware, just as UNIX, MINIX, MS-DOS,
OS/2, and VMS do. It contains process management, memory management,
a file system, and comes with over 100 utilities, just as all the above do.
You can think of it as an alternative to MINIX.
However, Amoeba is targeted at the other end of the spectrum. Whereas
MINIX is for single user, low-end, home and educational users with one
smallish machine, Amoeba is a full-fledged distributed system aimed at
high performance applications. At the Vrije Universiteit, we are running
it on a system with some 30-odd 68020s and 68030s. Its goal is to make
the whole collection of hardware look and act like a single system. Users
are not aware of where jobs run, where files are stored, etc. It is just
one big system. This is in contrast to say, Sun UNIX, in which users are
very much aware of the machine boundaries.
In addition to being distributed, Amoeba has been designed to be very fast.
Our major customer at the moment is the European Space Agency, which is
using it as the operating system for a digital system for transmitting
real time video over a fast LAN. Right now they have 1 camera on the
spacecraft, but eventually they want to have 50, and be able to dynamically
switch channels etc digitally. As you can well imagine, high performance
is a major issue here. That is why Amoeba was chosen over UNIX, Chorus,
Mach etc.
If you want to learn more about Amoeba, see the May 1990 issue of IEEE
Computer Magazine. If you want still more information, there is a 300
page book about Amoeba available via anonymous FTP on midgard.ucsc.edu
in the directory ftp/pub/amoeba in both source and compress postscript
form. Amoeba will be available to universities for a modest licensing
fee (probably $500 to $1000), including all the source code, in the second
half of 1990. It runs on Sun-3s, VAXes, and 386s. If we can find someone
to finance it, we will port it to RISC machines as well.
This said, what does Amoeba have to do with MINIX? In theory, nothing.
However, since I am the chief architect of both systems, when looking
around for a network protocol to put in MINIX, I was naturally attracted
to the Amoeba protocol, due to its great speed. Thus we have written a
driver for MINIX (and also one for UNIX) that implements the Amoeba
protocol for MINIX systems. In this way, two Amoeba systems can
communicate over an Ethernet using the WD board. Software is also
provided for remote login, file transfer, and other goodies. When using
the Amoeba protocols, Sun-3s, MINIX systems etc can talk to each other
over the Ethernet. The Amoeba driver I am about to supply is for the
IBM version of MINIX only.
Rather than post cdiffs against 1.3, I have decided to post the whole
thing. Please note that you can run Amoeba on a SINGLE MACHINE. You
do not need an Ethernet or two machines. All you have to do for the
single machine version is put the -DNONET flag in all the Makefiles.
This allows you to experiment with networking, RPC, etc. without a network,
but the code you develop will run unmodified on a real Ethernet.
Below you will find two items: The crcs for the amoeba directory, and
the manual. Please install amoeba at the top level, i.e., in the same
directory as kernel, mm, fs, and tools. This is essential, as it accesses
the kernel directory via ../stuff.
The posting consists of 4 parts. This one (part 0), parts 1 and 2 (the
kernel directory) and part 3 (the fs, mm, examples, and util directory,
and the top level Makefile, all shar'ed together for posting purposes).
The amoeba directory looks like this:
-rw-r--r-- 1 ast 239 Jun 29 1990 Makefile
drwxr-sr-x 2 ast 512 Jun 2 14:41 examples
drwxr-sr-x 2 ast 512 Jun 2 14:41 fs
drwxr-sr-x 2 ast 1024 Jun 2 14:41 kernel
drwxr-sr-x 2 ast 512 Jun 2 14:41 mm
drwxr-sr-x 2 ast 512 Jun 29 1990 util
Have fun.
Andy Tanenbaum (ast@cs.vu.nl)
echo x - amoeba.crc
sed '/^X/s///' > amoeba.crc << '/'
X54723 239 amoeba/Makefile
X54723 239 amoeba/Makefile.pc
X58850 460 amoeba/examples/Makefile
X58850 460 amoeba/examples/Makefile.pc
X06696 3080 amoeba/examples/READ_ME
X36731 1370 amoeba/examples/client1.c
X15288 1746 amoeba/examples/client2.c
X15305 5795 amoeba/examples/client3.c
X55621 199 amoeba/examples/header.h
X23651 852 amoeba/examples/server1.c
X16916 741 amoeba/examples/server2.c
X03452 2090 amoeba/examples/server3.c
X33919 4377 amoeba/fs/Makefile
X33919 4377 amoeba/fs/Makefile.pc
X35631 6452 amoeba/kernel/M
X30258 6487 amoeba/kernel/Makefile
X30258 6487 amoeba/kernel/Makefile.pc
X11736 28316 amoeba/kernel/amoeba.c
X48298 215 amoeba/kernel/amstat.h
X11854 1621 amoeba/kernel/assert.h
X06448 654 amoeba/kernel/byteorder.h
X52934 894 amoeba/kernel/conf.c
X30284 610 amoeba/kernel/conf.h
X33713 8134 amoeba/kernel/dp8390.c
X10565 8035 amoeba/kernel/dp8390.h
X29357 389 amoeba/kernel/dp8390info.h
X28437 821 amoeba/kernel/dp8390stat.h
X28320 172 amoeba/kernel/eplinfo.h
X50760 465 amoeba/kernel/etherformat.h
X59425 1347 amoeba/kernel/etherplus.c
X21899 826 amoeba/kernel/etherplus.h
X46334 32 amoeba/kernel/exception.h
X59877 1354 amoeba/kernel/global.h
X25776 1958 amoeba/kernel/internet.h
X27965 1427 amoeba/kernel/mpx.H
X43095 1139 amoeba/kernel/portcache.H
X24020 12208 amoeba/kernel/portcache.c
X42274 255 amoeba/kernel/portstat.h
X38600 1259 amoeba/kernel/task.h
X00190 4005 amoeba/kernel/trans.H
X45540 35796 amoeba/kernel/trans.c
X56652 916 amoeba/kernel/util.c
X36548 298 amoeba/log
X42699 1965 amoeba/mm/Makefile
X42699 1965 amoeba/mm/Makefile.pc
X41503 4256 amoeba/mm/amoeba.c
X64143 452 amoeba/util/Makefile
X64143 452 amoeba/util/Makefile.pc
X61433 767 amoeba/util/READ_ME
X23849 1312 amoeba/util/from.c
X32980 1337 amoeba/util/master.c
X43064 1488 amoeba/util/prot.c
X07462 1437 amoeba/util/rcp
X59949 4628 amoeba/util/rsh.c
X62914 8557 amoeba/util/sherver.c
X60854 421 amoeba/util/sherver.h
X13378 940 amoeba/util/to.c
/
echo x - amoeba.man
sed '/^X/s///' > amoeba.man << '/'
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X 11
X
X
X
X
X NETWORKING
X
X
X MINIX supports networking. This chapter describes the kind of support pro-
Xvided, how to use it, and how it should be installed.
X
X
X11.1. INTRODUCTION
X
X Network software can be divided into two general categories differing in the
Xway the software is integrated into the operating system and the user software.
XWhen networks first developed, they were used over slow wide-area links (56 kbps
Xor less), so the designers' main concern was using the available bandwidth effi-
Xciently. Programmer convenience was not considered. Later, as higher bandwidth
Xnetworks became widespread (especially local area networks, such as Ethernet),
Xthe focus changed from worrying about bandwidth utilization, to worrying about
Xmaking the network interface convenient for the programmers. This evolution is
Xvery similar to the evolution from assembly language programming, where the
Xmachine came first, to programming in high level languages, where the programmer
Xcame first.
X Networks of the first type of are said to be connection oriented, and use
Xwhat are called _s_l_i_d_i_n_g _w_i_n_d_o_w _p_r_o_t_o_c_o_l_s. All older networks, especially wide
Xarea networks, are of this type. Some of the better known protocols are X.25,
XTCP/IP, and OSI. Networks of the second type are connectionless, and use what
Xis called remote procedure call (RPC). Virtually all modern distributed operat-
Xing systems are based on this concept. Some well-known examples are the work of
X
X
X 277
X
X
X
X
X
X
X
X
X
X
X278 NETWORKING CHAP. 11
X
XXerox PARC [1], the V kernel [2], and Amoeba [3-11]. While it is certainly pos-
Xsible to build RPC on top of a connection-oriented protocol, this approach is
Xinefficient compared to building the RPC on top of the bare network. For an
Xintroduction to connection-oriented protocols, RPC, and networking in general,
Xsee [12].
X Networking in MINIX is based on RPC. Briefly summarized, communication
Xbetween two processes works as follows. One of the processes, called the
X_s_e_r_v_e_r, has some service to offer, such as a file storage. The other process,
Xthe _c_l_i_e_n_t, wants to use this service. The interface to the service consists of
Xa collection of procedures that the client can call. In the case of a file
Xserver, the procedures might be CREATE_FILE, RENAME_FILE, READ_DATA, WRITE_DATA,
Xand so on. These are library routines available on the client's machine.
X When the client calls one of these procedures, the procedure sends a message
Xto the server containing the procedure name and its parameters. The procedure
Xthen blocks waiting for the reply. When the message gets to the server, it is
Xdecoded there and executed. The reply is sent back to the calling procedure on
Xthe client's machine, which then returns the results to the caller. From the
Xprogrammer's point of view, having remote services in the network essentially
Xmeans that there is a new collection of procedures to call. The programmer is
Xnot burdened with concepts like opening connections, sending data, or thinking
Xin terms of acknowledgements, all of which are needed in the connection-oriented
Xmodel. Nor is the network software burdened with having to manage connections.
X In effect, RPC is based on the abstraction of the procedure call, whereas
Xconnection-oriented networks are based on the much lower-level concept of making
Xthe network look like an input/output device. While at first glance it might
Xseem that connection-oriented networking could be made to fit with the
XUNIX/MINIX concept of a pipe, pipes are set up in a very different way (by a
Xcommon ancestor), and fit very poorly to the most common style of local area
Xnetwork programming, where the client has a request and the server gives a
Xresponse. With wide area networks, this kind of interaction is painfully slow,
Xdue to the low bandwidth, so the only services generally available are mail and
Xfile transfer, which are batch-oriented. MINIX networking has been designed for
Xinteractive use on high performance local area networks, so for this reason, RPC
Xhas been chosen over the older connection-oriented style.
X In particular, MINIX networking has been designed to be compatible with the
Xform of RPC used in the Amoeba distributed operating system [3-11]. Not only
Xhave the concepts and the implementation been well tested, but the performance
Xis exceedingly good. For example, for doing file transfers, something that
Xconnection-oriented protocols are supposed to be good at, Amoeba running on two
XSun 3s achieves triple the throughput of TCP/IP running on the same hardware.
XData transfers between two Zenith Z-248s running the Amoeba RPC on MINIX have
Xbeen measured at 165 kbytes/sec, almost as fast as TCP/IP transfers between two
XSun 3/50s. Considering that the Suns are two times as fast as the Z-248s and
Xthe network software is 100% CPU limited (doubling the CPU speed doubles the
Xthroughput), this is a strong argument for the Amoeba RPC. As a final statis-
Xtic, the RPC throughput between a client and server located on the same Z-248 is
X1.5 Mbytes/sec, an extremely high figure for this class of machine, and much
Xbetter than what Suns and VAXes normally achieve locally, despite their greater
XCPU power. In conclusion, although RPC was chosen for its elegance and ease of
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XSEC. 11.1 INTRODUCTION 279
X
Xuse, it turns out that it also has excellent performance, even doing things like
Xbulk transfer, and certainly doing things like short request-reply interactions.
X A few words about Amoeba are probably in order here. It is a distributed
Xoperating system that was developed at the Vrije Universiteit in Amsterdam and
Xis now being further developed there and at the Centre for Mathematics and Com-
Xputer Science in Amsterdam. It currently runs on the Sun 3 (and other 680x0
Xprocessors), VAXstations, and 80386s. Note that Amoeba is a complete operating
Xsystem, just like UNIX, MINIX or VMS. The only relation between Amoeba and MINIX
Xis that MINIX networking uses the Amoeba RPC protocols. Other than that they
Xare quite different in structure, funtionality, and goals. Amoeba was designed
Xto run on systems consisting of dozens of processors, and yet give the program-
Xmer the illusion that it is a traditional single-CPU time sharing system. For
Xmore information about Amoeba, see the references.
X
X
X11.2. OBJECTS
X
X Amoeba is an object-based system, and to a considerable extent this orienta-
Xtion is reflected in the protocol. As a consequence, MINIX also acquires a cer-
Xtain object-orientation. Very briefly, an object is a programmer defined
Xabstract data type that has well-defined operations on it. As an example, a
Xfile server could define file and directory objects, and provide operations to
Xread and write the file objects, and insert files in, and delete files from,
Xdirectory objects. Clients can perform these operations by doing RPCs with the
Xfile server. Henceforth we will adopt the Amoeba terminology and call these
XRPCs _t_r_a_n_s_a_c_t_i_o_n_s. A transaction consists of a request message from a client to
Xa server, followed by a reply message from the server back to the client.
X It is up to the writer of each server to decide what kinds of objects the
Xserver will support and what operations will be available on them. The struc-
Xture of the system guarantees that clients can only perform the operations pro-
Xvided by the server. This style of networking is intended to force constraints
Xon programmers, just as high-level languages force constraints on former
Xassembly-language programmers.
X Objects are normally protected by capabilities, which are currently (Amoeba
X4.0) 128-bit numbers, although in the the next version of Amoeba (Amoeba 5.0)
Xthis will become 256 bits. When a client asks a server to create an object, the
Xserver returns a capability for the object. This capability must be presented
Xby the client to perform subsequent operations on the object. In Amoeba, capa-
Xbilities are protected crytographically. Since the MINIX kernel, unlike the
XAmoeba kernel, was not designed from scratch as a distributed system, the pro-
Xtection aspects in MINIX are not fully implemented.
X A capability has 4 fields, described below. These fields are important
Xbecause they appear in the Amoeba and MINIX message headers.
X Port: 48-bit number used to identify the server owning the object.
X Object: 24-bit number used by the server to identify the object
X Rights: 8 bits telling which operations are allowed
X Cksum: 48-bit checksum to prevent tampering with the capability
XThe _p_o_r_t field is a (random) 48-bit number used for addressing. Any 48-bit
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X280 NETWORKING CHAP. 11
X
Xnumber can be used as a port. In some situations, an ASCII string can be used
Xas a port, with the first 48 bits taken as the port number. All messages in
XAmoeba and MINIX are sent to ports, not to machine addresses. The mapping of
Xports to machine addresses is done deep down in the system, and is of little
Xconcern to the average programmer. Thus: a port uniquely identifies a server
Xand provides a logical address to which all messages for the server are sent.
X The remaining three fields are called the private part of the capability. In
Xtheory, each server can use them any way it wants to. In practice, to prevent
Xtotal chaos, all existing servers adhere to the following conventions (just as
Xmost UNIX programs adhere to the convention that certain files contain ASCII
Xcharacters with a line feed at the end of each line). The _o_b_j_e_c_t field is used
Xby the server to identify the specific object being accessed. For example, when
Xa file server created a new file on behalf of a client, it could put the i-node
Xnumber of the new file in this field, so that when the client later used the
Xcapability, the server could tell which file was being addressed. The field is
X24-bits long, providing each server with 16 million object identifers.
X The _r_i_g_h_t_s field contains a bit map for up to eight protected operations.
XEach bit controls permission to perform one operation. Thus a file server could
Xallocate bit 0 for READ_DATA, bit 1 for WRITE_DATA, bit 2 for APPEND_DATA, bit 3
Xfor DELETE_FILE, and so on. When a capability arrives from a client, the server
Xchecks to see if the bit corresponding to the relevant operation is on. If it
Xis not, the operation is rejected. In this way, a user can create a file, ask
Xthe server to turn off the WRITE_DATA and DELETE_FILE bits, and then give the
Xcapability to another user. This new user cannot perform WRITE_DATA and
XDELETE_FILE operations, but can perform the operations whose bits are turned on.
X A moment's thought will reveal that the above protection scheme is worthless
Xif users can turn the rights bits on and off by themselves. To prevent this,
Xthe _c_k_s_u_m field is used. When creating a new object, the server simultaneously
Xcreates a random number and stores it in its internal tables (e.g., in the i-
Xnode). It then combines the rights bits and the random number, and passes the
Xresult through a one-way cryptographic function. The result of this function is
Xput in the _c_k_s_u_m field. When a capability comes in from a client, the server
Xuses the object number to locate the original random number. It then combines
Xit with the rights bits present in the capability, and runs the result through
Xthe one-way function. If the result disagrees with the _c_k_s_u_m field, the capa-
Xbility is considered invalid, and an error return is sent back. In this way,
Xusers who change the rights bits will simply invalidate their capabilities.
XAttempts to break the scheme by finding an inverse to the one-way function can
Xbe handled by choosing a cryptographically strong one-way function. Brute force
Xdoes not work either, as picking checksums at random will require, on the aver-
Xage, 2**47 attempts to guess the 48-bit checksum. Since a null transaction over
Xa 10 Mbit/sec Ethernet using SUN 3/50s takes about 1.4 msec, about 3000 years
Xare needed to perform the search. Furthermore, it is easy enough to program a
Xserver to artificially increase the transaction time to 1 sec after 10 unsuc-
Xcessful attempts have been made, thus increasing the mean search time to
X3,000,000 years.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XSEC. 11.3 OVERVIEW OF TRANSACTIONS 281
X
X11.3. OVERVIEW OF TRANSACTIONS
X
X To summarize what we have covered so far, the normal style of networking in
XMINIX (and Amoeba) is to structure dialogues in terms of clients and servers.
XEach server manages one or more types of objects, and provides operations for
Xclients to perform operations on these objects. When a client asks a server to
Xcreate an object for it, the server then returns a capability for the object to
Xthe client. This capability identifies the server, identifies the object, and
Xtells which subset of the operations the holder of the capability may perform.
XTo have an operation performed, the client sends a request message to the server
X(with the capability embedded in the message header), and the server then sends
Xback a reply. In most cases, the calls to the server are embedded in library
Xprocedures, called _s_t_u_b_s, to encapsulate the message passing and hide it from
Xthe users.
X Transactions provide a basis for a large number of user services. In MINIX,
Xusers can use them to build arbitrary services. Two key services are provided
Xas standard for MINIX, remote execution and remote file copying. These services
Xmake use of a process called the shell server, or sherver for short. The
Xsherver accepts messages from remote (or local) clients, executes the commands
Xin them, and returns the output.
X Communication is implemented as follows. Each server listens to a unique 48-
Xbit port. A client that wants service from the server sends a request to that
Xport and blocks until it receives a reply. (If the client cannot find anyone
Xlistening to the port after a given period, it times out and returns an error
Xstatus.) When the server is ready, it returns a reply to the client, which
Xthen continues execution. Each transaction is independent of the previous tran-
Xsactions; there is no connection or virtual circuit.
X Clients must have some way of discovering a server's port. Under Amoeba a
Xdirectory server is used. The directory server stores capabilities for objects
Xand associates them with an ASCII string. The directory server has a well known
Xport. Under MINIX you make initial contact with a sherver that has a well known
Xport and then the sherver creates a secret port for all further transactions on
Xthat machine.
X There are four stub routines in the user library which provide the basic
Xinterface between user processes and transactions. They are:
X 1. _g_e_t_r_e_q - Get request (used by servers to get a request)
X 2. _p_u_t_r_e_p()- Put reply (used by servers to send reply)
X 3. _t_r_a_n_s()- Transaction (used by clients to do a transaction)
X 4. _t_i_m_e_o_u_t- Sets the time limit at which _t_r_a_n_s gives up
XGetreq() and _p_u_t_r_e_p are used by servers to get a request from a client and to
Xsend a reply. A server may not do a _g_e_t_r_e_q until it has replied to the previous
X_g_e_t_r_e_q. The call _t_r_a_n_s is used by clients to send a request to a server. It
Xblocks until a reply or a signal arrives, or, if it cannot find a server listen-
Xing to his port, it times out and returns an error code. The length of the
Xtimeout is set using the function _t_i_m_e_o_u_t. This timeout has to do with locating
Xservers, not how long they have to do the work.
X Messages of up to 30000 bytes can be sent between client and server. This
Xlimit will increase to 1 Gbyte in the next version of Amoeba but will probably
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X282 NETWORKING CHAP. 11
X
Xremain at 30000 bytes in MINIX due to the small address space of the IBM PC. It
Xis possible to provide security so that servers only execute remote procedure
Xcalls for authorized users. The protection mechanism uses capabilities and is
Xdiscussed in detail in the references. It will not be discussed much here.
XThis protection mechanism is not implemented in the remote shell software avail-
Xable with MINIX. (It requires a directory server, among other things. The
Ximplementation is left as an exercise for the reader.)
X
X
X11.4. SYNTAX AND SEMANTICS OF TRANSACTION PRIMITIVES
X
X Now we will take a detailed look at the syntax and semantics of the library
Xroutines for using transactions, followed by some simple examples to indicate
Xhow the functions are typically used. Remember, that when programming with tran-
Xsactions, the primitives used in C programs are _g_e_t_r_e_q, _p_u_t_r_e_p, _t_r_a_n_s, and
X_t_i_m_e_o_u_t. These can be thought of as network system calls, although they are not
Ximplemented quite like that in MINIX. If you are building a server, it will
Xtypically have a main loop with a _g_e_t_r_e_q at the top, a switch in the middle
Xbased on some field of the incoming message, and a _p_u_t_r_e_p at the bottom. Furth-
Xermore, the server writer will generally also provide a set of stub procedures
Xthat contain _t_r_a_n_s calls to access the server. The average user will call these
Xlibrary procedures, and will not make _t_r_a_n_s calls directly, although he is, of
Xcourse, free to do so if he wishes.
X Transaction messages always begin with a special header. The exact layout of
Xthese messages is defined by the Amoeba protocol. By using this protocol, MINIX
Xmachines can communicate with one another, and with Suns and Vaxes running
XAmoeba. Device drivers have also been written for UNIX to allow UNIX processes
Xto speak Amoeba, and have Amoeba clients and servers run on UNIX. At the Vrije
XUniversiteit, all the Suns, Vaxes, and other machines that run UNIX have such
Xdrivers to communicate with each other and with machines running Amoeba and
XMINIX. It is the local lingua franca, just as TCP/IP is at some sites.
X The Amoeba header is defined in the header file /_u_s_r/_i_n_c_l_u_d_e/_a_m_o_e_b_a._h, which
Xmust be included in all programs using transactions. The header definition is
Xgiven below. The types used in the header struct are also defined in _a_m_o_e_b_a._h.
Xtypedef struct {
X port h_port; /* port (i.e., logical address) of the dest. */
X port h_signature;/* used for authentication and protection */
X private h_priv;/* 10 bytes: object, rights, and cksum */
X unshort h_command;/* code for operation desired/status returned */
X long h_offset; /* parameter field */
X unshort h_size;/* parameter field */
X unshort h_extra;/* parameter field */
X} header;
X The message header contains the port to which the message should be sent, a
Xcommand/status field for use by the server and space for some parameters to go
Xwith the command or status. Let us now look at the four network primitives.
XThe first one, getreq, has the following declaration:
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XSEC. 11.4 SYNTAX AND SEMANTICS OF TRANSACTION PRIMITIVES 283
X
X unshort getreq(hdr, buffer, size)
X header *hdr;
X char *buffer;
X unshort size;
XThe three parameters refer to the header, the buffer, and the buffer size,
Xrespectively. In a sense, they are analogous to the parameters of the MINIX
XREAD and WRITE system calls. The _h_d_r parameter points to a header struct, which
Xis used to allow the server to specify which port it wants to listen to. The
X_h__p_o_r_t field of the header must be initialized with the port number. The _b_u_f_f_e_r
Xparameter is a pointer to a buffer to hold the incoming message. It can hold a
Xmaximum of size bytes, specified by the third parameter. If successful _g_e_t_r_e_q
Xreturns the number of the bytes of data in the buffer that were actually
Xreceived. In addition, the other fields of the header are filled in by the sys-
Xtem. If an error occurs then it returns a negative error code. Possible error
Xcodes (defined in _a_m_o_e_b_a._h) are:
X FAILED: - Null port or _g_e_t_r_e_q done before previous _p_u_t_r_e_p
X BADADDRESS: - The buffer pointer and/or size was not valid
X ABORTED: - A signal was received
X TRYAGAIN: - There were no free transaction slots in the kernel tables
XNote that after a _g_e_t_r_e_q, _t_r_a_n_s may be used to communicate with another server
Xbefore doing the _p_u_t_r_e_p. In other words, a server may call other servers to help
Xit do its job, but it may not process multiple transactions simultaneously. (In
XAmoeba, server processes may contain multiple threads to allow parallelism, but
XMINIX does not allow multiple threads per process.)
X The next call is _p_u_t_r_e_p, used by servers to reply to requests and send back
Xresults and status information. The declaration is:
X
X unshort putrep(hdr, buffer, size)
X header *hdr;
X char *buffer;
X unshort size;
X
XThe header returned contains status information, and possibly a new port (in the
X_h__s_i_g_n_a_t_u_r_e field). A buffer containing size bytes of data is also returned to
Xthe client. If successful, _p_u_t_r_e_p returns the number of bytes sent. The reply
Xmessage is not acknowledged, so that a successful return from this call does not
Xguarantee that the client got the reply. In general, it is up to the client to
Xtry again if the reply is not forthcoming quickly enough. Possible error condi-
Xtions for _p_u_t_r_e_p are defined in _a_m_o_e_b_a._h as follows:
X
X FAILED: - No _g_e_t_r_e_q was done first
X BADADDRESS: - The buffer pointer and/or size was not valid
X ABORTED: - A signal was received
X
X Now we come to the call used by clients to request services and wait for
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X284 NETWORKING CHAP. 11
X
Xreplies. Servers can also use this call to request services from other servers.
XThus at one instant a process may be acting as a server and at another the same
Xprocess may be acting as a client. The client call is:
X
X unshort trans(hdr1, buffer1, size1, hdr2, buffer2, size2)
X header *hdr1, *hdr2;
X char *buffer1, *buffer2;
X unshort size1, size2;
X
XThe call has two independent sets of parameters. Those with suffix 1 are used
Xfor sending the request message to the server. Those with suffix 2 are used for
Xgetting the reply. Both sets have a header, a buffer, and a size. The two _h_d_r
Xpointers point to structs for message headers. The first one contains parame-
Xters copied to the outgoing message to the server and the second one contains
Xspace for the data to be copied in from the server's _p_u_t_r_e_p. The two buffer
Xparameters are for the outgoing and incoming data, respectively, and the two
Xsizes tell how large these buffers are.
X After making a _t_r_a_n_s call, the client blocks until the message has been sent,
Xreceived, processed by the server, and replied to. Only then can the client
Xcontinue execution. At this point the fields of _h_d_r_2 and _b_u_f_f_e_r_2 will contain
Xthe reply data. Like MINIX itself, transactions support only this synchronous
Xform of communication. Experience has painfully shown that asynchronous stream
Xcommunication is difficult for programmers to deal with. After all, everything
Xelse in programming languages is synchronous. (Can you imagine what it would be
Xlike to have a procedure call return control to the caller before having fin-
Xished its work?)
X If successful, _t_r_a_n_s, returns the number of bytes in the reply. Possible
Xerror codes are:
X
X FAILED: - Null port or server crashed between _g_e_t_r_e_q and _p_u_t_r_e_p
X NOTFOUND: - The port locate failed to find a server before the timeout
X BADADDRESS: - A buffer pointer and/or size was not valid
X ABORTED: - A signal was received
X TRYAGAIN: - There were no free transaction slots in the kernel's tables
X
XThe final network primitive deals with setting timeouts. When a client first
Xdoes a transaction on a previously unknown port, the kernel broadcasts a locate
Xmessage to find the server. It then waits a certain amount of time for a server
Xto reply. If no server replies before the timer goes off, the _t_r_a_n_s fails with
XNOTFOUND. The _t_i_m_e_o_u_t call allows the client to determine how long to wait for
Xa server to reply. After a reply has been received, the kernel keeps it in a
Xcache, so that locates will not be needed subsequently. It is important to
Xrealize that the timeout relates to locating servers, not to how much time
Xservers have to perform their work. The declaration is:
X
X unshort timeout(time)
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XSEC. 11.4 SYNTAX AND SEMANTICS OF TRANSACTION PRIMITIVES 285
X
X unshort time;
X
XThe function sets the length of the locate timeout in tenths of a second. The
Xdefault is 300 (30 seconds). A timeout of 0 means do not time out. The _t_i_m_e_o_u_t
Xcall returns the length of the previous timeout.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X286 NETWORKING CHAP. 11
X
X11.5. SERVER STRUCTURE
X
X A typical server has the following form:
X /* Declarations needed by the server. */
X header hdr; /* header for receiving requests */
X char buffer[BUFSIZE]; /* buffer for receiving requests */
X char reply[BUF2SIZE]; /* buffer for sending replies */
X unshort size, replysize; /* sizes of the two buffers */
X unshort getreq; /* function declaration */
X char *strncpy(); /* string function */
X
X signal(SIGAMOEBA, SIG_IGN); /* ignore signals */
X
X while (1) {
X
X /* Have the server listen to a 48-bit port equal to ASCII "MyServ" */
X strncpy(&hdr.h_port, "MyServ", HEADERSIZE);
X
X /* Wait for a request to come in for that port. */
X size = getreq(&hdr, buffer, BUFSIZE);
X
X /* If the size returned is negative then an error occurred. */
X if ((short) size < 0) {
X handle_error();
X } else {
X perform_request(); /* carry out the work */
X hdr.h_status = OK; /* or whatever */
X putrep(&hdr, reply, replysize);/* send reply back */
X }
X }
XIf all the information necessary for the request is in the headers then the
Xbuffers in _g_e_t_r_e_q and _p_u_t_r_e_p can be replaced by the value NILBUF and the buffer
Xsizes can be replaced by 0.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XSEC. 11.5 SERVER STRUCTURE 287
X
X11.6. CLIENT STRUCTURE
X
X The structure of a client program is much more variable. A program that
Xdeals with the above server might look like this:
X /* Declarations needed by the client. */
X header hdr; /* header used for request */
X char buffer[BUFSIZE]; /* buffer used for request */
X short size; /* size of the buffer */
X unshort trans; /* function declaration */
X char *strncpy(); /* string function */
X
X /* Initialize server port to "MyServ". */
X strncpy(&hdr.h_port, "MyServ", HEADERSIZE);
X
X /* Send request to server listening to that port. */
X size = (short) trans(&hdr, buffer, BUFSIZE, &hdr, NILBUF, 0);
X if (size < 0) {
X printf("trans failed %d0, size);
X } else {
X if (hdr.h_status != OK)/* nonzero status is an error */
X work_not_done();
X else
X successful_trans;
X }
X
X
X11.7. SIGNAL HANDLING
X
X It is important for programmers to understand how signals work. If a client
Xreceives a signal while doing a _t_r_a_n_s, the signal propagates to the server. If
Xthe server is also doing a _t_r_a_n_s then it propagates again to the next server,
Xand so on. The aim of this is to request all servers to terminate their tran-
Xsaction as soon as possible.
X If the server receiving the signal is not doing a transaction and not already
Xdoing a _p_u_t_r_e_p then the server code must handle the signal. It may choose to
Xcatch the signal and send a reply immediately or simply ignore the signal. If
Xit does not catch the signal then it will die since the signal propagated is
XSIGAMOEBA (which is defined as SIGEMT for MINIX). In this case the transaction
Xwill fail (with return status FAILED for the client).
X Once the transaction is completed the client process will be signaled. It in
Xturn must handle the original signal (not necessarily SIGAMOEBA). The exact
Xtransaction semantics of Amoeba are not supported under MINIX due to difficulty
Xin keeping user processes alive until a transaction terminates after a signal.
XSignal propagation does occur, but the client may die before a reply comes in.
XThis should not matter too much for most applications. In the next rewrite of
XAmoeba the syntax and semantics of these functions will change in non-compatible
Xways, but this will probably not appear in MINIX.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X288 NETWORKING CHAP. 11
X
X11.8. IMPLEMENTATION OF TRANSACTIONS IN MINIX
X
X Amoeba transactions are implemented in the MINIX kernel as a number of kernel
Xtasks. Several alterations were made to the kernel to support these tasks,
Xincluding the addition of an (optional) ethernet driver (for the Western Digital
XEtherCard Plus, also known as the WD1003E) and the possibility to specify the
Xsize of the stack for kernel tasks on a per task basis. (Amoeba tasks need
Xlarger stacks than the other MINIX kernel tasks.) There is also an extra system
Xcall that is handled by MM. This is the Amoeba system call and is the interface
Xto the kernel. Special handling of signals is also provided for in the MM task.
X There are five kernel tasks for Amoeba. The first acts as a manager which
Xaccepts asynchronous events. Possible events are:
X 1. An ethernet packet has arrived
X 2. A local signal has arrived
X 3. A user task involved in an active transaction has died
X 4. A sweep timeout has occurred
X(Locate timeouts are implemented using a counter which is decremented every
Xtenth of a second by a sweep routine.) Each of the other four tasks manage a
Xsingle user process' transactions. Thus, a maximum of four processes can simul-
Xtaneously do transactions under MINIX. The number of transaction tasks is, how-
Xever, a constant in an include file and can be increased if needed.
X In the MINIX kernel there is a table which keeps a record of the current
Xstate of a transaction. This table is called _a_m__t_a_s_k and is declared in the
Xfile _a_m_o_e_b_a._c. This records many things, including, the process number of the
Xtask doing the transaction, the current state (locating, waiting for a reply,
Xwaiting for a request, etc.) and the relevant ports and machine addresses.
X The Amoeba network protocol is a stop and wait protocol that guarantees at
Xmost once delivery of a message. A message consists of the concatenation of the
Xtransaction header with the data in the buffer (if any) given to _t_r_a_n_s, _g_e_t_r_e_q
Xor _p_u_t_r_e_p. The transaction code divides messages up into packets which fit on
Xthe underlying network medium (which is ethernet in the case of MINIX). It then
Xsends over the message fragments and they are reassembled on the remote machine
Xbefore being given to the recipient.
X Each packet begins with an ethernet header (which consists of the source and
Xdestination ethernet addresses) followed by a 10-byte Amoeba internet header
Xcontaining data about the source and destination processes to ensure that the
Xmessage is delivered to the correct process. The rest of the packet is used for
Xsending data.
X
X
X11.9. COMPILING THE SYSTEM
X
X There are several interesting things you need to know before you can build a
XMINIX kernel with Amoeba transactions in it. First of all, you do not need an
XEthernet to use transactions. You can have your clients and servers running on
Xa single machine. In this mode, it is possible to write and debug network
Xsoftware without having a network. Later, when you move to a real network, the
Xcode will already be fully debugged, as the system itself makes no distinction
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XSEC. 11.9 COMPILING THE SYSTEM 289
X
Xbetween local and remote transactions.
X Second, the transaction code is quite substantial. So much so that it would
Xtend to overshadow the rest of MINIX if it were fully integrated into it. This
Xfact, combined with the knowledge that not all MINIX users are interested in
Xnetworking has led to adding a new top-level directory in MINIX, _a_m_o_e_b_a. This
Xdirectory and its subdirectories contain all the networking code. If you are
Xnot interested in networking, just ignore it.
X Installation of networking is largely auto-configured using the makefiles
Xprovided. Two new -D entries are used in the _m_m and _a_m_o_e_b_a/_k_e_r_n_e_l makefiles:
X -DAM_KERNEL (used in _m_m and _a_m_o_e_b_a/_k_e_r_n_e_l) enables networking
X -DNONET (used in _a_m_o_e_b_a/_k_e_r_n_e_l) single machine networking
Xin other words, local transactions only If you use -DAM_KERNEL but not DNONET,
Xyou get full networking and MUST have a Western Digital Etherplus card.
X If you add a new kernel task of your own then it MUST come between the Amoeba
Xkernel tasks and the printer task in the file kernel/table.c and should be num-
Xbered relative to AMOEBA_CLASS in the file _h/_c_o_m._h (i.e. The task number should
Xbe AMOEBA_CLASS+1 for the first new task, AMOEBA_CLASS+2 for the second new
Xtask, etc.). Be sure to set NR_TASKS correctly.
X To compile and install networking, you must follow the steps below carefully.
X
X
X11.10. HOW TO INSTALL NETWORKING IN MINIX
X
X You must do the following important steps carefully. However, before start-
Xing, make sure that /_u_s_r/_l_i_b/_c_p_p has at least 50000 bytes of stack space (_s_i_z_e
Xwill tell you). If you, use _c_h_m_e_m to give it more.
X 1. Make sure that you are in the Amoeba directory and that there is plenty
X of free disk space. Now edit _M_a_k_e_f_i_l_e to include or exclude _N_O_N_E_T from
X _C_F_L_A_G_S as you prefer.
X 2. Type:
X make
X 3. When you are instructed to do so, insert a blank diskette and hit the
X return key.
X 4. Reboot your machine using the new boot floppy.
X 5. Test the system. The directory _a_m_o_e_b_a/_e_x_a_m_p_l_e_s contains several pro-
X grams to test the reliability of transactions. The _R_E_A_D__M_E file in the
X directory gives more details.
X 6. If you have an ethernet card then install the network tools. The
X directory amoeba/util contains utilities for remote shells, remote file
X copying and message sending. These only work with machines that have
X Amoeba transactions installed. The _R_E_A_D__M_E file there gives more
X details.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X290 NETWORKING CHAP. 11
X
X11.11. NETWORKING UTILITIES
X
X There are several utility programs which you may find useful if you have a
Xnetwork connection. They are listed below with a brief outline of their use.
XOther utilities are possible and reasonably simple to write as shell scripts
Xthat use _r_s_h (remote shell, described below). The utilities are located in the
Xamoeba/utilities directory.
X
X
X11.12. REMOTE SHELL
X
X One of the main features of MINIX networking is the use of the remote shell.
XThis utility is a server that accepts commands over the network from clients and
Xexecutes them. The syntax of this command is:
X rsh [-bei] _p_o_r_t _c_o_m_m_a_n_d
X_T_h_i_s _p_r_o_g_r_a_m _e_x_e_c_u_t_e_s _t_h_e _c_o_m_m_a_n_d _s_p_e_c_i_f_i_e_d _b_y _c_o_m_m_a_n_d on the machine with a
Xsherver (described below) listening to the port _p_o_r_t, which is an ASCII string
Xof up to 6 characters. It is used to generate a unique port name for the under-
Xlying transaction mechanism.
X Normally standard output and standard error from the command are written on
Xstandard output of the local process. If the -e flag is specified then they are
Xkept separate. The -i flag specifies that standard input for the command should
Xcome from the local process. The -b flag specifies that the _r_s_h should be
Xstarted in the background. Some examples:
X rsh bozo
X_s_t_a_r_t_s _a_n _i_n_t_e_r_a_c_t_i_v_e _s_h_e_l_l _o_n _t_h_e _m_a_c_h_i_n_e _r_u_n_n_i_n_g _a _s_h_e_r_v_e_r _w_i_t_h _p_o_r_t _b_o_z_o.
XSubsequent commands that you type will be fed to the remote shell. You can use
Xcd to change to a directory on the remote machine, ls to list files in the
Xremote directory, and any other commands you want. In effect, _r_s_h gives you a
Xsimple form of remote login. Note that to make this work, the remote process
Xlistening on the port _b_o_z_o must be a shell server (sherver).
X As a second example of _r_s_h, consider
X rsh jumbo cat /etc/passwd
X_w_h_i_c_h _d_i_s_p_l_a_y_s _o_n _y_o_u_r _s_c_r_e_e_n _t_h_e _f_i_l_e /_e_t_c/_p_a_s_s_w_d from the machine running a
Xsherver with port jumbo. The _r_s_h command could also have redirected this output
Xto a local file or pipe.
X A slightly more complex example is
X rsh -i freddo 'cat >/usr/ast/junk' </etc/termcap
Xwhich runs the command
X cat >/usr/ast/junk
Xon machine the machine running a sherver with port _f_r_e_d_d_o and takes as input the
Xfile /_e_t_c/_t_e_r_m_c_a_p from the local machine. Note that by quoting the second argu-
Xment, it is passed as a string to the remote sherver. If the command contains
Xmagic characters (e.g., *.c) the resulting action depends on whether the command
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XSEC. 11.12 REMOTE SHELL 291
X
Xis quoted or not. If it is not quoted, the local shell will expand the magic
Xcharacters before _r_s_h is even called. If the command is quoted, the command
Xstring is passed unmodified to the remote sherver, which then expands it in the
Xdirectory it is currently working in.
X When you log into a remote machine with _r_s_h, you get a shell having the uid
Xand gid of the sherver (see below). To get your own uid and gid, type
X exec su george
X_a_s_s_u_m_i_n_g _t_h_a_t _y_o_u_r _l_o_g_i_n _i_s _g_e_o_r_g_e. If you have a password, _s_u will ask for it.
XNeedless to say, the _s_u program will use /_e_t_c/_p_a_s_s_w_d on the remote machine. Do
Xnot forget to use exec, as this eliminates the need for an extra shell. If you
Xdo not need your own uid, do not bother, as it costs memory.
X
X
X11.13. SHERVERS
X
X To enable remote shell operations, it is necessary to have a sherver running
Xon the destination machine. Shervers can be started up by:
X sherver port
Xassuming that sherver is kept in /_u_s_r/_b_i_n. This program listens to the port
Xspecified and accepts a single request from the program _r_s_h. It then executes it
Xwith the uid and gid of the sherver. When it is finished, the sherver exits.
X The sherver gets its input from a pipe. This means that it can only do those
Xthings possible with a pipe as input. In particular, signals (e.g., DEL), EOF
X(e.g., CTRL-D), and the ioctl system call do not work properly. Hitting DEL
Xremotely will kill the sherver. There is no simple solution, except to use stty
Xto change your DEL character so that you do not hit it out of habit.
X
X
X11.14. MASTERS
X
X Another useful program is _m_a_s_t_e_r. It is started up as follows:
X master count uid gid command
X_T_h_i_s _p_r_o_g_r_a_m _s_t_a_r_t_s _u_p _c_o_u_n_t _c_o_p_i_e_s _o_f _t_h_e _p_r_o_g_r_a_m _s_p_e_c_i_f_i_e_d _b_y _c_o_m_m_a_n_d _w_i_t_h
X_u_s_e_r _i_d _u_i_d _a_n_d _g_r_o_u_p _i_d _g_i_d. _T_h_e _c_o_m_m_a_n_d _m_a_y _b_e _g_i_v_e_n _p_a_r_a_m_e_t_e_r_s. _I_f _a_t _a_n_y
X_t_i_m_e _t_h_e _c_o_m_m_a_n_d _e_x_i_t_s _o_r _d_i_e_s _t_h_e_n _m_a_s_t_e_r will start up a new invocation of it.
XThis was designed to work with shervers but has other applications as well. For
Xexample,
X /usr/bin/master 1 2 2 /etc/sherver mumbo
X_w_i_l_l _s_t_a_r_t _a _s_i_n_g_l_e _s_h_e_r_v_e_r _l_i_s_t_e_n_i_n_g _t_o _t_h_e _p_o_r_t _m_u_m_b_o and ensure that there is
Xalways a sherver running. This sherver will have uid=2 and gid=2, so that _r_s_h
Xcalls to _m_u_m_b_o will be executed with this uid/gid combination. It is suggested
Xto start up _m_a_s_t_e_r in the /_e_t_c/_r_c file of any machine running shervers. When a
Xsherver finishes executing a command, it exists. By having _m_a_s_t_e_r running in
Xthe background all the time, every time a sherver exists, its parent, _m_a_s_t_e_r,
Xwill create a new one. This mechanism is somewhat akin to init creating a new
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X292 NETWORKING CHAP. 11
X
Xlogin process whenever a shell exits. Since $PATH is generally not set prior to
Xexecuting /_e_t_c/_r_c, _m_a_s_t_e_r should be specified as /_u_s_r/_b_i_n/_m_a_s_t_e_r.
X The amount of stack space to give to _m_a_s_t_e_r (and _s_h_e_r_v_e_r) is important. If
Xit is too little, the programs will act weird. If it is too much, everything
Xwill work fine, but memory will be wasted and there may not be enough left to
Xrun all the programs. Some experimentation is required. In any event, if
Xthings act strange, use _c_h_m_e_m to allocate more stack space to these programs to
Xsee if that helps.
X
X
X11.15. FILE TRANSFER
X
X The standard MINIX networking provides for file transfer using a shell script
Xcalled rcp (remote cp). The syntax of the call is
X rcp [port!]from_file [port!]to_file
XIt can also do local file copy but this is more easily accomplished with cp.
XHere are two examples of rcp usage:
X rcp jumbo!/etc/passwd
X rcp jumbo!/etc/passwd freddo!/usr/ast/pebble
XThe first one will copy the file /_e_t_c/_p_a_s_s_w_d from the machine running a sherver
Xwith the port jumbo to the file _p_a_s_s_w_d in the current directory. The second one
Xwill copy the file /_e_t_c/_p_a_s_s_w_d from the machine running a sherver with the port
Xjumbo to the file /_u_s_r/_a_s_t/_p_e_b_b_l_e on the machine running a sherver with the port
X_f_r_e_d_d_o. Thus it is possible to issue commands on machine A to copy files from
Xmachine B to machine C.
X
X
X11.16. REMOTE PIPES
X
X It is possible to set up remote pipes using the programs _t_o and _f_r_o_m. The
Xprogram _t_o reads from standard input and writes its output to the named port.
XSimilarly, _f_r_o_m reads from the named port and writes to standard output. For
Xexample, consider the following commands, possibly given on two different
Xmachines:
X cat F* | sort | to 'port66'
X _f_r_o_m '_p_o_r_t_6_6' | _u_n_i_q -_c | _s_o_r_t -_n
XThe first command concatenates files beginning with 'F', sorts them, and writes
Xthe output to 'port66'. The second commands reads from 'port66' and provides
Xinput to the rest of the pipeline.
X
X
X11.17. THE ETHERNET INTERFACE
X
X The ethernet driver in this version of Minix is for the Western Digital Eth-
Xercard Plus card, which is also known as the WD1003E. The ethernet controller
Xchip on this board is the National Semiconductor DP8390. If you have a
X
X
X
X
X
X
X
X
X
X
X
X
X
X
XSEC. 11.17 THE ETHERNET INTERFACE 293
X
Xdifferent type of ethernet controller then there are several things you need to
Xknow about the interface between the driver and the Amoeba transaction layer in
Xorder to write a suitable driver for your card.
X There were several fundamental assumptions made while designing the high
Xlevel protocol which affect the ethernet driver.
X 1. The ethernet controller has enough local memory to buffer at least one
X incoming packet and one outgoing packet and will not overwrite a buffer
X with a new incoming packet until the buffer has been released.
X 2. Read buffers are released in the same order as they were allocated.
X After a read interrupt has occurred and (*_b_u_f_r_e_a_d)() has been called,
X then _b_u_f_r_e_a_d will not be called again until an eth_release has been
X done.
X 3. The ethernet driver generates no write interrupts. This is because we
X found that busy waiting was more efficient than doing a context switch
X and waiting for an interrupt. By the time the context switch was done,
X the interrupt had already happened, so we had to switch back. It's
X faster to just wait for it. On a very slow machine, a different stra-
X tegy might be
X appropriate.
X
XThere are several routines used by the high level code which should be provided
Xby the ethernet driver. Unless otherwise stated, these routines are called in
Xthe file _a_m_o_e_b_a._c.
X 1. _e_t_h_e_r_a_d_d_r - get ethernet address of this host from rom.
X 2. _e_t_h__i_n_i_t - initialises the ethernet card and sets pointers to routines
X to be called on packet arrival and departure.
X 3. _e_t_h__g_e_t_b_u_f - returns pointer to next write buffer.
X 4. _e_t_h__w_r_i_t_e - writes the current "write buffer" to the net.
X 5. _e_t_h__r_e_l_e_a_s_e - release a read buffer for reuse.
X 6. _e_t_h__s_t_p - shuts up the ethernet chip so that reboot can stop all inter-
X rupts from the chip. The normal reboot procedure does not stop the
X WD1003E from running, so the next time interrupts are enabled it makes
X a fuss (called from klib88.s).
X
XThe files _d_p_8_3_9_0._c, _d_p_8_3_9_0._h, _d_p_8_3_9_0_i_n_f_o._h and _d_p_8_3_9_0_s_t_a_t._h contain routines
Xspecific to the NS DP8390 chip. These may need some slight changes before work-
Xing correctly with another manufacturer's board which also uses this chip. The
Xfiles _e_t_h_e_r_p_l_u_s._c and _e_t_h_e_r_p_l_u_s._h contain routines specific to the WD1003E
Xboard.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X294 NETWORKING CHAP. 11
X
X11.18. REFERENCES
X
X 1. Birrell, A.D., and Nelson, B.J.: "Implementing Remote Procedure Calls," _A_C_M
X _T_r_a_n_s_a_c_t_i_o_n_s _o_n _C_o_m_p_u_t_e_r _S_y_s_t_e_m_s, vol. 2, pp. 39-59, Feb. 1984.
X
X 2. Cheriton, D.. "The V Kernel: A Software Base for Distributed Systems," _I_E_E_E
X _S_o_f_t_w_a_r_e _M_a_g_a_z_i_n_e, vol. 1, pp. 19-42, April 1984.
X
X 3. Bal, H.E., Renesse, R. van, and Tanenbaum, A.S.: "Implementing Distributed
X Algorithms using Remote Procedure Call," _P_r_o_c. National Computer Conference
X AFIPS, pp. 499-505, 1987.
X
X 4. Renesse, R. van, Tanenbaum, A.S., Staveren, H., and Hall, J.: "Connecting
X RPC-Based Distributed Systems using Wide-Area Networks," _P_r_o_c. _S_e_v_e_n_t_h _I_n_t_e_r_-
X _n_a_t_i_o_n_a_l _C_o_n_f. _o_n _D_i_s_t_r. _C_o_m_p_u_t_e_r _S_y_s_t_e_m_s, IEEE, pp. 28-34, 1987.
X
X 5. Tanenbaum, A.S., Mullender, S.J., and van Renesse, R.: "Using Sparse Capa-
X bilities in a Distributed Operating System," _P_r_o_c. _S_i_x_t_h _I_n_t_e_r_n_a_t_i_o_n_a_l _C_o_n_f.
X _o_n _D_i_s_t_r. _C_o_m_p_u_t_e_r _S_y_s_t_e_m_s, IEEE, 1986.
X
X 6. Mullender, S.J., and Tanenbaum, A.S.: "The Design of a Capability-Based Dis-
X tributed Operating System," _C_o_m_p_u_t_e_r _J_o_u_r_n_a_l, vol. 29, pp. 289-299, Aug. 1986.
X
X 7. Tanenbaum, A.S., and Renesse, R. van: "Distributed Operating Systems," _C_o_m_-
X _p_u_t_i_n_g _S_u_r_v_e_y_s, vol. 17, pp. 419-470, Dec. 1985.
X
X 8. Mullender, S.J., and Tanenbaum, A.S.: "A Distributed File Service Based on
X Optimistic Concurrency Control," _P_r_o_c. _T_e_n_t_h _S_y_m_p. _O_p_e_r. _S_y_s_t. _P_r_i_n., pp. 51-
X 62, 1985.
X
X 9. Mullender, S.J., and Tanenbaum, A.S.: "Protection and Resource Control in
X Distributed Operating Systems," _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_s, vol. 8, pp. 421-432, Oct.
X 1984.
X
X10. Mullender, S.J., Rossum, G. van, Tanenbaum, A.S., Renesse, R. van, Staveren,
X H. van: "Amoeba-A Distributed Operating System for the 1990s," _I_E_E_E _C_o_m_p_u_t_e_r
X _M_a_g_a_z_i_n_e, May 1990.
X
X11. Tanenbaum, A.S., Renesse, R. van, Staveren, H. van, Sharp, G.J., Mullender
X S.J., Jansen, A.J., and Rossum, G. van: "Experiences with the Amoeba Distri-
X buted Operating System," _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M.
X
X12. Tanenbaum, A.S., _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_s, 2nd ed., Englewood Cliffs, NJ:
X Prentice-Hall, 1989.
X
X
X
X
X
X
X
X
X
X
X
X
X
/droege@infko.UUCP (Detlev Droege) (06/13/90)
In article <6922@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > Here is the long awaited Amoeba driver for MINIX 1.5. First a bit of > introduction. Read the whole thing to see the relevance to MINIX. ... > provided for remote login, file transfer, and other goodies. When using > the Amoeba protocols, Sun-3s, MINIX systems etc can talk to each other ====== > over the Ethernet. The Amoeba driver I am about to supply is for the > IBM version of MINIX only. ... > Have fun. > > Andy Tanenbaum (ast@cs.vu.nl) Sun-3s talk to MINIX !!! That's the point !! I remember the Sun-3 AMOEBA driver for UNIX couldn't be posted by Dr. Tanenbaum because it required changes in the SunOS 3.X kernel. "This should change with the new SunOS release", he stated. Well, SunOS 4.0.[13] is out and running (at least on our SUNs). Will you post such a driver, Dr. Tanenbaum ? I'm shure, lots of people would find that more than only useful, don't you, folks ? Hoping for good news Detlev -- Detlev Droege, Uni Koblenz (EWH), FB Informatik Rheinau 3-4, D-5400 Koblenz (West Germany) UUCP: ..!unido!infko!droege droege@infko.UUCP (Voice: +49 261 9119-0)
mgu@chorus.fr (Marc Guillemont) (06/16/90)
From article <6922@star.cs.vu.nl>, by ast@cs.vu.nl (Andy Tanenbaum): > In addition to being distributed, Amoeba has been designed to be very fast. > Our major customer at the moment is the European Space Agency, which is > using it as the operating system for a digital system for transmitting > real time video over a fast LAN. Right now they have 1 camera on the > spacecraft, but eventually they want to have 50, and be able to dynamically > switch channels etc digitally. As you can well imagine, high performance > is a major issue here. That is why Amoeba was chosen over UNIX, Chorus, > Mach etc. The European Space Agency is also a customer (not the major one) of Chorus syste`mes. They need a distributed operating system which can support (among other things) flexible and efficient dynamic reconfiguration of distributed Ada programs. That is why CHORUS was chosen over UNIX, Amoeba, Mach, etc. -- _ __ _ _ _ ___ Marc Guillemont ' ) ) ' ) ) ) / ) Chorus syste`mes /--' __ / / / / __ . . 6, avenue Gustave Eiffel / / ' / / ( (___/_(_/_ F-78182, St-Quentin-en-Yvelines Cedex Tel: +33 (1) 30 57 00 22 Fax: +33 (1) 30 57 00 66 E-mail: mgu@chorus.fr or mgu%chorus.fr@mcsun.EU.net
ast@cs.vu.nl (Andy Tanenbaum) (06/17/90)
In article <5459@chorus.fr> mgu@chorus.fr (Marc Guillemont) writes: >> That is why Amoeba was chosen over UNIX, Chorus, Mach etc. >The European Space Agency is also a customer (not the major one) of Chorus >syste`mes. They need a distributed operating system which can support (among >other things) flexible and efficient dynamic reconfiguration of distributed >Ada programs. That is why CHORUS was chosen over UNIX, Amoeba, Mach, etc. Fair enough. Everyone who wants speed should sign up for Amoeba. Everyone who wants Ada should sign up for Chorus :-) Andy Tanenbaum (ast@cs.vu.nl)