Server writing: observations and questions

[Neal H Walfield]

On Sat, Oct 14, 2000 at 09:52:12PM -0500, Neal H Walfield wrote:
> Hi,
> 
> I have built the hurd and been looking aournd.  I have found the
> following strangeness:

Hi,

I now understand why the strangeness happens (understanding the strangeness
will be a different matter).  Anyway, for those interested, mig can provide
constructors, i.e. intran, and destructors that can essentially `mutate'
interfaces.

Here are some observations and a few questions about writing a server
without using any of the libraries, e.g. trivfs, directly.  

A client gets a port with a send right to the server using
file_name_lookup, i.e.:

        file_t server;
        server = file_name_lookup (argv[1], O_READ, 0666);

Generally, these above flags/permissions work, however what is the
best combination and what do they mean in this context?

In order an the open, i.e. file_name_lookup, to work successfully, the server
must support the fsys_* calls, specifically, the fsys_getroot call.  This can be
done be either placing the new demuxer on top of trivfs's the way that exec and
company do (from hurd/exec/main.c):

        static int
        exec_demuxer (mach_msg_header_t *inp, mach_msg_header_t *outp)
        {
          extern int exec_server (mach_msg_header_t *inp, mach_msg_header_t 
*outp);
          extern int exec_startup_server (mach_msg_header_t *, 
mach_msg_header_t *);
          return (exec_startup_server (inp, outp) ||
                  exec_server (inp, outp) ||
                  trivfs_demuxer (inp, outp));
        }

or by reimplementing the fsys_calls.  This solutions means writing a lot of
code or ripping it out of trivfs and creating stubs for all of the fsys class
except for fsys_goaway and fsys_getroot.

It seems worthwhile to include support for port notification via:

        #include <hurd/ports.h>

        ...

        int
        demuxer (mach_msg_header_t *inp,
                 mach_msg_header_t *outp)
        {
          return (my_server (inp, outp)
                  || my_fsys_server (inp, outp)
                  || ports_notify_server (inp, outp)
                  || ports_interrupt_server (inp, outp));
        }

This is especially true as it requires only three lines of additional code.
Why are there no stubs for the fsys calls that do the same thing?  Would
it be feasible to create one?

When implementing the client, the expected results can be obtained from
the server, however, if an invalid port, i.e. server, is used, perror
cannot decode errno:

        err = get_time (server, &hour, &minute, &second);
        if (err != KERN_SUCCESS)
          {
            printf ("KERN_SUCCESS = %d, err = %d\n",
                    KERN_SUCCESS, err);
            perror("get_time: ");
            return 1;
          }

I take it should I not be using errno; thus, what should I use to
decode the return result?

Here are a few runs.  The server is on `node' and `foo' does not exist.

        neal@hurd:~/time (0)$ ./client node 
        server: `node'
        The current time is: 14:44.55
        neal@hurd:~/time (1)$ ./client foo  
        server: `foo'
        Error opening server port: No such file or directory
        neal@hurd:~/time (0)$ ./client .  
        server: `.'
        KERN_SUCCESS = 0, err = -303
        get_time: : (os/kern) successful

Trying to do other operations, such as an `ls -l', on the server result in an
unknown ipc.  How can I find out ipc it is?

        neal@hurd:~/time (0)$ ls -l node server
        ls: node: (ipc/mig) bad request message ID
        -rwxr-xr-x    1 neal     neal       125568 Oct 15 10:19 server

Thanks,
-Neal

-- 
Neal H Walfield
University of Massachusetts at Lowell
neal@walfield.org or neal@cs.uml.edu