Hi,
I started a support library for servers. At the moment it makes it a
lot easier to write servers. But it still far from being complete.
For testing I converted tmpfs to use this library and wrote a server
which only passes the received messages to another server (acts
simillar to a simple mount, but it leaves all permission checks out).
I don't expect it to be usefull as it is, but is a good template for
real servers so I'll append it as a example)
I enclose the README and the server.h which holds all the current
documentation. If someone is interested mail me for the code or try to
get it from
http://ibch01.inf.tu-dresden.de:8001/people/jw/vsta/v132/srv/lib/
(But I am behind the slowest line you may think of.)
---- The README ----
This is a support library for servers.
It implements a abstraction of what a server is. This is independent
of the underlying OS. (Actually only implemented for VSTa, should be
easy for QNX and L3 -- this is what I know, and almost anything else.)
See "server.h" for Details of the provided abstraction.
At top of this interface it becomes much more easy to write a server.
Beside the system independence you get, some of the edge cases
disappear (because you don't see the message interface). Furthermore
the name handling becomes uniformed.
libc/statsup.c is copied and adapted. (Unfortunately it does some msg_
actions itself.)
Side note:
This code could benefit from a proposed kernel service
msg_send_and_receive. As long as kernel entry is that expensive as on
the intel it would save a lot of execution time.
TODO:
* Think about a VSTa independend "struct msg".
* Add support for multithreaded servers. (currently a matter of the
server specific code).
* Fix the hackery around the unknown value of the M_READ bit.
* improve the service selection on a received message. (As long as
VSTa needs about 10-20 the time of similar systems for a context
switch it doesn't matter.)
Contact:
joerg.wittenberger@inf.tu-dresden.de
----- server.h ------
#ifndef __SERVER_H
#define __SERVER_H
/*
* server.h
*
* REASONING
* This implements a abstraction of what a server is.
* A server build at top of this interface is not VSTa specific in
* respect to the interface it serves. (It may be VSTa specific in the
* sense of being a client of another server.)
*
* A server consists of a set of services (functions of the type
* service) which are bound to a message. These functions all act
* on a received message and a data structure associated with the
* client. They return a NULL pointer on success or a pointer to a
* error string on failure. On success the message is modified to be
* used as the reply message.
*
* One may think about the mentioned data structure as a object served
* and the functions as methods on this object (and the message as
* arguments to this method).
*
* Every server has to provide a function init_server (and no main!)
* which does all startup initialization of it's internal data
* structures and even so establish connections to servers it uses.
* It does NOT establish any namer_registration. (The name to use for
* registration is the first argument to the server, but this is a
* VSTa specific issue.)
*
* There should are a special function to generate and initialize a
* new data structure (ignoring the provided pointer) which is usually
* bound to the M_CONNECT (under VSTa) and acts as the constructor in
* the sense of object orientation, a function to copy a object from
* another one (usually bound to the M_DUP) which may be seen as the
* constructor with a object to copy and also a function which deletes
* such a object (usually on M_DISCONNECT), the destructor. A function
* which successfully created a new object (file in the sense of VSTa)
* should bind it to a client. All functions bound to successive
* messages from this client will act on this object. A binding gets
* revoked by a call to the bindclient with the same id but a NULL
* pointer as object.
*
*/
/*
* import "struct msg"
*/
#include <sys/msg.h>
typedef char* (service)(struct msg *, void *);
extern service* server_bindfn(int, service*); /* Bind function */
extern service* server_bindfn_dft(service*); /* (Re)bind the default */
extern void* server_bindclient(int, void*); /* bind client */
#ifdef WITH_PASSMSG
/*
* If WITH_PASSMSG is defined, the server has support for
* server_passmsg to pass a message on to another server. This is
* conditional compiled because of the questionable design of VSTa,
* which hides the M_READ bit while it doesn't provide a abstraction
* of it. So we have to do some hackery to find the correct meaning.
*/
extern char* server_passmsg(port_t, struct msg *);
#endif
extern int init_server(int argc, char **argv); /* supplied by client */
/*
* server_mmalloc
*
* some servers like to malloc buffers which have to be free'd after
* the msg_reply (in VSTa, generally spoken which live as long as the
* message is processed), but no service will ever see this point.
* Such buffers are malloc'ed by server_mmalloc with the corresponding
* struct msg. They are automatic free'd.
*
* This is a bit dangerous because of possible missuse: Never use this
* function with a other "struct msg" except the one in the arg (and
* only in servers which are at top of this interface). Also don't use
* it for buffers which are kept anywhere else (like the per client
* data)!
*
* It is usefull for all dynamic buffers in a service. Never
* free it yourself! Even never try to send back static buffers use
* buffers you got from this function!
*
*/
extern void* server_mmalloc(struct msg *,long);
#ifdef DEBUG
/*
* Set this to 1 if you like to get some syslog-info from the
* server.c. But only if this is also compiled with DEBUG.
*/
extern int server_dbg_flag;
#endif
#endif /* __SERVER_H */
/Joerg
-----------------------------------------------------------------------------
Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de
Rietzstr. 32b |
01139 Dresden |
Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8
WWW: <a href=http://www.inf.tu-dresden.de:~jw6/top.html> (click here) </a>
Received on Tue Dec 27 17:16:53 1994
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:11 PDT