[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shared-Memory for the Hurd?

From: Neal H Walfield
Subject: Re: Shared-Memory for the Hurd?
Date: Thu, 30 Nov 2000 23:56:49 -0500
User-agent: Mutt/1.2.5i

Al right, a lot this is stuff that I am not going to comment on as there
are much better people do do this (e.g. Roland).  However, I feel can
make the following comments:

  *  We do not have a netname server.  The hurd's equivalent is the file
     system:  this is where all ports are advertised.  In fact, thinking
     about the file system as a file system is inherently flawed:  it is
     much better to consider it a ``port system.''

     Having said that, what's a file?  Nothing more than a port managed
     by a server waiting for specific messages such as open, seek etc.
     (see /include/hurd/io.defs).

     So, how does one do non-io operations?  The function
     file_name_lookup (/include/hurd.h) returns a file_t which happens
     to be a perfectly valid port that any type of message can be sent
     to (not just io messages; of course, unknown messages will fail,
     however, you get the point).

     Thus, one could write a, e.g. ``bank server,'' that uses a custom
     interface (i.e. a MiG defs file) and settrans it into the file
     system.  Anyone who has a client that can talk the protocol also
     has the ability to use the server.

     To conclude, the shm server would live in, e.g. /servers/shm.
     Inheriting from libtreefs or libdiskfs seems like a good idea
     (enabling you to expose the maps in that directory).  Using trivfs
     is a bad idea (I did it in my procfs:; don't worry, it
     will not be going in CVS).

  *  Getting a task's task port would likely have to be done by
     requesting it from the task itself  (Correct me if I am wrong,
     however, I do not think that it can be requested from anyone except
     the task itself; check /include/hurd/process_request.defs).
     However, shmat, for instance, is wrapped in a libc function, then
     this would be quite transparent.

  *  Servers normally use many demuxers.  That is to say that they may
     implement their own interface and use others from libraries are the
     same time.  For instance:

     demuxer (mach_msg_header_t *inp,
              mach_msg_header_t *outp)
       int my_server (mach_msg_header_t *, mach_msg_header_t *);
       int my_fsys_server (mach_msg_header_t *, mach_msg_header_t *);
       int my_io_server (mach_msg_header_t *, mach_msg_header_t *);

       return (my_server (inp, outp)
               || my_fsys_demuxer (inp, outp)
               || my_io_demuxer (inp, outp)
               || ports_notify_server (inp, outp)
               || ports_interrupt_server (inp, outp))

     or using trivfs to handle all of the fsys and io details:

     demuxer (mach_msg_header_t *inp,
              mach_msg_header_t *outp)
       int trivfs_demuxer (mach_msg_header_t *, mach_msg_header_t *);
       int my_server (mach_msg_header_t *, mach_msg_header_t *);

       return (my_server (inp, outp)
               || trivfs_demuxer (inp, outp))

     Here, you are using trivfs and your own interface.

Hope this helps.

Good luck!

Neal H Walfield
University of Massachusetts at Lowell or

reply via email to

[Prev in Thread] Current Thread [Next in Thread]